Proposal: DEFER this not :-)

Considered

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

enochavatar of 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:

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

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

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

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

AntonErtlavatar of AntonErtl

We discussed your request for a feature at the standards meeting. On behalf of the committee, here is our reaction:

The committee knows how to implement forward declarations without the extra fetch required by deferred words. However, the benefit (a minor speedup in a relatively rare case) does not justify the cost in our opinion.

enochavatar of enoch

Thanks, I respect the committee's position but I beg to differ:

Readability of the source code is my main concern. Using defer to execute forward referenced target word requires introducing a new dictionary name where an undisciplined programmer may choose a name that would not be automatically associated with the target.

My proposal in a nutshell is to allow marking of forward references and let the implementer come up with his own "magic" how to go about it. Marking is not uncommon in Forth, ['] is a case in point.

Thanks, Enoch.

P/S If the committee objects to using Unicode marks, ellipsis ( …) in my implementation, so be it but I would remind everyone that we live in the 21st century and Forth inventor has long gone into color :-)

ruvavatar of ruv

@enoch wrote:

Readability of the source code is my main concern.

I rarely need a forward definition due to mutual recursion. And I also value readability.

My latest variant is to use recognizers to refer to a forward (not yet defined) definition, for example use a prefix fw::

: foo ... fw:bar ... ;
: bar ... foo ... ;

In this solution we don't need any separate definition.

GeraldWodniavatar of GeraldWodni

The committee thinks this idea looks promising and that it pops up repeatedly in discussions. We encourage the author or anybody else interested to track past practice like f: and r: or forward \<foo\> and : \<foo\> and create a full proposal.

Considered

Klaus_Schleisiekavatar of Klaus_Schleisiek

What's wrong with DEFER foo bla bla :noname <code for foo> ; IS foo No additional name needed.

ruvavatar of ruv

@Klaus_Schleisiekavatar,

Form a readability point of view, "additional name" doesn't mean a dictionary entry, but additional mention of the name.

And, in the case of mutual recursion, this looks differ:

defer FOO

: BAR ( ... -- ... )
  bla bla
  FOO
  bla bla
;

:noname ( ... -- ... )
  bla bla
  BAR
  bla bla
; is FOO

What's wrong is poor readability. Since at the begin of the second definition it's unclear what is it for.

I can add a comment at the begin of this anonymous definition:

:noname ( ... -- ... ) \ the word "FOO"
  bla bla
  BAR
  bla bla
; is FOO

Such a comment is not elegant. And moreover, by that I introduce additional mention of the name FOO.

Reply New Version