Jan Nieuwenhuizen <jann...@gnu.org> writes: > Werner LEMBERG writes: > >>> if we write xxx in LilyPond, this is considered to be a string. I >>> want xxx.yyy.zzz to be a list of strings ("xxx" "yyy" "zzz"). >> >> Go! > > isn't using symbols > > '(xxx yyy zzz) > > more scheme-like, schemonic, schemesque?
Well, this is one area where Lua as an extension language really shines: you don't need to choose between the representation as a string or the representation as an interned symbol because Lua only ever has interned strings. With LilyPond, we already have taken the choice Name -> "Name" and I would consider it rather awkward then if we had Name.other -> (list 'Name 'other) If we are going to choose the symbol representation (which comes at the cost of interning, a cost that is consolidated if you can do enough eq?-like comparisons that are more interesting for scalars), it does not make sense that we use strings for scalars. There is one advantage, though: after xxx = a . b \xxx will not get classified as a MARKUPLIST_IDENTIFIER. However, I have come to the conclusion that both MARKUP_IDENTIFIER as well as MARKUPLIST_IDENTIFIER are a bad idea. One reason is that after xxx = \markup text yyy = \markup \italic text you can use \yyy at top level (because it is a MARKUP_IDENTIFIER) but you can't use \xxx at top level (because it is a STRING_IDENTIFIER). Also after xxx = #'() \xxx is a MARKUPLIST_IDENTIFIER which is plain silly. Yes, even after I remove the classifications of MARKUP_IDENTIFIER and MARKUPLIST_IDENTIFIER, you will be able to use xxx = a . b \xxx at top level, with it being equivalent to \markuplist { a b } and I am not all too enthused about that. You'll also be able to use But \markuplist { a b } _is_ equivalent to #(list "a" "b") so I don't see that I can exactly do much about that if I want to stay reasonably consistent. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel