Thanks. But it seems this is only the old 16-bit DOS version.
I have been looking for the ANS-compatible layer file
mentioned in the discussion.
IMHO and without belittling strongforth's merits, I think
that it went too far and proposed another Forth dialect.
I am thinking on a much smaller scale i.e. unification of
operators for xVALUEs and xLOCALs. ANS Forth already has
overloaded TO but stops there.
Or has anyone found another way to bundle/overload Forth operators?
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?
On Tue, 30 Jul 2024 15:16:28 +0000, Stephen Pelc wrote:
The standard suggests/specifies that operators such as TO behave as if
they parse. Ignore that for the moment and define
variable operator
: to 1 operator ! ; immediate
A child of VALUE is probably an immediate word that inspects OPERATOR
and compiles the fetch action if 0 or the store action if 1. This scheme
can
be extended to support a wide range of operators, such as +TO INCR DECR
and so on. MPE has used this scheme for several decades with no tech
support issues. If you really want to to be fussy and avoid the use of
the
"as if" rule for parsing, you can do something like (untested) the below
for TO. But why bother?
: to
1 operator ! ' execute
; immediate
Thank you. So instead of wasting time on parsing during compilation- or interpretation time, the runtime action of an xVALUE (even when
compiled)
involves to walk a type-specific operator chain (a large CASE construct
in VFX). This makes them slower when compiled, but why not.
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
Stephen
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 orhttps://comp.lang.forth.narkive.com/rexLEBd0/strongforth-implemented-in-ans-forth
stack operations, depending on the data type.
There was once an interesting approach for a type-bound layer
on top of standard 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.
On 31/07/2024 08:47, albert@spenarnc.xs4all.nl wrote:
In article <v8b04c$137lg$1@dont-email.me>,Here's a program that demonstrates a non-parsing TO:
Stephen Pelc <stephen@vfxforth.com> wrote:
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 25:11:29 |
| Calls: | 9,488 |
| Calls today: | 7 |
| Files: | 13,617 |
| Messages: | 6,121,109 |