guile-user
[Top][All Lists]
Advanced

[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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]