[Top][All Lists]
[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
- Re: [GLISS] non-timed or non-musical events "z" "y", (continued)
- Re: [GLISS] non-timed or non-musical events "z" "y", David Kastrup, 2012/09/13
- Re: [GLISS] non-timed or non-musical events "z" "y", Werner LEMBERG, 2012/09/13
- Re: [GLISS] non-timed or non-musical events "z" "y", David Kastrup, 2012/09/13
- Re: [GLISS] non-timed or non-musical events "z" "y", Graham Percival, 2012/09/13
- Re: [GLISS] non-timed or non-musical events "z" "y", David Kastrup, 2012/09/13
- Re: [GLISS] non-timed or non-musical events "z" "y", Han-Wen Nienhuys, 2012/09/13
- Re: [GLISS] non-timed or non-musical events "z" "y", Graham Percival, 2012/09/14
- Re: [GLISS] non-timed or non-musical events "z" "y", David Kastrup, 2012/09/14
- Re: [GLISS] non-timed or non-musical events "z" "y", Werner LEMBERG, 2012/09/14
- Re: [GLISS] non-timed or non-musical events "z" "y", David Kastrup, 2012/09/16
- Re: [GLISS] non-timed or non-musical events "z" "y",
Graham Percival <=
- Re: [GLISS] non-timed or non-musical events "z" "y", Jay Anderson, 2012/09/22
- Re: [GLISS] non-timed or non-musical events "z" "y", David Kastrup, 2012/09/22
- Re: [GLISS] non-timed or non-musical events "z" "y", Francisco Vila, 2012/09/23
- Re: [GLISS] non-timed or non-musical events "z" "y", James, 2012/09/23
- Re: [GLISS] non-timed or non-musical events "z" "y", Joseph Rushton Wakeling, 2012/09/23
- Re: [GLISS] non-timed or non-musical events "z" "y", David Kastrup, 2012/09/23
- Re: [GLISS] non-timed or non-musical events "z" "y", Joseph Rushton Wakeling, 2012/09/24
- Re: [GLISS] non-timed or non-musical events "z" "y", Werner LEMBERG, 2012/09/13
- Re: [GLISS] non-timed or non-musical events "z" "y", David Kastrup, 2012/09/14
- Re: [GLISS] non-timed or non-musical events "z" "y", David Kastrup, 2012/09/26