Thomas Morley <thomasmorle...@gmail.com> writes: > Am Mo., 12. Nov. 2018 um 10:33 Uhr schrieb David Kastrup <d...@gnu.org>: > >> Because it only compiles a reference to the symbol binding of >> make-dummy-markup. That the symbol gets its value later is not a >> problem. That's the reason most of Guilev2's separate >> read/compile+macroexpand/execute phases work fine even when some stuff >> has been compiled already that only gets defined in the "execute" phase: >> the compiler puts in place-holders. When macro expansion does not rely >> on anything defined in the execution phase, that's fine. > > As a lesson in programming: > Iiuc, I could initiate a module and put in (not sure how) something > like (make-undefined-variable)
I am not sure what you try to express here. > and do (variable-set! ...) later. How does macro expansion into the > game? > > Do not reply, if you think it's too off-topic or would need a to > verbose answer. I don't understand. >> If we wanted to be doing that, the markup macro would need to >> postpone more work until later. > > Is there any reason worth the effort (apart from the demonstrated > (begin ...)-example) we would want to do so? Well, it's basically that macros run less synchronously with the rest in Guilev2 compared to Guilev1. That's because they are no longer an entity of their own but rather a variation on syntax transforms. define-markup-command compiles information the markup macro needs for working, but the actual commands recording this information into data structures are only executed at execution rather than macro expansion time. The problem with macro expansion time stuff is that it's very fuzzy what parts of the execution environment may be present and what not. For example, closures are quite likely not to work at expansion time. I am not sure that it's even possible to let the markup macro postpone things in a reasonable manner without obliterating all advantages of using a macro in the first place. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel