Hey Daniel, On Mon, May 12, 2025 at 1:48 PM Daniel Skinner <dan...@dasa.cc> wrote: > > 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).
Thanks for sharing this! Glad to know you have already been experimenting with WebIDL + Hoot. Seems like a good start to me! Method overloading is a tricky thing. We'd either have to embrace it and generate a single procedure that bakes in all the type dispatching or somehow generate one distinctly named procedure per overload. For the latter case, you'd probably want to hand edit the generated names. On the WebAssembly side, you'd need to generate a function per overload anyway because functions do not support variable length argument lists. Without thinking too hard about it, I think I could live with some amount of hand editing because compiling WebIDL is mostly a one-time process to reduce tedious work. - Dave
