lilypond-devel
[Top][All Lists]
Advanced

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

Re: referencing hash key with music symbol


From: Jeffery Shivers
Subject: Re: referencing hash key with music symbol
Date: Sat, 9 Jul 2016 19:57:13 -0400

>
> So you now state that the predicate is
> "symbol-list-or-music?" and a symbol does _not_, I repeat _not_ satisfy
> that predicate.  So it is more than likely that you are _not_ looking at
> 'Slur here but rather at '(Slur), namely indeed a symbol _list_.


No, I had already accounted for that. There were no 'wrong type' errors -
but I *was* getting a variation of other errors from just ever-so-slightly
changing the procedure around, so narrowing any of it down wasn't really
possible. Well, or so it seemed.

The problem turned out to be a syntax-ish issue in the lilypond code block
that happened to use the function. LP oddly wasn't pointing to that line
most times though. In any case, my original hope was that I was missing
some kind of obvious/weird rule about using symbols (or symbol lists..) in
lilypond that perhaps could have been answered without anyone feeling the
need to fully dissect my message, but I guess you can't win 'em all. ;-)

On Sat, Jul 9, 2016 at 1:34 PM, David Kastrup <address@hidden> wrote:

> Jeffery Shivers <address@hidden> writes:
>
> > ​David​, thanks for your response.
> >
> >> #(define mytable (make-hash-table))
> >> >
> >> > #(hash-set! mytable 'Slur slurDashed)
> >> >
> >> >
> >> > \score {
> >> >
> >> >     \new Staff {
> >> >
> >> >         #(let ((func (hash-ref mytable 'Slur)))
> >> >
> >> >             #{
> >> >
> >> >                 #func f'( g')
> >> >
> >> >             #})
> >> >
> >> >     }
> >> >
> >> > }
> >> Are you sure this works?
> >
> >
> > I have no idea what you're expecting, but yes. Entirely.
>
> Sorry, that was a first edit left in place: I had to double-check that
> \slurDashed was not a music function but a music identifier.
>
> >> And when LilyPond's opinion conflicts with that, your opinion
> >> does not carry the day when you want LilyPond to act on it.
> >
> >
> > Preach.
> >
> > "argument that the symbol satisfies" is gibberish
> >
> >
> > Not sure if this was a comment more on programming semantics or actual
> > sense; in either case, that's unfair. Regardless of what \criticalRemark
> > fully does, it takes some number of arguments: the one of them that 'Slur
> > satisfies in the context of the example I provided (regardless of
> whatever
> > else could be happening with the function) is a `symbol-list-or-music?`
> > predicate.
>
> That is not an "argument that the symbol satisfies" but rather "the
> symbol satisfies the argument predicate".  I repeat: you cannot just
> describe things in vague terms when all that you write is the
> description.  So you now state that the predicate is
> "symbol-list-or-music?" and a symbol does _not_, I repeat _not_ satisfy
> that predicate.  So it is more than likely that you are _not_ looking at
> 'Slur here but rather at '(Slur), namely indeed a symbol _list_.
>
> Your predicate should match your desired use cases.
> >
> > Maybe 4:00am should be my new cutoff time for asking for help.. The
> > following snippet (which I admit could have been provided initially -
> > and that would have saved us all this pointless conversation) does
> > work, and so tells me the question asked here did not need to be asked
> > in the first place.
>
> Depends on what you want the function to be good for.  There are good
> and valid reasons for accepting symbol lists as function arguments (see,
> for example, overrideProperty).  Whether this is one of those cases is
> something a minimal example will indeed rarely tell since multiple
> symbols tend to be used only in more complex (and thus non-minimal)
> cases.
>
> But yes, it would have made it possible to actually diagnose your
> problem.  When writing just "Slur", LilyPond can turn this, depending on
> current mode and the argument predicate, into a string, a symbol, a
> symbol list or a lyric syllable (and I possibly forgot something here).
> That makes it possible to write a lot of stuff in a rather natural
> manner, but it also means that you need to pick suitable predicates for
> matching the expectations of your code.
>
> Particularly when you don't understand why something isn't working, only
> describing in your own words what you think LilyPond must be seeing,
> without double-checking (or posting) at least the error messages is
> going to require a whole lot of second-guessing.  If you don't recognize
> the problem, it is unlikely that your high-level description will
> contain a pointer to what goes wrong.
>
> --
> David Kastrup
>


reply via email to

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