lilypond-user
[Top][All Lists]
Advanced

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

Re: Appreciation / Financial support


From: David Kastrup
Subject: Re: Appreciation / Financial support
Date: Thu, 31 May 2012 20:28:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> On Wed, May 30, 2012 at 1:08 AM, David Kastrup <address@hidden> wrote:
>> Han-Wen Nienhuys <address@hidden> writes:
>>
>>> As a consequence, GUILE is not only the language for writing
>>> extensions, but it is the entire platform upon which LilyPond is built
>>> internally too: almost every C++ data structure is manipulated and
>>> passed on as a SCM variable as well, and there is little prospect of
>>> ever being able to separate them.
>>>
>>> If I would re-do it, I would do so in a language where you can write
>>> have the data be inside native classes, and automate generating
>>> methods (setters, getters) and hooks (property callbacks), such that
>>> the core program wouldn't need to be aware of the scripting language.
>>
>> You mean, use Goops?
>
> It would have to be compiled too, for type checking.

Our property assignments are type checked at runtime.

> It would have to be actively maintained too; this was another grave
> error in choosing GUILE.

At the current point of time, it is actively maintained.  Over the total
project history, this was not consistently the case.  Hindsight is
cheap.  Personally, I feel that LilyPond is stronger tied down by C++
than by Scheme.  The one thing that C++ has running for it is speed, and
I am not really convinced that speed would really be affected all that
awfully if the main control was exercised from Scheme rather than C++.

I am currently working on the Goops angle with regard to contexts and
properties.  It should seriously open LilyPond to runtime/session
extension, and one will have to see what the performance impact is.
With the right choice of primitives, I don't think it should be all that
bad.  But it is pointless to discuss before trying.  It is easier to
agree over code than abstractly.

-- 
David Kastrup




reply via email to

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