Continued on developer list. Jan Nieuwenhuizen <janneke-l...@xs4all.nl> writes:
> As a new contributor/developer, by using a different, and a particular > unfriendly platform for free software development, you are faced with > tackling several difficult problems at once. > > This is only meant as an observation and an apology. Had you be > using a common GNU/Linux platform, installing all dependencies can > be done in a single command that runs in under a minute on my box. It's basically a startup investment. Personally, I have the impression that the current structure of C++ plus Scheme may not be the best setup since Scheme, as the principal script language, does not have the expressive power to work with Lilypond's internal data structures. Taking a comparative look at C/Elisp as used in Emacs, the actual programming is done in Elisp, with C delivering primitives and all access to the Elisp data structures. _If_ Emacs has the principal capabilities for some task, you can code the whole task in Elisp. This does not appear to be doable with Lilypond's Scheme. At least not to the degree where it is the preferred way of thinking about new tasks. At least I don't see how one can whip up new translators or context types just writing Scheme code. For a start from scratch, Lua would be a nice choice: message-passing coroutines (very nice for translators keeping context!), procedural syntax, very portable, fast. And you can learn everything worth knowing about it in few days. I can actually understand and work with the Lua coroutines. In contrast, I am not sure that trying to solve tasks with Scheme continuations in Lilypond will not crash down everything around you. Pretty much all usable Scheme data _structures_, (cons cell, array), have a non-local existence, and just the named handle to them is actually part of the dynamic context. So while continuations may have well-defined semantics on the dynamic context, this does not buy you useful semantics for the structured data you would want to manipulate in this context. Anyway, water down the drawbridge. Would it be feasible to create new listeners/performers/contexts purely in Scheme, by having generic enough C++ listener/performer/context factories that one can fit in everything worth having by using Scheme? Scheme might not be the nicest language for programming, but being able to solve everything important in some application in _one_ language without need of recompiling (or heap management) or language interfacing would be a good step towards recruiting new programmers and solving tasks, partly in form of libraries or packages which can be just used on-demand rather than needing to be compiled in. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
