[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rfc: next guile 1.8.x release
From: |
Ludovic Courtès |
Subject: |
Re: rfc: next guile 1.8.x release |
Date: |
Mon, 01 Feb 2021 22:49:10 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hi Massimiliano,
Thanks for the needs of TeXmacs this clearly. A few comments below…
Massimiliano Gubinelli <m.gubinelli@gmail.com> skribis:
> all these three features point to weakness of various possible solutions
>
> 1) we do not need a Scheme with a lot of OS interfaces, this duplicate
> functionalities in QT and in our own code. For example all the OS interaction
> is dealt with internal functions (also because TeXmacs has its own virtual
> filesystem). We do not need threads, GMP, etc... all these additional parts
> add bloat without providing real useful functionalities.
Threads and bignums (GMP) were already in 1.8 though, and overall
libguile exposes about as much functionality today than in 1.8. But I
can see that Qt and Guile are “competing” feature-wise.
> 2) it is better for us to have a Scheme which is not picky wrt. encodings.
You can use binary output for when you just want to write bytes (info
"(guile) Binary I/O").
> 3) compiled schemes or schemes without first-class modules are more difficult
> to adapt to our own flavour of scheme coding.
I don’t think this is necessarily the case. Probably you’ll want a
.scm -> .go rule in your makefiles, but that’s about it.
> Currently I'm trying three different routes:
>
> - embed S7 (which is fast, dynamic and minimal and works everywhere)
> - go for Guile 3 (I've still problems with phasing of macro expansion and
> bootstrap of our codebase. Will it work on Windows? Do we really need to
> carry on all the code we do not use?)
> - go for Chez Scheme (like for Guile 3 problems with compilation phases and
> bootstrap of our codebase. I'm more confident it will work on Windows and on
> new architecture, it is more compact than Guile, essentially only the
> compiler, I've still problems with the garbage collector at the level of C++
> interface).
It’s much easier to port from Guile to Guile than from Guile to
something else. :-)
The extra “code you don’t use” in Guile can be seen as a weight, but
longer-term, it could also change the way you approach problems in
TeXmacs and the way you structure it.
Guile 3 can be embedded just like Guile 1, but it supports a much
broader range of applications by being faster and providing more tools.
Ludo’.
- Re: rfc: next guile 1.8.x release,
Ludovic Courtès <=