> --------------------------------------------------------------------
> : if
> state @ 0= if
> cr ." WARNING: *** no interpretation semantics for: IF ***" cr
> then
> postpone if ;
> immediate
> --------------------------------------------------------------------

> The IF disambiguifier is obviously not STATE-smart.
> It does the the same thing no matter what STATE is,
> which is to compile the usual IF code.
> The only difference is that, in interpret mode you get a warning
> message telling you that this is illegal ANS-Forth code.
> This usually works in [ ... ] brackets, but it is still illegal.
> This is definitely not going to work outside of a colon word.
> Elizabeth Rather's bug in ANS-Forth was to fail to provide a way
> to distinguish between being inside a colon word in [ ... ] brackets,
> and being outside a colon word (STATE @ is zero in both cases).
>
> Alex McDonald routinely tells the same lie, saying that my
> disambiguifiers are STATE-smart. Everybody who supports ANS-Forth
> becomes a liar --- they can't accept the disambiguifiers --- they
> respond by telling lies, parroting Anton Ertl and Stephen Pelc.

NN

unread,

Jul 29, 2019, 7:23:53 PM7/29/19

to

On Monday, 29 July 2019 23:49:22 UTC+1, hughag...@gmail.com wrote:
[.snipped.]

> >
> > My question is: is the precondition being applied by Hugh's
> > disambiguifiers correct ? If the test is wrong, where is it wrong ?
>
> If STATE @ = 0 then you are in interpret state.
> Whether this is inside of [ ... ] brackets in a colon word,
> or is outside of a colon definition, there is no way to check.
> Either way, it is illegal.
>
> I've covered all of this multiple times.
> Gerry Jackson is trying to dodge this by starting a new thread.
> Here is one recent example:
>

[.snipped.]

Example 1 :

: pp state @ 0= if cr ." error: In interpretation mode"
abort then postpone postpone ; immediate
: pp1 123 ;
: pp4 [ pp pp1 ] ; immediate
: pp5 pp4 ;

Example 2 :

: ?comp state @ 0= if cr ." error: In interpretation mode"
abort then ; immediate

: pp ?comp postpone postpone ; immediate
: pp1 123 ;
: pp4 [ pp pp1 ] ; immediate
: pp5 pp4 ;

Example 1 fails
Example 2 works

Hugh,

Did you consider factoring the test into a separate word
like example 2 and if yes, why did you reject it in favour of
inlining it ?

unread,

Jul 30, 2019, 4:13:03 AM7/30/19

to

[snipped]

No they are not equivalent. Changing ?comp to immediate or
non-immediate makes a difference, to when the test is done.

Is example 2 valid ? What I am trying to understand is
does it work because I am using gforth or will it work in all forths?

If you have a counter example where something along the lines of (2) will
fail but (1) will work, I would like to see it just so that I have
something to compare and think about.

Anton Ertl

unread,

Jul 30, 2019, 5:03:33 AM7/30/19

to

NN <novembe...@gmail.com> writes:
>On Tuesday, 30 July 2019 05:00:21 UTC+1, hughag...@gmail.com wrote:
>> On Monday, July 29, 2019 at 4:23:53 PM UTC-7, NN wrote:
>> > Example 1 :
>> >
>> > : pp state @ 0= if cr ." error: In interpretation mode"
>> > abort then postpone postpone ; immediate
>> > : pp1 123 ;
>> > : pp4 [ pp pp1 ] ; immediate
>> > : pp5 pp4 ;
>> >
>> >
>> > Example 2 :
>> >
>> > : ?comp state @ 0= if cr ." error: In interpretation mode"
>> > abort then ; immediate
>> >
>> > : pp ?comp postpone postpone ; immediate
>> > : pp1 123 ;
>> > : pp4 [ pp pp1 ] ; immediate
>> > : pp5 pp4 ;
>> >
>> > Example 1 fails
>> > Example 2 works

...

>Is example 2 valid ? What I am trying to understand is
>does it work because I am using gforth or will it work in all forths?

As far as I can see, Example 2 is a standard program, as is Example 1.
"Works" and "Fails" seems to refer to the intent of these
examples (which seems to be to finish without error).

Will Example 2 finish without error on "all Forths"? Probably not.
fig-Forth had a non-immediate ?COMP that checks STATE at run-time
(like Example 1), and used in in all "Compiler words" (in
Forth-94/2012). I would not be surprised if there are still systems
around that use such a ?COMP in words with undefined interpretation
semantics, such as POSTPONE, and such an implementation would produce
an error when the compilation semantics of POSTPONE is performed in
interpret state (in PP).

NN

unread,

Jul 30, 2019, 6:01:29 AM7/30/19

to

Its not so much about pass/fail but rather what becomes apparent is
changing when the test is done ( - making ?comp immediate or non-immediate )
has an effect, on whether the example works or aborts.

At this point I started to wonder, if I cant see anything wrong
with example 2, am I fooling myself, by changing when the test to
get the result I want.

Alex's answer (above) is succinct as to why I shouldnt be following
example (1).

Anton Ertl

unread,

Jul 30, 2019, 6:29:24 AM7/30/19

to

NN <novembe...@gmail.com> writes:
>On Tuesday, 30 July 2019 10:03:33 UTC+1, Anton Ertl wrote:
>> NN <novembe...@gmail.com> writes:
>> >On Tuesday, 30 July 2019 05:00:21 UTC+1, hughag...@gmail.com wrote:
>> >> On Monday, July 29, 2019 at 4:23:53 PM UTC-7, NN wrote:
>> >> > Example 2 :
>> >> >
>> >> > : ?comp state @ 0= if cr ." error: In interpretation mode"
>> >> > abort then ; immediate
>> >> >
>> >> > : pp ?comp postpone postpone ; immediate
>> >> > : pp1 123 ;
>> >> > : pp4 [ pp pp1 ] ; immediate
>> >> > : pp5 pp4 ;
>> >> >
>> >> > Example 1 fails
>> >> > Example 2 works
>> ...
>> >Is example 2 valid ? What I am trying to understand is
>> >does it work because I am using gforth or will it work in all forths?

...

>At this point I started to wonder, if I cant see anything wrong
>with example 2, am I fooling myself, by changing when the test to
>get the result I want.

The ?COMP part of example 2 will not report an error for example 2 on
any not too outlandish system.

What I wrote about earlier is whether the rest (in particular the
compilation semantics of POSTPONE) would work as intended on "all
systems".

Alex McDonald

unread,

Jul 30, 2019, 7:46:06 AM7/30/19

to

On 30-Jul-19 06:26, hughag...@gmail.com wrote:
> On Monday, July 29, 2019 at 1:04:52 PM UTC-7, Alex McDonald wrote:
>> On 29-Jul-19 20:56, NN wrote:
>>> To the above may I just add :
>>>
>>> (1) Ruvim's third post into the discussion:
>>>
>>> https://groups.google.com/d/msg/comp.lang.forth/vrq2f2XXy1Q/ZJ855-heDgAJ
>>>
>>>
>>> (2) And Anton's reply to Rod is easy to miss, but important
>>>
>>> "There is one thing you need to understand about interpretation and
>>> compilation semantics in the standard: they do not depend on STATE.
>>> Only the text interpreter uses STATE to decide whether to perform
>>> interpretation semantics or compilation semantics; nothing else does."
>>>
>>>
>>>
>>> My question is: is the precondition being applied by Hugh's
>>> disambiguifiers correct ? If the test is wrong, where is it wrong ?
>>>
>>
>> It is wrong at the point where it does STATE @ IF. From there, it's all
>> downhill on skates with no brakes because it's state smart *at run
>> time*. I refer you to Anton's reply that you reproduced above as to why
>> this is wrong.
>>
>> --
>> Alex
>
> I find it quite humorous that members of Elizabeth Rather's cult
> are now opposed to STATE-smart Forth systems.
> Alex McDonald poetically describes it as:
> "downhill on skates with no brakes."

It's your code we're discussing, not STATE smart Forths.

: if
state @ 0= if

cr ." WARNING: *** no interpretation semantics for: IF ***" cr

then
postpone if ;
immediate

If you look closely, you'll see that your disambiguifier has given IF
interpretation semantics, since it is an IMMEDIATE word. It (amusingly
and incorrectly) then issues the message that there are no
interpretation semantics for your disambiguificated IF. Skates on,
brakes off.

Anton's observation needs repeated ad nauseam, and I'd have it in the
standard where it discusses STATE, as normative text:

"There is one thing you need to understand about interpretation and
compilation semantics in the standard: they do not depend on STATE. Only
the text interpreter uses STATE to decide whether to perform
interpretation semantics or compilation semantics; nothing else does."

--
Alex

Gerry Jackson

unread,

Jul 30, 2019, 11:51:27 AM7/30/19

to

On 30/07/2019 06:52, Anton Ertl wrote:
> Gerry Jackson <do-no...@swldwa.uk> writes:
>> I think I'll add code similar to that above to the Forth 2012 suite of
>> test programs, not just for POSTPONE.
>
> You find a number of such tests that I wrote in 1996 (last updated
> 2011) in <https://www.complang.tuwien.ac.at/forth/postponetest.fs>.
> It does not include tests of Forth-2012 words.
>
> It does include a test of POSTPONE S" which you may or may not want to
> include in your test suite: On one hand, this test is a standard
> program according to the document, on the other hand the Forth-94 and
> Forth-2012 committees probably intended that STATE-smart S" is
> acceptable. If you include it, maybe someone will finally propose a
> change to the document that reflects this intention; or they might
> just ignore the test, just as they have done the last 23 years.
>

I would like to include the whole of your postponetest.fs in the test
suite. Are you willing for me to do that? I will of course give you the
credit (or do I mean blame!) for the program.

Regarding S" I'm not very keen on introducing restrictions to make
system implementers' lives easier so I would retain the tests on it.

--
Gerry

A. K.

unread,

Jul 30, 2019, 12:40:02 PM7/30/19

to

Am Dienstag, 30. Juli 2019 17:51:27 UTC+2 schrieb Gerry Jackson:
> On 30/07/2019 06:52, Anton Ertl wrote:
> > Gerry Jackson <do-no...@swldwa.uk> writes:
> >> I think I'll add code similar to that above to the Forth 2012 suite of
> >> test programs, not just for POSTPONE.
> >
> > You find a number of such tests that I wrote in 1996 (last updated
> > 2011) in <https://www.complang.tuwien.ac.at/forth/postponetest.fs>.
> > It does not include tests of Forth-2012 words.
> >
> > It does include a test of POSTPONE S" which you may or may not want to
> > include in your test suite: On one hand, this test is a standard
> > program according to the document, on the other hand the Forth-94 and
> > Forth-2012 committees probably intended that STATE-smart S" is
> > acceptable. If you include it, maybe someone will finally propose a
> > change to the document that reflects this intention; or they might
> > just ignore the test, just as they have done the last 23 years.
> >
>
> I would like to include the whole of your postponetest.fs in the test
> suite. Are you willing for me to do that? I will of course give you the
> credit (or do I mean blame!) for the program.
>

Be careful not to further weaken the standard's acceptance by that.
Many legacy Forths might become non-compliant.

IMHO it would be much more important to have an accepted standard test
for fp numbers. No complaint, just an observation.

Anton Ertl

unread,

Jul 30, 2019, 12:53:16 PM7/30/19

to

Gerry Jackson <do-no...@swldwa.uk> writes:
>I would like to include the whole of your postponetest.fs in the test
>suite. Are you willing for me to do that?

Sure, go ahead, I put my parts in the public domain for that reason.
The file says it is based on Hayes' core.fr, but AFAIK you already
include that, so it should not be a problem, and it has a very liberal
licence anyway.

m...@iae.nl

unread,

Jul 30, 2019, 1:19:22 PM7/30/19

to

On Tuesday, July 30, 2019 at 10:13:03 AM UTC+2, NN wrote:
[..]

> Is example 2 valid ? What I am trying to understand is
> does it work because I am using gforth or will it work in all forths?
>
> If you have a counter example where something along the lines of (2) will
> fail but (1) will work, I would like to see it just so that I have
> something to compare and think about.

FORTH> : pp state @ 0= if cr ." error: In interpretation mode" abort then postpone postpone ; immediate ok
FORTH> : pp1 123 ; ok
FORTH> : pp4 [ pp pp1 ] ; immediate
error: In interpretation mode
FORTH> : pp5 pp4 ;
Error -13
: pp5 pp4 ;
---------^
pp4 ?
FORTH> ok
FORTH> : ?comp state @ 0= if cr ." error: In interpretation mode" abort then ; immediate ok
FORTH> ok
FORTH> : pp ?comp postpone postpone ; immediate
Redefining pp ok
FORTH> : pp1 123 ;
Redefining pp1 ok
FORTH> : pp4 [ pp pp1 ] ; immediate ok
[2]FORTH> : pp5 pp4 ;
Caught exception 0xc000001d
ILLEGAL INSTRUCTION
instruction pointer = $00000000050F6A00
RAX = $012B8E00 RBX = $050F69F0
RCX = $050F69F0 RDX = $00000414
RSI = $01DD87E8 RDI = $0A3BF7B8
RBP = $01125F38 RSP = $0A3BF800
R8 = $00001320 R9 = $00000020
R10 = $00FF6EE0 R11 = $01112914
R12 = $00000080 R13 = $01157000
R14 = $01135FE8 R15 = $01110000
Hardware exception in ``pp4''+$03DCE000
**** RETURN STACK DUMP ****
$00000000 (0)
$0122D390 (19059600)
$00000000 (0)
$0000000A (10)
$@@? (+$00000DEA)
$@@? (+$00000B79)
$00000000 (0)
$0122D378 (19059576)
$00000000 (0)
$0000000A (10)
FORTH> ok

Example 2 fails, but for a different reason
than I expect you may be thinking of.

-marcel

Alex McDonald

unread,

Jul 30, 2019, 1:47:52 PM7/30/19

to

They either meet the standard or they don't; omitting the test doesn't
change that. Is it important? Not unless you depend on a specific
behaviour, in which case my advice would be to best avoid that behaviour
or use a different Forth that meets the standard if you can't do without.

>
> IMHO it would be much more important to have an accepted standard test
> for fp numbers. No complaint, just an observation.

See http://www.forth200x.org/documents/html/testsuite.html section
F.2.3. You might find the notes in F.2.1 interesting.

--
Alex

A. K.

unread,

Jul 30, 2019, 3:54:17 PM7/30/19

to

Sure. The old story. When you've seen one Forth, you've seen one Forth.
BTW I wouldn't be surprised if Swiftforth rejects that postponetest.fs
But I might be wrong either. It's just one Forth. As you said, take another.

hughag...@gmail.com

unread,

Jul 30, 2019, 7:30:14 PM7/30/19

to

On Tuesday, July 30, 2019 at 4:46:06 AM UTC-7, Alex McDonald wrote:
> On 30-Jul-19 06:26, hughag...@gmail.com wrote:
> > I find it quite humorous that members of Elizabeth Rather's cult
> > are now opposed to STATE-smart Forth systems.
> > Alex McDonald poetically describes it as:
> > "downhill on skates with no brakes."
>
> It's your code we're discussing, not STATE smart Forths.
>
> : if
> state @ 0= if
> cr ." WARNING: *** no interpretation semantics for: IF ***" cr
>
> then
> postpone if ;
> immediate
>
> If you look closely, you'll see that your disambiguifier has given IF
> interpretation semantics, since it is an IMMEDIATE word. It (amusingly
> and incorrectly) then issues the message that there are no
> interpretation semantics for your disambiguificated IF. Skates on,
> brakes off.

I need to "look closely" at the disambiguifier? I wrote it!
Also, I read the documentation for IF (6.1.1700):

"Interpretation semantics for this word are undefined."

This is why the warning message is given --- I originally did
an abort with an error message, but I switched to a warning
to appease Anton Ertl who wanted to use compiling words such
as IF POSTPONE COMPILE, etc. inside of [ ... ] brackets
(doing this is not ANS-Forth however!).

An immediate word executes at compile-time inside of a colon word,
but this does not set STATE @ to zero (interpretation mode).
OTOH, [ does set STATE @ to zero (interpretation mode),
and ] sets STATE @ back to non-zero (compilation mode).

I would expect anybody with one week of Forth experience to know this.
Other than the fact that you brown-nose the Forth-200x committee,
what qualification do you have to call yourself a Forth programmer?
You know nothing about Forth! You are an annoying clown.

> Anton's observation needs repeated ad nauseam, and I'd have it in the
> standard where it discusses STATE, as normative text:
>
> "There is one thing you need to understand about interpretation and
> compilation semantics in the standard: they do not depend on STATE. Only
> the text interpreter uses STATE to decide whether to perform
> interpretation semantics or compilation semantics; nothing else does."

The Forth-200x committee want to educate me on Forth! LOL
"Ad nauseam" is really the best word for the baloney served by the
ANS-Forth and Forth-200x cult.

Mark Wills

unread,

Jul 31, 2019, 6:50:44 AM7/31/19

to

I'd say it's a grey area that the standard doesn't cover well. Originally,
Hugh's code aborted, but I think he changed it to provide a warning instead.

My system (a classical ITC implementation) does not permit IF to be used
outwith a colon definition. In such a case, I would want it to abort rather
than silently compile some code which is just going to crash my system or
whatever.

Perhaps a 'strict' variable could be used to determine what IF does under
these circumstances? Abort, warn, or do nothing.

But we should't forget the purpose of Hugh's code: To disambiguify (is that
a word? I dunno). In that context, I believe it does what it says on the tin,
it prevents IF from being used under ambiguous circumstances, whis is where
all the demons live.

I believe that by using disambiguifiers the chances of code running *in the
same way* across different systems (thereby producing the same results) is
increased.

So, I agree with your interpretation in that executing some code (a warning)
at compile/interpret time, you are introducing interpretation sematics, but
that's a rather strict interpretation, and I'd rather have a system that says
"hey, demons live there, don't do that" rather than silently compile a program
that isn't going to run, leaving me to scratch my head and wonder where the
the problem is, and why it runs on system A, and not system B.

Cheers

Mark

Rod Pemberton

unread,

Jul 31, 2019, 8:11:12 AM7/31/19

to

On Tue, 30 Jul 2019 09:40:01 -0700 (PDT)
"A. K." <minf...@arcor.de> wrote:

> Am Dienstag, 30. Juli 2019 17:51:27 UTC+2 schrieb Gerry Jackson:
> > On 30/07/2019 06:52, Anton Ertl wrote:
> > > Gerry Jackson <do-no...@swldwa.uk> writes:

> > >> I think I'll add code similar to that above to the Forth 2012
> > >> suite of test programs, not just for POSTPONE.
> > >
> > > You find a number of such tests that I wrote in 1996 (last updated

> > > 2011) in [snip]. It does not include tests of Forth-2012 words.

> > >
> >
> > I would like to include the whole of your postponetest.fs in the
> > test suite.
>

> Be careful not to further weaken the standard's acceptance by that.
> Many legacy Forths might become non-compliant.
>

Why do you think this? I would've thought that interpreted Forths
which implement POSTPONE would all be compliant.

Rod Pemberton
--
Once upon a time, many decades ago in a place far away, humble people
sought their freedom, and lost. "Ideas are bulletproof."

Alex McDonald

unread,

Jul 31, 2019, 9:04:15 AM7/31/19

to

Remember Anton's advice;

"There is one thing you need to understand about interpretation and
compilation semantics in the standard: they do not depend on STATE.
Only the text interpreter uses STATE to decide whether to perform
interpretation semantics or compilation semantics; nothing else does."

What does strict mean? If true, does it means "strictly adhere to the
standard"? If so, then it should do nothing if the STATE is 0. If it
lets words like state smart IF abort when STATE is 0, then it's not
following the standard, so it's not really being very strict at all.

How would a strict variable help with this?

: ppif state @ 0<> if ." warn etc" then postpone if ; immediate
: pp1 [ ppif ] then ;

That's valid Forth. So is this.

] if then [

] enters compilation state. It does not need to be inside a : ; to work,
and I have used it bare like this to generate code stubs for objects.
What would a strict variable do here?

>
> But we should't forget the purpose of Hugh's code: To disambiguify (is that
> a word? I dunno). In that context, I believe it does what it says on the tin,
> it prevents IF from being used under ambiguous circumstances, whis is where
> all the demons live.

The purpose of Hugh's code is to get words like IF to always return an
XT from FIND to support his macro expansion scheme. It doesn't prevent
anything at all, but it does emit an incorrect message.

>
> I believe that by using disambiguifiers the chances of code running *in the
> same way* across different systems (thereby producing the same results) is
> increased.

That's a noble desire, and Hugh's "disambiguificators" are perfectly
legal Forth; but the message is incorrect, and that's all they do apart
from letting FIND return an XT for interpretation semantics. They would
be better as

: if postpone if ; immediate

Here, IF inside the definition has no defined interpretation semantics,
but the above code does not execute those semantics; it executes the
compilation semantics.

>
> So, I agree with your interpretation in that executing some code (a warning)
> at compile/interpret time, you are introducing interpretation sematics, but
> that's a rather strict interpretation, and I'd rather have a system that says
> "hey, demons live there, don't do that" rather than silently compile a program
> that isn't going to run, leaving me to scratch my head and wonder where the
> the problem is, and why it runs on system A, and not system B.

Well, by doing it properly, because the interpretation semantics of IF
are not being used when you POSTPONE IF.

STC 32bit: 0.06.10 Build: 847
if
^^
Error -14 in (console): if is compilation only
: ppif postpone if ;
ok
: pp1 [ ppif ] then ;
ok

--
Alex

A. K.

unread,

Jul 31, 2019, 9:05:09 AM7/31/19

to

Am Mittwoch, 31. Juli 2019 14:11:12 UTC+2 schrieb Rod Pemberton:
> On Tue, 30 Jul 2019 09:40:01 -0700 (PDT)
> "A. K." <minf...@arcor.de> wrote:
>
> > Am Dienstag, 30. Juli 2019 17:51:27 UTC+2 schrieb Gerry Jackson:
> > > On 30/07/2019 06:52, Anton Ertl wrote:
> > > > Gerry Jackson <do-no...@swldwa.uk> writes:
>
> > > >> I think I'll add code similar to that above to the Forth 2012
> > > >> suite of test programs, not just for POSTPONE.
> > > >
> > > > You find a number of such tests that I wrote in 1996 (last updated
> > > > 2011) in [snip]. It does not include tests of Forth-2012 words.
> > > >
> > >
> > > I would like to include the whole of your postponetest.fs in the
> > > test suite.
> >
> > Be careful not to further weaken the standard's acceptance by that.
> > Many legacy Forths might become non-compliant.
> >
>
> Why do you think this? I would've thought that interpreted Forths
> which implement POSTPONE would all be compliant.
>

We are talking about this file:
https://www.complang.tuwien.ac.at/forth/postponetest.fs
which follows a stricter view than the postpone-test in core.fr

By narrowing the acceptance window, some Forths might be thrown out,
that pass core.fr.

Anton Ertl

unread,

Jul 31, 2019, 12:02:02 PM7/31/19

to

Alex McDonald <al...@rivadpm.com> writes:
>That's valid Forth. So is this.
>
>] if then [

That's debatable. IF appends its run-time semantics to the current
definition, but there is no current definition. So it's not clear
what is required of the system here.

However, it demonstrates in the other direction that STATE @ does not
answer the question whether there is a current definition.

Gerry Jackson

unread,

Jul 31, 2019, 1:09:22 PM7/31/19

to

On 31/07/2019 11:50, Mark Wills wrote:
>> Anton's observation needs repeated ad nauseam, and I'd have it in the
>> standard where it discusses STATE, as normative text:
>>
>> "There is one thing you need to understand about interpretation and
>> compilation semantics in the standard: they do not depend on STATE. Only
>> the text interpreter uses STATE to decide whether to perform
>> interpretation semantics or compilation semantics; nothing else does."
>>
>> --
>> Alex
> I'd say it's a grey area that the standard doesn't cover well.

Depends what you mean by the word 'cover'. Rewording your statement - if
you mean does it explain it unambiguously I'd say yes but you have to
search around for the relevant information as I did in the original post
and realise what it does *not* say. If you mean is there a clear
explanation in one place then I'd say no. So it's a grey area for casual
readers who, probably wouldn't even think about it if their attention
wasn't drawn to it. I certainly didn't!

The problem is that people make untrue claims about what is legal and
what is not based on uninformed opinion/gut feel because,
understandably, they don't invest the time to understand the issues. I
think a section somewhere explaining this would be a good idea.

> Originally,
> Hugh's code aborted, but I think he changed it to provide a warning instead.

I might be wrong but I thought his disambiguifiers have always aborted.

--
Gerry

Alex McDonald

unread,

Jul 31, 2019, 1:38:09 PM7/31/19

to

On 31-Jul-19 16:57, Anton Ertl wrote:
> Alex McDonald <al...@rivadpm.com> writes:
>> That's valid Forth. So is this.
>>
>> ] if then [
>
> That's debatable. IF appends its run-time semantics to the current
> definition, but there is no current definition. So it's not clear
> what is required of the system here.

Looking for "current definition" I find only a few references, and the
most significant are in : and :NONAME

... Enter compilation state and start the current definition, producing
colon-sys.

and the termnating ;

... End the current definition, allow it to be found in the dictionary
and enter interpretation state, consuming colon-sys.

There's no indication, as you say, of what happens outside a current
definition. However, my system (and I suspect others) just keeps on
compiling, even though there's no standard way of capturing what is
compiled.

STC 32bit: 0.06.10 Build: 847

code-here ] if true else false then exit [ constant foo
ok
10 foo execute .
-1 ok
0 foo execute .
0 ok
foo dis
( $41AE42 ' v-emit $4E + )
( $0 ) add ebp $4 \ 83C504
( $3 ) test eax eax \ 85C0
( $5 ) mov eax dword { $-4 ebp } \ 8B45FC
( $8 ) je ' v-emit $6A + \ 0F840E000000
( $E ) mov dword { $-4 ebp } eax \ 8945FC
( $11 ) or eax $-1 \ 83C8FF
( $14 ) sub ebp $4 \ 83ED04
( $17 ) jmp ' v-emit $73 + \ E909000000
( $1C ) mov dword { $-4 ebp } eax \ 8945FC
( $1F ) and eax $0 \ 83E000
( $22 ) sub ebp $4 \ 83ED04
( $25 ) ret \ C3 ok

(The reference to V-EMIT is caused by the disassembler not having a
current definition to refer to.)

However, none of this applies to CODE which makes no reference to a
current definition.

CODE bar
] if true else false then [
next;

which generates exactly the same code as FOO except it has a header.
This working depends on my system being a native code compiler. I'd be
interested to know if other Forths can capture the fragment using CODE,
with or without non-standard parts.

>
> However, it demonstrates in the other direction that STATE @ does not
> answer the question whether there is a current definition.

This is (I think, because sifting through his ranting is hard and I'm
never sure I've understood what he's saying) one of Hugh Aguilar's many
complaints; that STATE's value should reflect the text interpreter
seeing words outside (eg 1) and interpreting (0) or compiling (-1)
inside a definition.

--
Alex

Gerry Jackson

unread,

Jul 31, 2019, 1:40:51 PM7/31/19

to

I don't think that's a problem that should concern test programs. IMHO
test programs should test conformance to the standard, no more no less.
Corner cases are important and need to be tested. I think the original
core test program only tests the basic operation of words in the core,
there are plenty of things not yet covered.

>
> IMHO it would be much more important to have an accepted standard test
> for fp numbers. No complaint, just an observation.
>

I agree but I'm not a heavy user of FP numbers and haven't implemented
them in my system, so I have neither the motivation or detailed
knowledge to write a comprehensive FP test program. Apparently neither
has anyone else. Some years ago I gathered some existing FP tests
together that various people had written and included them in the test
suite as provisional tests with a suggestion that someone might add to
them etc. AFAIK nobody has.

There are a number of problems that even I can think of e.g.
- the FP format/number of bits is not mandated (assuming IEEE formats
would probably be reasonable)
- how to definitively test for 'nearness' of results
- acceptable accuracy of various mathematical functions
- ...

But then again is it crucial? It could be argued that most Forth systems
use FP hardware or software libraries that have been well tested and
exercised in the world. So assuming they are fit for purpose is
reasonable. Applications using FP could (and should?) test accuracy of
whatever FP algorithms they use anyway. I don't think I agree with that
but some might.

--
Gerry

hughag...@gmail.com

unread,

Jul 31, 2019, 4:34:54 PM7/31/19

to

On Wednesday, July 31, 2019 at 6:04:15 AM UTC-7, Alex McDonald wrote:
> On 31-Jul-19 11:50, Mark Wills wrote:
> > I'd say it's a grey area that the standard doesn't cover well. Originally,
> > Hugh's code aborted, but I think he changed it to provide a warning instead.

It is not all that grey.
Words such as IF are documented:

"Interpretation semantics for this word are undefined."

Here "semantics" is Elizabeth Rather's goofy terminology for "action"
or "behavior," and "undefined" is one of the many words she uses
for "illegal." This seems pretty black-and-white --- the words can't
be executed in interpret-mode, which means inside of [ ... ] brackets.
In some cases (the compiling words, such as IF etc.) it makes sense
to execute them inside of [ ... ] brackets.
Banning this is a bug in ANS-Forth.
In other cases (words such as R> etc.) it makes sense to ban them.
Another bug in ANS-Forth is that STATE is two-state when it should
be tri-state --- words such as IF etc. should be able to determine
that they are in [ ... ] brackets (okay) or outside of any colon
definition (not okay), but in ANS-Forth they can't make this determination.

> > My system (a classical ITC implementation) does not permit IF to be used
> > outwith a colon definition. In such a case, I would want it to abort rather
> > than silently compile some code which is just going to crash my system or
> > whatever.
> >
> > Perhaps a 'strict' variable could be used to determine what IF does under
> > these circumstances? Abort, warn, or do nothing.
>
> Remember Anton's advice;
>
> "There is one thing you need to understand about interpretation and
> compilation semantics in the standard: they do not depend on STATE.
> Only the text interpreter uses STATE to decide whether to perform
> interpretation semantics or compilation semantics; nothing else does."
>
> What does strict mean? If true, does it means "strictly adhere to the
> standard"? If so, then it should do nothing if the STATE is 0. If it
> lets words like state smart IF abort when STATE is 0, then it's not
> following the standard, so it's not really being very strict at all.
>
> How would a strict variable help with this?
>
> : ppif state @ 0<> if ." warn etc" then postpone if ; immediate
> : pp1 [ ppif ] then ;
>
> That's valid Forth.

Alex McDonald is the reason why Forth-200x will fail.
He repeats himself over and over again, and he is obviously wrong.
This is the true face of Forth-200x!

Stephen Pelc seems to think that, given Alex McDonald's loyalty,
Alex is making a positive contribution to Forth-200x and needs
to be kept. Stephen Pelc is making a fool out of himself.
Alex McDonald is dumb! Alex McDonald makes Forth-200x seem to be
irredeemably dumb. Stephen Pelc will never disassociate himself
from Alex McDonald in the same way that Elizabeth Rather and
Bernd Paysan have never disassociated themselves from John Passaniti.

Alex McDonald is very old; a lot of this weird nonsense is senility.
He was probably always dumb though.
Stephen Pelc is very desperate for supporters if the best he can find
is Alex McDonald with his continuous wrongness.
The Forth-200x committee also includes Peter Knaggs
who doesn't know how to implement a linked list.
The Forth-200x committee also includes Anton Ertl and Bernd Paysan
who blatantly lied about the rquotations in their EuroForth paper.

Stephen Pelc is failing badly.
All of the Forth-200x committee members are liars and fools.
Every time that I write ANS-Forth code that works,
I deny Stephen Pelc yet another path to success.
Stephen Pelc is not going to succeed. He should just resign from
the Forth-200x committee while he still has his dignity.

> So is this.
>
> ] if then [
>
> ] enters compilation state. It does not need to be inside a : ; to work,
> and I have used it bare like this to generate code stubs for objects.
> What would a strict variable do here?

Making ] an ANS-Forth word was another bug in ANS-Forth.
Maybe a HERE prior to the ] provides an xt similar to :NONAME
unless it doesn't. It is undefined where this code compiles or how
it could be executed eventually. This is just more ambiguity.

> > But we should't forget the purpose of Hugh's code: To disambiguify (is that
> > a word? I dunno). In that context, I believe it does what it says on the tin,
> > it prevents IF from being used under ambiguous circumstances, whis is where
> > all the demons live.
>
> The purpose of Hugh's code is to get words like IF to always return an
> XT from FIND to support his macro expansion scheme. It doesn't prevent
> anything at all, but it does emit an incorrect message.

My disambiguifiers do assure that FIND returns an xt for these words.
They also assure that FIND indicates them to be immediate.
They also assure that FIND returns the same xt whether STATE is
true or false at the time FIND is executed (pretty much; the ANS-Forth
document just says that FIND may or may not return different xt values
depending upon STATE, but doesn't say this weirdness is only for IF etc.,
although in practice it is only for IF etc.).

> > I believe that by using disambiguifiers the chances of code running *in the
> > same way* across different systems (thereby producing the same results) is
> > increased.
>
> That's a noble desire, and Hugh's "disambiguificators" are perfectly
> legal Forth; but the message is incorrect, and that's all they do apart
> from letting FIND return an XT for interpretation semantics. They would
> be better as
>
> : if postpone if ; immediate
>
> Here, IF inside the definition has no defined interpretation semantics,
> but the above code does not execute those semantics; it executes the
> compilation semantics.
>
> > So, I agree with your interpretation in that executing some code (a warning)
> > at compile/interpret time, you are introducing interpretation sematics, but
> > that's a rather strict interpretation, and I'd rather have a system that says
> > "hey, demons live there, don't do that" rather than silently compile a program
> > that isn't going to run, leaving me to scratch my head and wonder where the
> > the problem is, and why it runs on system A, and not system B.
>
> Well, by doing it properly, because the interpretation semantics of IF
> are not being used when you POSTPONE IF.

The difference between Alex McDonald and an Uzi is that an Uzi
eventually stops repeating itself.
Alex McDonald just goes on and on saying that the warning message
is incorrect, but it isn't.
Alex McDonald spent over four years attacking my array SORT because
it supported elements of any size, and he thought that it should
be limited to elements of cell size like Will Baden's SORT.
Four years is a long time! As I said, this is most likely senility.
He just gets stuck on these idiotic ideas, and he never lets go.
Actually, all of the Forth-200x members are like this.
Stephen Pelc should have realized that he wasn't going to win his
fight against disambiguifiers, and just admitted that he was wrong.
Instead he steadfastly continues on and on, obviously wrong,
but never able to admit that he is wrong. This is the path to failure.

The Forth-200x committee is a joke, similar to the Flat Earth Society.
They can never admit that they are wrong about anything.
They just blindly press onward, becoming increasingly ridiculous.
Even C programs know more about Forth than they do!

Rod Pemberton

unread,

Jul 31, 2019, 7:45:31 PM7/31/19

to

On Wed, 31 Jul 2019 06:05:07 -0700 (PDT)

Is this just a broad generic claim that something is narrower because
this file has a different set of more complicated tests, or did you
have something specific in mind which constitutes a "stricter view"? ...

So, AIUI, IIRC, POSTPONE does two things:
a) replaces COMPILE
b) replaces [COMPILE]

In other words, how can there be a "narrower" or "stricter" view of
POSTPONE when only two things must be tested and be working for
POSTPONE? ... I.e., any test for POSTPONE is only going to be able to
test two things, because POSTPONE only does two things. AISI, any
other interactions found via additional testing are actually testing
for something else, and not actually testing POSTPONE's functionality.
Yes?

dxforth

unread,

Jul 31, 2019, 11:08:14 PM7/31/19

to

On Tuesday, 30 July 2019 04:34:50 UTC+10, Gerry Jackson wrote:
> ...
> No doubt someone will let me know if I'm wrong - please do.

>
> I think I'll add code similar to that above to the Forth 2012 suite of
> test programs, not just for POSTPONE.
>

> --
> Gerry

While 200x can endorse any 'test code' it likes it can't claim
to have the final word on ANS as it's just their interpretation.
As previously stated I would regard as suspicious any interpretation
that, 25 years on, suddenly invalidates existing implementations.

It's my observation those who make argument on the basis on what
'ANS says' are often the same people who have no problem repealing
what ANS said when it doesn't fit into their view of what Forth
should be.

A. K.

unread,

Aug 1, 2019, 1:05:02 AM8/1/19

to

For example, perhaps a syntax issue

SwiftForth i386-Win32 3.2.2 08-Jul-2010
include tester.fr
VERBOSE isn't unique.
-> isn't unique.
2 definitions were hidden
ok
include core.fr
TESTING CORE WORDS
TESTING BASIC ASSUMPTIONS
TESTING BOOLEANS: INVERT AND OR XOR
TESTING 2* 2/ LSHIFT RSHIFT
TESTING COMPARISONS: 0= = 0< < > U< MIN MAX
TESTING STACK OPS: 2DROP 2DUP 2OVER 2SWAP ?DUP DEPTH DROP DUP OVER ROT SWAP
TESTING >R R> R@
TESTING ADD/SUBTRACT: + - 1+ 1- ABS NEGATE
TESTING MULTIPLY: S>D * M* UM*
TESTING DIVIDE: FM/MOD SM/REM UM/MOD */ */MOD / /MOD MOD
TESTING HERE , @ ! CELL+ CELLS C, C@ C! CHARS 2@ 2! ALIGN ALIGNED +! ALLOT
TESTING CHAR [CHAR] [ ] BL S"
TESTING ' ['] FIND EXECUTE IMMEDIATE COUNT LITERAL POSTPONE STATE
TESTING IF ELSE THEN BEGIN WHILE REPEAT UNTIL RECURSE
TESTING DO LOOP +LOOP I J UNLOOP LEAVE EXIT
TESTING DEFINING WORDS: : ; CONSTANT VARIABLE CREATE DOES> >BODY
TESTING EVALUATE
TESTING SOURCE >IN WORD
TESTING <# # #S #> HOLD SIGN BASE >NUMBER HEX DECIMAL
TESTING FILL MOVE
TESTING OUTPUT: . ." CR EMIT SPACE SPACES TYPE U.
YOU SHOULD SEE THE STANDARD GRAPHIC CHARACTERS:
!"#$%&'()*+,-./0123456789:;<=>?@
ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`
abcdefghijklmnopqrstuvwxyz{|}~
YOU SHOULD SEE 0-9 SEPARATED BY A SPACE:
0 1 2 3 4 5 6 7 8 9
YOU SHOULD SEE 0-9 (WITH NO SPACES):
0123456789
YOU SHOULD SEE A-G SEPARATED BY A SPACE:
A B C D E F G
YOU SHOULD SEE 0-5 SEPARATED BY TWO SPACES:
0 1 2 3 4 5
YOU SHOULD SEE TWO SEPARATE LINES:
LINE 1
LINE 2
YOU SHOULD SEE THE NUMBER RANGES OF SIGNED AND UNSIGNED NUMBERS:
SIGNED: -80000000 7FFFFFFF
UNSIGNED: 0 FFFFFFFF
TESTING INPUT: ACCEPT

PLEASE TYPE UP TO 80 CHARACTERS:
asd
RECEIVED: "asd"
TESTING DICTIONARY SEARCH RULES

GDX isn't unique.
End of Core word set tests

1 definition was hidden
ok
include postponetest.fs TESTING POSTPONE (
TESTING POSTPONE +LOOP
TESTING POSTPONE ."
TESTING POSTPONE ;
TESTING POSTPONE ABORT"
TESTING POSTPONE BEGIN
TESTING POSTPONE DO
s:\Forth\SwiftForth\bin\postponetest.fs
153: { : PDO6 ( PAT: {0 0},{0 0}{1 0}{1 1},{0 0}{1 0}{1 1}{2 0}{2 1}{2 2} ) >>> ,{0 ?

Gerry Jackson

unread,

Aug 1, 2019, 3:29:53 AM8/1/19

to

[ snipped core test output ]

>
> GDX isn't unique.
> End of Core word set tests
>
> 1 definition was hidden
> ok
> include postponetest.fs TESTING POSTPONE (
> TESTING POSTPONE +LOOP
> TESTING POSTPONE ."
> TESTING POSTPONE ;
> TESTING POSTPONE ABORT"
> TESTING POSTPONE BEGIN
> TESTING POSTPONE DO
> s:\Forth\SwiftForth\bin\postponetest.fs
> 153: { : PDO6 ( PAT: {0 0},{0 0}{1 0}{1 1},{0 0}{1 0}{1 1}{2 0}{2 1}{2 2} ) >>> ,{0 ?
>

I don't know what you mean here or what failed. The ,{0 is inside a
( ... ) comment so why is it queried?

I tried running postponetest.fs with SwiftForth after changing all the
{ ... } to T{ ... }T to match the tester.fr used in the test suite.
with this result:
----------------------------
SwiftForth i386-Win32 3.7.8 05-Jul-2019

( output from core tests deleted )

***YOU SHOULD SEE THIS FIRST.
YOU SHOULD SEE THIS LATER.
**
WRONG NUMBER OF RESULTS: T{ : PAQ1 [ POSTPONE-ABORT" THIS SHOULD NOT
ABORT" ] ; -> }T***********
WRONG NUMBER OF RESULTS: T{ : PSQ4 [ POSTPONE-S" XY" ] ; -> }T
d:\projects\forthapps\forthsystemtests\dev\postponetest.fs
302: T{ PSQ4 SWAP DROP -> 2 }T >>> Stack underflow
d:\projects\forthapps\forthsystemtests\anstests\src\runtests.fth
14: s" ..\..\dev\postponetest.fs" included
d:\projects\forthapps\forthsystemtests\anstests\portability\swifttestsboot.fth
6: s" runtests.fth" included
s"
d:\projects\forthapps\forthsystemtests\anstests\portability\swifttestsboot.fth"
included
Exit? (Yes/No/Edit)
------------------------------------

so it failed POSTPONE-ABORT and crashed with POSTPONE-S"

I commented out the crashing tests of S" and the output was:

-------------------------------------
SwiftForth i386-Win32 3.7.8 05-Jul-2019

***YOU SHOULD SEE THIS FIRST.
YOU SHOULD SEE THIS LATER.
**
WRONG NUMBER OF RESULTS: T{ : PAQ1 [ POSTPONE-ABORT" THIS SHOULD NOT
ABORT" ] ; -> }T***********
WRONG NUMBER OF RESULTS: T{ : PSQ4 [ POSTPONE-S" XY" ] ; -> }T******
--------------------------------------

Ignore the asterisks, they replace the TESTING xyz messages. Two failures.

--
Gerry

hughag...@gmail.com

unread,

Aug 1, 2019, 7:42:04 AM8/1/19

to

On Monday, July 29, 2019 at 11:34:50 AM UTC-7, Gerry Jackson wrote:
> Note
> 1. During the compilation of PPP4 the text interpreter never encounters
> the *name* POSTPONE and so doesn't try to interpret it. It interprets
> POSTPONE-POSTPONE which does have interpretation semantics.
>
> 2. Nowhere in the standard does it say that the word [ suspends or stops
> compilation of the current definition. It merely sets STATE to 0 and
> lets the text interpreter carry on.
>
> 3. Nowhere in the standard does it say that words whose compilation
> semantics are *indirectly* executed (such as POSTPONE via
> POSTPONE-POSTPONE in the definition of PPP4) between [ and ] cannot
> cause something to be compiled.
>
> 4. Nowhere in the standard does it say that the compilation semantics of
> POSTPONE depend on the value held in STATE.
>
> 5. I believe the above is true for the other words with undefined
> interpretation semantics.

This isn't true for any of the words with
undefined interpretation semantics.
If it were true, then words such as R> IF ABORT" etc. could be used
whenever STATE is zero, such as inside of [ ... ] brackets,
or even outside of colon definitions at the command-line!

Gerry Jackson believes that by burying the "no interpretation semantics"
word inside of disambiguifier with POSTPONE , he has quibbled away
the fact that it is being interpreted. This isn't true.
Just because its *name* isn't being found by the text interpreter
doesn't mean that it isn't being interpreted when it executes.

There is really no difference between executing a disambiguified word
or the pre-disambiguified word. It does the same thing either way.
The disambiguification only affects what FIND does when given the name
of the word. The disambiguifier allows FIND to find an xt, it allows
FIND to return the same xt whether STATE is true or false when FIND
executes, and it allows FIND to indicate that the word is immediate.
That is all that the disambiguifier does.
The disambiguifier doesn't give the word any new properties that
it didn't previously have, or change how it behaves in any way
(except you get a warning message when you execute it when STATE
is zero; this was always illegal, but you didn't get warned previously).

The disambiguifiers cause FIND to work.
For years I thought that FIND was irrevocably broken and hence that
ANS-Forth was utterly useless for cross-compilation.
Then I figured out how the disambiguifiers fix FIND
(actually, Anton Ertl told me about the disambiguifiers back in 2009
when I was just starting on ANS-Forth, but it took years to grok this).
The disambiguifiers cause FIND to work, which is a good thing.
The disambiguifiers don't have magical powers though -- they don't
allow words such as R> IF ABORT" etc. to work when STATE is zero ---
this continues to be illegal in ANS-Forth, as it should be.

> Conclusions
> 1. Hugh has missed the point about the "text interpreter encountering
> the name" and is mistaken in his belief that the interpretation
> semantics of POSTPONE are executed in PPP4.
> 2. Hugh shouldn't complain about the use of 'goofy terminology' (his
> words) such as compilation semantics, which are precisely defined,
> instead of using his own vague terminology.
> 3. Hugh should read the standard carefully before mistakenly ranting
> about it
> 4. Hugh should apologise to Anton and Alex for continually calling them
> liars
> 5. The disambiguifiers that Hugh continually (and I might say
> tiresomely) brags about are non-compliant with respect to the ANS Forth
> and Forth 2012 standards because the above code won't work. Furthermore
> a program using them wouldn't be a standard program.

Gerry Jackson has joined the liars Anton Ertl and Alex McDonald
in telling this preposterous lie, founded upon magical thinking.

Note that this isn't the first time that Gerry Jackson has tried to
"educate" me on a subject that he knows nothing about, after I had
written ANS-Forth code that worked.
He tried to educate me on how many comparisons m SORT-EIGHT requires
(he said 19) after I had already posted code that did the sort in
12 to 17 comparisons (Alex McDonald said a minimum of 16).

Gerry Jackson also tried to educate me on how to write SET-CONTEXT
in ANS-Forth that does what setting CONTEXT did in Forth-83.
Of course, he failed to write any code that works, and this was
after I had posted code that did work. He said that I didn't know
how SET-ORDER works, despite the fact that my code relies on
SET-ORDER and despite the fact that he didn't know what SET-ORDER does
(he didn't understand that SET-ORDER will clobber FORTH-WORDLIST
unless this "anchor" wid is explicitly checked for).

Gerry Jackson is a clown.
He is helping to discredit ANS-Forth with his lies and incompetence.

Anton Ertl

unread,

Aug 1, 2019, 8:02:26 AM8/1/19

to

dxforth <dxf...@gmail.com> writes:
>As previously stated I would regard as suspicious any interpretation
>that, 25 years on, suddenly invalidates existing implementations.

Postponetest.fs has existed since 1996, and there have been repeated
discussions on the topic here since that time. Forth, Inc. (for
example) could have implemented S" in a standard-compliant way in the
meantime; alternatively, they could have made a proposal for allowing
a STATE-smart implementation of S". There is nothing sudden about it.

And actually, STATE-smartness has been controversial for much longer.
E.g., [shaw88] discusses how to avoid STATE-smart words. And I guess
there was a reason why Forth-83 committee standardized ' and [']
rather than a STATE-smart word.

@Article{shaw88,
author = {George W. Shaw},
title = {Forth Shifts Gears},
journal = {Computer Language},
year = {1988},
pages = {67--75 (May), 61--65 (June)},
annote = {Discusses multiple code fields, their application
for implementing \texttt{value} and \texttt{defer},
and how they are implemented. Also discusses
state-smart words and how to use MCFs to avoid
them.}

}

>It's my observation those who make argument on the basis on what
>'ANS says' are often the same people who have no problem repealing
>what ANS said when it doesn't fit into their view of what Forth
>should be.

Of course. If you care about a standard, you propose changes in
places that you want to see improved.

A. K.

unread,

200x is controlled by 2 - possibly 3 - people at the most who will do
nothing that jeopardizes their position or contradicts the systems they
control - even if it is for the general benefit for Forth. Those are
the rules by which 'participants' in your Standard must play. I didn't
come to Forth for that. Neither, it would appear, is the wider world
interested.

A. K.

unread,

Aug 2, 2019, 3:23:05 AM8/2/19

to

Pardon me, but IMO that sounds too negative. Although I am not actively
participating in the process, I am a Forther since 40 years, so I know
a few Forth generations. The world is not perfect, so we have to be glad
about and thankful for those people who engage themselves in maintaining
and developing the Forth language. Intellectual discourse and exchange
of experiences and of different opinions are just necessary part of the
game. So are compromises. No reason to become personal.

Alex McDonald

unread,

Aug 2, 2019, 4:32:28 AM8/2/19

to

On 02-Aug-19 02:57, dxforth wrote:
> On Thursday, 1 August 2019 22:02:26 UTC+10, Anton Ertl wrote:
>> dxforth <dxf...@gmail.com> writes:
>>> As previously stated I would regard as suspicious any interpretation
>>> that, 25 years on, suddenly invalidates existing implementations.
>> Postponetest.fs has existed since 1996, and there have been repeated
>> discussions on the topic here since that time. Forth, Inc. (for
>> example) could have implemented S" in a standard-compliant way in the
>> meantime; alternatively, they could have made a proposal for allowing
>> a STATE-smart implementation of S". There is nothing sudden about it.
>
> While I've not looked at Postponetest.fs I can say with confidence its

Perhaps you should look. Making an effort to do a little research is a
usual precursor to intelligent discussion.

> existence since 1996 and your views as to which systems are "standard-
> compliant" is just personal opinion. ANS never endorsed it. Repeat
> it as much as you like. The idea ANS didn't foresee or allow a state-
> smart S" I find hard to believe.
>
> If Win32Forth happened to pass your previous POSTPONE-POSTONE test it
> was more by accident than planning. Any POSTPONE based on COMPILE runs
> the risk of crashing if there is no STATE check. The lack of a STATE
> check is why Win32F "passes". Good luck with a properly protected system.
> So when ANS said 'no interpretation' for POSTPONE it's *my* interpretation
> they intended 'not under any circumstances'.
>

Win32Forth is a hobbyist system.

"Win32Forth (including the integrated WinEd editor) is a public domain
Forth language development system. That means it is provided without
support. As time and inclination permit, we will at times update
Win32Forth and repair bugs that we decide to fix. However no warranty
for usability, reliability, correctness or any other characteristic is
provided or implied. If you choose to use Win32Forth for an application,
either personal or commercial, you assume the responsibility for its
usability, reliability, correctness and all other program
characteristics and warranty responsibilities.

Win32Forth is NOT bug free. It never will be. It is too large and
complicated for me [Tom Zimmer] or anyone else to ever find all the bugs
that can be hidden within it. As we become aware of bugs, we try to fix
them, but some things are better not fixed, so beware, there are
definite limits to Win32Forth's ability to crash gracefully. When we say
production, we mean it works. For at least 1 person, reliably and
regularly, and on a range of applications."

I think you may have meant SwiftForth.

--
Alex

Anton Ertl

unread,

Aug 2, 2019, 8:25:18 AM8/2/19

to

Not that I know of. I will scan it in the second half of August, and
make it available.

Alex McDonald

unread,

Aug 2, 2019, 8:30:25 AM8/2/19

to

On 02-Aug-19 13:19, Anton Ertl wrote:
> Alex McDonald <al...@rivadpm.com> writes:
>> On 01-Aug-19 12:47, Anton Ertl wrote:
>>> @Article{shaw88,
>>> author = {George W. Shaw},
>>> title = {Forth Shifts Gears},
>>> journal = {Computer Language},
>>> year = {1988},
>>> pages = {67--75 (May), 61--65 (June)},
>>> annote = {Discusses multiple code fields, their application
>>> for implementing \texttt{value} and \texttt{defer},
>>> and how they are implemented. Also discusses
>>> state-smart words and how to use MCFs to avoid
>>> them.}
>>> }
>>>
>>
>> I can't find this, not even in the ACM archives; there are contents
>> entries for the publication Computer Language but no downloadable
>> articles. Are there copies somewhere in the ether?
>
> Not that I know of. I will scan it in the second half of August, and
> make it available.

Many thanks.

>
> - anton
>

--
Alex

Anton Ertl

unread,

Aug 2, 2019, 9:17:49 AM8/2/19

to

dxforth <dxf...@gmail.com> writes:
>On Thursday, 1 August 2019 22:02:26 UTC+10, Anton Ertl wrote:
>> dxforth <dxf...@gmail.com> writes:
>> >As previously stated I would regard as suspicious any interpretation
>> >that, 25 years on, suddenly invalidates existing implementations.
>>
>> Postponetest.fs has existed since 1996, and there have been repeated
>> discussions on the topic here since that time. Forth, Inc. (for
>> example) could have implemented S" in a standard-compliant way in the
>> meantime; alternatively, they could have made a proposal for allowing
>> a STATE-smart implementation of S". There is nothing sudden about it.
>
>
>While I've not looked at Postponetest.fs I can say with confidence its
>existence since 1996 and your views as to which systems are "standard-
>compliant" is just personal opinion. ANS never endorsed it.

Just for reference, what did "ANS" (whoever that may be) endorse, and
where can I find out something about it?

>The idea ANS didn't foresee or allow a state-
>smart S" I find hard to believe.

The Forth-94 TC probably intended to make STATE-smart implementations
of S" standard, but forgot to put the necessary restrictions in.
However, while this topic has been discussed repeatedly, nobody (not
even anybody from Forth, Inc.) put in the effort to make a proposal
for such a restriction.

>If Win32Forth happened to pass your previous POSTPONE-POSTONE test it
>was more by accident than planning. Any POSTPONE based on COMPILE runs
>the risk of crashing if there is no STATE check.

Why should it? Just two weeks ago I tested a POSTPONE based on
COMPILE (under the name "(COMPILE)"), and it performs nicely on
Gforth, SwiftForth, and VFX
<2019Jul1...@mips.complang.tuwien.ac.at>. The source code is:

: (compile) ( -- ) r> dup cell+ >r @ compile, ;
: postpone ( "name" -- )
bl word find dup 0= abort" Can't compile "
0> IF compile, ELSE postpone (compile) , THEN ;
immediate

Why would a STATE check be necessary or in any way useful? This
POSTPONE also passes the test

: POSTPONE-POSTPONE
POSTPONE POSTPONE ;

: PPP1 123 ;
: PPP4 [ POSTPONE-POSTPONE PPP1 ] ; IMMEDIATE
: PPP5 PPP4 ;
PPP5 . \ prints 123

Actually the error message indicates that this POSTPONE is derived
from a COMPILE (in bigForth) that was coded probably as follows:

: compile ( "name" -- )
bl word find dup 0= abort" Can't compile "
compile (compile) , ; immediate
\ ^^^^^^^^^^^^^^^^^ can be replaced with "['] (compile) compile,"
\ if the cross-compiler does not have COMPILE.

So bigForth (a native-code system) turned the traditional COMPILE
(which works only on a traditional threaded-code system) into a parsing
version, and later into POSTPONE. POSTPONE must parse, so the problem
that the classical COMPILE (here under the name (COMPILE)) has when
used interpretively does not exist for POSTPONE.

One could imagine a ?COMP test in (COMPILE) to "protect" against its
use in interpret state. The test above would not trip this ?COMP.
One would need an additional test:

: ppp6 [ ppp4 ] ;
ppp6

But with the (COMPILE) as defined above, this test passes, too.

>The lack of a STATE
>check is why Win32F "passes". Good luck with a properly protected system.

Why the scary quotes around 'passes'? And what's proper about a
"protection" that produces a false alarm?

>So when ANS said 'no interpretation' for POSTPONE it's *my* interpretation
>they intended 'not under any circumstances'.

Forth-94 says:

|Interpretation semantics for this word are undefined.

That does not mean "Performing the compilation semantics of this word
in interpret state is not allowed".

>200x is controlled by 2 - possibly 3 - people at the most who will do
>nothing that jeopardizes their position or contradicts the systems they
>control - even if it is for the general benefit for Forth.

You claim that based on what? Who are these 2 or 3 people?

hughag...@gmail.com

unread,

Aug 2, 2019, 9:28:44 AM8/2/19

to

On Friday, August 2, 2019 at 1:32:28 AM UTC-7, Alex McDonald wrote:
> Win32Forth is NOT bug free. It never will be. It is too large and
> complicated for me [Tom Zimmer] or anyone else to ever find all the bugs
> that can be hidden within it. As we become aware of bugs, we try to fix

> them, but some things are better not fixed...
> --
> Alex

Alex McDonald seems to be telling us that he is Tom Zimmer. :-O

My experience with Win32Forth is that it has serious bugs.
I tried using the visual gui generator.
It was an unusable bug-ridden mess, released without any testing.
AFAIK, this was written by Alex McDonald.

hughag...@gmail.com

unread,

Aug 2, 2019, 9:48:57 AM8/2/19

to

On Friday, August 2, 2019 at 6:17:49 AM UTC-7, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
> >The lack of a STATE
> >check is why Win32F "passes". Good luck with a properly protected system.
>
> Why the scary quotes around 'passes'? And what's proper about a
> "protection" that produces a false alarm?
>
> >So when ANS said 'no interpretation' for POSTPONE it's *my* interpretation
> >they intended 'not under any circumstances'.
>
> Forth-94 says:
>
> |Interpretation semantics for this word are undefined.
>
> That does not mean "Performing the compilation semantics of this word
> in interpret state is not allowed".

Anton Ertl is really slinging bullshit here!
This use of Elizabeth Rather's goofy term "semantics" is obfuscation.
The word IF doesn't have multiple "semantics," whatever that means.
The word IF just does one thing, which is compile the code for
a conditional branch (traditionally it compiled 0BRANCH and also
left info on the stack so ELSE or THEN could fill in the operand later).
IF is traditionally immediate and it is used inside of colon definitions.
It is illegal to execute IF when STATE @ = 0 (interpret mode).

It actually makes sense to compiling words such as IF inside of
[ ... ] brackets, but unfortunately STATE is two-state and doesn't
distinguish between being in a colon definition inside of [ ... ] brackets
( STATE @ = 0) or being outside of a colon definition ( STATE @ = 0).
This is a bug in ANS-Forth. There is no way to fix ANS-Forth though,
because ANS-Forth is written in stone and fixed by ANSI in 1994.

Anton Ertl is trying to quibble away this problem.
He wants his code to be ANS-Forth by fiat, although it is actually illegal.
Most likely the code he is trying to claim is ANS-Forth is his GRAY program.
This is bullshit! Code that has compiling words executed inside
of [ ... ] brackets is not ANS-Forth because this was banned.
This has been true for common ANS-Forth programmers since 1994,
but now Anton Ertl wants to change this with magical thinking.

> >200x is controlled by 2 - possibly 3 - people at the most who will do
> >nothing that jeopardizes their position or contradicts the systems they
> >control - even if it is for the general benefit for Forth.
>
> You claim that based on what? Who are these 2 or 3 people?

Stephen Pelc, Elizabeth Rather (or her employee Leon Wagner),
and Anton Ertl. Forth Inc. is actually fading away though.
Stephen Pelc is the new Emperor of Forth and he is totally focused
on selling VFX. He cripples Forth-200x so it won't compete against VFX.
Anton Ertl seems to be angling for a job at MPE.

Gerry Jackson

unread,

Aug 2, 2019, 12:32:43 PM8/2/19

to

You either haven't read the argument I made or you are incapable of
understanding it, otherwise you would realise that, in the example being
discussed, which I repeat here since you snipped it:

: POSTPONE-POSTPONE
POSTPONE POSTPONE ;
: PPP1 123 ;
: PPP4 [ POSTPONE-POSTPONE PPP1 ] ; IMMEDIATE
: PPP5 PPP4 ;
PPP5 . \ prints 123

inside the [ ... ] brackets PPP1 is never seen by the text interpreter,
so how could it be interpreted?

I'll add POSTPONE to the list of things in the ANS standard you don't
understand or didn't know existed like ACCEPT, CATCH & THROW, GET-ORDER
& SET-ORDER, the fact that a cross compiler can be written in ANS Forth,
that disambiguifiers are not ANS Forth compliant ... oh yes and pointers.

>
> > existence since 1996 and your views as to which systems are "standard-
> > compliant" is just personal opinion. ANS never endorsed it. Repeat
> > it as much as you like. The idea ANS didn't foresee or allow a state-
> > smart S" I find hard to believe.
> >
> > If Win32Forth happened to pass your previous POSTPONE-POSTONE test it
> > was more by accident than planning. Any POSTPONE based on COMPILE runs
> > the risk of crashing if there is no STATE check. The lack of a STATE
> > check is why Win32F "passes". Good luck with a properly protected system.
> > So when ANS said 'no interpretation' for POSTPONE it's *my* interpretation
> > they intended 'not under any circumstances'.
> >
>
> Win32Forth is a hobbyist system.

So is Gforth - which Anton likes to claim is superior to all the others
because it implements things 'properly'.

>
> "Win32Forth (including the integrated WinEd editor) is a public domain
> Forth language development system. That means it is provided without
> support. As time and inclination permit, we will at times update
> Win32Forth and repair bugs that we decide to fix. However no warranty
> for usability, reliability, correctness or any other characteristic is
> provided or implied. If you choose to use Win32Forth for an application,
> either personal or commercial, you assume the responsibility for its
> usability, reliability, correctness and all other program
> characteristics and warranty responsibilities.
>
> Win32Forth is NOT bug free. It never will be. It is too large and
> complicated for me [Tom Zimmer] or anyone else to ever find all the bugs
> that can be hidden within it. As we become aware of bugs, we try to fix
> them, but some things are better not fixed, so beware, there are
> definite limits to Win32Forth's ability to crash gracefully. When we say
> production, we mean it works. For at least 1 person, reliably and
> regularly, and on a range of applications."
>
> I think you may have meant SwiftForth.

No. I mentioned Win32Forth because you held it up as example of an
threaded code system that worked with Anton's 'compliant code'. I've
looked at the Win32F code and concluded the mechanism by which it
worked was due to a vulnerability. To the extent nobody has documented
a case whereby Win32F has crashed as a result of the vulnerability (?)
it probably doesn't need a "fix" however that's not up to me. I use
Win32F about as much as I use SwiftForth, VFX, Gforth etc - only for
the occasional test. None are as convenient as having your own Forth.

>
> --
> Alex

gwj....@gmail.com

unread,

Aug 3, 2019, 1:13:28 AM8/3/19

to

Yes,that's your other debating tactic, pasting huge bits of previous posts that nobody bothers to read. I certainly haven't wasted my time doing so.

dxforth

unread,

Aug 3, 2019, 2:25:29 AM8/3/19

to

On Friday, 2 August 2019 17:23:05 UTC+10, A. K. wrote:
> Am Freitag, 2. August 2019 03:57:43 UTC+2 schrieb dxforth:

> > ...

> > 200x is controlled by 2 - possibly 3 - people at the most who will do
> > nothing that jeopardizes their position or contradicts the systems they
> > control - even if it is for the general benefit for Forth. Those are
> > the rules by which 'participants' in your Standard must play. I didn't
> > come to Forth for that. Neither, it would appear, is the wider world
> > interested.
>
> Pardon me, but IMO that sounds too negative. Although I am not actively
> participating in the process, I am a Forther since 40 years, so I know
> a few Forth generations. The world is not perfect, so we have to be glad
> about and thankful for those people who engage themselves in maintaining
> and developing the Forth language. Intellectual discourse and exchange
> of experiences and of different opinions are just necessary part of the
> game. So are compromises. No reason to become personal.

The results of 200x speak for themselves. Has Forth been advanced by
the reluctance of remaining vendors to adopt meaningful change or by the
novelties introduced by armchair experts on c.l.f.? Only if Forth were
dead or not worth it could one stand by and say nothing.

Alex McDonald

unread,

Aug 3, 2019, 7:31:52 AM8/3/19

to

On 03-Aug-19 05:58, dxforth wrote:
> On Friday, 2 August 2019 18:32:28 UTC+10, Alex McDonald wrote:
>> On 02-Aug-19 02:57, dxforth wrote:
>>> On Thursday, 1 August 2019 22:02:26 UTC+10, Anton Ertl wrote:
>>>> dxforth <dxf...@gmail.com> writes:
>>>>> As previously stated I would regard as suspicious any interpretation
>>>>> that, 25 years on, suddenly invalidates existing implementations.
>>>> Postponetest.fs has existed since 1996, and there have been repeated
>>>> discussions on the topic here since that time. Forth, Inc. (for
>>>> example) could have implemented S" in a standard-compliant way in the
>>>> meantime; alternatively, they could have made a proposal for allowing
>>>> a STATE-smart implementation of S". There is nothing sudden about it.
>>>
>>> While I've not looked at Postponetest.fs I can say with confidence its
>>
>> Perhaps you should look. Making an effort to do a little research is a
>> usual precursor to intelligent discussion.
>
> Intelligent discussion doesn't involve making pronouncements about what
> systems are standard-compliant when one isn't authorized to do so. Cf.
> Elizabeth who has been very careful not to say things in a way that could
> be construed as speaking on behalf of the ANS-TC.

Authorized? I and anyone else can have an opinion and express it on the
standard. Anyone can contribute to the Hayes tester.

No-one could mistake me or anyone else here as speaking on behalf of a
committee that hasn't met in over 25 years, with the possible exception
of Elizabeth, who was the chair of the TC. I suppose that might
constrain her; she's very polite and was probably chosen to be chair for
her diplomatic qualities.

(Hugh, you can STFU at this point.)

>
>>
>>> existence since 1996 and your views as to which systems are "standard-
>>> compliant" is just personal opinion. ANS never endorsed it. Repeat
>>> it as much as you like. The idea ANS didn't foresee or allow a state-
>>> smart S" I find hard to believe.
>>>
>>> If Win32Forth happened to pass your previous POSTPONE-POSTONE test it
>>> was more by accident than planning. Any POSTPONE based on COMPILE runs
>>> the risk of crashing if there is no STATE check. The lack of a STATE
>>> check is why Win32F "passes". Good luck with a properly protected system.
>>> So when ANS said 'no interpretation' for POSTPONE it's *my* interpretation
>>> they intended 'not under any circumstances'.
>>>
>>
>> Win32Forth is a hobbyist system.
>
> So is Gforth - which Anton likes to claim is superior to all the others
> because it implements things 'properly'.

It is, I would have thought, superior if it produces the right results
when compared to others that don't.

>
>>
>> "Win32Forth (including the integrated WinEd editor) is a public domain
>> Forth language development system. That means it is provided without
>> support. As time and inclination permit, we will at times update
>> Win32Forth and repair bugs that we decide to fix. However no warranty
>> for usability, reliability, correctness or any other characteristic is
>> provided or implied. If you choose to use Win32Forth for an application,
>> either personal or commercial, you assume the responsibility for its
>> usability, reliability, correctness and all other program
>> characteristics and warranty responsibilities.
>>
>> Win32Forth is NOT bug free. It never will be. It is too large and
>> complicated for me [Tom Zimmer] or anyone else to ever find all the bugs
>> that can be hidden within it. As we become aware of bugs, we try to fix
>> them, but some things are better not fixed, so beware, there are
>> definite limits to Win32Forth's ability to crash gracefully. When we say
>> production, we mean it works. For at least 1 person, reliably and
>> regularly, and on a range of applications."
>>
>> I think you may have meant SwiftForth.
>
> No. I mentioned Win32Forth because you held it up as example of an
> threaded code system that worked with Anton's 'compliant code'. I've

I haven't been involved with Win32Forth in nearly a decade. The
confusion is understandable; I was referring to WF32, a completely
different system. Names for Forth systems are quite difficult; there are
so many <x>forths already.

> looked at the Win32F code and concluded the mechanism by which it
> worked was due to a vulnerability. To the extent nobody has documented
> a case whereby Win32F has crashed as a result of the vulnerability (?)
> it probably doesn't need a "fix" however that's not up to me. I use
> Win32F about as much as I use SwiftForth, VFX, Gforth etc - only for
> the occasional test. None are as convenient as having your own Forth.

My Forth and the one I referred to in the POSTPONE test posts is a
native code compiler called WF32 that (now) passes the entire Hayes test
suite and the additional POSTPONE tests. I uncovered a problem running
Stephen Pelc's benchmarks due to an error in my LOCALS, but now it's
fixed, I'll update https://github.com/alextangent/wf32 in the next
couple of weeks.

--
Alex

unread,

Aug 12, 2019, 9:32:29 PM8/12/19

to

On Saturday, 3 August 2019 21:31:52 UTC+10, Alex McDonald wrote:
> On 03-Aug-19 05:58, dxforth wrote:

> > ...

> > Intelligent discussion doesn't involve making pronouncements about what
> > systems are standard-compliant when one isn't authorized to do so. Cf.
> > Elizabeth who has been very careful not to say things in a way that could
> > be construed as speaking on behalf of the ANS-TC.
>
> Authorized? I and anyone else can have an opinion and express it on the
> standard. Anyone can contribute to the Hayes tester.

Yes, authorized. It's a matter of fact the Hayes tester was never
sanctioned by the ANS TC. It was somebody's interpretation of the
ANS doc put into code. So when you say:

"ANS tests; failing POSTPONETEST.FTH POSTPONE POSTPONE"

you are not testing against ANS but a string of opinions about ANS.

It's also a fact 200x has accepted the Hayes tester and whatever
additions it sees fit to authorize. Consequently a person may assert
their system passes the 200x tests but they can't say it passes the
'ANS tests' because the latter never authorized any.

That 200x leaders continue to refer to 'what ANS requires' is telling.
ANS is the authority to which they appeal to standard followers.
When they tell you ANS needs to be changed, it's on their authority
and chances are if you accepted one authority you'll accept the other.

hughag...@gmail.com

unread,

Aug 12, 2019, 11:09:43 PM8/12/19

to

On Saturday, August 3, 2019 at 4:31:52 AM UTC-7, Alex McDonald wrote:
> Authorized? I and anyone else can have an opinion and express it on the
> standard. Anyone can contribute to the Hayes tester.

This whole thread started because Anton Ertl and Alex McDonald
had been repeatedly lying about ANS-Forth.
They said that "no interpretation semantics" words can be
executed inside of [ ... ] brackets. This is despite the fact
that ANS-Forth section 4.1.2 (Ambiguous Conditions) includes:
"interpreting a word with undefined interpretation semantics."
Gerry Jackson then joined in and began lying about this too!
He tried to quibble the word "interpret" although everybody
knows that this means STATE @ = 0
(which it is inside of [ ... ] brackets).

ANS-Forth is not a standard at all because blatant liars can
express their opinion, and if they brown-nose Elizabeth Rather,
then their opinion is accepted by the ANS-Forth cult.

> No-one could mistake me or anyone else here as speaking on behalf of a
> committee that hasn't met in over 25 years, with the possible exception
> of Elizabeth, who was the chair of the TC. I suppose that might
> constrain her; she's very polite and was probably chosen to be chair for
> her diplomatic qualities.
>
> (Hugh, you can STFU at this point.)

I agree that Elizabeth Rather has awesome diplomatic qualities!

In 1994 there were a lot of incompatible Forth systems in use,
so code was not portable, causing an obvious need for a standard.
Elizabeth Rather wanted to get as many Forth system developers
as possible to sign on to ANS-Forth, so she told all of them
that they were ANS-Forth compliant!
Elizabeth Rather was the Fairy Godmother of ANS-Forth.
She would tap each TC member on the top of the head
with her magic wand and say: "You are ANS-Forth compliant!"
The problem, of course, was that none of their systems were
compatible and code was not portable between their system
(this, alert readers will remember, was the problem with
not having a standard that indicated the need for a standard).

So, ANS-Forth accomplished nothing.
ANS-Forth became a standard that doesn't standardize anything.
Now, 1/4 century later, Alex McDonald says that anybody's
opinion about ANS-Forth is valid
(by "anybody" he means any brown-noser of Elizabeth Rather,
but he most certainly does not mean that my opinion is valid).

To obtain a Forth standard, "diplomatic qualities" are not needed.
What is needed, is a backbone.
An ambiguous standard is less than worthless.
Decisions need to be made one way or the other.
Then it is necessary to tell every Forth system developer:
"If your system doesn't conform, you must change it to conform,
in order to be standard compliant.
If you are unwilling to do so, then you are non-standard."

Also, the decisions being made have to make sense.
You can't just say that PolyForth is inherently standard compliant,
because PolyForth is a crap Forth system that doesn't make sense.
Garbage in, garbage out!

Alex McDonald

unread,

Aug 13, 2019, 4:45:20 AM8/13/19

to

On 13-Aug-19 02:32, dxforth wrote:
> On Saturday, 3 August 2019 21:31:52 UTC+10, Alex McDonald wrote:
>> On 03-Aug-19 05:58, dxforth wrote:
>>> ...
>>> Intelligent discussion doesn't involve making pronouncements about what
>>> systems are standard-compliant when one isn't authorized to do so. Cf.
>>> Elizabeth who has been very careful not to say things in a way that could
>>> be construed as speaking on behalf of the ANS-TC.
>>
>> Authorized? I and anyone else can have an opinion and express it on the
>> standard. Anyone can contribute to the Hayes tester.
>
> Yes, authorized.

By whom? There is no surviving authority, just a copyright by ANS and
ISO on their finalized documents. The successor to ANS X3J14 was INCITS
J14, which disbanded the committee prior to 2015.
http://www.incits.org/dotAsset/2d4a0a6d-0117-4f95-b788-6a0e0fd30f78.pdf

> It's a matter of fact the Hayes tester was never
> sanctioned by the ANS TC.

The Forth 200x Standardisation Committee was formed in 2004 to allow the
Forth community to contribute to an updated standard. The Hayes tester
postdates ANS but predates Forth200x;

"After the publication of the original ANS Forth document (ANSI
X3.215-1994), John Hayes developed a test suite, which included both a
test harness and a suite of core tests."

The tester represents an individual's and now community's effort to
standardize (informally so far) specifications in the existing standard,

> It was somebody's interpretation of the
> ANS doc put into code. So when you say:>
> "ANS tests; failing POSTPONETEST.FTH POSTPONE POSTPONE"
>
> you are not testing against ANS but a string of opinions about ANS.

The original specification omitted to have any conformance tests. I'll
note that in a footnote and add your splendid text above the next time I
post.

>
> It's also a fact 200x has accepted the Hayes tester and whatever
> additions it sees fit to authorize. Consequently a person may assert
> their system passes the 200x tests but they can't say it passes the
> 'ANS tests' because the latter never authorized any.
>
> That 200x leaders continue to refer to 'what ANS requires' is telling.
> ANS is the authority to which they appeal to standard followers.
> When they tell you ANS needs to be changed, it's on their authority
> and chances are if you accepted one authority you'll accept the other.

Here, for your information, is NIST conformance testing advice.
https://www.nist.gov/itl/ssd/information-systems-group/conformance-testing.
This thinking is recent in terms of the ANS spec; in the early 1990s
when the ANS X3J14 was doing its work, little thought was given to it.

"The general definition for conformance has changed over time and been
refined for specific standards. In 1991, ISO/IEC DIS 10641 defined
conformance testing as "test to evaluate the adherence or non-adherence
of a candidate implementation to a standard." ISO/IEC TR 13233 defined
conformance and conformity as "fulfillment by a product, process or
service of all relevant specified conformance requirements."

Neither was a reference implementation considered. The original goals of
gforth included such a wish;
https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Goals.html#Goals including
the claim "Gforth conforms to the ANS Forth standard." MPE claims "ANS
standard Forth with many extensions". SwiftForth from Forth Inc. claims
"SwiftForth was implemented for ANS Forth compliance, and includes a
copy of the Hayes compliance test suite."

Conformance is being added to the spec in Forth200x. That some have
recognised this issue is laudable, and I for one support their work to
rectify the omission.

--
Alex

hughag...@gmail.com

unread,

Aug 13, 2019, 10:35:37 PM8/13/19

to

On Tuesday, August 13, 2019 at 1:45:20 AM UTC-7, Alex McDonald wrote:
> Here, for your information, is NIST conformance testing advice.
> https://www.nist.gov/itl/ssd/information-systems-group/conformance-testing.
> This thinking is recent in terms of the ANS spec; in the early 1990s
> when the ANS X3J14 was doing its work, little thought was given to it.

The ANS-Forth TC gave "little thought" to conformance testing because
the only test is whether the Fairy Godmother taps the sycophant
on his head with her magic wand and says: "You're ANS-Forth compliant!"

ANS-Forth is a muddle of ambiguity resulting from Elizabeth Rather's
"diplomatic qualities" that involve liberal use of the magic wand
on incompatible Forth systems allowing everybody to claim to be
standard, so they would sign on to the ANS-Forth "grassroots effort"
that has the Forth Inc. marketing-department head as its chair-person.

Here is an example:
--------------------------------------------------------------------
The control-flow stack may, but need not, physically exist
in an implementation. If it does exist, it maybe, but need not be,
implemented using the data stack. The format of the control-flow stack
is implementation defined. Since the control-flow stack may be implemented
using the data stack, items placed on the data stack are unavailable
to a program after items are placed on the control-flow stack
and remain unavailable until the control-flow stack items are removed.
--------------------------------------------------------------------

How exactly do you test an ANS-Forth system for compliance?

> Neither was a reference implementation considered.

LOL

> Conformance is being added to the spec in Forth200x. That some have
> recognised this issue is laudable, and I for one support their work to
> rectify the omission.

Just press the flush lever --- if Elizabeth Rather's marketing gimmick
makes whoosh as it goes down the drain, then it has conformed to
every meaningful test that a pile of poo can conform to.

dxforth

unread,

Aug 13, 2019, 10:55:47 PM8/13/19

to

On Tuesday, 13 August 2019 18:45:20 UTC+10, Alex McDonald wrote:
> On 13-Aug-19 02:32, dxforth wrote:
> > On Saturday, 3 August 2019 21:31:52 UTC+10, Alex McDonald wrote:

> ...

> >> Authorized? I and anyone else can have an opinion and express it on the
> >> standard. Anyone can contribute to the Hayes tester.
> >
> > Yes, authorized.
>
> By whom?

The ANS TC - the only body in a position to confirm/deny opinion about
the doc by means of a vote.

> There is no surviving authority […]

Exactly. So anything unconfirmed by the ANS TC amounts to opinion.

> > It's a matter of fact the Hayes tester was never
> > sanctioned by the ANS TC.
>
> The Forth 200x Standardisation Committee was formed in 2004 to allow the
> Forth community to contribute to an updated standard. The Hayes tester
> postdates ANS but predates Forth200x;

Hayes test suite I have is dated 1995. It's likely the ANS TC knew
of it given Hayes was a representative of John Hopkins at ANS.

> "After the publication of the original ANS Forth document (ANSI
> X3.215-1994), John Hayes developed a test suite, which included both a
> test harness and a suite of core tests."
>
> The tester represents an individual's and now community's effort to
> standardize (informally so far) specifications in the existing standard,
>
> > It was somebody's interpretation of the
> > ANS doc put into code. So when you say:>
> > "ANS tests; failing POSTPONETEST.FTH POSTPONE POSTPONE"
> >
> > you are not testing against ANS but a string of opinions about ANS.
>
> The original specification omitted to have any conformance tests. I'll
> note that in a footnote and add your splendid text above the next time I
> post.

ANS didn't include any conformance tests. It doesn't follow that it
was an omission. I recall reading discussions of the time asking
whether the TC would certify systems as ANS-compliant. The response
IIRC was that the TC declined to do so.

The problem posed by a test suite is that of overt/inadvertent omission/inclusion which I raised at the time 200x was considering
incorporating it. I can give the example of REPRESENT which has
omissions leaving it open to interpretation. Any test based on the
spec would be useless/misleading to users and implementers alike.

dxforth

unread,

Aug 14, 2019, 12:26:18 AM8/14/19

to

On Wednesday, 14 August 2019 12:35:37 UTC+10, hughag...@gmail.com wrote:
> ..

> ANS-Forth is a muddle of ambiguity resulting from Elizabeth Rather's
> "diplomatic qualities" that involve liberal use of the magic wand
> on incompatible Forth systems allowing everybody to claim to be
> standard, so they would sign on to the ANS-Forth "grassroots effort"
> that has the Forth Inc. marketing-department head as its chair-person.

It was 200x that was billed as a "grassroots effort". At 15 years it
must hold a world record for the longest time anyone has sat producing
a computing language standard. In the meantime those who have wanted
to do anything with Forth have moved on.

Alex McDonald

unread,

Aug 14, 2019, 8:46:07 AM8/14/19

to

On 14-Aug-19 03:55, dxforth wrote:
> On Tuesday, 13 August 2019 18:45:20 UTC+10, Alex McDonald wrote:
>> On 13-Aug-19 02:32, dxforth wrote:
>>> On Saturday, 3 August 2019 21:31:52 UTC+10, Alex McDonald wrote:
>> ...
>>>> Authorized? I and anyone else can have an opinion and express it on the

. =======

>>>> standard. Anyone can contribute to the Hayes tester.
>>>
>>> Yes, authorized.
>>
>> By whom?
>
> The ANS TC - the only body in a position to confirm/deny opinion about
> the doc by means of a vote.
>
>> There is no surviving authority […]
>
> Exactly. So anything unconfirmed by the ANS TC amounts to opinion.

Which, if you look up a little to where I've marked it, is exactly what
I said in my first post.

>
>>> It's a matter of fact the Hayes tester was never
>>> sanctioned by the ANS TC.
>>
>> The Forth 200x Standardisation Committee was formed in 2004 to allow the
>> Forth community to contribute to an updated standard. The Hayes tester
>> postdates ANS but predates Forth200x;
>
> Hayes test suite I have is dated 1995. It's likely the ANS TC knew
> of it given Hayes was a representative of John Hopkins at ANS.

That's a matter of opinion. But see below; it doesn't invalidate the effort.

>
>> "After the publication of the original ANS Forth document (ANSI
>> X3.215-1994), John Hayes developed a test suite, which included both a
>> test harness and a suite of core tests."
>>
>> The tester represents an individual's and now community's effort to
>> standardize (informally so far) specifications in the existing standard,
>>
>>> It was somebody's interpretation of the
>>> ANS doc put into code. So when you say:>
>>> "ANS tests; failing POSTPONETEST.FTH POSTPONE POSTPONE"
>>>
>>> you are not testing against ANS but a string of opinions about ANS.
>>
>> The original specification omitted to have any conformance tests. I'll
>> note that in a footnote and add your splendid text above the next time I
>> post.
>
> ANS didn't include any conformance tests. It doesn't follow that it
> was an omission. I recall reading discussions of the time asking
> whether the TC would certify systems as ANS-compliant. The response
> IIRC was that the TC declined to do so.

An omission is not necessarily deliberate. I can find absolutely no
written evidence that this was brought to the TC for consideration.

In general, that a TC declines to certify systems is pretty obvious; no
TC in its right mind wants to do that, and it's way outside the remit of
an ANS or ISO standards TC project scope.

The only example of official compiler validation I know of is Ada.
https://www.adaic.org/ada-resources/standards/ada-95-documents/acaa/.
The Ada Conformity Assessment Authority (ACAA) certifies testing that is
carried out by third parties, not by ANSI or ISO. And nowhere is the Ada
TC involved.

None of the venerable C, C++ or Fortran do this kind of testing either,
or even provide a test suite. As an example, Fortran; there was an
unofficial NIST test suite for Fortran77, and a test suite called
SHAPE95, started by two individuals and supported by a community effort
for Fortran 95. There's no test suite I can find for Fortran 2003.

We're in the same position as everyone else. From comp.lang.fortran;

==============

> But then what are the
> criteria for 'full F2003 compliance'? If a compiler-writer
> claims that he has a 'full F2003 compliant compiler', then what are
> the criteria that he uses to support his statement?

Ultimately, good faith and his reputation. It's a hard standard to
read (or to write books about, as Richard can tell you) and there is no
official test or validation program. Real vendors won't claim
to support it unless they really think they do. And, they'll do
their best to fix any omissions or errors. There is an interpretation
process that will get J3 to give an official answer to a specific
question. For the past many years, essentially all of the interp
questions have come from compiler writers who are trying to understand
the standard.

It's not a great situation. The best advice is to get several
compilers and try your code on several of them--with full error
checking and standards conformance options turned on.

Dick Hendrickson

==============

The Dick Hendrickson was one of the authors of SHAPE95; the Richard
referred to was Richard Maine, the editor of the Fortran2003 standard.
That was written in 2007, so a lack of conformance tests isn't a new
problem.

I'd refer you to "For the past many years, essentially all of the
interp[retation] questions have come from compiler writers who are
trying to understand the standard." Since the J3 committee is still
active, at least they can get an authoritative answer. Forthers can't,
since J14 is quite dead. So the current Forth200x committee and places
like CLF is the best we have.

I'm with Dick and his assertion that it's all "Ultimately, good faith
and [the compiler writer's] reputation". The authority you assign to the
ANS TC is pointless; it passed into history when J13 was disbanded. That
some in the community have set up an effort to provide learned opinion
and further development is a positive move; I fail to see why you would
want to rip it down.

Elsewhere you say (in reply to the odious Hugh Aguilar)

> It was 200x that was billed as a "grassroots effort". At 15 years it
> must hold a world record for the longest time anyone has sat producing
> a computing language standard. In the meantime those who have wanted
> to do anything with Forth have moved on.

I think the 15 year effort is the right kind of standards setting. There
is absolutely no point in having a dynamic language and a static
standard; look at previous Forth standards for case studies.

Every year, Forth200x provides a set of opinions on ANS and additions in
its own right. There's a lot to like about that kind of flexible and
progressive activity.

Perhaps you might like to explain where you think those who have wanted
to do anything with Forth have moved to; as Forth200x should surely
follow, and I'm not seeing that happening.

>
> The problem posed by a test suite is that of overt/inadvertent > omission/inclusion which I raised at the time 200x was considering
> incorporating it. I can give the example of REPRESENT which has
> omissions leaving it open to interpretation. Any test based on the
> spec would be useless/misleading to users and implementers alike.
>

Then the standard wording of REPRESENT is useless if practical examples
that test the specification can't be agreed upon. That's one of the
values of something like the Hayes tester; it tests everyone's
understanding of the spec.

--
Alex

hughag...@gmail.com

unread,

Aug 14, 2019, 1:58:01 PM8/14/19

to

This thread started out with the odious sycophant Gerry Jackson
attacking me:

On Friday, August 2, 2019 at 9:32:43 AM UTC-7, Gerry Jackson wrote:
> I'll add POSTPONE to the list of things in the ANS standard you don't
> understand or didn't know existed like ACCEPT, CATCH & THROW, GET-ORDER
> & SET-ORDER, the fact that a cross compiler can be written in ANS Forth,
> that disambiguifiers are not ANS Forth compliant ... oh yes and pointers.

When Gerry Jackson says that I don't know what pointers are,
this is a reference to the odious sycophant Alex McDonald who spent
over 4 years saying that I have:
"a serious misunderstanding of how pointers work."

On Wednesday, August 14, 2019 at 5:46:07 AM UTC-7, Alex McDonald wrote:
> On 14-Aug-19 03:55, dxforth wrote:
> Elsewhere you say (in reply to the odious Hugh Aguilar)
>
> > It was 200x that was billed as a "grassroots effort". At 15 years it
> > must hold a world record for the longest time anyone has sat producing
> > a computing language standard. In the meantime those who have wanted
> > to do anything with Forth have moved on.
>
> I think the 15 year effort is the right kind of standards setting. There
> is absolutely no point in having a dynamic language and a static
> standard; look at previous Forth standards for case studies.

ANS-Forth was presented as representing the Forth community, as if it were
a "grassroots effort" rather than a Forth Inc. marketing gimmick.
I find Elizabeth Rather's insult to the Forth community to be odious!

Forth-200x is a long-running circle-jerk with no conclusion expected.
All of the odious Forth-200x sycophants get a thrill out of pretending
to be the experts on Forth who set the standard for mere Forth programmers
such as myself. They aren't going to conclude the fun. They will spend
another 15 years debating idiotic nonsense such as recognizers that have
nothing to do with Forth programming. They avoid Forth programming,
but they endlessly debate with each other on the subject.

Stephen Pelc wants the Forth-200x circle-jerk to continue forever
because it puts his competition in a box labeled: "non-producing idiots."
Stephen Pelc wants to tell his prospective clients:
----------------------------------------------------------------------
If you have a lot of free time on your hands you can join the
Forth-200x mailing list to debate endlessly about the formal definition
for what Forth is, with "experts" such as JennyB who says:

On Thursday, May 30, 2019 at 8:11:04 AM UTC-7, JennyB wrote:
> Don't count me an expert; Forth has only ever been a hobby with me,
> as a way of playing with language. I mostly write poems these days.

If you are a super-duper "expert" like Peter Knaggs, who is incapable
of implementing a linked-list in Forth, we may even appoint you
to the Forth-200x committee! This is the perfect job for a narcissist
who enjoys strutting and pontificating in front of a video camera.

As a Forth-200x sycophant you are expected to be a liar. For example,
Anton Ertl and Bernd Paysan (Forth-200x committee members)
wrote a EuroForth-2018 paper attacking rquotations in which they said:
"the higher-order word that calls the rquotation must not use locals."
If you are comfortable with lying, then join the Forth-200x sycophants!
Anton Ertl is the referee for EuroForth, so liars are encouraged to join.

If you want to actually use Forth for some practical purpose however,
then you have to buy VFX ($$$) and ignore both ANS-Forth and Forth-200x
because I routinely ignore ANS-Forth even when this is not necessary.
For example, I wrote SYNONYM in VFX specific code despite the fact
that it is trivial to write in ANS-Forth given the disambiguifiers.
Ignoring ANS-Forth and Forth-200x is the professional Forth way!
----------------------------------------------------------------------

> Every year, Forth200x provides a set of opinions on ANS and additions in
> its own right. There's a lot to like about that kind of flexible and
> progressive activity.

The Forth-200x committee find a lot to like about Alex McDonald too!
Alex McDonald claims to: "do standards for a living."
He has spent his life on his knees groveling before various committees.
What is not to like?

This phrase seems quite humorous to me:
"flexible and progressive activity."
Perhaps John Passaniti can explain what this activity is!

> Perhaps you might like to explain where you think those who have wanted
> to do anything with Forth have moved to; as Forth200x should surely
> follow, and I'm not seeing that happening.

In 1994 there was a mass exodus abandoning Forth and switching over to C.
UR/Forth was the de facto standard in the early 1990s.
ANS-Forth declared UR/Forth to be non-standard, but did not provide
a working ANS-Forth compiler, so the UR/Forth crowd just switched to C.

Alex McDonald pretends that Forth-200x is a massive movement.
There are actually fewer than 20 Forth-200x enthusiasts though.
This is less than half the number of Heaven's Gate cult members.

dxforth

unread,

Aug 15, 2019, 12:32:46 AM8/15/19

to

On Wednesday, 14 August 2019 22:46:07 UTC+10, Alex McDonald wrote:
> ...

> The authority you assign to the
> ANS TC is pointless; it passed into history when J13 was disbanded.

It's the authority of the ANS TC that you are using every time you quote
a passage from ANS.

> That
> some in the community have set up an effort to provide learned opinion
> and further development is a positive move; I fail to see why you would
> want to rip it down.

We are all subject to scrutiny. Forth Standards however deserve greater
attention by virtue of their ability to make Forth look like an idiot.

>
> Elsewhere you say (in reply to the odious Hugh Aguilar)
>
> > It was 200x that was billed as a "grassroots effort". At 15 years it
> > must hold a world record for the longest time anyone has sat producing
> > a computing language standard. In the meantime those who have wanted
> > to do anything with Forth have moved on.
>
> I think the 15 year effort is the right kind of standards setting. There
> is absolutely no point in having a dynamic language and a static
> standard; look at previous Forth standards for case studies.

Why has 200x taken 15 years and nothing of substance to show? It's a
mirror of c.l.f. and like the latter goes on forever until you tire of it.

NN

unread,

Aug 15, 2019, 4:47:15 AM8/15/19

to

From my perspective, seems to me that being in 200x is a thankless task. I
would say they are doing the best they can. But your statement did make me
wonder, what do mean when you say "nothing of substance to show", what did
you expect to change in 15 years ?

Kerr-Mudd,John

unread,

Aug 15, 2019, 5:43:58 AM8/15/19

to

On Wed, 14 Aug 2019 17:58:00 GMT, hughag...@gmail.com wrote:

> This thread started out with the odious sycophant Gerry Jackson
> attacking me:

>

> ANS-Forth was presented as representing the Forth community, as if it
> were a "grassroots effort" rather than a Forth Inc. marketing gimmick.
> I find Elizabeth Rather's insult to the Forth community to be odious!

> Stephen Pelc wants the Forth-200x circle-jerk to continue forever
> because it puts his competition in a box labeled: "non-producing
> idiots." Stephen Pelc wants to tell his prospective clients:

>

> If you are a super-duper "expert" like Peter Knaggs, who is incapable
> of implementing a linked-list in Forth, we may even appoint you
> to the Forth-200x committee! This is the perfect job for a narcissist
> who enjoys strutting and pontificating in front of a video camera.
>
> As a Forth-200x sycophant you are expected to be a liar. For example,
> Anton Ertl and Bernd Paysan (Forth-200x committee members)
> wrote a EuroForth-2018 paper attacking rquotations in which they said:
> "the higher-order word that calls the rquotation must not use locals."
> If you are comfortable with lying, then join the Forth-200x
> sycophants! Anton Ertl is the referee for EuroForth, so liars are
> encouraged to join.

> The Forth-200x committee find a lot to like about Alex McDonald too!
> Alex McDonald claims to: "do standards for a living."
> He has spent his life on his knees groveling before various
> committees. What is not to like?
>
> This phrase seems quite humorous to me:
> "flexible and progressive activity."
> Perhaps John Passaniti can explain what this activity is!
>

>

unread,

Aug 15, 2019, 12:43:50 PM8/15/19

to

On Thursday, August 15, 2019 at 9:09:21 AM UTC-7, a...@littlepinkcloud.invalid wrote:
> NN <novembe...@gmail.com> wrote:
> > On Thursday, 15 August 2019 05:32:46 UTC+1, dxforth wrote:
> >> Why has 200x taken 15 years and nothing of substance to show? It's a
> >> mirror of c.l.f. and like the latter goes on forever until you tire of it.
> >
> > From my perspective, seems to me that being in 200x is a thankless task.
>

> How can any sane person claim that there is
> nothing of substance to show?
>
> Andrew.

Being in Forth-200x is a thankless task because
Forth-200x is a purely negative contribution to Forth.
You don't deserve thanks; you deserve condemnation.
The most notable feature of Forth-200x is recognizers,
but that has nothing to do with writing Forth programs.

I am primarily opposed to Forth-200x claiming to be the Standard
for Forth --- I take this as a personal insult.
I wouldn't care about it if it had an honest name,
such as Recognizer Forth --- if it was just presented as
the goofy attempt by Anton Ertl (not a professional programmer)
to design a version of Forth with complicated syntax and a
monolithic interpreter to parse the source-code.

Note that Andrew Haley's background in Forth was teaching the
novice class for Forth Inc.. He is not a Forth programmer.
His career in Forth is based entirely on agreeing with
Elizabeth Rather on comp.lang.forth. He is her "pocket boy."
He failed at implementing <SWITCH but, given his history as a teacher,
he chose to go to EuroForth to strut in front of the video camera
pretending to be the world's expert on <SWITCH in Forth:
https://groups.google.com/forum/#!topic/comp.lang.forth/9IHvRJmMn20
I took this as a personal insult because I implemented <SWITCH years ago.

Alex McDonald

unread,

Aug 15, 2019, 2:44:33 PM8/15/19

to

On 15-Aug-19 16:53, Anton Ertl wrote:
> NN <novembe...@gmail.com> writes:
>>From my perspective, seems to me that being in 200x is a thankless task.
>
> From my perspective, the reward is that, as a programmer, I can now
> use more features in my standard-conformant code that would otherwise
> have been system-specific extensions.
>
> But sometimes I wonder if that is worth the effort, and if I should
> not just publish code with such features, and leave it to the users of
> Forth systems to complain to their system implementor that they want
> that feature to run my code.

It's worth the effort. The naysayers are few. There's Hugh, who is in a
state of perpetually taking insult and inchoate rage. dxforth has some
valid concerns but seems to see the standard as being set in tablets of
ANS TC stone. S/he doesn't approve but s/he is unclear as to what should
be done. This confuses me.

There's the usual Greek chorus with a variable membership, but that's to
be expected; it's usenet.

>
>> I
>> would say they are doing the best they can. But your statement did make me
>> wonder, what do mean when you say "nothing of substance to show", what did
>> you expect to change in 15 years ?
>
> Apparently what we have to show is not to his liking. He's not the
> first and he won't be the last.
>
> In any case, what we have to show can mostly be found on
> www.forth200x.org. There you find the various accepted (and other)
> proposals, you find the Forth-2012 document (also at
> <http://forth-standard.org/standard/words>) and the various documents
> (including the latest draft) at <http://www.forth200x.org/documents/>.
>
> - anton
>

I looked again at the committee and contributors, the "we" in your reply.

Prof. Sergey Baranov
Paul E. Bennet
Willem Botha
Dr. M. Anton Ertl
Andrew Haley
Dr. Ulrich Hoffmann
Dr. Peter Knaggs (Editor)
Howerd Oakford
Bernd Paysan (Treasure)
Stephen Pelc (Chair)
Leon Wagner
Gerald Wodni (Technical)
Federico de Ceballos
Dr. Bill Stoddart
Dr. Willi Stricker
Carsten Strotmann
John Hayes
Marcel Hendrix
Gerry Jackson
Alex McDonald
Bruce McFarling
Charles G. Montgomery
Krishna Myneni
Tim Partridge
Elizabeth Rather
David N. Williams

That's quite a list and a huge positive. There's no reason to stop
because of one or two dismissive comments on clf.

--
Alex

Krishna Myneni

unread,

Aug 15, 2019, 7:41:55 PM8/15/19

to

On Thu, 15 Aug 2019 15:53:32 +0000, Anton Ertl wrote:

> NN <novembe...@gmail.com> writes:
>>From my perspective, seems to me that being in 200x is a thankless task.
>
> From my perspective, the reward is that, as a programmer, I can now use
> more features in my standard-conformant code that would otherwise have
> been system-specific extensions.
>

I agree. For some applications I prefer to write code which is highly
portable. This is the only way to get feedback from other interested
users, to make it as simple as possible for them to execute it with a
variety of Forth systems. Feedback is essential for development.

> But sometimes I wonder if that is worth the effort, and if I should not
> just publish code with such features, and leave it to the users of Forth
> systems to complain to their system implementor that they want that
> feature to run my code.
>

Yes, it's worth the effort! I refer to both the ANS Forth document and to
the Forth-2012 document frequently, as a Forth system developer and as a
Forth programmer. Indeed, the kForth-32 github project includes the
Forth-2012 spec in its doc/ folder (the 64-bit version will as well).
Even though my system was intended to go past some conventional Forth
constraints, I can and do write code that is compatible with systems
which aim for a higher degree of conformance to the specs. I have also
find it fairly easy to adapt code written to the specs to run under my
system. A Forth system does not have to be highly conformant to the spec
in order for the spec to be very useful to that system!

>>I
>>would say they are doing the best they can. But your statement did make
>>me wonder, what do mean when you say "nothing of substance to show",
>>what did you expect to change in 15 years ?
>

I appreciate the effort that the unofficial standards committee puts into
it and, in any group effort such as this, there will be politics.
Consensus may not always produce the best result but it is likely to
improve the product more often than not. The Forth-2012 document, which
borrows considerably from the ANS Forth documentation, clearly took a lot
of effort and deliberation. Legitimate concerns about a revision to the
unofficial standard should be evaluated fairly. However, people who only
provide constant negative feedback clearly don't understand the magnitude
of the effort.

...

Krishna

hughag...@gmail.com

unread,

Aug 15, 2019, 10:43:42 PM8/15/19

to

On Thursday, August 15, 2019 at 4:41:55 PM UTC-7, Krishna Myneni wrote:
> On Thu, 15 Aug 2019 15:53:32 +0000, Anton Ertl wrote:
>
> > NN <novembe...@gmail.com> writes:
> >>From my perspective, seems to me that being in 200x is a thankless task.
> >
> > From my perspective, the reward is that, as a programmer, I can now use
> > more features in my standard-conformant code that would otherwise have
> > been system-specific extensions.
>
> I agree. For some applications I prefer to write code which is highly
> portable.

Then you should like the disambiguifiers.
These allow FIND to behave the same on all ANS-Forth systems,
and to behave in a way that makes sense conforming to common practice
(words such as IF etc. are immediate).

Stephen Pelc lies about the disambiguifiers, saying they don't work.
https://groups.google.com/forum/#!topic/comp.lang.forth/T-yYkpVwYew

> However, people who only
> provide constant negative feedback clearly don't understand the magnitude
> of the effort.

How much effort went into implementing the Paysan-faked quotations?
That is crap code!
Bernd Paysan and Anton Ertl put most of their effort into lying
about the rquotations at Euro Forth-2018, saying they don't work:
--------------------------------------------------------------------
Of course, in classical Forth fashion, some users explored the idea
of what outer-locals accesses can be performed with minimal eﬀort.
In particular, Usenet user “humptydumpty” introduced rquotations, a
simple quotation-like implementation that uses return-address manipulation.
The Forth system does not know about these rquotations and therefore
treats any locals accessed inside rquotations as if they were
accessed outside. In the case of Gforth (as currently implemented)
this works as long as the locals stack is not changed in the
meantime; e.g., the higher-order word that calls the rquotation
must not use locals. There is no easy way to see whether this restriction
has been met; this is also classical Forth style, but deﬁnitely not
user-friendly. Static analysis could be used to ﬁnd out in many cases
whether the restriction has been met, but that would probably require
more eﬀort than implementing the approach presented in this paper,
while not providing as much functionality.
--------------------------------------------------------------------

Bernd Paysan, Anton Ertl and Stephen Pelc are liars.
Their "effort" is "only negative" (your words) to the Forth community.
I feel confident that I can defeat them.
A viable Forth standard will rise from their ashes.

hughag...@gmail.com

unread,

Aug 16, 2019, 1:15:09 AM8/16/19

to

The following is my rquotation code that works.
Of course, Krishna Myneni will sneer and say that zero effort
is required to write code like this.
Stephen Pelc will sneer and say:

On Tuesday, June 25, 2019 at 3:35:43 PM UTC-7, Stephen Pelc wrote:
> You are just demonstrating your ignorance and your failure to
> accept that anyone else can do better than you.

Perhaps Stephen Pelc will say: "RTFM" or "Do try to keep up."
He has a variety of insults that he flings at me,
but all of them state the he is the Emperor of Forth
and that he declares by fiat that I am not a Forth programmer at all.
----------------------------------------------------------------------
\ ******
\ ****** R[ ]R quotations.
\ ****** https://groups.google.com/forum/#!topic/comp.lang.forth/3LSqmBIZuzY
\ ****** This is highly non-standard! ANS-Forth (section 3.2.3.3.) says:
\ ****** A program shall not access values on the return stack (using R@, R>, 2R@ or 2R>) that it did not place there using >R or 2>R;
\ ******

\ In the stack-picture comments, RQ is a continuation (a vector to a quotation).

\ HumptyDumpty invented rquotations --- this was very good programming --- I hadn't thought of it.
\ What I call REX0 he called RCALL --- also, he didn't have REX which I invented (this only works in VFX and SwiftForth).
\ If only REX0 is used, rquotations can be used under any ANS-Forth system (theoretically non-standard though).
\ REX is a lot more useful though because the HOF almost always needs to have locals.

\ My improved version for VFX or SwiftForth should be easy to port to other ANS-Forth systems --- any Forth system with locals.
\ Some assembly-language is required, but it is pretty straight forward.

VFX? SwiftForth? or [if]

: rexit ( -- ) rdrop ;
: (r:) ( -- rq ) r@ 5 + ; \ 5 is the size of a JMP instruction in 32-bit x86
: r[ ( -- rq ) postpone (r:) postpone ahead ; immediate
: ]r ( -- ) postpone rexit postpone then ; immediate

: rex0 ( rq -- ) >r ; \ requires the HOF to not have locals

\ REX0 is the same as EXECUTE
\ We don't use EXECUTE however because in the other version (not VFX or SwiftForth) REX0 is different.

VFX? [if]

code rex ( rq -- ) \ requires the HOF to have locals
push edi \ this is the HOF's LF which won't be used by the quotation
mov edi, 0 [edi] \ this is the parent's LF which will be used by the quotation
mov eax, ebx
mov ebx, 0 [ebp] lea ebp, w [ebp]
call eax
pop edi \ restore HOF's LF
next, end-code

[then]

SwiftForth? [if]

156 constant lf-offset \ this is the offset for the local-frame in the user-variables (ESI is the user-variable base)

code rex ( rq -- ) \ requires the HOF to have locals
lf-offset [esi] edx mov
edx push \ this is the HOF's LF which won't be used by the quotation
-4 [edx] eax mov \ this is the old ESP
0 [eax] eax mov \ this is the parent's LF which will be used by the quotation
eax lf-offset [esi] mov
ebx eax mov [drop]
eax call
lf-offset [esi] pop \ restore HOF's LF
ret end-code

[then]

[else] \ this was written by HumptyDumpty and works on gForth, SwiftForth and VFX

: rexit ( -- ) RDROP ;
: (r:) ( -- rq ) R@ false ;
: r[ ( -- rq ) postpone (r:) postpone IF ; immediate
: ]r ( -- ) postpone REXIT postpone THEN ; immediate

: rex0 ( rq -- ) >R true ; \ requires the HOF to not have locals

\ REX is not supported in HumptyDumpty's code.

[then]

\ REX is used in a HOF that has local variables.
\ REX0 is used in a HOF that does not have local variables.
\ REX0 is also used in the parent function itself, when there is no HOF used.
----------------------------------------------------------------------

none albert

unread,

Aug 16, 2019, 6:02:08 AM8/16/19

to

In article <0a1fd60e-0b93-4078...@googlegroups.com>,
Mark Wills <markwi...@gmail.com> wrote:
>On Tuesday, 30 July 2019 12:46:06 UTC+1, Alex McDonald wrote:
>> On 30-Jul-19 06:26, hughag...@gmail.com wrote:
>> > On Monday, July 29, 2019 at 1:04:52 PM UTC-7, Alex McDonald wrote:
>> >> On 29-Jul-19 20:56, NN wrote:
>> >>> To the above may I just add :
>> >>>
>> >>> (1) Ruvim's third post into the discussion:
>> >>>
>> >>> https://groups.google.com/d/msg/comp.lang.forth/vrq2f2XXy1Q/ZJ855-heDgAJ
>> >>>
>> >>>
>> >>> (2) And Anton's reply to Rod is easy to miss, but important
>> >>>
>> >>> "There is one thing you need to understand about interpretation and
>> >>> compilation semantics in the standard: they do not depend on STATE.
>> >>> Only the text interpreter uses STATE to decide whether to perform
>> >>> interpretation semantics or compilation semantics; nothing else does."
>> >>>
>> >>>
>> >>>
>> >>> My question is: is the precondition being applied by Hugh's
>> >>> disambiguifiers correct ? If the test is wrong, where is it wrong ?
>> >>>
>> >>
>> >> It is wrong at the point where it does STATE @ IF. From there, it's all
>> >> downhill on skates with no brakes because it's state smart *at run
>> >> time*. I refer you to Anton's reply that you reproduced above as to why
>> >> this is wrong.
>> >>
>> >> --
>> >> Alex
>> >
>> > I find it quite humorous that members of Elizabeth Rather's cult
>> > are now opposed to STATE-smart Forth systems.
>> > Alex McDonald poetically describes it as:
>> > "downhill on skates with no brakes."
>>
>> It's your code we're discussing, not STATE smart Forths.
>>
>> : if
>> state @ 0= if
>> cr ." WARNING: *** no interpretation semantics for: IF ***" cr
>>
>> then
>> postpone if ;
>> immediate
>>
>> If you look closely, you'll see that your disambiguifier has given IF
>> interpretation semantics, since it is an IMMEDIATE word. It (amusingly
>> and incorrectly) then issues the message that there are no
>> interpretation semantics for your disambiguificated IF. Skates on,
>> brakes off.
>>
>> Anton's observation needs repeated ad nauseam, and I'd have it in the
>> standard where it discusses STATE, as normative text:
>>
>> "There is one thing you need to understand about interpretation and
>> compilation semantics in the standard: they do not depend on STATE. Only
>> the text interpreter uses STATE to decide whether to perform
>> interpretation semantics or compilation semantics; nothing else does."
>>
>> --
>> Alex
>
>I'd say it's a grey area that the standard doesn't cover well. Originally,
>Hugh's code aborted, but I think he changed it to provide a warning instead.
>
>My system (a classical ITC implementation) does not permit IF to be used
>outwith a colon definition. In such a case, I would want it to abort rather
>than silently compile some code which is just going to crash my system or
>whatever.
>
>Perhaps a 'strict' variable could be used to determine what IF does under
>these circumstances? Abort, warn, or do nothing.
>
>But we should't forget the purpose of Hugh's code: To disambiguify (is that
>a word? I dunno). In that context, I believe it does what it says on the tin,
>it prevents IF from being used under ambiguous circumstances, whis is where
>all the demons live.
>
>I believe that by using disambiguifiers the chances of code running *in the
>same way* across different systems (thereby producing the same results) is
>increased.
>
>So, I agree with your interpretation in that executing some code (a warning)
>at compile/interpret time, you are introducing interpretation sematics, but
>that's a rather strict interpretation, and I'd rather have a system that says
>"hey, demons live there, don't do that" rather than silently compile a program
>that isn't going to run, leaving me to scratch my head and wonder where the
>the problem is, and why it runs on system A, and not system B.

I think an extensible language like Forth makes this discussion moot.
If you want it, add it. Do not add everything in the main system.

forthassembler.html~/PROJECT/ciforths/ciforth$ lina

80386 ciforth beta 2019Jul20
IF
IF ? ciforth ERROR # 17 : COMPILATION ONLY, USE IN DEFINITION
BYE

~/PROJECT/ciforths/ciforth$ lina -a
WANT -scripting-
OK
1 IF "AA{" TYPE ELSE "MOPNLY" TYPE
THEN
AA{ OK
BYE

>
>Cheers
>
>Mark

Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

none albert

unread,

Aug 16, 2019, 8:15:03 AM8/16/19

to

In article <qj0vqd$hku$1...@dont-email.me>,
Alex McDonald <al...@rivadpm.com> wrote:
<SNIP>

>Then the standard wording of REPRESENT is useless if practical examples
>that test the specification can't be agreed upon. That's one of the
>values of something like the Hayes tester; it tests everyone's
>understanding of the spec.

Nobody in its right mind considers passing the Hayes tester as proof
of comformance. On the other hand any problem signalled really is a
defect. There is no controversy about how the results of the Hayes
tests are to be interpreted. This makes the tester invaluable for
bringing up new systems and as a regression test.
It is a black box test.

A comprehensive test must by written by a compiler writer
in concord with the Forth system, and is definitely a white
box test. If a standards body would define a compliance test,
the same falsification would result as with performance tests.
Provisions to pass tests would be added where the underlying code is
a mess and should actually fail.

>--
>Alex

none albert

unread,

Aug 16, 2019, 8:15:03 AM8/16/19

to

In article <3c18ed9c-a4a5-4dbe...@googlegroups.com>,
<m...@iae.nl> wrote:
>On Friday, August 2, 2019 at 6:53:05 PM UTC+2, Gerry Jackson wrote:
>> On 01/08/2019 23:43, a...@littlepinkcloud.invalid wrote:
>> > Gerry Jackson <do-no...@swldwa.uk> wrote:
>> >>
>[..]
>> I agree. Perhaps the way forward is to test what we can with an exact FP
>> representation, if that's possible for all FP formats. Then run a Forth
>> version of 'Paranoia' which, I believe tests the quality of a floating
>> point implementation. Krishna Myneni provided a Forth version when I
>> posted a call for FP test programs. It's been included with the test
>> suite for years but I've no idea if anyone has tried it. ISTM that I
>> tried it on a few systems at the time with mixed results.
>
>Here are the results of PARANOIA when run on iForth.
>There is one defect.
>
>-marcel

<SNIP>
Jesus, why not trim to show only the defect.

In my opinion the defect is not in iforth, but in an improper translation
of paranoia to Forth.
A good translation would use FLNP1 FEXPM1 in that part with better
results than FORTRAN and iforth would certainly pass.

Krishna Myneni

unread,

Aug 16, 2019, 8:38:13 AM8/16/19

to

On Fri, 16 Aug 2019 11:15:07 +0000, none) (albert wrote:

> In article <3c18ed9c-a4a5-4dbe...@googlegroups.com>,
> <m...@iae.nl> wrote:

...

>>Here are the results of PARANOIA when run on iForth.
>>There is one defect.
>>

...

>
> In my opinion the defect is not in iforth, but in an improper
> translation of paranoia to Forth.
> A good translation would use FLNP1 FEXPM1 in that part with better
> results than FORTRAN and iforth would certainly pass.
>

The test results in question from iForth appear to be

----
Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.389056e0 as X -> 1.
DEFECT Calculated 2.718282e0 for
(1 + (-5.421011e-20 ) ^ (-3.689349e19 );
differs from correct value by -4.670774e0
This much error may spoil financial
calculations involving tiny interest rates.
----

Possibly as a result of using extended precision (80-bit) in iForth, X
approaches 1 with a finer step, and the flaws in the system
implementation of FEXP are exposed at that granularity. This may be why
the test passes in double-precision floating point on systems like
kforth32 and gforth. Output from kforth32 running paranoia:

----
Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065e+00 as X -> 1.
Accuracy seems adequate.
----

The test exposes flaws in FEXP at the precision used in the calculation,
which is what it is intended to do. I would not call this a
mistranslation of the original BASIC code.

KM

hughag...@gmail.com

unread,

Aug 16, 2019, 9:06:47 AM8/16/19

to

On Friday, August 16, 2019 at 5:38:13 AM UTC-7, Krishna Myneni wrote:
> On Fri, 16 Aug 2019 11:15:07 +0000, none) (albert wrote:
> > In my opinion the defect is not in iforth, but in an improper
> > translation of paranoia to Forth.
> > A good translation would use FLNP1 FEXPM1 in that part with better
> > results than FORTRAN and iforth would certainly pass.
>
> The test results in question from iForth appear to be
>
> ----
> Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.389056e0 as X -> 1.
> DEFECT Calculated 2.718282e0 for
> (1 + (-5.421011e-20 ) ^ (-3.689349e19 );
> differs from correct value by -4.670774e0
> This much error may spoil financial
> calculations involving tiny interest rates.
> ----

This has already been discussed:

On Tuesday, May 25, 2010 at 4:55:07 PM UTC-7, Hugh Aguilar wrote:
> Does anybody have code for FEXPM1? The reason why I ask is that there
> is a bug in Win32Forth's FEXPM1 that is holding up the port of my
> slide-rule program. I do have a copy of "Computer Approximations," so
> I could write the function myself. Unfortunately, the book is buried
> in storage and is a hassle for me to find.
>
> I looked in SwiftForth to find out how they implemented the function,
> and this is what I found:
>
> see fexpm1
> 47281F 47276F ( FEXP ) CALL E84BFFFFFF
> 472824 47102F ( #1.0E ) CALL E806E8FFFF
> 472829 470CEF ( F- ) JMP E9C1E4FFFF
>
> I hope nobody at Forth Inc. complains about me posting their
> proprietary code on c.l.f.. I'm giving away all of their best code!

This thread started out with Gerry Jackson "educating" me
on how POSTPONE works. That didn't work out very well.

Now the ANS-Forth cult has switched over to numerical precision,
which is an innocuous topic that allows them to appear to be
mighty big experts while not requiring them to write any code.

hughag...@gmail.com

unread,

Aug 16, 2019, 9:33:05 PM8/16/19

to

On Thursday, August 15, 2019 at 11:44:33 AM UTC-7, Alex McDonald wrote:
> On 15-Aug-19 16:53, Anton Ertl wrote:
> > NN <novembe...@gmail.com> writes:
> >>From my perspective, seems to me that being in 200x is a thankless task.
> >
> > From my perspective, the reward is that, as a programmer, I can now
> > use more features in my standard-conformant code that would otherwise
> > have been system-specific extensions.
> >
> > But sometimes I wonder if that is worth the effort, and if I should
> > not just publish code with such features, and leave it to the users of
> > Forth systems to complain to their system implementor that they want
> > that feature to run my code.
>
> It's worth the effort. The naysayers are few. There's Hugh, who is in a
> state of perpetually taking insult and inchoate rage. dxforth has some
> valid concerns but seems to see the standard as being set in tablets of
> ANS TC stone. S/he doesn't approve but s/he is unclear as to what should
> be done. This confuses me.
>
> There's the usual Greek chorus with a variable membership, but that's to
> be expected; it's usenet.

One of the funniest things about the ANS-Forth cult is
their tendency to use big words when they don't know what
the words mean. This is the hallmark of pseudo-intellectualism!
Here Alex McDonald uses "inchoate" incorrectly.
In the ANS-Forth document Elizabeth Rather used "semantics" incorrectly.
These are clowns --- they aren't taken seriously in the real world.

Gerry Jackson

unread,

Aug 17, 2019, 6:10:48 AM8/17/19

to

On 15/08/2019 15:43, hughag...@gmail.com wrote:
> On Thursday, August 15, 2019 at 2:43:58 AM UTC-7, Kerr-Mudd,John wrote:
>> On Wed, 14 Aug 2019 17:58:00 GMT, hughag...@gmail.com wrote:
>>> Alex McDonald pretends that Forth-200x is a massive movement.
>>> There are actually fewer than 20 Forth-200x enthusiasts though.
>>> This is less than half the number of Heaven's Gate cult members.
>>
>> Is there anyone in the Forth community you admire? So much bile.
>
> I was impressed by the quality of UR/Forth.
> UR/Forth worked okay for writing MFX with only a few flaws,
> and I'm not aware of any other Forth that would have been adequate.
> So I admire Ray Duncan.
>
> I was impressed by the MiniForth design.
> This was the only Forth processor developed in the 20th century
> by anybody other than Charles Moore.
> This continues to be the only VLIW Forth processor ever developed.
> So I admire John Hart.
>
> I was impressed by the design of Forth.
> So I admire Charles Moore.
>

You omitted the person you most admire and worship, someone who has who
is the world's leading Forth programmer, who has written the worlds best
pattern matcher, called stringstack.4th, in any language. Someone called
Hugh Aguilar. (sarcasm in case you thought it was a compliment).

[snipped a load of the same old abusive Aguilar shite repeated for the
umpteenth time]

--
Gerry

Gerry Jackson

unread,

Aug 17, 2019, 10:45:59 AM8/17/19

to

unread,

Aug 18, 2019, 2:29:30 PM8/18/19

to

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> - Values are worse wrt. reification and factoring. Variables work
> through addresses of their contents. So we write words that take
> addresses and do something with them.

The only things to do with addresses are @ and ! them. If @ then you
may as well use a value. ! is a little bit different but is it really
good practice to for a word to update one of its callers' VALUEs?

An advantage of VALUE is that the compiler can more straightforwardly
put VALUEs in registers.

Having VALUE define two words (a getter and a setter, as it were,
instead of just a getter) could fix the blemish of TO:

5 VALUE foo

would define the words "foo" and "!foo" and set foo to 5. Then "3 !foo"
would set foo to 3, eliminating TO. If the magic creation of a new word
is itself too ugly, VALUE itself could take two args, giving the names
of the getter and setter:

5 VALUE foo !foo

The use of !foo as the setter of foo would just be a convention.

If you -really- wanted a called word to set foo, you could tick the
setter and pass it:

: bar .... ['] !foo some-hack ... ;

some-hack would call the xt to set foo. The compiler could notice
the creation of this xt and aovid putting foo in a register, at least
while the xt was alive.

hughag...@gmail.com

unread,

Aug 18, 2019, 3:58:44 PM8/18/19

to

On Sunday, August 18, 2019 at 11:29:30 AM UTC-7, Paul Rubin wrote:
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> > - Values are worse wrt. reification and factoring. Variables work
> > through addresses of their contents. So we write words that take
> > addresses and do something with them.
>

> The only things to do with addresses are @ and ! them. If @ then you
> may as well use a value. ! is a little bit different but is it really
> good practice to for a word to update one of its callers' VALUEs?
>
> An advantage of VALUE is that the compiler can more straightforwardly
> put VALUEs in registers.
>
> Having VALUE define two words (a getter and a setter, as it were,
> instead of just a getter) could fix the blemish of TO:
>
> 5 VALUE foo
>
> would define the words "foo" and "!foo" and set foo to 5. Then "3 !foo"
> would set foo to 3, eliminating TO. If the magic creation of a new word
> is itself too ugly, VALUE itself could take two args, giving the names
> of the getter and setter:
>
> 5 VALUE foo !foo
>
> The use of !foo as the setter of foo would just be a convention.
>
> If you -really- wanted a called word to set foo, you could tick the
> setter and pass it:
>
> : bar .... ['] !foo some-hack ... ;
>
> some-hack would call the xt to set foo. The compiler could notice
> the creation of this xt and aovid putting foo in a register, at least
> while the xt was alive.

That is ridiculously complicated!
How is the compiler going to know at compile-time whether the
xt is "alive" or not at run-time?

What Anton Ertl says here, I have already said multiple times.
Gerry Jackson really doesn't know very much about Forth,
and he deserves to be slapped down by the Forth-200x committee member.

Even when Anton Ertl is right though, he is still wrong.
He is wrong because he is using his position as a Forth-200x
committee member to represent himself as being above me.

Alex McDonald

unread,

Aug 18, 2019, 4:33:48 PM8/18/19

to

On 18-Aug-19 19:29, Paul Rubin wrote:

>
> Having VALUE define two words (a getter and a setter, as it were,
> instead of just a getter) could fix the blemish of TO:
>
> 5 VALUE foo
>
> would define the words "foo" and "!foo" and set foo to 5. Then "3 !foo"
> would set foo to 3, eliminating TO. If the magic creation of a new word
> is itself too ugly, VALUE itself could take two args, giving the names
> of the getter and setter:
>
> 5 VALUE foo !foo
>
> The use of !foo as the setter of foo would just be a convention.
>

Recognizers can accomplish this, and iirc it was Anton that proposed
->foo as a syntax to support setting a value. If your Forth supports
recognizers, it is trivial to implement.

--
Alex

Paul Rubin

unread,

Aug 18, 2019, 8:34:29 PM8/18/19

to

Alex McDonald <al...@rivadpm.com> writes:
> Recognizers can accomplish this, and iirc it was Anton that proposed
> ->foo as a syntax to support setting a value. If your Forth supports
> recognizers, it is trivial to implement.

Adding syntactic hair like that also seems messy. How does the
following look to you?

: make-getter ( n "getter" -- addr )
CREATE HERE SWAP , DOES> ( addr -- n ) @ ;
: make-setter ( addr "setter" -- )
CREATE , DOES> ( n addr -- ) @ ! ;
: mvalue ( n "getter" "setter" -- ) make-getter make-setter ;

Now you can say

10 MVALUE foo ->foo \ creates foo and ->foo and sets foo to 10
foo . \ prints 10
20 ->foo \ updates foo to now have 20
foo . \ prints 20

If you get rid of TO, then the existing word VALUE would basically do
the same thing as CONSTANT.

So if I were redesigning Forth, I'd get rid of TO, eliminate VALUE since
it now does the same thing as CONSTANT, then re-use the word "VALUE" to do
what MVALUE above does. Any pitfalls?

Anyway, since VALUE is already in use, the next best thing is to add
the new word MVALUE.

Anton Ertl

unread,

Aug 19, 2019, 2:30:32 AM8/19/19

to

Paul Rubin <no.e...@nospam.invalid> writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> - Values are worse wrt. reification and factoring. Variables work
>> through addresses of their contents. So we write words that take
>> addresses and do something with them.
>
>The only things to do with addresses are @ and ! them.

You can also, e.g., pass them around on the stack. And that allows
significant simplifications in some code. E.g., consider insert-end an
element at the end of a linked list:

0
field: list-next
field: list-val
constant list-size

: insert-end ( x addr-list -- )
begin dup @ while @ list-next repeat
( x addr-last ) list-size allocate throw ( x addr-last list )
0 over list-next !
rot over list-val ! ( addr-last list )
swap ! ;

variable mylist 0 mylist !
5 mylist insert-end
7 mylist insert-end

Now show me how you would design INSERT-END to work with a MYFIELD
that's defined with VALUE. And INSERT-END is not limited to dealing
with global single-cell words. You can use it for lists stored in an
array, or in other lists, or anything else that can store cells.

Java cannot pass addresses of object-references around, and as a
consequence the Java code for this kind of task is incredibly
complicated.

>If @ then you
>may as well use a value. ! is a little bit different but is it really
>good practice to for a word to update one of its callers' VALUEs?

As shown above, there are cases where you want to pass something that
you want updated; but it's indeed not a good idea to use values for
that something.

>An advantage of VALUE is that the compiler can more straightforwardly
>put VALUEs in registers.

For (per-task) UVALUEs that is true, for global VALUEs only on systems
without multi-tasking.

>If you -really- wanted a called word to set foo, you could tick the
>setter and pass it:
>
> : bar .... ['] !foo some-hack ... ;
>
>some-hack would call the xt to set foo.

In INSERT-END we want both read and write access, so we would have to
pass both xts. And when dealing with an array element, we would have
to pass closures for reading and writing the element; and create
additional closures inside INSERT-END for accessing LIST-NEXT. And
the result would be slow, unless we complicate the compiler into
optimizing all these closures away, to get efficient code equivalent
to the one shown above.

Gerry Jackson

unread,

Aug 19, 2019, 4:12:25 AM8/19/19

to

In my first post about using values, it wasn't instead of using
addresses and @ and !. As lower level primitives @ and ! can be used
where values are inappropriate, as Andrew Haley pointed out and you do
above. I prefer values where they reduce stack noise much like locals
(values) do had they been defined as producing addresses.

--
Gerry

a...@littlepinkcloud.invalid

unread,

Aug 19, 2019, 4:43:21 AM8/19/19

to

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> a...@littlepinkcloud.invalid writes:
>>I recently came across something new to me: the user value. I wanted
>>to set a user value in another task. How to do it?
>
> Don't!

Nonsense. It's been in the Forth multi-tasker since forever (or at
least the mid-1970s) and it's the right way to initialize the user
area before a task starts.

>>As far as Standard Forth is concerned, TO is defined in a way that
>>makes it impractical to define your own kinds of VALUEs.
>
> There is just no standard way to do it.

That's right.

Andrew.

a...@littlepinkcloud.invalid

unread,

Aug 19, 2019, 4:45:07 AM8/19/19

to

Paul Rubin <no.e...@nospam.invalid> wrote:
> An advantage of VALUE is that the compiler can more straightforwardly
> put VALUEs in registers.

Ummm, what? That would be locals, surely.

Andrew.

A. K.

unread,

Aug 19, 2019, 4:58:07 AM8/19/19

to

I think so too. My "problem" with TO is that it is too overloaded.
VALUES and locals are completely different things, but TO applies
to both. An optimizing compiler should also handle spilled locals
when there are no free register slots. That's overcomplicated IMO.