Re: preliminary GLISS discussions

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Thu, Aug 30, 2012 at 9:02 AM, Graham Percival
> <address@hidden> wrote:
>> That's why I wanted to make sure that proposals are in "good
>> shape" before discussing them on the main list.  But there seems
>> to be general consensus that we want to discuss all proposals here
>> anyway, so I can roll with that.
>>
>>> For example, I understand that requiring '-' for every post event
>>> would simplify the parser. At the same time, it is not clear to me
>>> what benefit simplifying that part of the parser will bring us.
>>
>> - people writing automated lilypond importers or exporters
>>   (including algorithmic composition)
>> - people reading/writing lilypond scores manually (see below).
>
> Automated writers are a non-argument: exporters can choose to prepend
> the '-' always.
>
> Automated readers - I am not very convinced about this. Reading .ly
> correctly implies having a complete scheme interpreter at your
> disposal.  Or are we limiting ourselves to cases where there is no
> escaped scheme (including any escapes that are present when using
> identifiers) ?

Actually, at the Waltrop meeting I demonstrated using something like

bk = #{ \book { \include "sourcefile.ly" } #}

which leaves you with music, headers, and similar stuff.  Music
functions have already done their work then.  This is, of course, not
feasible for more complex scores, but one can just redefine the various
processing hooks and run LilyPond directly on the files to get at the
actual data to be typeset, foregoing most of the Scheme complications
(of course, you can't expect to interpret details like user-defined
context overrides and engravers, though they will be part of the data
structures as well).

Using LilyPond for reading LilyPond files (as opposed to parsers written
in Python) has the advantage of being rather thorough, and the
disadvantage to be tied into a single version (not all that helpful if
you want to write something like convert-ly).

> Manual writers: can we make up our minds here? I've always been
> against frivolous syntax for shortcuts (one example in particular is
> the "q" for repetition).  Why do we put in "q" for users to save some
> keystrokes, and at the time propose to require a mostly redundant '-'
> in front of zillions of postevents?

That was pretty much my reaction, both regarding q as well as this
proposal.  However, "mostly redundant" is only a valid sentiment for the
first part of the proposal as Janek wanted to quite differentiate the
meaning depending on whether - was added or not, having both a postevent
meaning as well as a seemingly orthogonal non-postevent meaning (in the
various examples he made, the proposed non-postevent meanings were
different enough to actually require a per-case definition rather than
being derivable from the post-event meaning).

-- 
David Kastrup