[prev in list] [next in list] [prev in thread] [next in thread]
List: lilypond-user
Subject: Re: Appreciation / Financial support
From: David Kastrup <dak () gnu ! org>
Date: 2012-05-31 18:28:07
Message-ID: 877gvsryrs.fsf () fencepost ! gnu ! org
[Download RAW message or body]
Han-Wen Nienhuys <hanwenn@gmail.com> writes:
> On Wed, May 30, 2012 at 1:08 AM, David Kastrup <dak@gnu.org> wrote:
>> Han-Wen Nienhuys <hanwenn@gmail.com> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic