Re: Guile foreign object interface

[Arne Babenhauserheide]

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

> 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,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

signature.asc
Description: PGP signature