code:
: uno ." hello" ;
bl word uno find \ returns -1 flagm so word found
drop execute \ prints "hello" in Gforth and SPforth, but gives a stack overflow in MinForth
code end:
All good old ANS94 words. Can't find an explanation in the MinForth manual. Can you explain it?

Thanks for the error report, but sorry
I cannot reproduce your bug:

┌────────────────────────┐
│ MinForth V3.6 - 32 bit │
└────────────────────────┘
Stacks: d:1024 r:512 f:128
Unused: 199M
# : uno ." hello" ; ok
# uno hello ok
# bl word uno find ok
9380180 -1 # drop ok
9380180 # execute hello ok
#

On 27/11/2023 7:51 pm, Antoni Gual Via wrote:
> code:
> : uno ." hello" ;
> bl word uno find \ returns -1 flagm so word found
> drop execute \ prints "hello" in Gforth and SPforth, but gives a stack overflow in MinForth
> code end:
> All good old ANS94 words. Can't find an explanation in the MinForth manual. Can you explain it?

Try instead:

: f bl word find ;

f uno drop execute

El dia dilluns, 27 de novembre de 2023 a les 10:35:03 UTC+1, dxf va escriure:
> On 27/11/2023 7:51 pm, Antoni Gual Via wrote:
> > code:
> > : uno ." hello" ;
> > bl word uno find \ returns -1 flagm so word found
> > drop execute \ prints "hello" in Gforth and SPforth, but gives a stack overflow in MinForth
> > code end:
> > All good old ANS94 words. Can't find an explanation in the MinForth manual. Can you explain it?
> Try instead:
>
> : f bl word find ;
>
> f uno drop execute

Thanks dxf, this way it works

Antoni Gual Via <antonigualvia@gmail.com> writes:
>: uno ." hello" ;
>bl word uno find \ returns -1 flagm so word found
>drop execute \ prints "hello" in Gforth and SPforth, but gives a stack overflow in MinForth

In some Forth systems the text interpreter uses WORD (and the buffer
where it stores the result), so it could be that FIND sees the string
"FIND" in that buffer, not "UNO".

Interestingly, looking at
<https://forth-standard.org/standard/usage#usage:transient>, I don't
find permission that the system's text interpreter may clobber the
buffer used by WORD; if so, that surely is an oversight in the standard.

>code end:
>All good old ANS94 words. Can't find an explanation in the MinForth manual. Can you explain it?

--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

You are right. I hadn't realized that this had changed somewhere along the way.
In an older MinForth version:

┌──────────────────────────┐
│ MinForth V3.4.9 - 32 bit │
└──────────────────────────┘
Stacks: d:128 r:128 f:64
Unused: 4,193,620 bytes
# : uno ." hello" ; ok
# uno hello ok
# bl word uno find ok
4353220 -1 # drop ok
4353220 # execute
? execute
^ ?? stack underflow
Stacks: -4
Backtrace: FIND
#

Obviously this isn't correct behaviour either because standard 6.1.1550
stipulates that if the definition is not found FIND should return
( c-addr 0 ) and not panick from some internal error when c-addr
points to nirvana, or the string has been overwritten like in this case.

Perhaps this could make a new test candidate for the ANS test suite.

In article <uk1ns3$3n542$1@dont-email.me>, dxf <dxforth@gmail.com> wrote:
>On 27/11/2023 7:51 pm, Antoni Gual Via wrote:
>> code:
>> : uno ." hello" ;
>> bl word uno find \ returns -1 flagm so word found
>> drop execute \ prints "hello" in Gforth and SPforth, but gives a stack overflow in MinForth
>> code end:
>> All good old ANS94 words. Can't find an explanation in the MinForth manual. Can you explain it?
>
>Try instead:
>
>: f bl word find ;
>
>f uno drop execute

There is no point in forcing this code to work in this way,
as its only purpose could be to test the Forth implementation.

This triggers the question whether the original code is standard.
I think it is. Then the implementation should be fixed.

Groetjes Albert
>
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

Anton Ertl wrote:
> In some Forth systems the text interpreter uses WORD (and the buffer
> where it stores the result), so it could be that FIND sees the string
> "FIND" in that buffer, not "UNO".

IIRC some Forth systems copy parsed word names to somewhere after HERE
to prepare new headers, at least F83 did. With the advent of recognizers
this is no longer practical because re-parsing the input stream is rather
common with recognizers.

BTW regarding EuroForth-2023, do we have a public link to view the
scripts or slides?

In article <2023Nov27.132848@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Antoni Gual Via <antonigualvia@gmail.com> writes:
>>: uno ." hello" ;
>>bl word uno find \ returns -1 flagm so word found
>>drop execute \ prints "hello" in Gforth and SPforth, but gives a stack overflow in MinForth
>
>In some Forth systems the text interpreter uses WORD (and the buffer
>where it stores the result), so it could be that FIND sees the string
>"FIND" in that buffer, not "UNO".
>
>Interestingly, looking at
><https://forth-standard.org/standard/usage#usage:transient>, I don't
>find permission that the system's text interpreter may clobber the
>buffer used by WORD; if so, that surely is an oversight in the standard.

You mean, the standard suggests that `BL WORD' could be used in the interpreter,
passing the result to FIND . Obviously that doesn't work in this context,
because now the interpreter uses the phrase `BL WORD' to isolate the word FIND .
So you propose to add:
"the system's text interpreter may clobber the buffer used by WORD;"
Fine by me. It makes so much sense that it is only natural to forget
to state it.

Modern systems have abandoned WORD a long time ago, with its forced
copying. The character passed is at the same time data and
a control variable.

[You can always accommodate legacy stuff as a "loadable extension"]

>
>>code end:
>>All good old ANS94 words. Can't find an explanation in the MinForth manual. Can you explain it?

>
>--
>M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

albert@cherry.(none) (albert) writes:
>In article <2023Nov27.132848@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Antoni Gual Via <antonigualvia@gmail.com> writes:
>>>: uno ." hello" ;
>>>bl word uno find \ returns -1 flagm so word found
>>>drop execute \ prints "hello" in Gforth and SPforth, but gives a stack overflow in MinForth
>>
>>In some Forth systems the text interpreter uses WORD (and the buffer
>>where it stores the result), so it could be that FIND sees the string
>>"FIND" in that buffer, not "UNO".
>>
>>Interestingly, looking at
>><https://forth-standard.org/standard/usage#usage:transient>, I don't
>>find permission that the system's text interpreter may clobber the
>>buffer used by WORD; if so, that surely is an oversight in the standard.
>
>You mean, the standard suggests that `BL WORD' could be used in the interpreter,
>passing the result to FIND .

I don't find any such suggestion, or any restriction (on programs)
that would allow the system to work that way, but it certainly was
common practice in 1994, so if they forgot to put such a restriction
in, it's an oversight. But maybe I just looked in the wrong part of
the standard.

If they really forgot to put such a restriction in, the question is if
it should be fixed. Maybe these days no Forth-2012 system uses WORD
in the text interpreter; in that case there is no need to add such a
restriction.

>So you propose to add:
>"the system's text interpreter may clobber the buffer used by WORD;"

Probably written differently, but in essence that's the restriction I
mentioned above.

>Fine by me. It makes so much sense that it is only natural to forget
>to state it.

I remember several people tripping over this footangle over the years,
and the thread was started by another instance. It may have been an
ok idea when memory was tight (but not really: PARSE-NAME does not
consume extra memory). These days it's just a trap waiting to be
sprung.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 28/11/2023 2:06 am, albert wrote:
> In article <2023Nov27.132848@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Antoni Gual Via <antonigualvia@gmail.com> writes:
>>> : uno ." hello" ;
>>> bl word uno find \ returns -1 flagm so word found
>>> drop execute \ prints "hello" in Gforth and SPforth, but gives a stack overflow in MinForth
>>
>> In some Forth systems the text interpreter uses WORD (and the buffer
>> where it stores the result), so it could be that FIND sees the string
>> "FIND" in that buffer, not "UNO".
>>
>> Interestingly, looking at
>> <https://forth-standard.org/standard/usage#usage:transient>, I don't
>> find permission that the system's text interpreter may clobber the
>> buffer used by WORD; if so, that surely is an oversight in the standard.
>
> You mean, the standard suggests that `BL WORD' could be used in the interpreter,
> passing the result to FIND . Obviously that doesn't work in this context,
> because now the interpreter uses the phrase `BL WORD' to isolate the word FIND .
> So you propose to add:
> "the system's text interpreter may clobber the buffer used by WORD;"
> Fine by me. It makes so much sense that it is only natural to forget
> to state it.
>
> Modern systems have abandoned WORD a long time ago, with its forced
> copying.

SwiftForth i386-Win32 3.11.9-RC1 01-Sep-2022

: uno ." hello" ; ok
bl word uno find drop execute ok
..s
0 <-Top ok

dxf <dxforth@gmail.com> writes:
>On 28/11/2023 2:06 am, albert wrote:
>> Modern systems have abandoned WORD a long time ago, with its forced
>> copying.
>
>SwiftForth i386-Win32 3.11.9-RC1 01-Sep-2022
>
>: uno ." hello" ; ok
>bl word uno find drop execute ok
>.s
>0 <-Top ok

Let's start with a more obvious test case:

: ctype count type ; cr bl word uno ctype

Here's the output for different systems:

output system
uno Gforth 0.7.3, Copyright (C) 1995-2008 ...
ctype iForth-5.1-mini
uno lxf
ctype SwiftForth x64-Linux 4.0.0-RC52 20-Sep-2022
uno VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64

So iForth and SwiftForth still use WORD in the text interpreter.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

minforth@gmx.net (minforth) writes:
>BTW regarding EuroForth-2023, do we have a public link to view the
>scripts or slides?

There are currently only the preliminary proceedings
<http://www.euroforth.org/ef23/papers/>. I'll announce here when the
finished proceedings are ready.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

minforth@gmx.net (minforth) writes:
>With the advent of recognizers
>this is no longer practical because re-parsing the input stream is rather
>common with recognizers.

The various proposals on recognizers all call the recognizers after
the parsing step of the text interpreter and have a stack effect
( c-addr u -- ... ). Whether that string is produced by PARSE-NAME,
BL WORD COUNT, or in some other way does not make a difference.

The only recognizer in Gforth that parses is the string recognizer,
but that works as follows: If there is a string

"bla bla bla"

the text interpreter parses the '"bla', the string recognizer sees
that this starts with '"', but does not end with '"', and therefore
parses from the input buffer until it finds a '"'. So the string
recognizer combines the passed start of the string with the parsed
rest of the string; it also processes escapes (e.g., '\n'). But there
is no reparsing.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

Anton Ertl wrote:
[..]
> ctype iForth-5.1-mini
[..]
> So iForth and SwiftForth still use WORD in the text interpreter.

Intentionally, because "properly written" legacy code uses WORD
assuming there is no copying, abd there is more old than new
code :--) Not much chance doing this right.

-marcel

On 28/11/2023 4:16 am, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> On 28/11/2023 2:06 am, albert wrote:
>>> Modern systems have abandoned WORD a long time ago, with its forced
>>> copying.
>>
>> SwiftForth i386-Win32 3.11.9-RC1 01-Sep-2022
>>
>> : uno ." hello" ; ok
>> bl word uno find drop execute ok
>> .s
>> 0 <-Top ok
>
> Let's start with a more obvious test case:
>
> : ctype count type ; cr bl word uno ctype
>
> Here's the output for different systems:
>
> output system
> uno Gforth 0.7.3, Copyright (C) 1995-2008 ...
> ctype iForth-5.1-mini
> uno lxf
> ctype SwiftForth x64-Linux 4.0.0-RC52 20-Sep-2022
> uno VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
>
> So iForth and SwiftForth still use WORD in the text interpreter.

And arguably closer to ANS in which WORD and FIND are Core.

The one and only core word required for parsing is >IN.

Anton Ertl wrote:
> So the string
> recognizer combines the passed start of the string with the parsed
> rest of the string; it also processes escapes (e.g., 'n'). But there
> is no reparsing.

I found it easier to reposition >IN for cases where other string delimiters
are required. There are also strings as string delimiters eg embedded HTML.

On 28/11/2023 6:24 pm, minforth wrote:
> The one and only core word required for parsing is >IN.

20 years of 200x and still WORD is in Core. Must be important.

mhx@iae.nl (mhx) writes:
>Anton Ertl wrote:
>[..]
>> ctype iForth-5.1-mini
>[..]
>> So iForth and SwiftForth still use WORD in the text interpreter.
>
>Intentionally, because "properly written" legacy code uses WORD

Code using WORD in a system that does not clobber the WORD buffer has
no problem, on the contrary: A system that clobbers the WORD buffer
limits how WORD can be used. There even might be existing code that
uses WORD that works on systems where the text interpreter does not
clobber the WORD buffer, but not on systems where it does; see the
start of this thread for an example.

I have a hard time coming up with an example where a legacy program
would fail on a system where the text interpreter does not clobber the
WORD buffer: Assume the text interpreter uses BL WORD for parsing a
word. It then COMPILE,s a word (and the WORD buffer is not used by
that), or it EXECUTEs a word. In the latter case the word can read
its name from the WORD buffer, but why would the programmer want to do
that?

And the practical experience supports this theory: I don't remember
anybody reporting that a legacy program does not work on Gforth
because it does not use WORD in the text interpreter. And it's not
just Gforth that does not use WORD in its text interpreter, VFX and
lxf do not use it, either.

>assuming there is no copying

There is no way to implement a WORD that does not copy.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

dxf <dxforth@gmail.com> writes:
>On 28/11/2023 4:16 am, Anton Ertl wrote:
>> So iForth and SwiftForth still use WORD in the text interpreter.
>
>And arguably closer to ANS in which WORD and FIND are Core.

What argument is that supposed to be? Forth-94 (ANS Forth) does not
allow text interpreters to clobber the WORD buffer. And it does not
prescribe that the text interpreter must use WORD and FIND, or that
the Forth system calls any other Core word.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

minforth@gmx.net (minforth) writes:
>Anton Ertl wrote:
>> So the string
>> recognizer combines the passed start of the string with the parsed
>> rest of the string; it also processes escapes (e.g., 'n'). But there
>> is no reparsing.
>
>I found it easier to reposition >IN for cases where other string delimiters
>are required.

Actually, looking at REC-STRINGin Gforth, it's as follows:

: rec-string ( addr u -- addr u' r:string | rectype-null ) \ gforth-experimental
\G Convert strings enclosed in double quotes into string literals,
\G escapes are treated as in @code{S\"}.
2dup s\" \"" string-prefix?
IF drop source drop - 1+ >in ! \"-parse
save-mem over to try-free ['] translate-string
ELSE 2drop ['] notfound THEN ;

The line starting with 2DUP checks if addr u starts with '"'. The
next line indeed assumes that addr points into the input buffer and
then sets >IN to point right after. But it's also possible (although
a little bit more complicated) implement this without this assumption.

So yes, a text interpreter using PARSE-NAME makes it easier to
implement REC-STRING, and using PARSE-NAME in the text interpreter is
a better idea anyway (because it avoids problems like those that
started this thread), but if you are a die-hard WORD fan, even to the
extent of using it in the text interpreter, you can still implement
recognizers, including REC-STRING.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

In article <2023Nov28.095531@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>minforth@gmx.net (minforth) writes:
>>Anton Ertl wrote:
>>> So the string
>>> recognizer combines the passed start of the string with the parsed
>>> rest of the string; it also processes escapes (e.g., 'n'). But there
>>> is no reparsing.
>>
>>I found it easier to reposition >IN for cases where other string delimiters
>>are required.
>
>Actually, looking at REC-STRINGin Gforth, it's as follows:
>
>: rec-string ( addr u -- addr u' r:string | rectype-null ) \ gforth-experimental
> \G Convert strings enclosed in double quotes into string literals,
> \G escapes are treated as in @code{S\"}.
> 2dup s\" \"" string-prefix?
> IF drop source drop - 1+ >in ! \"-parse
> save-mem over to try-free ['] translate-string
> ELSE 2drop ['] notfound THEN ;
>
>The line starting with 2DUP checks if addr u starts with '"'. The
>next line indeed assumes that addr points into the input buffer and
>then sets >IN to point right after. But it's also possible (although
>a little bit more complicated) implement this without this assumption.
>
>So yes, a text interpreter using PARSE-NAME makes it easier to
>implement REC-STRING, and using PARSE-NAME in the text interpreter is
>a better idea anyway (because it avoids problems like those that
>started this thread), but if you are a die-hard WORD fan, even to the
>extent of using it in the text interpreter, you can still implement
>recognizers, including REC-STRING.

These insights came to me d.d. dec 21 2000 (!) thinking how figForth
should evolve.

I named it (WORD) at the time. Then later NAME. In the loadable extensions
there is
'NAME ALIAS PARSE-NAME
In ciforth all number, string and other denotations parse, without
affecting ISO compatibility.
Reparsing of the input stream is only
needed in rare cases, e.g. for a word that prints its own name. I
think it is best to be avoided if possible, for it makes for tricky code.

>
>- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

In article <2023Nov27.181604@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>dxf <dxforth@gmail.com> writes:
>>On 28/11/2023 2:06 am, albert wrote:
>>> Modern systems have abandoned WORD a long time ago, with its forced
>>> copying.
>>
>>SwiftForth i386-Win32 3.11.9-RC1 01-Sep-2022
>>
>>: uno ." hello" ; ok
>>bl word uno find drop execute ok
>>.s
>>0 <-Top ok
>
>Let's start with a more obvious test case:
>
>: ctype count type ; cr bl word uno ctype
>
>Here's the output for different systems:
>
>output system
>uno Gforth 0.7.3, Copyright (C) 1995-2008 ...
>ctype iForth-5.1-mini
>uno lxf
>ctype SwiftForth x64-Linux 4.0.0-RC52 20-Sep-2022
>uno VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
>
>So iForth and SwiftForth still use WORD in the text interpreter.

I don't think that it follows.

I have a newbee option in lina that automatically loads unknown
words, it can run the test.

lina -n
COPYRIGHT (c) 2000-2022 Albert van der Horst, THE NETHERLANDS
....
autoload on, case insensitive
stack printing on, index lines printing on
OK
: ctype count type ; cr bl word uno ctype
....
WANT WORD \ Automatically generated command
uno
S[] OK

In the kernel WORD is nowhere to be seen and it can't possibly
be used in INTERPRET.

lina
AMDX86 ciforth beta 2023Nov06
WORD
WORD ? ciforth ERROR # 12 : NOT RECOGNIZED

SEE INTERPRET

: INTERPRET
BEGIN NAME DUP WHILE
OVER >R FOUND DUP 0= 0000,0000,0000,000C ?ERROR DUP >FFA @ DUP
0000,0000,0000,0008 AND IF
OVER >NFA @ @ R@ + PP ! THEN
RDROP 0000,0000,0000,0004 AND STATE @ 0= OR IF
EXECUTE ELSE , THEN
?STACK REPEAT
DROP DROP
;

You can see NAME figure prominently in the interpreter loop.

>
>- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

In article <uk47mh$6lai$1@dont-email.me>, dxf <dxforth@gmail.com> wrote:
>On 28/11/2023 6:24 pm, minforth wrote:
>> The one and only core word required for parsing is >IN.
>
>20 years of 200x and still WORD is in Core. Must be important.

In Ireland there is a law that requires you to warn the public,
if you you throw poo off the second floor.
Must be important.

Groetjes Albert
>
>
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -