Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #60025 > unrolled thread
| Started by | Alex <alex@rivadpm.com> |
|---|---|
| First post | 2017-05-29 20:47 +0100 |
| Last post | 2017-05-30 11:03 -0700 |
| Articles | 14 on this page of 94 — 13 participants |
Back to article view | Back to comp.lang.forth
Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 20:47 +0100
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 20:57 +0100
Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-05-29 13:18 -0700
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 22:47 +0100
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 07:43 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 07:30 +0000
Re: Another recognizer discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-30 09:53 +0200
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-30 22:02 +0100
Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-05-31 01:27 -0700
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:12 +0100
Re: Another recognizer discussion minforth@arcor.de - 2017-05-31 03:43 -0700
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:03 +0100
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 16:46 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 11:28 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 12:17 +0000
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:10 +0100
Re: Another recognizer discussion mhx@iae.nl - 2017-05-31 11:01 -0700
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-05-31 22:55 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 05:50 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-05-31 23:57 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 09:08 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-06-01 03:33 -0700
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-01 09:05 +0000
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 15:05 +0100
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 10:05 -0500
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 16:32 +0100
Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-01 09:31 -0700
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 19:00 +0100
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-04 22:56 +0000
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-05 14:41 +0100
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 03:07 -0500
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 16:28 +0000
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-11 02:14 -0500
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-11 10:55 +0000
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-12 03:22 -0500
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 15:21 +0000
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-14 04:10 -0500
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-15 10:43 +0000
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-15 09:11 -0500
Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 02:55 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-14 10:19 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 05:44 -0700
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 14:27 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 08:06 -0700
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 16:36 +0000
Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 09:48 -0700
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-15 17:18 +0000
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-15 18:50 +0100
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-15 19:22 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-06-15 13:09 -0700
Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 13:43 -0700
Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-15 22:55 +0200
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-15 22:20 +0100
pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 17:04 +0000
Re: pre-Rfd for smart word definition mechanism (was: Another ...) stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 21:58 +0000
Re: pre-Rfd for smart word definition mechanism (was: Another ...) JennyB <jennybrien@googlemail.com> - 2017-06-17 00:26 -0700
Re: pre-Rfd for smart word definition mechanism (was: Another ...) minforth@arcor.de - 2017-06-17 01:18 -0700
Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 15:24 +0000
Re: pre-Rfd for smart word definition mechanism (was: Another ...) JennyB <jennybrien@googlemail.com> - 2017-06-17 12:29 -0700
Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-18 12:29 +0000
Re: pre-Rfd for smart word definition mechanism (was: Another ...) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-18 16:47 +0200
Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 10:20 +0000
Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 13:01 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 16:55 +0000
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 17:40 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 16:47 +0000
Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 10:34 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 17:35 +0000
Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-06-17 15:24 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-18 12:00 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 12:29 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 07:35 +0000
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-11 10:39 +0000
Re: Another recognizer discussion Richard Owlett <rowlett@cloud85.net> - 2017-06-11 07:19 -0500
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 14:04 +0000
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 12:50 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-15 16:19 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 07:59 +0000
Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 11:48 +0200
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 10:24 +0000
Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 13:04 +0200
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 13:30 +0000
Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 16:36 +0200
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 15:51 +0000
Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 21:09 +0200
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 15:55 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 14:21 +0000
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-04 23:07 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 15:49 +0000
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-11 11:14 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-06-11 08:24 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 15:07 +0000
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 12:11 +0100
Re: Another recognizer discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-30 11:03 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-06-02 13:04 +0200 |
| Message-ID | <86vaoek5uu.fsf@molnjunk.nocrew.org> |
| In reply to | #60186 |
Anton Ertl wrote:
>> In my (biased and subjective) opinition, it's possible to do better
>> than both of these. My version has no IFs at all. It's quite simple.
>
> Please show it.
I wrote about it a few years ago. The idea is that the integer returned
by FIND is in a tight range, so it's suitable as an index for a table
lookup. (Actually, I use a variation on FIND-NAME like everybody else,
but that irrelevant here.)
Here's the code that corresponds to the versions you posted:
find 1+ cells interpreters + @ execute
Of course, these supporting definitions are needed too:
create interpreters ' execute , ' number , ' execute ,
: [ 0 state ! ['] execute interpreters ! ; immediate
: ] 1 state ! ['] compile, interpreters ! ;
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-02 13:30 +0000 |
| Message-ID | <2017Jun2.153057@mips.complang.tuwien.ac.at> |
| In reply to | #60188 |
Lars Brinkhoff <lars.spam@nocrew.org> writes:
>I wrote about it a few years ago. The idea is that the integer returned
>by FIND is in a tight range, so it's suitable as an index for a table
>lookup. (Actually, I use a variation on FIND-NAME like everybody else,
>but that irrelevant here.)
>
>Here's the code that corresponds to the versions you posted:
>
> find 1+ cells interpreters + @ execute
>
>Of course, these supporting definitions are needed too:
>
> create interpreters ' execute , ' number , ' execute ,
> : [ 0 state ! ['] execute interpreters ! ; immediate
> : ] 1 state ! ['] compile, interpreters ! ;
Cute.
For FIND-NAME, the stack effect is not convenient for handling the
number case without an IF, so I would go for this:
2dup find-name dup if
nip nip name>something execute
else
number
then
But the rest is simpler:
defer name>something
: [ false state ! ['] name>interpret is name>something ;
: ] true state ! ['] name>compile is name>something ;
- 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: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-06-02 16:36 +0200 |
| Message-ID | <86k24ujw30.fsf@molnjunk.nocrew.org> |
| In reply to | #60195 |
Anton Ertl wrote: > For FIND-NAME, the stack effect is not convenient for handling the > number case without an IF, so I would go for this: > > 2dup find-name dup if > nip nip name>something execute > else > number > then For me personally, I try to design stack effects to reduce juggling at the call sites. A case could be made that all this duping and nipping is a sign that FIND-NAME could be redesigned. For this to carry any weight, a survey would have to be made to see many different use cases for FIND-NAME. But I understand other people have other preferences.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-02 15:51 +0000 |
| Message-ID | <2017Jun2.175147@mips.complang.tuwien.ac.at> |
| In reply to | #60199 |
Lars Brinkhoff <lars.spam@nocrew.org> writes:
>Anton Ertl wrote:
>> For FIND-NAME, the stack effect is not convenient for handling the
>> number case without an IF, so I would go for this:
>>
>> 2dup find-name dup if
>> nip nip name>something execute
>> else
>> number
>> then
>
>For me personally, I try to design stack effects to reduce juggling at
>the call sites. A case could be made that all this duping and nipping
>is a sign that FIND-NAME could be redesigned. For this to carry any
>weight, a survey would have to be made to see many different use cases
>for FIND-NAME.
For the case above, a better stack effect would be
find-name1 ( c-addr u -- nt true | c-addr u false )
Then you could write
find-name1 if
name>something execute
else
number
then
For an if-less approach, we could combine this with
NUMBER1 ( c-addr u -- (x|xd) xt )
where the xt contains the xt of LITERAL or 2LITERAL. And then have
find-name1 1+ cells state-rec + @ execute
: number1drop number1 drop ;
create int-rec ' name>interpret , ' number1drop ,
create comp-rec ' name>compile , ' number1 ,
int-rec value state-rec
: [ false state ! int-rec to state-rec ;
: ] true state ! comp-rec to state-rec ;
This also gets rid of an IF in NUMBER.
In a recognizer FIND-NAME1 probably works similarly well, because the
control flow is similar.
But for code like
[ s" [[" find-name ] Literal =
FIND-NAME1 would be worse.
My general experience is that words with run-time-dependent stack
effect suck; I remember one particular case where I wanted to use
SEARCH-WORDLIST, and IIRC needed to get something from before the
SEARCH-WORDLIST call to the TOS after the call. So, if you deviate
from the pattern above, FIND-NAME1 will produce the same problem.
Finally, there is the Forth convention of consuming the arguments.
All of this has led me to design the stack effect
FIND-NAME ( c-addr u -- nt|0 )
FIND-NAME-IN ( c-addr u wid -- nt|0 )
This costs a 2DUP and NIP NIP in the code above, but still seems the
best stack effect to me. What stack effect do you use?
- 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: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-06-02 21:09 +0200 |
| Message-ID | <86fufijjfd.fsf@molnjunk.nocrew.org> |
| In reply to | #60201 |
Anton Ertl writes: > What stack effect do you use? I have FIND-NAME ( c-addr u -- c-addr u 0 | xt +-1 ) This wasn't a deliberate design, just a small upgrade from FIND. But it has worked out well in my code. It seems that roughly 50% of the time I have used FIND-NAME, this output was helpful. In most of the other cases, I throw an error if an xt is not found, so cleaning up c-addr u isn't necessary.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-01 15:55 +0000 |
| Message-ID | <2017Jun1.175531@mips.complang.tuwien.ac.at> |
| In reply to | #60145 |
Alex <alex@rivadpm.com> writes:
>Actually, an NT is just like an XT. There is absolutely nothing stopping
>a system having all NTs as XTs and using
>
>: execute name>interpret xt-execute ;
>: compile, name>compile xt-compile, ;
That implementation of COMPILE, has at least the same bug that VFX
has, and if XT-COMPILE, does something different from XT-EXECUTE, even
more. A correct definition would be:
: compile, name>interpret xt-compile, ;
But of course we also want to perform
( nt ) name>compile execute
( nt ) name>compile swap postpone literal compile,
The former is used in, e.g., the text interpreter in compile state,
the latter in POSTPONE.
Stephen Pelc has proposed giving names to the four combinations, but I
think that the present factoring is better.
- 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: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-01 14:21 +0000 |
| Message-ID | <2017Jun1.162143@mips.complang.tuwien.ac.at> |
| In reply to | #60132 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Thu, 01 Jun 2017 05:50:57 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>stephen@mpeforth.com (Stephen Pelc) writes:
>>>IMHO name tokens had a rationale for TRAVERSE-WORDLIST, but I was
>>>afraid that they would open the FIG-Forth can of worms that ANS
>>>nailed shut with the XT. Now we see that indeed NTs are rampant, but
>>>just replicating existing practice.
>>
>>Can you elaborate on that? Which can of worms do you mean? Do you
>>think that FIND-NAME/SEARCH-NAME opens it, and if so, why? I don't
>>understand what you mean with the last sentence at all.
>
>I mean exposing the whole header navigation word set. Internally,
>most systems have words to traverse dictionary headers. In FIG-Forth
>they were standardised, e.g. >NFA ( xt -- nfa ).
I guess you mean
NFA ( pfa -- nfa )
> From ANS onwards,
>these words were retired. I still see very little need to expose
>them again.
Noted. But what does this have to do with FIND-NAME/SEARCH-NAME?
>>>The whole point of an XT was to provide a single point of reference to
>>>a word. an XT is an opaque type (anything the implementation wants it
>>>to be). In many systems it's the address of the interpretation
>>>behaviour of the word - it's optimised for EXECUTE. The cost of
>>>providing a link to a name field or name token is a single
>>>instruction on most desktop CPUs and even just one on most modern
>>>embedded CPUs.
>>
>>In Gforth <=0.7 there is no reliable way to get to the name field, if
>>one even exists. Do you want to disenfrenchise systems that are
>>implemented that way, and prescribe the implementation to provide a
>>link to the name field?
>
>To use one of your favourite phrases, it's a quality of implementation
>issue. MPE values the source management facilities provided by LOCATE
>and XREF enough to provide the access. If you make these tools using
>other techniques, you may not need direct access.
So LOCATE and XREF have nothing to do with the back link and even less
with FIND-NAME/SEARCH-NAME and are a red herring.
> I'm not trying to
>disenfranchise a system at all, I'm trying to retain the original
>ANS meaning of an XT.
The original ANS meaning is that you can EXECUTE it and COMPILE, it
(and do the things you can do with other cells), nothing more. And
FIND-NAME/SEARCH-NAME don't take this away, so they retain the
original ANS meaning of xt.
>>>The ghastliness of multiple xts for compilation actions is just
>>>exposing internal structures that should not be exposed. The idea
>>>of the ANS XT applies today just as much as did in 1994.
>>
>>Your idea of xts is incompatible with ANS Forth. Have you fixed VFX's
>>COMPILE, to be ANS Forth compliant already? Remember, in ANS Forth
>>and Forth-2012 its stack effect is
>>
>>COMPILE, ( xt -- )
>>
>>I can dig out the bug report again that I sent you two years ago.
>
>Your bug report was very helpful in clarifying my view of
>interpretation and compilation in Forth-2012. The report basically
>says that COMPILE, cannot be used for words that parse or have a
>stack effect, e.g. IF.
You can certainly use COMPILE, on the xt of IF (that you get, e.g.,
from FIND), but that must not perform the compilation semantics of IF,
because that is incompatible with the stack effect of COMPILE,. In
consequence, C" IF" FIND in compilation state has to return ( xt-if 1
), i.e., immeditae, and xt-if, when EXECUTEd, performs the compilation
semantics of IF. COMPILE,ing that xt is like POSTPONE IF (which again
has the right stack effect).
>These are the words that have non-default
>compilation semantics (NDCS). In VFX I can define NDCS, as the
>analogue for COMPILE, for these words. In practice, the
>definition for VFX is:
>: NDCS, ( i*x xt -- j*x ; may parse ) COMPILE, ;
I don't see how that fixes the bug in COMPILE,.
>>Anyway, there are Forth systems that have an xt for interpretation and
>>something independent for compilation, in order to implement words
>>such as S" (ANS Forth). On these systems you cannot get to the
>>compilation semantics from the interpretation semantics (or vice
>>versa). Do you want to disenfrenchise these systems by prescribing the
>>implementation?
>
>These systems have already broken the idea of an XT. These systems
>are already broken.
They may have broken *your* idea of an XT, but so what? Such systems
can certainly be compatible with the requirements of ANS Forth, unlike
VFX, where COMPILE, does not work as specified by ANS Forth,
demonstrating that your idea of an XT is incompatible with ANS Forth.
>>An NT provides access to interpretation and compilation semantics, and
>>to the word name.
>
>That's an implementation issue for a system with a broken XT.
System issues can be solved with system-specific approaches (aka
carnal knowledge), no need to standardize NTs for that.
No, the main benefit of these features is for standard programs: E.g.,
let's have a table of words
create word-table
s" if" find-name ,
s" 2*" find-name ,
s" then" find-name ,
: show-nts ( addr u -- )
cells over + swap do i @ name>string type space 1 cells +loop ;
: compile-nts ( addr u -- )
cells over + swap do i @ name>compile execute 1 cells +loop ;
word-table 3 show-nts \ prints "IF 2* THEN"
: foo [ word-table 3 compile-nts ] ;
see foo \ prints:
\ : foo
\ IF 2*
\ THEN ; ok
3 true foo . \ prints 6
There is no standard (and, on some systems, no non-standard) way to do
the this with a table of xts. You may point out that the
initialization of the table uses the not (yet?) standard FIND-NAME,
and that's the reason why it should be standardized, but if we are in
a pinch, we can get the nts of these words already in Forth-2012 using
TRAVERSE-WORDLIST.
>>An XT can only be EXECUTEd and COMPILE,d; you cannot get the
>>interpretation and compilation semantics of a word from it in ANS
>>Forth or Forth-2012, nor the word name. That is reflected in the
>>definition of FIND (ANS Forth and Forth-2012):
>
>People regularly store XTs in variables and tables.
And they DUP and SWAP them. So yes, you can also perform all general
cell operations on xts. You can also perform them on nts, which are
also cells. I did not think that they were worth mentioning.
> See DEFER and IS.
Yes, in Forth-2012 you can also use DEFER@, DEFER! and IS on them.
>>|For a given string, the values returned by FIND while compiling may
>>|differ from those returned while not compiling.
>>
>>If the xt was the single point of reference to a word as you claim,
>>this sentence would make no sense.
>
>cmForth made little sense at the time. That sentence is just a
>concession to cmForth. It was a mistake in 1994 and it's still
>unnecessary in 2017. The dual wordlist approach is just a bad
>design decision in the long term.
The ANS Forth TC obviously thought differently. And not only have
they written that sentence into ANS Forth, they also specified FILE
S", which actually makes it necessary to return different xts if you
want to comply with ANS Forth even in corner cases; for TO they at
least ambiguified the corner cases.
And the Forth-2012 committee changed neither this sentence in FIND nor
did we change that aspect of FILE S", and we added two more words of
its ilk, IS and ACTION-OF (both with ambiguified corner cases). Maybe
these things are a mistake in ANS Forth, but we obviously could not
find a consensus on a better solution; i.e., what they did is
apparently not that bad.
>Building tables of XTs when you do not know whether you can use the XT
>with COMPILE, just forces you to build special tools and double the
>size of the table by having separate interpretation and compilation
>entries. The simple way:
>create atable \ -- addr
> ' foo ,
> ' bar ,
> ...
>The bad way:
>create atable \ -- addr
> 'interp foo , 'comp foo ,
> 'interp bar , 'comp bar ,
> ...
You need to store the immediacy flag, too, for the compilation
semantics.
>Having two results from FIND disenfranchises simple techniques in
>Forth that have been available for a very long time. Multiple results
>from FIND is a mistake that leads to complexity.
It's what the standard (ANS and 2012) specifies, so if you want to
write a standard program, you have to deal with that.
By contrast, if you store NTs in atable, you can get to the
interpertation semantics with NAME>INTERPRET and to the compilation
semantics with NAME>COMPILE; you need to store only one cell.
create atable \ -- addr
s" foo" find-name ,
s" bar" find-name ,
And to be able to do that, FIND-NAME would be convenient.
>The XT as a single
>point of contact promotes simplicity.
Looking at the "bad way", I can't say I agree. As for the "simple
way", it does not work in a standard program in general (i.e., when
words with non-default compilation semantics are involved).
I am not a fan of FIND, either, but as long as we have words with
funky combinations of interpretation and compilation semantics, the
idea that the xt can do it all is, as the saying goes, "clear, simple,
and wrong". That's why I use FIND-NAME and want to see it
standardized. It allows us to use a solution that leads to simple
code, no need to deal with the FIND mess. It may not be as simple as
having only an xt, but correctness has it's price.
The other alternative is to destandardize S" (and throw in TO, IS,
ACTION-OF, and STATE for good measure), make all the words with
undefined interpretation semantics either immediate (most of them) or
normal words (stuff like COMPILE,). Then we only have normal (default
compilation semantics) and immediate words, FIND returns the same xt
independent of STATE, and we can make ATABLE as follows:
create atable \ -- addr
'imm foo , ,
'imm bar , ,
where 'imm produces the results of FIND, i.e., an xt and 1 or -1.
Even that is not really simple, but at least there is just a single xt
per word now. But my impression is that too many Forthers are too
much in love with "smart" words like S", and this approach is not
viable.
- 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: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-04 23:07 +0000 |
| Message-ID | <59349179.979670725@news.eternal-september.org> |
| In reply to | #60146 |
On Thu, 01 Jun 2017 14:21:43 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >>Having two results from FIND disenfranchises simple techniques in >>Forth that have been available for a very long time. Multiple results >>from FIND is a mistake that leads to complexity. > >It's what the standard (ANS and 2012) specifies, so if you want to >write a standard program, you have to deal with that. IMHO the standard is just wrong. We should get rid of the state smart results from FIND. >I am not a fan of FIND, either, but as long as we have words with >funky combinations of interpretation and compilation semantics, the >idea that the xt can do it all is, as the saying goes, "clear, simple, >and wrong". That's why I use FIND-NAME and want to see it >standardized. It allows us to use a solution that leads to simple >code, no need to deal with the FIND mess. It may not be as simple as >having only an xt, but correctness has it's price. > >The other alternative is to destandardize S" (and throw in TO, IS, >ACTION-OF, and STATE for good measure), make all the words with >undefined interpretation semantics either immediate (most of them) or >normal words (stuff like COMPILE,). Then we only have normal (default >compilation semantics) and immediate words, FIND returns the same xt >independent of STATE, and we can make ATABLE as follows: > >create atable \ -- addr >'imm foo , , >'imm bar , , > >where 'imm produces the results of FIND, i.e., an xt and 1 or -1. >Even that is not really simple, but at least there is just a single xt >per word now. But my impression is that too many Forthers are too >much in love with "smart" words like S", and this approach is not >viable. I would love that perspective to be true, but the problem is that ANS and Forth-2012 have introduced non-default compilation semantics, and implementations have taken advantage of them. Similarly gForth seems to depend on the cmForth concession in FIND. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-10 15:49 +0000 |
| Message-ID | <2017Jun10.174907@mips.complang.tuwien.ac.at> |
| In reply to | #60308 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Thu, 01 Jun 2017 14:21:43 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>>Having two results from FIND disenfranchises simple techniques in
>>>Forth that have been available for a very long time. Multiple results
>>>from FIND is a mistake that leads to complexity.
>>
>>It's what the standard (ANS and 2012) specifies, so if you want to
>>write a standard program, you have to deal with that.
>
>IMHO the standard is just wrong.
A few postings upthread you praised the ANS XT. Hmm.
>We should get rid of the state
>smart results from FIND.
Maybe. What are you willing to sacrifice for this? There are a few
options:
1) Also get rid of words like S".
2) Keep S", but either ambiguify the corner cases (as was done in TO)
in order to allow STATE-smart implementation of S". Or outright
specify S", TO, etc. in a STATE-smart way.
3) Forget about writing user-defined text interpreters with FIND.
Well, you cannot do that in Forth-94 or Forth-2012, but it is common
practice, and both standards committees probably intended to support
this.
>I would love that perspective to be true, but the problem is that ANS
>and Forth-2012 have introduced non-default compilation semantics, and
>implementations have taken advantage of them.
It would not be a problem if there was consensus that we don't want
such words. But I don't see such a consensus.
>Similarly gForth seems
>to depend on the cmForth concession in FIND.
Gforth uses FIND-NAME and FIND-NAME-IN (aka SEARCH-NAME), and does not
use (and therefore does not depend on) FIND at all.
Gforth only provides FIND in order to support legacy software. So the
question when implementing it is how to best support that software. A
prominent use of FIND is to write user-defined text interpreters. In
the presence of S" this means that we have to implement FIND to
produce a STATE-dependent result. I did not like that, either, but of
all the options (see above) this one was the least harmful.
- 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: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-11 11:14 +0000 |
| Message-ID | <593d2458.327997530@news.eternal-september.org> |
| In reply to | #60567 |
On Sat, 10 Jun 2017 15:49:07 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >stephen@mpeforth.com (Stephen Pelc) writes: >>On Thu, 01 Jun 2017 14:21:43 GMT, anton@mips.complang.tuwien.ac.at >>(Anton Ertl) wrote: >> >>>>Having two results from FIND disenfranchises simple techniques in >>>>Forth that have been available for a very long time. Multiple results >>>>from FIND is a mistake that leads to complexity. >>> >>>It's what the standard (ANS and 2012) specifies, so if you want to >>>write a standard program, you have to deal with that. >> >>IMHO the standard is just wrong. > >A few postings upthread you praised the ANS XT. Hmm. From the tex above, it should be clear that I think that the standard is wrong to have a state-smart FIND. >>We should get rid of the state >>smart results from FIND. > >Maybe. What are you willing to sacrifice for this? There are a few >options: > >1) Also get rid of words like S". > >2) Keep S", but either ambiguify the corner cases (as was done in TO) >in order to allow STATE-smart implementation of S". Or outright >specify S", TO, etc. in a STATE-smart way. > >3) Forget about writing user-defined text interpreters with FIND. >Well, you cannot do that in Forth-94 or Forth-2012, but it is common >practice, and both standards committees probably intended to support >this. S" TO and friends have Non-Default Compilation Semantics. We just need to introduce words for setting and determining this condition. At the same time we should do the same for immediate words. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-06-11 08:24 -0700 |
| Message-ID | <96b3ca50-d004-47ea-9fc0-0b50491134e7@googlegroups.com> |
| In reply to | #60606 |
Am Sonntag, 11. Juni 2017 13:14:41 UTC+2 schrieb Stephen Pelc: > On Sat, 10 Jun 2017 15:49:07 GMT, anton@mips.complang.tuwien.ac.at > (Anton Ertl) wrote: > > >stephen@mpeforth.com (Stephen Pelc) writes: > >>On Thu, 01 Jun 2017 14:21:43 GMT, anton@mips.complang.tuwien.ac.at > >>(Anton Ertl) wrote: > >> > >>>>Having two results from FIND disenfranchises simple techniques in > >>>>Forth that have been available for a very long time. Multiple results > >>>>from FIND is a mistake that leads to complexity. > >>> > >>>It's what the standard (ANS and 2012) specifies, so if you want to > >>>write a standard program, you have to deal with that. > >> > >>IMHO the standard is just wrong. > > > >A few postings upthread you praised the ANS XT. Hmm. > > From the tex above, it should be clear that I think that the > standard is wrong to have a state-smart FIND. > > >>We should get rid of the state > >>smart results from FIND. > > > >Maybe. What are you willing to sacrifice for this? There are a few > >options: > > > >1) Also get rid of words like S". > > > >2) Keep S", but either ambiguify the corner cases (as was done in TO) > >in order to allow STATE-smart implementation of S". Or outright > >specify S", TO, etc. in a STATE-smart way. > > > >3) Forget about writing user-defined text interpreters with FIND. > >Well, you cannot do that in Forth-94 or Forth-2012, but it is common > >practice, and both standards committees probably intended to support > >this. > > S" TO and friends have Non-Default Compilation Semantics. We just need > to introduce words for setting and determining this condition. At the > same time we should do the same for immediate words. > I am using extended header flags since long. They occupy one cell per header. For "normal" words the flag contains -1 1 for standard FIND (which is not state-smart). Otherwise the cell contains the word's compilation token ct. So >FLAG @ means ( xt -- f|ct ). Dual sematic words can be defined like this: : [S"] ....... ; COMPILES S" So COMPILES just patches the flag cell in S" header. It's a cousin to IS. The interpreter loop is just a bit more complicated because it has to check the flag returned by FIND a bit more. Very simple and no trouble with POSTPONE et al.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-13 15:07 +0000 |
| Message-ID | <2017Jun13.170754@mips.complang.tuwien.ac.at> |
| In reply to | #60606 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Sat, 10 Jun 2017 15:49:07 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>stephen@mpeforth.com (Stephen Pelc) writes:
>>>On Thu, 01 Jun 2017 14:21:43 GMT, anton@mips.complang.tuwien.ac.at
>>>(Anton Ertl) wrote:
>>>
>>>>>Having two results from FIND disenfranchises simple techniques in
>>>>>Forth that have been available for a very long time. Multiple results
>>>>>from FIND is a mistake that leads to complexity.
>>>>
>>>>It's what the standard (ANS and 2012) specifies, so if you want to
>>>>write a standard program, you have to deal with that.
>>>
>>>IMHO the standard is just wrong.
>>
>>A few postings upthread you praised the ANS XT. Hmm.
>
>From the tex above, it should be clear that I think that the
>standard is wrong to have a state-smart FIND.
In ANS Forth, FIND is very relevant to understand what ANS Forth means
by xt. If they really intended the xt to be a single point of
reference, FIND would return a single xt and otherwise just a
not-found flag, and it would the same xt for the same name independent
of STATE.
However, in actual ANS Forth (and Forth-2012) FIND returns an xt plus
immediacy information, indicating that the xt is not enough to
determine immediacy information. Moreover, it may return different
results (including different xts) in different states, showing that
the same named word can have several xts. This would be unnecessary
if a single xt/immediacy pair could represent both interpretation and
compilation semantics.
In conclusion, unlike you claimed, the ANS Forth TC did not intend the
xt to be the single point of reference for a named word. The only way
to reference a named word in ANS Forth is through it's name string (by
FINDing it). We improved on that in Forth-2012 by introducing the nt
along with operations on the nt. Now, what's missing is FIND-NAME and
SEARCH-NAME.
- 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: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-01 12:11 +0100 |
| Message-ID | <ogosi4$bea$1@dont-email.me> |
| In reply to | #60120 |
On 5/31/2017 23:55, Stephen Pelc wrote: > > Stephen > > P.S. You asked for my input. > > Yes, I did, and there's no need to apologise for being a contrarian. Tbf it wouldn't be worth an RfD if you as MPE found it unworkable or even just straightforward unwanted. I'll "pile on" in the latest discussion you and Anton are having. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-30 11:03 -0700 |
| Message-ID | <98830d8e-3fe0-48b8-a2ec-aa0432c7ca68@googlegroups.com> |
| In reply to | #60025 |
> I'm particularly interested in the third entry, which has the signature > of ( c-addr u -- 0 | nt ). > > SEARCH-WORDLIST is not that useful because it returns an XT, and WF32 > uses a separate interpretation XT and a compile XT, derived from the NT > (name token). Amforth has SEARCH-NAME ( addr len wid -- nt|0) and on top of it FIND-NAME (addr len -- nt|0) that uses the search order. Matthias
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.forth
csiph-web