Re: "Structure and interpretation" of Scheme (was: Comments wanted on code highlighting in PDF output)

[Jean Abou Samra]

Le 22/02/2022 à 21:46, Luca Fascione a écrit :
> Thanks Jean, this is very useful and informative.
> I'll go read sicp (again, last time was several years ago) and 
> meanwhile experiment with the code you sent me.
>
> As to format, it's not that I don't get it, it's just that straight up 
> interpolation, being more compact, is better for simple things.
> In Scheme you do sprintf, that's ok. It's very cool for the bigger 
> things and I certainly prefer it to C++ streams (in C++ I mean).
> But there too, for complex types being able to overload << is real 
> handy, and if we only had printf() it'd be less fun.



The disadvantage of Scheme is that this is not predefined. The advantage
is that leveraging the power of hygienic macros you can write it yourself.


\version "2.22.1"

#(use-modules (ice-9 match)
              (ice-9 receive))

#(define-macro (interpolate str)
   (let loop ((parts (string->list str))
              (acc '())
              (vals '()))
     (match parts
      (()
       `(format #f
                ,(apply string (reverse! acc))
                . ,(reverse! vals)))
      ((#\{ . rest)
       (receive (part remaining)
         (break! (lambda (c) (eqv? c #\}))
                 rest)
         (let ((sexpr (call-with-input-string
                       (apply string part)
                       read)))
           (loop (cdr remaining)
                 (cons #\a (cons #\~ acc))
                 (cons sexpr vals)))))
      ((char . rest)
       (loop rest
             (cons char acc)
             vals)))))

#(define person "Luca Fascione")
#(define email "l.fascione@gmail.com")

#(display (interpolate "{person} <{email}>"))



> I'll go read, might come back with questions,
> very very grateful in the meantime.
>
> One question back to lilypond:
> as I was saying I theorize it ought to be the fingering to "push up" 
> (in \stemsUp mode) the beaming,
> can I fiddle around and mess with the stem lengths in 
> before-line-break (or after-line-break)?



The length of a beamed stem is determined by the beam (see
the comment above quantized-positions in define-grobs.scm).
In before-line-breaking, there isn't much you can usefully
do since horizontal spacing is not yet known, so the beam
doesn't have a lot information to work with (it does try to
make so-called "pure" estimates but trust me, you don't want
to worry about that). In after-line-breaking, probably, but
it's best to avoid it if you can. after-line-breaking can
introduce dependency on callback order, where the order of
after-line-breaking callbacks setting and reading properties
can affect the correctness of the computation, e.g. if
A sets B.x in after-line-breaking and C needs B.x, it
will go wrong if D.after-line-breaking needs what C wants
B.x for, because D.after-line-breaking can possibly
happen before A.after-line-breaking, and thus read the B.x
property and use it to compute other properties, which get cached,
before B.x has seen its eventual value computed. This tricky
interaction between side effects and the cached property model
is best kept to a minimum -- use after-line-breaking for grob
suicide essentially. Instead, hook in specific callbacks for
the properties you want to change. Have you been pointed at
documentation resources about callbacks yet? There are

https://lilypond.org/doc/v2.22/Documentation/extending/callback-functions

and

https://extending-lilypond.readthedocs.io/en/latest/backend.html#understanding-callbacks

For Beam the story is a little more complicated than basic
callbacks, because there are side effects precisely, but
I'll stop making this reply longer and explain that on the
dedicated thread instead (when I get the time ... sigh).

Best,
Jean