Re: Guile foreign object interface

[David Kastrup]

Arne Babenhauserheide <address@hidden> writes:

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

We are talking about Free Software here.  Its programmers and
maintainers are the ones who have to find the energy to take it places.
An entity "Guile" that would be able to assign resources does not really
exist.

My personal impression is that the goals and distribution of the energy
right now does not really scale to match the goals that Guile has been
selected for with respect of its intended and announced roles in the GNU
project a long time ago.

That's unfortunate, but a mismatch of hopes and expectations, even
_announced_ hopes and expectations with what actually turns out to be
possible given finite resources and inspiration, is not malice.

> Yes, it would be a strategy, but not one which inspires much
> confidence in the longterm stability of its goals.

"longterm stability of goals" is a mixed blessing.  The world changes.
Guile 2.0 is not as stable as Guile 1.8 was for use, but the version
numbers don't suggest differently.  I was not involved with LilyPond
when it still worked with Guile versions like 1.4: I assume that was
quite more strenuous.

There is no really established and comfortable migration path from
Guile-1.8 to Guile-2.x but there is not a large corpus of applications
that would make working on such a path in general rewarding or even
worthwhile.

So it is natural that projects are "left behind" as default and one
needs to find the best way to help them over into the future with
explicit and manual effort.  With larger adoption of Guile, the choices
and options here might have looked differently.

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

As I see it, it's not big enough that strategic guarantees can be given.
If you need guarantees, you need to invest into the resources needed for
that.

>> The C++ part [of LilyPond] 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.

Where is "here"?  It would look better, for sure.

-- 
David Kastrup