Re: Operator overloading?

On 31/07/2024 08:47, albert@spenarnc.xs4all.nl wrote:

In article <v8b04c$137lg$1@dont-email.me>,
Stephen Pelc  <stephen@vfxforth.com> wrote:

On 25 Jul 2024 at 08:30:58 BST, "minforth" <minforth> wrote:
>

Forth has a lot of ‘redundant’ operators for e.g. arithmetic or
stack operations, depending on the data type.
>
There was once an interesting approach for a type-bound layer
on top of standard Forth:
>

https://comp.lang.forth.narkive.com/rexLEBd0/strongforth-implemented-in-ans-forth

>
Unfortunately, the website for downloading strongforth.f
is no longer available.
>
Or has anyone found another way to bundle/overload Forth operators?

>
The standard suggests/specifies that operators such as TO behave as if
they parse. Ignore that for the moment and define

 There was a discussion about that before. The stipulaton is null and void.
It was established that there was no way a compliant program could
decide either way. It could be as well eliminated.
 

Here's a program that demonstrates a non-parsing TO:
  VFX Forth 64 for Windows x64
   © MicroProcessor Engineering Ltd, 1998-2023
  Version: 5.43 [build 4238]
  Build date: 9 November 2023
  Free dictionary = 6731782 bytes [6574kb]
111 value x x . 111  ok
222 to cr .( Does TO parse? ) x x 222 = [if] .( No it doesn't!) [then]
Does TO parse? No it doesn't! ok
Using a flag means that x could be on another line or even in another file.
You could argue that it's not a standard program because it contains a deliberate ambiguous condition so a parsing TO would fail in some way but it does demonstrate non-compliant behaviour.
Whether it matters is another matter.
--
Gerry