Digest #12 2016-10-02
ACCEPT receive a string from the STDIN (standard input) or from the keyboard (as
KEY word does)?
The committee discussed this proposal and we came up with a one-liner that provides the same one-shot functionality without changes to the internals of header creation. It only requires quality of implementation on
: definitions that they go into the vocabulary that is current at the time of : instead of
; (which all quality implementations done by the committee members do).
: in ( "voc" "defining-word" -- ) get-current >r also ' execute definitions previous ' execute r> set-current ;
Use would be
in gui : init-gl ( .. -- .. ) ... ; in gui variable foo in gui defer bar
We perceive this solution to be more elegant (quite portable one-liner with existing words instead of changing some internals), but nonetheless thank you for pointing out the need for this functionality. Of course, it requires quality implementations for
: to work, so we encourage people to implement their
: without relying on the ambiguous condition.
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.
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.
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 :-)
ACCEPT typically uses KEY (or EKEY) and thus should get the input from the same source as KEY. On a hosted console Forth, that's usually STDIN, but if you run the Forth in a GUI windows, it's the keyboard input events from that window.