Re: A question about a scheme function with two input notes

[Jean Abou Samra]

[This is the continuation of
https://lists.gnu.org/archive/html/lilypond-user/2022-12/msg00321.html]


Le 30/12/2022 à 15:07, David Kastrup a écrit :

You conflate "parsing" and "reading".  For #{...#}, there is a
rudimentary scan for # and $

Yes, I know that.

that tends to deliver false positives (which then just don't get evaluated 
later on)

This sounds worrisome. Do you have examples of that happening?

The Scheme reader will throw an error that is incomprehensible
for the user in case this happens and # or $ is followed by something
that is not a valid Scheme expression, so avoiding false positives
is important for correctness.

and may get confused into
overlooking actual positives.  \ offers a lot more potential for getting
this wrong.

It would also make Guile evaluate one (lambda () <variable>) per use
of \ in #{ #}, which I don't believe is costly.

It is.  The optimisation of not putting up closures for most constants
made a relevant performance difference.

I did a test with a file constructed using

$ echo '\version "2.25.1"' > perftest.ly
$ for i in `seq 10000`; do echo '##{ #1 #}' >> perftest.ly; done

I pinned my CPUs at 2GHz (to reduce statistical noise) and measured:

$ hyperfine -m 30 'master/build/out/bin/lilypond perftest.ly'
Benchmark 1: master/build/out/bin/lilypond perftest.ly

  Range (min … max):    1.410 s …  1.498 s    30 runs

$ hyperfine -m 30 'build/out/bin/lilypond perftest.ly'
Benchmark 1: build/out/bin/lilypond perftest.ly

  Range (min … max):    1.539 s …  1.917 s    30 runs


The second one is with the removal of the (or (symbol? expr) ...) test
in parser-ly-from-scheme.scm. The difference is about 0.16s for 10,000
expressions, or 16μs / expression.

Next, I tried this:

$ cat perftest.ly
\version "2.25.1"

#(define-syntax-rule (repeat n body body* ...)
   (let ((n* n))
     (do ((i 0 (1+ i)))
       ((eqv? i n*))
       body body* ...)))

#(repeat 10000
  #{ #1 #})


Result:

$ hyperfine -m 30 -i 'master/build/out/bin/lilypond perftest.ly'
Benchmark 1: master/build/out/bin/lilypond perftest.ly

  Range (min … max):   825.1 ms … 859.3 ms    30 runs

$ hyperfine -m 30 -i 'build/out/bin/lilypond perftest.ly'
Benchmark 1: build/out/bin/lilypond perftest.ly

  Range (min … max):   803.9 ms … 855.5 ms    30 runs



The main difference is that this one executes the reader logic
only once, but evaluates the resulting #{ #} expression many
times (which is closer to what happens with music functions).
This one actually turns out faster without the optimization.
It could be due to the fact that a closure makes parse-scm.cc
bail out before looking up 'compile-scheme-code in the Scheme
option hash table, or to scm_primitive_eval (constant) being
a little slower than ly_call (lambda_returning_constant).

At any rate, the difference is ~2μs / evaluation.

  Time (mean ± σ):      1.446 s ±  0.021 s    [User: 1.395 s, System: 0.107 s]   Time (mean ± σ):      1.609 s ±  0.083 s    [User: 1.551 s, System: 0.108 s]   Time (mean ± σ):     840.7 ms ±   7.9 ms    [User: 793.3 ms, System: 96.9 ms]   Time (mean ± σ):     822.7 ms ±  13.0 ms    [User: 779.4 ms, System: 98.8 ms]

And there is absolutely no associated gain at all since
$identifier will work just fine where scoping is needed.  The gain of
"people using Scheme but not understanding it might by chance escape
trivial errors" is not really a gamechanger.

The Notation manual has a section on what it calls "substitution
functions", which is separate from the section on music functions
in the Extending manual, and I think that is for good reason.
Those "substitution functions" have the form of a define-music-function
where the body is just a #{ ... #}. There is little Scheme "programming"
involved for that apart from cargo-cult copy&pasting of the
define-music-function template and picking type predicates
from the list in the documentation.

I regularly see people (especially on lilypond-user-fr lately)
wondering why returning #{ \book { ... } #} from a music function
does not work, and that sort of thing.

It's LilyPond's kind of "macro" facility, which is accessible to
all users including those who know nothing about Scheme, and
I think there is a point in making it behave more like users
would expect ("just use variables like you always do, except
that the variables change every time").

Jean

OpenPGP_signature
Description: OpenPGP digital signature