Han-Wen Nienhuys <[email protected]> writes: > On Wed, May 30, 2012 at 1:08 AM, David Kastrup <[email protected]> wrote: >> Han-Wen Nienhuys <[email protected]> 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 _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
