Re: On elisp running native

[Stefan Monnier]

> Libgccjit is modeled following a C-like semantic, I guess because plugs
> where a conventional Gcc front-end would.  Consequently I've no reason
> to think this should change but yes... this is not a strong proof I get
> it.

I do expect it to change over time, but that's not what I'm worried
about.  The worry is more the fact that since it's not very widely used
AFAIK there's a higher risk it could be completely dropped at some
point, or superseded by a another API that looks quite different,
e.g. because it plugs into a different stage of the compiler.

None of this is really foreseeable and I'd expect that it wouldn't be
too hard to retarget LIMPLE to another backend (Emacs is pretty popular
within the programming-language research community, so there's a fairly
good chance we could find people able and willing to take on the
challenge if/when it comes up, so I'm confident that it's not too
serious a worry), but it's still part of the things a maintainer has to
worry about.

> And this let me think to Eli's point on windows missing compatibility.
> There's good chance that the reason for this is that libgccjit does use
> dlopen&friends.  Actually these are exactly the features of libgccjit
> infrastructure we do *not* use.
> One could potentially write another final-pass targeting C from LIMPLE.

Generating C code sounds painful to me compared to using libgccjit.
It must be possible to solve the Windows compatibility in a more
direct way.

> I've decided to use libgccjit cause I thought was the nicest technical
> solution.  (admittedly quite GNUish :)

I think it was a sound choice.


        Stefan