Proposal: [22] DEFER this not :-)
This proposal has been moved into this section. Its former address was: /standard/core/DEFER
This page is dedicated to discussing this specific proposal
ContributeContributions
enoch
[22] DEFER this not :-)Proposal2016-09-02 16:14:36
Going Forward
Some time ago I floated on the c.l.f. mailing list the desire for future Forth specs to include some "natural" forward reference resolution mechanism rather than rely on defer (cf gforth section 5.9.10 on Deferred Words).
Unsurprisingly, I did not get an enthusiastic reception. The Forth veterans were not impressed with defer being inefficient and with defer reducing readability. So I decided to see how difficult it would be to provide such mechanism in my pet Forth project.
Since I use a Python script (amforth-shell.py) to upload Forth code to the SUT (system under test) this turned out to be a trivial task:
Add an immediate Forth word … (Unicode ellipsis, e.g., easy to introduce via Emacs \ldots TeX input) to display the current DP (dictionary pointer) value.
The ellipsis is used to mark in compilations the beginning of the two common forward reference instances, for example:
… my-last-word
and… ['] my-last-word execute
.Capture the above two source line instances via a simple Python regular expression:
re.compile(ur"…\s+(\['\]\s+)?(\S+)", re.UNICODE)
. Replace group(2) with an erased Flash placeholder code (ffff
in my case) and collect from the SUT into a dictionary the name to IP (instruction pointer) value mappings.A source line directive (aka a pragma), #resolve, sends to the SUT the appropriate
' name ip !i
commands to patch the Flash memory appropriately.
For your consideration, Respectfully, Enoch.
P/S Why \ldots (ellipsis) for a name: It is not something that you type in by accident. It takes little space on your source line. It hints that there is more to it...