Re: helper function that should take a list argument doesn't do anything

[Janek Warchoł]

On Fri, Nov 9, 2012 at 10:31 PM, David Kastrup <address@hidden> wrote:
> Janek Warchoł <address@hidden> writes:
>> Well, i don't quite understand why
>>
>> manualBeam =
>> #(define-music-function
>>      (parser location beg-end)
>>      (pair?)
>>    #{
>>      \once \override Beam #'positions = #beg-end
>>    #})
>>
>> works then.
>
> Here #' is inside of LilyPond code, not inside of Scheme code.  #
> switches from LilyPond to Scheme, #{ from Scheme to LilyPond.  # in
> LilyPond is followed by _one_ Scheme expression, like 'positions or like
> beg-end.

ah, ok.

>> But nevermind, you don't have to explain this.  I'd just want to say
>> that from a user's perspective it's very frustrating that i cannot
>> simply copy-and-paste some valid lilypond code into #{ #}
>
> You did not copy and paste valid LilyPond code into #{ #}.  You replaced
> a constant in a constant list by a symbol.  That was not valid outside
> of #{ #}, and it did not became valid inside of it.

Hmm.  Indeed.  Too bad that to make the code valid one has to make it
significantly different.

>>> or quasi-quoting (backtick at the start, evaluated stuff with , before
>>> it), like
>>> #`((alignment-distances . ,distances))
>>> I am not entirely sure that . , is accepted, but if it isn't,
>>> #`((alignment-distances ,@distances))
>>> should do the trick instead (,@ is the list splicing operator, basically
>>> stripping one level of parens when inserting).
>>
>> looks like black magic to me.
>
> ' and ` are explained in pretty much every Lisp or Scheme manual or
> introduction.  Quoting stops Scheme from _evaluating_ an expression, and
> a variable name that is not evaluated is just a symbol without any
> connection to a value.  Only when evaluated (so outside of quoting) is
> the variable and value corresponding to a symbol looked up.

I get the idea of quoting, but all these special characters with
special meanings make me dizzy.  Hmm.

>> and have it work, especially when some similar code works without any
>> problems.  I hope that you know how to improve this situation
>> somewhere in the future.
>
> Absolutely nothing I can do here.  The Scheme interpreter and Scheme
> syntax is a given. [...]

On Fri, Nov 9, 2012 at 10:47 PM, David Kastrup <address@hidden> wrote:
> Actually, if you were using 2.17.6, you could just write
>
> staffdist =
> #(define-music-function (parser location distances)
>                         (list?)
>                         #{
>                           \overrideProperty
>                           Score.NonMusicalPaperColumn.
>                           line-break-system-details.alignment-distances
>                           #distances
>                         #})

Now, that's *precisely* what i call "improving the situation"!  I like
this!  :-)

It may be surprising to you that i didn't try it.  Here's why: i *did*
try running convert-ly on that source file (i wasn't sure whether i'd
get everything right), and it changed

\overrideProperty #"Score.NonMusicalPaperColumn"
#'line-break-system-details #'((alignment-distances . (30)))

into

\overrideProperty
Score.NonMusicalPaperColumn.line-break-system-details
#'((alignment-distances . (30)))

i was surprised to see #'((alignment-distances . (30))), (with hash)
but i didn't have time to investigate.

So, maybe it's a defect in convert-ly?

Anyway, your work is really cool!


On Fri, Nov 9, 2012 at 10:52 PM, David Kastrup <address@hidden> wrote:
> Oh, and I'd use number-list? instead of just list? as a predicate.  The
> more generic your predicate is, the stranger the results for bad uses of
> the function will become.  If LilyPond sees that some predicate is
> wrong, it pulls the plug on the whole function call and substitutes a
> dummy value instead.  Usually much more straightforward than if a value
> gets accepted and problems occur afterwards.

Good point, thanks for the advice :-)

best,
Janek