guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Curiosity: Microkernel implemented in Guile ?


From: Nala Ginrut
Subject: Re: Curiosity: Microkernel implemented in Guile ?
Date: Sun, 26 Jun 2022 18:37:31 +0800

OK, let's face the issues, I encountered similar problems like what you
described.

1. To avoid the irritating compiling message, I have to use parameters to
rebind current-error-port.

2. Sometimes folks compile the Guile code and installed it in a wrong load
path, so when you run it, it will auto compile everthing again.

3. The debug information seems broken for a long time, it's not good to
trace the error. But I don't think it's because of the design of Guile,
it's broken when Guile had upgraded the VM implementation. It was good
before that.

4. For quick experiment attempt you described, I confess I have no better
idea. But it's good to hear your experiences.

Best regaeds.


On Sat, Jun 25, 2022, 22:36 Jean Abou Samra <jean@abou-samra.fr> wrote:

>
>
> >  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
>
>
>
>
>
>
>


reply via email to

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