@MSGID: 1@dont-email.me> 87143006
@REPLY:
<7d6e2f3b-4e68-41f8-82c2-6f7723c88858n@googlegroups.com> 42e323ea
@REPLYADDR dxf <dxforth@gmail.com>
@REPLYTO 2:5075/128 dxf
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
<7d6e2f3b-4e68-41f8-82c2-6f7723c88858n@googlegroups.com>
@TZUTC: 1000
@PID: Mozilla Thunderbird
@TID: FIDOGATE-5.12-ge4e8b94
On 25/09/2023 12:48 am, Hans Bezemer wrote:
> 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.

 There are reasons for continuing to use ELSE but how did we get
ELSE ? ELSE is a 
 logical complement to IF and I suspect that`s why every language
has it. Having 
ELSE, it has become a habit - one whose cost we`ve not really considered before.

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

I agree.  For me it`s the syntax rather than the mechanism that irritates.
ELSE (aka ENDOF) is built into the syntax and the user is stuck with it.
--- Mozilla Thunderbird
 * Origin: A noiseless patient Spider (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