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?
On 27/11/2023 7:51 pm, Antoni Gual Via wrote:
code:Try instead:
: 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?
: f bl word find ;
f uno drop execute
: 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?
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".
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
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
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 .
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.
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.
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
BTW regarding EuroForth-2023, do we have a public link to view the
scripts or slides?
With the advent of recognizers
this is no longer practical because re-parsing the input stream is rather >common with recognizers.
ctype iForth-5.1-mini[..]
So iForth and SwiftForth still use WORD in the text interpreter.
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.
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 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
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.
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.
The one and only core word required for parsing is >IN.
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
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.
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.
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
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.
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.
...
From a Forth perspective, the most obvious "shortcoming" is that Forth
only talks about parsing input sources, but there are no standard words
for parsing string data, such as sscanf in C.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 20:24:20 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,617 |
| Messages: | 6,121,093 |