[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 21:34:49 +0100 |
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
- guilev2 problem (user-markup-command sometimes not accepted), Thomas Morley, 2018/11/11
- Re: guilev2 problem (user-markup-command sometimes not accepted), David Kastrup, 2018/11/11
- Re: guilev2 problem (user-markup-command sometimes not accepted), David Kastrup, 2018/11/11
- Re: guilev2 problem (user-markup-command sometimes not accepted), Thomas Morley, 2018/11/12
- Re: guilev2 problem (user-markup-command sometimes not accepted), David Kastrup, 2018/11/12
- Re: guilev2 problem (user-markup-command sometimes not accepted), Thomas Morley, 2018/11/12
- Re: guilev2 problem (user-markup-command sometimes not accepted), David Kastrup, 2018/11/12
- Re: guilev2 problem (user-markup-command sometimes not accepted),
Thomas Morley <=
- Re: guilev2 problem (user-markup-command sometimes not accepted), David Kastrup, 2018/11/12