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

[Thomas Morley]

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