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

[David Kastrup]

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.

> 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