I wrote a very haphazard idl parser during the last lisp game jam. I dont recommend using it for a number of reasons (for one, I don't have experience in designing scheme libraries for reuse) but it was enough to identify a few interesting questions that cropped up then and (during the current game jam) related to method overloading.
https://codeberg.org/dskinner/shields-tyvm/src/branch/main/modules/dom/canvas Until i decided how to handle, i opted for some final hand editing to remove overloads and such. This generates the scheme and a JavaScript object to merge with custom module object when loading the wasm module. I ripped off some other parser pattern doing regex from something I think you wrote somewhere since it was quick and easy to do in context of a jam, but if doing proper i would want to write an actual lexer/parser which is well out of scope for something that could be done during a jam (or maybe there's a bison idl to leverage, but I don't have any experience with that sort of thing). On Mon, May 12, 2025, 9:27 AM Thompson, David <dthomps...@worcester.edu> wrote: > Hi Nala, > > On Tue, May 6, 2025 at 8:36 PM Nala Ginrut <nalagin...@gmail.com> wrote: > > > > Congrats! > > I've read the article about Hoot work with DOM. Will this be an official > library or framework? > > We don't currently have any plans to release a UI framework, but it > would be nice to have libraries that provide essential wrappers around > various web APIs (like DOM). I know from looking at Kotlin JS and > Kotlin Wasm that it's possible to parse the various WebIDL > specifications and automatically generate the Scheme code. The first > step along the way, though, is to build a high-level JS FFI for Hoot > on top of the existing low-level Wasm FFI. Then we need a WebIDL > parser, which I hear is not an easy thing to write but I haven't > looked into the complications. > > Hope this helps give some context, > > - Dave > >
