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

[Luca Fascione]

Doubling up part of a different reply, in case somebody might find this
useful at some point in the future:
I went and learned about Scheme. Obv the classic reference would be SICP
(Structure and Intepretation of Computer programs)
But as I was reading stuff I stumbled into this pdf by Prof Wilson of
UTexas/Austin which was a resource far more suitable for my needs
(knows how to program in several languages, just need to learn this
language, and be precise about the semantics).
So I wrote a few lines of comment on the book, here they are. If they
should go somewhere specific, let me know if I can help with that.

========
FWIW, I don't recall seeing this reference in your resources about learning
Scheme, so I'll leave a comment here:

Paul Wilson (professor at UTexas, Austin) wrote some notes on Scheme approx
in 1996,
which I thought were extremely well conceived and clear. Certainly more to
the point that sicp
(which is a very interesting approach if you're learning Lisp and sw
engineering at the same time,
but I found did not make good use of my pre-acquired understanding of the
field, and just slowed me down).
I found the book very easy to follow and I loved that he teaches Scheme by
showing a series of gradually
more accurate implementations of scheme, partially in scheme. Also it
teaches Scheme in a way that is
very compatible with other programming languages, that makes it really easy
to keep it straight in one's head
what is new information or different vs what is just the same.
Unfortunately the several available copies online were never completed, so
there are several little bugs,
missing cross-references and other polish-grade features missing. But I
thought the juice of the book is certainly excellent.

It seems Prof Wilson has since retired, and various threads on the internet
indicate folks are unable to reach him.
He seems to have done work in the 90's about garbage collection in
languages.
=========

HTH
Luca

On Tue, Feb 22, 2022 at 10:08 PM Jean Abou Samra <jean@abou-samra.fr> wrote:

> 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
>
>
>
>