[Top][All Lists]

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

Re: # and $ (was Re: metronome-mark-alignment)

From: David Kastrup
Subject: Re: # and $ (was Re: metronome-mark-alignment)
Date: Wed, 15 Jan 2020 03:00:27 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Aaron Hill <address@hidden> writes:

> On 2020-01-14 5:18 pm, David Kastrup wrote:
>> No, it's that \notes is identical to $notes (apart from the syntax) in
>> that it creates a copy.  So whenever you write \something and do
>> something with it, whatever you do with it will not affect the original
>> stuff stored in the Scheme variable something .  Basically the idea is
>> that you get a copy whenever you reference a variable, but the music
>> passed around in expressions and from one function to another does not
>> get copied unless you need more than one version of it.
> Ah, that makes sense.  Thanks!

The whole #/$/\ thing in its current form has not been around for all
that long and basically started with

commit 2a07e6101abd393b88f22309dcda0c7ed032d85c
Merge: ccebc5251f ccc485525e
Author: David Kastrup <address@hidden>
Date:   Thu Nov 10 15:41:41 2011 +0100

    Let #{ ... #} pass its $ handling to environment cloning and run convert-ly

in version 2.15.18 with a few later amendments.  # was there before
that, but stuff inside of #{ ... #} was rather icky with some different
meaning of $ in there and things like closures not working across
#{ ... #} layers and internals bleeding out whenever something went
wrong, and partly even when it went right.  Similar to like LaTeX bleeds
TeX internals whenever something unexpected happens.

The effects of $ were previously achieved with #(ly:export ...) but the
timing was unpredictable and all # expressions were evaluated early like
now only the $ (and \ ) expressions are.

The whole treatise in the extension guide might read like a complicated
mess but the basic semantics are rather few and work dependably in spite
of significant magic behind the scenes.  Another such thing are music
functions: they were quite limited at one time (no default arguments,
hardwiring of a lot of argument type predicates) and lots of LilyPond
elements these days implemented with music functions were instead
hardwired into the parser, making extensions in LilyPond functionality
require tampering with the parser and recompiling.

Again, the tutorials and documentation make this appear awfully
complicated but it is in a completely different ballpark to what it once

Making that appreciatable will probably require a few generations of
power users just taken some things for granted and learning from the
previous generation and not obsessing in the kind of internals-heavy
detail I tend to fall into when writing documentation.

David Kastrup

reply via email to

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