Re: Some wild considerations and a question

[Jean Abou Samra]

Greetings everybody,


> > - rely only on C++, flex, bison and the extension language.
> >    Eliminating the need for GUB and Python would greatly simplify
> >    porting LilyPond to various environments, including web sites,
> >    phones and tablets.
>
> GUB will be history soon, thanks to the work mainly of Jonas.


Is this true, Jonas? I've heard of scripts you wanted to replace
GUB with, but the last time I read about them, Han-Wen was skeptical
of this idea because GUB had precisely been created to replace the
scripts that were used before and were a nightmare to maintain.

Le 19/10/2020 à 23:57, David Kastrup a écrit :
> Jacques Menu <imj-muzhic@bluewin.ch> writes:
>
> > Hello folks,
> >
> > Sorry, this message is rather long…
> >
> >
> > I’ve been wondering what design decisions would be made, should
> > someone start a project like LilyPond today, with the years-long
> > experience we have behind us in this field.
> >
> > LilyPond can be characterized the following way, please excuse any
> > important omission or error:
> >         - its native syntax is TeX inspired;
> Wrong.  Its earliest implementations used TeX as a backend and continued
> where MPP, a preprocessor for a TeX-based music system let off.  As a
> consequence, early accent input in lyrics was TeX-based (it isn't
> anymore), there is % as a line comment character and \ for introducing a
> control sequence/word.  That's about it.  Very few lexical similarities
> that actually remain these days.  You cannot change syntax on the fly
> (as with TeX), the input is structured and nested and has a grammar.

Well, to me there is still a vague (yes, vague) family resemblance in 
things like

\paper {
  indent = 5\mm
}

I agree that it's become loose over the time.


Jacques, let me add one thing to the list: LilyPond was created with its
own fonts. It also has involved spacing algorithms as well as a workflow
relyingon complex relationship networks between objects.To me that is
the best part of LilyPond (since this is how it manages to produce beautiful
outuput). The less enthusing part is the difficulty to get your head 
around it.

> Half of the wish list makes little sense in relation with what LilyPond
> currently does.  Of course that may mean that what LilyPond currently
> does is not transparent and accessible in sufficient degree to a typical
> user.  Changing that is certainly a worthwhile and partly an ongoing
> project.  I've actually invested a whole lot of work to make the
> programmatic side of LilyPond match the user side of LilyPond better and
> more naturally and get rid of strange things concerning the mapping of
> music expressions to Scheme expressions.

Let me emphasize the point that already surfaced twice in this
thread: the lack of documentation of LilyPond's inner workings.
Learning how to extend LilyPond is, in my experience, a painful
process. To give just an example, Scheme engravers are documented
nowhere. This is in contrast with the otherwise extensive documentation
of every possible type of notation in the Notation Reference.

When/if I get sufficient time for this, I'd very much like to start
mailing list threads to ask questions about the internals of LilyPond,
in order to understand myself first, and have documentation come out of
that. This would benefit both users and the development team, I believe.


Cheers,
Jean