lilypond-devel
[Top][All Lists]
Advanced

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

Re: guilev2 problem (user-markup-command sometimes not accepted)


From: Thomas Morley
Subject: Re: guilev2 problem (user-markup-command sometimes not accepted)
Date: Mon, 12 Nov 2018 11:45:13 +0100

Am Mo., 12. Nov. 2018 um 10:33 Uhr schrieb David Kastrup <address@hidden>:
>
> Thomas Morley <address@hidden> writes:
>
> > Am So., 11. Nov. 2018 um 21:14 Uhr schrieb David Kastrup <address@hidden>:
> >>
> >> David Kastrup <address@hidden> writes:
> >>
> >> > I think that Guilev2 may do the syntax form expansion concerning
> >> > "markup" before executing the define-markup-command when both are
> >> > contained in one begin form.  Macros are executed a bit differently in
> >> > Guilev2 than in Guilev1.
> >
> > Followup questions:
> > Is this fixable?
>
> Unlikely.  Macro expansion and execution are different phases in
> Guilev2.
>
> > If yes, it is worth the effort?
> >
> >> The markup macro is a piece of crock anyway.  Use
> >> (display-scheme-music (make-dummy-markup "foo"))
> >> or
> >> (display-scheme-music #{ \markup \dummy foo #})
> >> here to get out of that predicament.
> >
> > Yep, works.
> > Part of the problem is I have only a vague guess where in our source
> > which syntax possibility regarding markup is made available.
> >
> > I _think_ 'make-dummy-markup' and 'dummy-markup' is done with
> > (defmacro-public define-markup-command ...) from markup-macros,scm.
>
> Yes.
>







> > Though not sure about (markup #:dummy ...), where is it made
> > available?
>
> The markup macro is defined at the top of scm/markup.scm .  It
> references the various markup predicates.

Well, I overlooked it.
I had expected to find the various macros related to markup in
markup-macros.scm.
Any need to have the 'markup'.macro in markup.scm rather than in
markup-macros.scm?

> Guilev2 expands it at a time
> in your example where those predicates are not yet defined.
>
> > The error "Not a markup command: ..." seems to come from (define
> > (compile-markup-expression expr) ...) triggered by (define
> > (lookup-markup-command-aux symbol) ...) which looks at
> > (current-module).
> > As far as I can tell 'lookup-markup-command-aux' searches the module
> > for 'dummy-markup', without success.
> >
> > So the guess is for guilev2 'define-markup-command ' is not done for
> > 'dummy', when 'lookup-markup-command-aux' starts?
> > Why does 'make-dummy-markup' work then?
>
> 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) 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.

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


Thanks,
  Harm



reply via email to

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