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
<dthomps...@worcester.edu>
wrote:
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
