VALUE and TO implementation (was: Operator overloading?)

On 2024-07-31 13:41, mhx wrote:

On Wed, 31 Jul 2024 9:08:43 +0000, Gerry Jackson wrote:
[..]

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

[..]
 As does iForth.
 

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.

   222 TO cr
 should (I hope!) produce an exception (unless CR is redefined),
so this *definitely* fails and doesn't even finish the test.
 I'm not sure that you can use a buggy program to test for an ambiguous
condition (looks like a top job for an eager lawyer). It would be
much better if the anomaly can be shown with a valid program.

When we want to apply a parsing word to a calculated string, we can use "execute-parsing" (that can be defined in a standard way [1]). For a not parsing "to", this standard-compliant method will fail.
A testcase:
   : apply-compiling(to) ( sd.name -- )
     [: postpone to ;] execute-parsing
   ;
   t{ 0 value x -> }t
   t{ : t1 1 [ s" x" apply-compiling(to) ] ; -> }t
   t{ x t1 x -> 0 1 }t
NB: "postpone" can be defined in a standard way via "find-name" so that is apples to "to" [2].
[1] <https://theforth.net/package/compat/current-view/execute-parsing.fs>
[2] <https://github.com/ForthHub/discussion/discussions/103#user-content-solution>
--
Ruvim