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

Just a cursory glance over the lexer and this looks proper. Hopefully I can
make time to play with the parser results over the weekend.

Thanks!

On Fri, Jun 6, 2025, 2:36 PM Ricardo G. Herdt <[email protected]> wrote:

> 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
> >>
>