Web IDL parser for Guile (was: Re: [ANN] Hoot 0.6.1 released!)

Hi,

Motivated by this discussion I took the chance to have some fun writing 
parsers and
wrote one for Web IDL files in Guile:

https://codeberg.org/rgherdt/webidl-parser

Actually there are two parsers involved. The first reads the 
WebIDL-grammar and generates parts of
the main parser for IDL files. But that's an implementation detail :) . 
See README.md.

For now the result is an s-expression based parse tree, with some 
simplifications to make
working with it easier. I could develop it further to simplify even more 
or help generating
bindings or something like that. If you have ideas of what target 
bindings could look like let me know. Right
now I'm not sure what information of IDL-described APIs are relevant for 
binding generation, so I will
postpone work on it until needed.

I did some tests with IDL references from 
https://github.com/w3c/webref/tree/curated. Most of them
work, with two exceptions due a possible inconsistency in the spec, as 
noted in my README.
Solving it should be trivial though. Some IDLs I got from Gecko are 
problematic, since they have #ifdef
directives and stuff like that, which are not expected by the grammar. 
Adapting the lexer shouldn't be difficult,
just let me know if that's needed.

Have a nice weekend,

Ricardo Herdt


Am 20.05.2025 15:10 schrieb Daniel Skinner:
> As I understand it, type resolution for method dispatching would need 
> to
> happen at runtime. When I benchmarked this for a macro I was 
> experimenting
> with that expanded to type switching between fibers signal and fibers
> channel, I found the cost non-trivial. I don't know enough about the 
> macro
> system to know if that can be accomplished at compile time. Because of
> that, I think giving someone the option to import the 1:1 binding via 
> some
> mechanism is important.
> 
> I took approach of just appending argument arity to function names but 
> I
> would be curious what the distinct argument aritys are that actually 
> have
> overloads. For example, if it is always n=1 then I would be comfortable
> making a not-necessarily-future-proof choice of just specifying the arg
> type as part of the ffi export name. Preferably this entire file 
> doesn't
> require hand editing.
> 
> Additionally, methods need to be bound as well for externs from the
> currently parsed idl; this isn't being done at all currently.
> 
> From there, I would see a hand edited file that provided a nicer api 
> that
> can expose and rename however and provide runtime method overloading if
> desired. This part becomes more artistic and higher variety in opinion.
> 
> For example, fill-style has overloads for rgba string and for gradient
> object. Some options might be:
> 
> * provide an overloaded fill-style
> * provide fill-style-string and fill-style-gradient
> * provide the idea of (color arg) and color just knows how to apply 
> itself
> as a (fill-style) under the correct syntactic context so none of the 
> normal
> stuff is necessarily exposed
> 
> None of those choices are necessarily correct so I would consider it a 
> goal
> to have the ffi.scm generated to not require hand editing based on
> conventions informed by a little up front research so that people might 
> be
> able to pursue their own ideas separate to whatever nicer api is built 
> on
> top of ffi.scm
> 
> On Mon, May 19, 2025, 1:25 PM Thompson, David 
> <[email protected]>
> wrote:
> 
>> Hey Daniel,
>> 
>> On Mon, May 12, 2025 at 1:48 PM Daniel Skinner <[email protected]> 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
>>