Re: Curiosity: Microkernel implemented in Guile ?

[Jean Abou Samra <jean@abou-samra.fr>]

>  Le 24 juin 2022 à 09:45, Dr. Arne Babenhauserheide 
> <arne_bab@web.de> a écrit :
> 
>  
>  Jean Abou Samra <jean@abou-samra.fr> writes:
> 
>>>>  Le 24 juin 2022 à 03:13, Nala Ginrut <nalaginrut@gmail.com> a 
>>>> écrit :
>>> 
>>>  Agreed, Guile's design was widened.
> 
>>  Let’s be honest: it wasn’t widened, but shifted. I don’t 
>> think today’s Guile is a good fit for an extension language.
> 
>  Why? Which change caused it to not be good as extension language?



(Also replying to Nala.) On the one hand, you have Guile without 
compiled
bytecode, which is slow to run, and more importantly painful to use
because there are no error locations and often no function names in
error messages. On the other hand, Guile with bytecode takes compilation
time, which is an impediment in applications where it is merely being
used as a language that is practical to use for small extensions to an
existing program, without a need for optimized code. It forces you to
recompile even if you just touched one file, since otherwise it emits
;;; messages about outdated .go files that create noise and/or affect
correctness. The compilation is impractical to set up when interfacing
with C if your main function is on the C side since compiling is started
from the Scheme side. There is no dependency tracking, so you need to
recompile everything whenever you change one file, which does not 
encourage
quick experiments. Bytecode is fussy to integrate in installers: when 
the user
unpacks an archive, you need to ensure that the .go files are unpacked
after the .scm files, otherwise Guile will consider them outdated. I
could list more …

As a developer on one of the main applications extended with Guile in
existence (LilyPond), I would not recommend Guile to anyone looking
for an extension language for a new application today.

Sorry for not exactly bringing enthusiasm to this otherwise interesting
thread.

Best regards,
Jean