Aaron Hill <[email protected]> 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 <[email protected]> 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 was. 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
