Hi all, Sorry to be very late/unresponsive to this discussion. As I understand it from reading the email thread, there are several optimizations and changes to SRFI-143 that would make it more performant or inline with the intent of the original SRFI.
I have unfortunately not had much time for scheme in the past couple years, and though I'd love to get back to it eventually, I'd hate to simply sit on the sources for this (or any other eggs I maintain) without allowing for it to evolve. I'd be happy to give Jeremy and anyone else interested in this effort read/write access to the sources at https://git.sr.ht/~dieggsy/srfi-143, or transfer the egg to a different maintainer/repo entirely if that approach is preferred. Diego On Tuesday, February 6th, 2024 at 11:04 AM, felix.winkelm...@bevuta.com <felix.winkelm...@bevuta.com> wrote: > > Aha, so as long as something is wrapped we don't see the same kind of > > inlining. > > > Correct. > > > So what would this look like? I can see fx+ above, which uses > > `chicken:fx+` (prefixed, 2-arity) and foldr to accomplish its multi-arg > > case. Is adding `(inline-file)` to the srfi-143.egg enough for this? I > > suspect partly that the foldr and `(fx+ . args)` form in general is > > going to be hard to optimize out, but perhaps a case-lambda is faster? > > > If we make the operations variadic, the compiler can always > optimize (fx+ ...) into nested calls to dyadic lower-level primitives, > but this applies only to optimizations that the compiler knows about. > For user-defined inlinings, this is currently not possible. > > > Thanks for the really informed reply Felix, this was very helpful in > > understanding what's happening with SRFI-143. I can hopefully start > > crafting a patch for this now. > > > No problem, you are very welcome. > > > cheers, > felix
