lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GLISS] non-timed or non-musical events "z" "y"


From: Graham Percival
Subject: Re: [GLISS] non-timed or non-musical events "z" "y"
Date: Sat, 22 Sep 2012 15:07:57 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Sep 14, 2012 at 12:00:49AM +0200, David Kastrup wrote:
> Graham Percival <address@hidden> writes:
> 
> >> How about considering how they are supposed to translate to and from
> >> Scheme?
> >
> > Woah.  Is the syntax supposed to support translating from scheme
> > to .ly ?!
> 
> Reality check.  Everything you do needs a representation in Scheme.

Of course.  I'm questioning your "to and **from**" sentence
(emphasis added).

Basically, if we have
  A:= c4-\something{ s4\< s s\!\> s\! }
  B:= << c4 {s4\< s s\!\> s\!} >>
  C:= some scheme

we already have an unambiguous translation from B->C.  If we have
an unambiguous translation from A->B (by assumption), then we have
an unambiguous translation from A->C.  This part works (again,
with the assumption of A->B).

However, we clearly do not have a translation C->A vs. C->B.  Is
this a problem?  Do we need to transate **from** scheme to a
*particular* bit of ly language?


> > I'm not fond of prefix functions; that's why I didn't care for
> > your \at function.
> 
> LilyPond does not have anything but prefix functions.  Event functions
> don't get to see the preceding expression as an argument: they just get
> attached to them when LilyPond sweeps up the whole kaboodle, but they
> don't get to operate on them.  It is rather the job of the preceding
> expression itself to collect them usefully, so that is again a prefix
> operation.

So the fact that in
  c4\p d4
the \p applies to the c4 is due to the design of the c4
expression?


> Take a look at the \tempo command.  Everybody and their dog tells me
> that this is just what a musician wants in syntax.  Whenever I do
> significant work on the parser, \tempo pitches in with a few dozen
> reduce/reduce errors and takes an hour of extra time.

I have no problem with splitting \tempo into a \tempo_bpm and
\tempoMark command.  Or perhaps it would be better to just use
\mark, and add markup functions which mimic the "text" parts of
the existing \tempo command (if they don't already exist, which
they probably do).

- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]