,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2016-10-01 12:47:01  ruv  wrote:
| requestClarification - Source of a string
| see: https://forth-standard.org/standard/core/ACCEPT#contribution-23
`------------------------------------------
Should `ACCEPT` receive a string from the STDIN (standard input) or from the keyboard (as `KEY` word does)?



,---------.
| Replies |
`---------´


,------------------------------------------
| 2016-09-08 14:22:36  BerndPaysan  replies:
| proposal - WLSCOPE -- wordlists switching made easier
| see: https://forth-standard.org/proposals/wlscope-wordlists-switching-made-easier#reply-32
`------------------------------------------
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.


,------------------------------------------
| 2016-09-15 13:47:11  AntonErtl  replies:
| proposal - DEFER this not :-)
| see: https://forth-standard.org/proposals/defer-this-not-#reply-34
`------------------------------------------
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.



,------------------------------------------
| 2016-09-16 10:55:30  enoch  replies:
| proposal - DEFER this not :-)
| see: https://forth-standard.org/proposals/defer-this-not-#reply-35
`------------------------------------------
Thanks, I respect the committee's position but I beg to differ: 

[Readability of the source code](https://en.wikipedia.org/wiki/Computer_programming#Readability_of_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 :-)



,------------------------------------------
| 2016-10-01 18:41:58  BerndPaysan  replies:
| requestClarification - Source of a string
| see: https://forth-standard.org/standard/core/ACCEPT#reply-38
`------------------------------------------
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.