[Top][All Lists]

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

Re: Guile foreign object interface

From: Arne Babenhauserheide
Subject: Re: Guile foreign object interface
Date: Sat, 11 Mar 2017 17:31:19 +0100
User-agent: mu4e 0.9.16; emacs 25.1.1

David Kastrup <address@hidden> writes:

> Arne Babenhauserheide <address@hidden> writes:
>> PS: Just saying "it’s a scripting language now" will not cut it.
> With an implied "rather than an extension language": that _would_ cut
> it.  It would imply LilyPond having to work with a fork of Guile-1.8,
> and possibly encourage active maintenance of such a fork independently
> of LilyPond.  It would also put a clear perspective on Emacs-Guile's
> future, namely none.

It would also show that Guile leaves people behind who choose it. Yes,
it would be a strategy, but not one which inspires much confidence in
the longterm stability of its goals.

>> People who adopt Guile now will have to ask whether it will stay a
>> viable option as scripting language, and they will again look at
>> Lilypond to see whether Guile-as-an-option kept its promises.
> Well, Guile is not an "option" in LilyPond,

I did not mean it as option in Lilypond. I meant it as strategic

> and it is clearly more than just an extension language (as I believe
> it is designed to be in GnuCash).  It's more like its programming
> paradigm.  The C++ part is structured to fit in with Guile.  But this
> sort of 1:1 relation is much more tenuous with Guile-2 since the
> interaction costs have become quite larger.  So it works better for
> either applications that have just a little Guile, or for applications
> that have little else.

I hope that will change again. I’m sure most people here want Lilypond
to be faster with Guile 2.x than with Guile 1.8.

Best wishes,
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Attachment: signature.asc
Description: PGP signature

reply via email to

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