Re: Guile foreign object interface

[David Kastrup]

Arne Babenhauserheide <address@hidden> writes:

> David Kastrup writes:
>
>> To a certain degree one can chalk this off as "growing pains" that
>> long-standing users have to shoulder, at least when working with
>> development rather than stable versions.
>
> I’d like to chime in here. When looking at the prospects of larger Guile
> adoption, I think that Lilypond is a critical component: It is an early
> adopter and the absolute top tool in the niche it took.
>
> People thinking about adopting Guile will ask themselves "is this a
> viable longterm option?". They will then look at Lilypond, the prime
> example of a highly successful Guile-using tool.
>
> So this is not just a growing pain for Lilypond. It is a critical issue
> for Guile.
>
> Both communities, Lilypond and Guile, need Lilypond-Guile2 to work well.
>
> And given the speed I see from Guile 2.1.7 at other tasks, there should
> be ways to make Lilypond-Guile2.2 outperform Lilypond-Guile1.8
> significantly.
>
> Best wishes,
> Arne
>
> 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 be a valid and clear option to pursue.  In some respects, that
is where I see Guile drifting, but it appears to me as something
happening more by accident than design and it is not apparently what its
developers actively _chose_ for Guile's future.

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

-- 
David Kastrup