On Thursday 21 December 2006 15:01, Han-Wen Nienhuys wrote:
> Erik Sandberg escreveu:
> > On Thursday 21 December 2006 12:55, Han-Wen Nienhuys wrote:
> >> Erik Sandberg escreveu:
> >>> BTW, in this case it may be good to register the fraction as its own
> >>> argument type, so \tuplets and \tuplet are generic music functions,
> >>> both with signature
> >>> (tuplet-fraction? music?)
> >>
> >> it would be cool if we could pull this off, that would make \time
> >> generic too.
> >
> > Hm, if we do this together with the 2:3 syntax change, then we would
> > suddenly be able to write:
> > \time 4:3
> > which would be equivalent to:
> > \time 3/4
> > That's a bit confusing.
> >
> > BTW, if we start adding new types, it would be nice to create a new
> > 'type' data structure, to be used in function signatures. The data
> > structure would contain a type-checking predicate, a name (displayed when
> > type-check fails), and perhaps a type ID for the lexer. This would allow
> > more complex types, e.g. 'sequential music', 'single note or chord',
> > 'pair of numbers' (as in #'(1 . 3)), etc; perhaps the system could be
> > used for
> > define-context-properties.scm as well.
>
> be careful. If you introduce type, you will have to introduce subtypes as
> well: seq-music is a subtype of music. Before you know, we'll be writing a
> type inference engine.
I don't understand. Why isn't is sufficient to let typechecking be carried out
by an arbitrary user-defined turing-complete function? music and seq-music
don't need to share any code, the type inference engine machinery would be
voluntary AFAICS (seq-music's predicate would check that the object is a
Music and that it's of type SequentialMusic, and seq-music's name would
be "sequential music").
And when it comes to parser, seq-music can just tell it that it expects a
Music, and typecheck after parsing. Alternatively, we create an independent
rule for seq-music which only accepts stuff on the form { }. This rule will
exist independently of the generic Music rule.
Or did I miss something?
--
Erik
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
