[Top][All Lists]
[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
- Re: Appreciation / Financial support, (continued)
- Re: Appreciation / Financial support, David Kastrup, 2012/05/29
- Re: Appreciation / Financial support, Janek WarchoĊ, 2012/05/29
- Re: Appreciation / Financial support, Nils, 2012/05/29
- Re: Appreciation / Financial support, David Kastrup, 2012/05/29
- Re: Appreciation / Financial support, Henning Hraban Ramm, 2012/05/29
- Re: Appreciation / Financial support, Marc Hohl, 2012/05/30
- Re: Appreciation / Financial support, Henning Hraban Ramm, 2012/05/30
- Re: Appreciation / Financial support, Han-Wen Nienhuys, 2012/05/29
- Re: Appreciation / Financial support, David Kastrup, 2012/05/30
- Re: Appreciation / Financial support, Han-Wen Nienhuys, 2012/05/31
- Re: Appreciation / Financial support,
David Kastrup <=
- Re: Appreciation / Financial support, address@hidden, 2012/05/30
- Re: Appreciation / Financial support, David Kastrup, 2012/05/30
- Re: Appreciation / Financial support, Bernardo Barros, 2012/05/30
- Re: Appreciation / Financial support, Bernardo Barros, 2012/05/30
- Re: Appreciation / Financial support, Henning Hraban Ramm, 2012/05/30
- Re: Appreciation / Financial support, David Kastrup, 2012/05/30
- Re: Appreciation / Financial support, Henning Hraban Ramm, 2012/05/31
- Re: Appreciation / Financial support, David Kastrup, 2012/05/31
- [OT] was "Re: Appreciation / Financial support", Kieren MacMillan, 2012/05/31
- Re: [OT] was "Re: Appreciation / Financial support", David Kastrup, 2012/05/31