Re: Constructive Criticism and a Question

[stk]

> > > . . . Note also that the tupletSequence
> > > function  would be implemented entirely in Scheme . . .

I'm not very fluent in Scheme, so this is a naive question.

I presume that ratios like 3:2 (or 2/3) could be made into some kind of
object type (possibly a "moment").  So I could imagine that it would be
possible to write a Scheme function definition to cover a syntax like

   \tupletSequence m:n #'( {...} {...} ... )

where the first argument is a moment and the second is a list of literal
music expressions.  (And I suppose I'm too optimistic about that syntax;
probably those {...} would have to be sprinkled with # or $ or other
spices.)  But there are some questions:

1) I don't see how this could accommodate the case where one of the music
expressions *were* a variable reference (\var) or *contained* a variable
reference.

2) Because the syntax      \tupletSequence m:n { {...} {...} }
is "nicer", it would be good if it could be written that way, but then the
second argument would not be a standard Scheme entity, so I don't see how
Scheme could handle it at all.

I don't really want you to explain to me how the tupletSequence function
would be written in Scheme, as I think that that would wind up being an
exceedingly long answer. My question is only this:  with your knowledge of
Scheme, is it clear to you that difficulties (1) & (2) are handleable?
Can tupletSequence really be defined in pure Scheme, as long as the parser
is modified to recognize the object m:n or n/m (so that there would exist
a type-verification-name for the object m:n for use in defining Scheme
functions)?

-- Tom

*************************************************************

On Sat, 6 Jan 2007, Erik Sandberg wrote:

> On Friday 05 January 2007 22:53, address@hidden wrote:
> > > . . . The { m1 m2 m3 } syntax is used for repeat alternatives
> > > already, and the meaning is very clear: Each music expression between the
> > > outer { } is a separate argument. Note also that the tupletSequence
> > > function  would be implemented entirely in Scheme . . .
> > >
> > > >    { {g8 f e} \seq {b8 a g} }
> > >
> > > \tuplet {g f e} \tuplet \seq \tuplet {b a g}
> > >
> > > >    {{c d e} {{f g} a} b c}
> > >
> > > \tuplet {c d e} \tuplet {{f g} a} \tuplet b \tuplet c
> >
> > OK.  Thank you for clarifying that.  I understand, from your original
> > remarks, that (here) you have written just "\tuplet" in the interest of
> > brevity, and that the full form would be
> >
> >    \tupletSequence 3:2 {{c d e} {{f g} a} b c}
> > meaning
> >    \tuplet 3:2 {c d e} \tuplet 3:2 {{f g} a} \tuplet 3:2 b \tuplet 3:2 c
>
> yes, that's right.
>
> > which implies the following things:
> >
> > a) tupletSequence is a Scheme function which just breaks up its
> > subexpressions naively, without any semantic analysis.
> >
> > b) \tuplet is a real LilyPond function; it is identical to \times,
> > except that the notation 3:2 (meaning 2/3) would be allowed.
> >
> > c) People would have to write \tupletSequence m:n { {...} {...} },
> > not \tuplet m:n { {...} {...} }.
>
> yep, this is right (thanks for expressing it clearly).
>
> > d) Any semantic errors in the subexpressions would be reported by the
> > \tuplet function, not by the \tupletSequence Scheme function.
>
> technically this is not correct (the \tuplet function doesn't detect semantic
> errors), but in principle you're right (\tuplet and \tupletSequence actually
> only create Music data structures, without performing semantic analysis;
> most 'semantic errors' are detected either when these data structures are
> further processed into typeset scores, or by the parser before the function
> applications)
>
> --
> Erik