@MSGID:
<7d6e2f3b-4e68-41f8-82c2-6f7723c88858n@googlegroups.com> 42e323ea
@REPLY: 1@dont-email.me> 632e3012
@REPLYADDR Hans Bezemer
<the.beez.speaks@gmail.com>
@REPLYTO 2:5075/128 Hans Bezemer
@CHRS: CP866 2
@RFC: 1 0
@RFC-References: 1@dont-email.me>
@RFC-Message-ID:
<7d6e2f3b-4e68-41f8-82c2-6f7723c88858n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
On Saturday, September 23, 2023 at 11:33:09 AM UTC+2, dxf wrote:
> YouTube offered this to me. Perhaps the world is catching on. 
> So what shall we do with ANS CASE :)

 It`s nothing new - but note it`s also a paradigm shift. In the
old days the world wanted
 a single return from a function - which was logical in a sense,
because long functions
 were still very much a reality. Using too many exit points was
waiting for an accident to
 happen. Maybe it was also fashionable to write long functions to
minimize function call
 overhead. Especially on older processors it`s not insignificant -
building a stack frame,
discarding it on exit.. you catch my drift.

 I quickly found out all that is not much of an issue with Forth,
because small functions
 (words) were the paradigm there (read "Thinking Forth"). So I
quickly switched to multiple
exits.

 On 4tH this was amplified by the introduction of the optimizer.
Using ;THEN instead of
 ELSE provided much tighter code, because it discarded superfluous
jumps. So if there
 was nothing after a THEN to execute, ELSE could be replaced by a
;THEN quite easily.

 BTW, if you got an ELSE clause and the IF requires a 0= you can
further simplify by 
switching the IF and ELSE clauses, so there is no need for 0= anymore.

 Anyways, you see that the C-like world is moving to shorter
functions, because they`re
 much easier to control. Of course, there are still exceptions -
e.g. when speed is the prime
 directive. I wouldn`t like to break up my VM code in smaller
chunks, for example. Worse,
I`m inlining a *lot* there for the same reason.

 I don`t know how other Forths are in this regard, but on smaller
tables CASE..ENDCASE is
 significantly faster than any other technique - with the exception
of direct indexed access.
 On smaller tables it even easily beats a binary search. So for
that reason - and that reason
alone - I`m keeping that construct in.

Hans Bezemer
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441