Re: [ANN] Hoot 0.6.1 released!

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
>