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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Thomas Morley-2
Hi,

the following works fine with current master (and every tested lily-version):
#(begin
 (define-markup-command (dummy layout props arg) (markup?)
   (interpret-markup layout props arg))
 (display-scheme-music (markup #:dummy "foo")))
#(display "whatever")

With guilev2 I get:
$ lilypond-git-guile-2.2 atest-85.ly
GNU LilyPond 2.21.0
Processing `atest-85.ly'
Parsing...
fatal error: Not a markup command: dummy

Not even the later 'display' is reached.

Though this works:
#(define-markup-command (dummy layout props arg) (markup?)
   (interpret-markup layout props arg)
#(display-scheme-music (markup #:dummy "foo")))
#(display "whatever")


I'm not able to track this down, anyone with some insight?


Thanks,
  Harm

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Thomas Morley <[hidden email]> writes:

> Hi,
>
> the following works fine with current master (and every tested lily-version):
> #(begin
>  (define-markup-command (dummy layout props arg) (markup?)
>    (interpret-markup layout props arg))
>  (display-scheme-music (markup #:dummy "foo")))
> #(display "whatever")
>
> With guilev2 I get:
> $ lilypond-git-guile-2.2 atest-85.ly
> GNU LilyPond 2.21.0
> Processing `atest-85.ly'
> Parsing...
> fatal error: Not a markup command: dummy
>
> Not even the later 'display' is reached.
>
> Though this works:
> #(define-markup-command (dummy layout props arg) (markup?)
>    (interpret-markup layout props arg)
> #(display-scheme-music (markup #:dummy "foo")))
> #(display "whatever")
>
>
> I'm not able to track this down, anyone with some insight?

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.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
David Kastrup <[hidden email]> writes:

> Thomas Morley <[hidden email]> writes:
>
>> Hi,
>>
>> the following works fine with current master (and every tested lily-version):
>> #(begin
>>  (define-markup-command (dummy layout props arg) (markup?)
>>    (interpret-markup layout props arg))
>>  (display-scheme-music (markup #:dummy "foo")))
>> #(display "whatever")
>>
>> With guilev2 I get:
>> $ lilypond-git-guile-2.2 atest-85.ly
>> GNU LilyPond 2.21.0
>> Processing `atest-85.ly'
>> Parsing...
>> fatal error: Not a markup command: dummy
>>
>> Not even the later 'display' is reached.
>>
>> Though this works:
>> #(define-markup-command (dummy layout props arg) (markup?)
>>    (interpret-markup layout props arg)
>> #(display-scheme-music (markup #:dummy "foo")))
>> #(display "whatever")
>>
>>
>> I'm not able to track this down, anyone with some insight?
>
> 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.

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.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Thomas Morley-2
Am So., 11. Nov. 2018 um 21:14 Uhr schrieb David Kastrup <[hidden email]>:

>
> David Kastrup <[hidden email]> writes:
>
> > Thomas Morley <[hidden email]> writes:
> >
> >> Hi,
> >>
> >> the following works fine with current master (and every tested lily-version):
> >> #(begin
> >>  (define-markup-command (dummy layout props arg) (markup?)
> >>    (interpret-markup layout props arg))
> >>  (display-scheme-music (markup #:dummy "foo")))
> >> #(display "whatever")
> >>
> >> With guilev2 I get:
> >> $ lilypond-git-guile-2.2 atest-85.ly
> >> GNU LilyPond 2.21.0
> >> Processing `atest-85.ly'
> >> Parsing...
> >> fatal error: Not a markup command: dummy
> >>
> >> Not even the later 'display' is reached.
> >>
> >> Though this works:
> >> #(define-markup-command (dummy layout props arg) (markup?)
> >>    (interpret-markup layout props arg)
> >> #(display-scheme-music (markup #:dummy "foo")))
> >> #(display "whatever")
> >>
> >>
> >> I'm not able to track this down, anyone with some insight?
> >
> > 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?
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.

Though not sure about (markup #:dummy ...), where is it made available?

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?


Sorry if this message is a bit mazily. I _am_ confused ...


Cheers,
  Harm

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Thomas Morley <[hidden email]> writes:

> Am So., 11. Nov. 2018 um 21:14 Uhr schrieb David Kastrup <[hidden email]>:
>>
>> David Kastrup <[hidden email]> 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.  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.

If we wanted to be doing that, the markup macro would need to postpone
more work until later.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Thomas Morley-2
Am Mo., 12. Nov. 2018 um 10:33 Uhr schrieb David Kastrup <[hidden email]>:

>
> Thomas Morley <[hidden email]> writes:
>
> > Am So., 11. Nov. 2018 um 21:14 Uhr schrieb David Kastrup <[hidden email]>:
> >>
> >> David Kastrup <[hidden email]> 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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Thomas Morley <[hidden email]> writes:

> Am Mo., 12. Nov. 2018 um 10:33 Uhr schrieb David Kastrup <[hidden email]>:
>
>> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Thomas Morley-2
Am Mo., 12. Nov. 2018 um 12:22 Uhr schrieb David Kastrup <[hidden email]>:

>
> Thomas Morley <[hidden email]> writes:
>
> > Am Mo., 12. Nov. 2018 um 10:33 Uhr schrieb David Kastrup <[hidden email]>:
> >
> >> 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.

Once I've cleared my mind so that I know exactly what I want to ask
(and how) I'll come back to this.

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

Many thanks for the detailed explanations.
I'm afraid it will take some time for me to understand.

Thanks,
  Harm

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Thomas Morley <[hidden email]> writes:

> Am Mo., 12. Nov. 2018 um 12:22 Uhr schrieb David Kastrup <[hidden email]>:
>>
>> 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.
>
> Many thanks for the detailed explanations.
> I'm afraid it will take some time for me to understand.

Once you do, you can explain it to me.  The above is basically
handwaving except that I have some experience where your hands will get
hurt if you choose to wave them there.  So it's constrained handwaving.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel