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 | 20 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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-14 10:19 +0000 |
| Message-ID | <2017Jun14.121916@mips.complang.tuwien.ac.at> |
| In reply to | #60715 |
minforth@arcor.de writes:
>Am Dienstag, 13. Juni 2017 18:30:58 UTC+2 schrieb Anton Ertl:
>>
>> TO, IS, and ACTION-OF already cannot be ticked or POSTPONEd.
>>
>
>I have read such statements now and then but haven't really thought
>it through:
>
>Now POSTPONE retrieves the compilation semantics of a word.
>But in dual-XT Forth systems retrieving the compilation semantics is
>a breeze, because the compilation token may be within the header structure.
>
>So ticking or postponing TO can be clear and bijective, but only in certain
>Forth implementations that can provide the compilation token of each word
>by some internal means.
>
>Or did I miss something?
No, that's pretty much it.
What I meant with the sentence above is that a standard program cannot
tick or POSTPONE these words; this is explicitly destandardized with
an ambiguous condition. If you try it, AFAIK no system produces an
error; some systems (e.g., Gforth) behave as described in the rest of
the word specification, others behave differently (e.g., in a
STATE-smart way). The ANS Forth TC added the ambiguous condition in
order to allow STATE-smart implementations.
- 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 | minforth@arcor.de |
|---|---|
| Date | 2017-06-14 05:44 -0700 |
| Message-ID | <1fd1be0d-2209-483d-87c3-21480041d54e@googlegroups.com> |
| In reply to | #60718 |
Am Mittwoch, 14. Juni 2017 13:40:08 UTC+2 schrieb Anton Ertl: > minforth@arcor.de writes: > >Am Dienstag, 13. Juni 2017 18:30:58 UTC+2 schrieb Anton Ertl: > >> > >> TO, IS, and ACTION-OF already cannot be ticked or POSTPONEd. > >> > > > >I have read such statements now and then but haven't really thought > >it through: > > > >Now POSTPONE retrieves the compilation semantics of a word. > >But in dual-XT Forth systems retrieving the compilation semantics is > >a breeze, because the compilation token may be within the header structure. > > > >So ticking or postponing TO can be clear and bijective, but only in certain > >Forth implementations that can provide the compilation token of each word > >by some internal means. > > > >Or did I miss something? > > No, that's pretty much it. > > What I meant with the sentence above is that a standard program cannot > tick or POSTPONE these words; this is explicitly destandardized with > an ambiguous condition. If you try it, AFAIK no system produces an > error; some systems (e.g., Gforth) behave as described in the rest of > the word specification, others behave differently (e.g., in a > STATE-smart way). The ANS Forth TC added the ambiguous condition in > order to allow STATE-smart implementations. > > - 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/ Thanks for the clarification. So the whole name-token discussion is about proper unambiguous identification of words, which is not achievable by execution tokens alone in all cases. So either one enhances Forth system functionality (which is rewarding) and which has already been done in gforth, or one tries to reword the standard document (which is frustrating). ;-)
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-14 14:27 +0000 |
| Message-ID | <59413e41.596775007@news.eternal-september.org> |
| In reply to | #60720 |
On Wed, 14 Jun 2017 05:44:22 -0700 (PDT), minforth@arcor.de wrote: >Thanks for the clarification. So the whole name-token discussion is about >proper unambiguous identification of words, which is not achievable by >execution tokens alone in all cases. VFX just uses XTs except to support the standard, e.g. for TRAVERSE-WORDLIST. There's an important point of philosophy and/or design here, which is that the XT was *intended* to be the single point of contact with a word - the XT is all you need. NTs were introduced to deal with dictionary name traversal issues when people with complex header structures and separated code realised that going from a code address to a header address and back was going to be slow. This misses the point that an XT is *not* a code address - it's a magic token from which all the required data can be found. Most systems optimise XTs for EXECUTE but there's no requirement for this to be so. >So either one enhances Forth system functionality (which is rewarding) >and which has already been done in gforth, or one tries to reword the >standard document (which is frustrating). ;-) There's no reason at all why headers (and dummies for :NONAMEs) cannot be XTs. In most such systems the cost for EXECUTE is a single fetch. It seems to me that systems should be free to choose what an XT really is. While an XT is an opaque type (system dependent) there is no point in trying to impose meaning on it. Adding NT, a second opaque type for the same thing, is verging on the absurd. In this discussion, it is perfectly appropriate to suggest that Gforth should enhance the functionality of its XTs. Note also that there are already parts of the Forth-2012 document that need rewording. That's why the standards process continues. 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-14 08:06 -0700 |
| Message-ID | <090eaf36-48ba-4d9c-8fa8-26bdf0573bbd@googlegroups.com> |
| In reply to | #60723 |
Am Mittwoch, 14. Juni 2017 16:27:33 UTC+2 schrieb Stephen Pelc: > On Wed, 14 Jun 2017 05:44:22 -0700 (PDT), minforth@arcor.de wrote: > > >Thanks for the clarification. So the whole name-token discussion is about > >proper unambiguous identification of words, which is not achievable by > >execution tokens alone in all cases. > > VFX just uses XTs except to support the standard, e.g. for > TRAVERSE-WORDLIST. There's an important point of philosophy > and/or design here, which is that the XT was *intended* to be > the single point of contact with a word - the XT is all you need. Do non-immediate compile-only words have an xt? Admitted, the question is theoretical because the standard reserves a throw code -14 for them, it offers no words to manage compile-only words. > NTs were introduced to deal with dictionary name traversal > issues when people with complex header structures and separated > code realised that going from a code address to a header address > and back was going to be slow. This misses the point that an XT > is *not* a code address - it's a magic token from which all the > required data can be found. Most systems optimise XTs for EXECUTE > but there's no requirement for this to be so. > > >So either one enhances Forth system functionality (which is rewarding) > >and which has already been done in gforth, or one tries to reword the > >standard document (which is frustrating). ;-) > > There's no reason at all why headers (and dummies for :NONAMEs) cannot > be XTs. In most such systems the cost for EXECUTE is a single fetch. > It seems to me that systems should be free to choose what an XT > really is. While an XT is an opaque type (system dependent) there > is no point in trying to impose meaning on it. Adding NT, a second > opaque type for the same thing, is verging on the absurd. > > In this discussion, it is perfectly appropriate to suggest that Gforth > should enhance the functionality of its XTs. Note also that there are > already parts of the Forth-2012 document that need rewording. That's > why the standards process continues. Right. It should also be noted that all this applies to Forth systems but not necessarily to applications. Most of my turnkey applications are stripped of directory information anyhow. Even if there is an interpreter loop in the target, compiling words are rare. There tokens become meaningless. IMO the simplest way to clean this hodgepodge would be to eliminate all words with dual semantics. TO already is a nightmare.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-14 16:36 +0000 |
| Message-ID | <594164a9.606606986@news.eternal-september.org> |
| In reply to | #60729 |
On Wed, 14 Jun 2017 08:06:20 -0700 (PDT), minforth@arcor.de wrote: >Do non-immediate compile-only words have an xt? >Admitted, the question is theoretical because the standard reserves >a throw code -14 for them, it offers no words to manage compile-only words. All words in VFX have an XT. >IMO the simplest way to clean this hodgepodge would be to eliminate all >words with dual semantics. TO already is a nightmare. Dual semantics have been around for decades. State smart words are occasionally useful to provide clean application notations. However, words with dual semantics can be problematic unless there are ways of implementing them correctly. Several Forth systems have different ways to implement them. Let us at least see if we can find a way to describe a correct interpreter and the additional words required. 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 | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2017-06-15 09:48 -0700 |
| Message-ID | <bb5d9533-db55-4c9b-a12c-224773ece6c1@googlegroups.com> |
| In reply to | #60744 |
On Wednesday, June 14, 2017 at 9:36:43 AM UTC-7, Stephen Pelc wrote:
>
> Let us at least see if we can find a way to describe a correct
> interpreter and the additional words required.
>
: INTERPRET ( -- )
BEGIN PARSE-NAME DUP WHILE
FIND-NAME OVER IF NUMBER ELSE
NIP STATE @ IF
NAME>COMP ELSE
NAME>EXEC THEN EXECUTE
THEN
REPEAT 2DROP
;
where FIND-NAME ( c-addr u -- 0 nt | c-addr u ) gives you your (not counted) string back if not found. There should be a NAME>IMMEDIATE word so that FIND can be defined in terms of it and FIND-NAME, for backward compatibility.
NAME>COMP and NAME>EXEC have the same semantics as in gForth.
NUMBER throws a -13 if not found. I think it should be a deferred word.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-15 17:18 +0000 |
| Message-ID | <5942c0ea.53530947@news.eternal-september.org> |
| In reply to | #60784 |
On Thu, 15 Jun 2017 09:48:29 -0700 (PDT), Brad Eckert <hwfwguy@gmail.com> wrote: >On Wednesday, June 14, 2017 at 9:36:43 AM UTC-7, Stephen Pelc wrote: >> >> Let us at least see if we can find a way to describe a correct >> interpreter and the additional words required. >> >: INTERPRET ( -- ) > BEGIN PARSE-NAME DUP WHILE > FIND-NAME OVER IF NUMBER ELSE > NIP STATE @ IF > NAME>COMP ELSE > NAME>EXEC THEN EXECUTE > THEN > REPEAT 2DROP >; Describe the words needed to make a word with separate interpretation and compilation actions is what I need. In such a way there can be standardisation of them. 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 | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-15 18:50 +0100 |
| Message-ID | <ohuh5q$1te$1@dont-email.me> |
| In reply to | #60786 |
On 6/15/2017 18:18, Stephen Pelc wrote:
> On Thu, 15 Jun 2017 09:48:29 -0700 (PDT), Brad Eckert
> <hwfwguy@gmail.com> wrote:
>
>> On Wednesday, June 14, 2017 at 9:36:43 AM UTC-7, Stephen Pelc wrote:
>>>
>>> Let us at least see if we can find a way to describe a correct
>>> interpreter and the additional words required.
>>>
>> : INTERPRET ( -- )
>> BEGIN PARSE-NAME DUP WHILE
>> FIND-NAME OVER IF NUMBER ELSE
>> NIP STATE @ IF
>> NAME>COMP ELSE
>> NAME>EXEC THEN EXECUTE
>> THEN
>> REPEAT 2DROP
>> ;
>
> Describe the words needed to make a word with separate
> interpretation and compilation actions is what I need. In
> such a way there can be standardisation of them.
This may be a spectacularly dim observation, but is that not exactly
what the recognizer proposal does?
( edited to simplify )
: interpreter ( -- )
begin
parse-name dup
while
forth-recognizer recognize
state @ cells- @ execute
repeat 2drop ;
where recognize provides a pointer to 3 actions; interpret, compile and
postpone.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-15 19:22 +0000 |
| Message-ID | <5942dc09.60474427@news.eternal-september.org> |
| In reply to | #60788 |
On Thu, 15 Jun 2017 18:50:11 +0100, Alex <alex@rivadpm.com> wrote: >This may be a spectacularly dim observation, but is that not exactly >what the recognizer proposal does? No. Recognisers are an implementation method for parsers. They don't cure cancer or fix Forth standards. What I want to discuss is standards for defining words with different interpretation and compilation actions. This is a pre-RFD discussion. Consider how to implement a version of ." that works in both interpretation and compilation states. We'll just ignore the STATE-smart version because we know that it has problems. One solution is provided and documented in VFX. : ." \ "ccc<quote>" -- \ *G Output the text up to the closing double-quotes character. [char] " word $. ; comp: ( xt -- ) drop postpone (.") ", ; The colon definition is the normal interpretation behaviour. COMP: sets the compilation behaviour of the last word compiled and whose xt is provided as a parameter. The action is what follows up to the semi-colon. With this notation there is no need for ." to be IMMEDIATE. 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-15 13:09 -0700 |
| Message-ID | <819ec646-c25d-445b-a6ff-9d30af89dacc@googlegroups.com> |
| In reply to | #60791 |
Am Donnerstag, 15. Juni 2017 21:22:21 UTC+2 schrieb Stephen Pelc: > On Thu, 15 Jun 2017 18:50:11 +0100, Alex <alex@rivadpm.com> wrote: > > >This may be a spectacularly dim observation, but is that not exactly > >what the recognizer proposal does? > > No. Recognisers are an implementation method for parsers. They > don't cure cancer or fix Forth standards. What I want to > discuss is standards for defining words with different > interpretation and compilation actions. This is a pre-RFD > discussion. > <COMPILES looks cute, like DOES>: : ." (interpretation-semantics) <COMPILES (compilation-sematics) ;
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2017-06-15 13:43 -0700 |
| Message-ID | <b28cae80-7020-4282-82ee-ef539c85659e@googlegroups.com> |
| In reply to | #60791 |
On Thursday, June 15, 2017 at 12:22:21 PM UTC-7, Stephen Pelc wrote: > > No. Recognisers are an implementation method for parsers. They > don't cure cancer or fix Forth standards. What I want to > discuss is standards for defining words with different > interpretation and compilation actions. This is a pre-RFD > discussion. > I think it's an important discussion to have, given that Forth is used so much to cross compile to MCUs. A dual-xt conceptual model may be the way forward in cross compilation. MPE ltd and FORTH inc invented a cross compiler standard at least 20 years ago. SwiftX follows that standard. It uses dual wordlists, which nobody is really happy with. Maybe that was your "write one to throw away". The benefits of ANS are for application writers. Implementors have the option of writing a standard that's backward compatible with ANS. I propose a separate DXT (dual-xt) standard that doesn't necessarily ride on an ANS system, but an ANS system can ride on it. Application writers can migrate to DXT as they see fit. DXT can clean up the remaining ANS state-smart issues with as big a hammer as necessary. Cross Forth is close to ANS but not quite. DXT should be at home in cross and native environments. I like Alex's idea of FIND-NAME filling in a smorgasboard-style data structure rather than making the interpreter go out and get the name features it wants using NAME>INT etc. I'd make that a static data structure or BUFFER:. For the smorgasboard name, NAMESTRUCT would be fine with me.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-06-15 22:55 +0200 |
| Message-ID | <86poe57yyk.fsf@molnjunk.nocrew.org> |
| In reply to | #60794 |
Brad Eckert wrote: > smorgasboard I want SMORGASBOARD in the standard. I don't care what it does.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-15 22:20 +0100 |
| Message-ID | <ohutgh$huu$1@dont-email.me> |
| In reply to | #60791 |
On 6/15/2017 20:22, Stephen Pelc wrote:
> On Thu, 15 Jun 2017 18:50:11 +0100, Alex <alex@rivadpm.com> wrote:
>
>> This may be a spectacularly dim observation, but is that not exactly
>> what the recognizer proposal does?
>
> No. Recognisers are an implementation method for parsers. They
> don't cure cancer or fix Forth standards. What I want to
> discuss is standards for defining words with different
> interpretation and compilation actions. This is a pre-RFD
> discussion.
>
> Consider how to implement a version of ." that works in both
> interpretation and compilation states. We'll just ignore the
> STATE-smart version because we know that it has problems.
>
> One solution is provided and documented in VFX.
> : ." \ "ccc<quote>" --
> \ *G Output the text up to the closing double-quotes character.
> [char] " word $.
> ;
> comp: ( xt -- ) drop postpone (.") ", ;
>
> The colon definition is the normal interpretation behaviour.
>
> COMP: sets the compilation behaviour of the last word compiled
> and whose xt is provided as a parameter. The action is what
> follows up to the semi-colon.
>
> With this notation there is no need for ." to be IMMEDIATE.
>
> Stephen
>
Ah, I see, apologies. I have this;
: ." ( -<string">- -- )
[char] " parse type
compiles> ( xt -- ) drop
postpone s" postpone type ;
The xt returned by COMPILES> is the interpretation semantics. IMMEDIATE
is the equivalent of ... COMPILES> EXECUTE ;
There are also
: compiles ( xt1 xt2 -- ) ... ; \ set the compile field of xt2 to xt1
: compiles-me ( xt -- ) ... ; \ sets xt as compilation for last name
\ defined
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-16 17:04 +0000 |
| Subject | pre-Rfd for smart word definition mechanism (was: Another ...) |
| Message-ID | <2017Jun16.190430@mips.complang.tuwien.ac.at> |
| In reply to | #60791 |
stephen@mpeforth.com (Stephen Pelc) writes:
>One solution is provided and documented in VFX.
>: ." \ "ccc<quote>" --
>\ *G Output the text up to the closing double-quotes character.
> [char] " word $.
>;
>comp: ( xt -- ) drop postpone (.") ", ;
>
>The colon definition is the normal interpretation behaviour.
>
>COMP: sets the compilation behaviour of the last word compiled
>and whose xt is provided as a parameter. The action is what
>follows up to the semi-colon.
I'll assume that you mean "semantics" (the standard term) when you
write "behaviour" (which otherwise might mean anything).
In VFX, COMP: does not set compilation semantics, it changes what
COMPILE, does. And in this case it changes COMPILE, to behave in a
non-standard way: when you COMPILE, the xt of .", it COMPILE, parses,
contrary to the standard specification of COMPILE,. Test at the end
of the posting.
Also, the changed COMPILE, does not "append the execution semantics of
the definition represented by xt to [...] the current definition" as
the standard specifies; instead, it performs the stuff after COMP:.
That's fine if the stuff after COMP: is equivalent to appending the
execution semantics, but in this case it isn't. An example of a
correct use of COMP: is:
: 2dup over over ;
comp: drop postpone over postpone over ;
That's why COMP: is called OPT: in Gforth: It must only be used for
optimization.
If we want to implement such a smart ." correctly, you can use the
same syntax, but COMP: then must not change COMPILE,, but change what
NAME>COMPILE produces, and what FIND produces in compile state.
However, because you also use COMP: in the sense of OPT:, I guess a
slightly different syntax would be better, and maybe you can then also
get rid of the DROP at the start of the COMP: part.
>With this notation there is no need for ." to be IMMEDIATE.
FIND must return xt 1 (i.e., immediate) for .", because the
compilation semantics of ." parses, it therefore has to be performed
through the EXECUTE branch of the text interpreter, not the COMPILE,
branch.
And here's the test that shows that this definition of ." behaves
incorrectly in VFX:
\ First add some checking to COMPILE,
: defers
\ "defers X" produces a call to the current content of the deferred word X
' defer@ compile, ; immediate
:noname ( xt -- )
>in @ >r
depth 1- >r
defers compile,
depth r> <> abort" compile, stack effect wrong"
>in @ r> <> abort" compile, input stream effect wrong" ;
is compile,
\ now the definition from above
: ." \ "ccc<quote>" --
\ *G Output the text up to the closing double-quotes character.
[char] " word $.
;
comp: ( xt -- ) drop postpone (.") ", ;
\ let's trigger the error
: foo ." abc" ;
\ outputs "compile, input stream effect wrong"
- 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-16 21:58 +0000 |
| Subject | Re: pre-Rfd for smart word definition mechanism (was: Another ...) |
| Message-ID | <59444ee9.155417743@news.eternal-september.org> |
| In reply to | #60841 |
On Fri, 16 Jun 2017 17:04:30 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >stephen@mpeforth.com (Stephen Pelc) writes: >>One solution is provided and documented in VFX. >>: ." \ "ccc<quote>" -- >>\ *G Output the text up to the closing double-quotes character. >> [char] " word $. >>; >>comp: ( xt -- ) drop postpone (.") ", ; >> >>The colon definition is the normal interpretation behaviour. >> >>COMP: sets the compilation behaviour of the last word compiled >>and whose xt is provided as a parameter. The action is what >>follows up to the semi-colon. > >I'll assume that you mean "semantics" (the standard term) when you >write "behaviour" (which otherwise might mean anything). >In VFX, COMP: does not set compilation semantics, it changes what >COMPILE, does. And in this case it changes COMPILE, to behave in a >non-standard way: when you COMPILE, the xt of .", it COMPILE, parses, >contrary to the standard specification of COMPILE,. Test at the end >of the posting. This discussion about notation would be more productive without your obsession to find errors in VFX Forth. Discuss the notation please. I actually now agree with you that the standard says that COMPILE, should not have a stack effect other than ( xt -- ) and that it should not parse. It just so happens that the VFX implementation (and probably many others) work just fine in both of these cases. I chose to call the version that works in these cases NDCS, Let's redefine ." to use NDCS, : ." \ "ccc<quote>" -- \ *G Output the text up to the closing double-quotes character. [char] " word $. ; ndcs: ( -- ) ['] (.") ndcs, ", ; The nice thing about this notation is that it gives the compiler a chance to set any flags or data structures needed for NDCS words. Without passing in an xt, we have an obvious implementation of IMMEDIATE and the traditional IMMEDIATE header flag can become the NDCS flag. Then you get your way as COMP: becomes reserved for code generators. Whether NDCS: needs an xt to be passed in will only be found with experience. >FIND must return xt 1 (i.e., immediate) for .", because the >compilation semantics of ." parses, it therefore has to be performed >through the EXECUTE branch of the text interpreter, not the COMPILE, >branch. No. It has to be handled by the NDCS handler. Why mandate the interpreter loop structure? The Gforth loop is so far from the classical and illustrative loop that you have no rights here. All I'm going to do is to add an NDCS flag and take account of it in the interpreter loop and POSTPONE. We do not have to add complexity to both get rid of STATE-smart words and to enhance functionality. For example, with my proposal, it becomes simple to make interpretive versions of the control flow 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 | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2017-06-17 00:26 -0700 |
| Subject | Re: pre-Rfd for smart word definition mechanism (was: Another ...) |
| Message-ID | <243986a6-4b06-430c-a320-45b623778a5e@googlegroups.com> |
| In reply to | #60861 |
I think Anton's point is that the classic interpreter loop
-1 = STATE @ AND IF COMPILE, ELSE EXECUTE THEN
and it's variants should run without modification. But this cannot handle NCDS words unless STATE is also checked elsewhere, either in the word itself (STATE-smart words) or in FIND.
Neither of these seems elegant or satisfactory, so any Forth that wants to use a 'clean' notation is going to have to re-write its outer interpeter anyway.
So.
FIND always returns the interpretation xt (which may raise an error for compile-only words)
EXECUTE executes that xt, so works for IMMEDIATE words or the interpretation semantics of
NDCS words.
COMPILE, compiles an optimised version of LITERAL EXECUTE
Since we don't want FIND to return any different flags, it seems NDCS words should be returned with an immediate flag, but instead of EXECUTE while compiling we need a new factor. Call it PCS for 'perform compiling semantics'.
: PCS ( xt -1|1 -- ) -1 = IF COMPILE, ELSE ... THEN ;
So the interpreter loop is ... FIND ?DUP IF STATE @ IF PCS ELSE EXECUTE THEN ELSE ...
This does not presume that the system can deduce the compilation semantics from the bare xt alone. If a system has FIND-NAME or something similar implemented to return an nt, then FIND could use that internally and cache the result for PCS.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-06-17 01:18 -0700 |
| Subject | Re: pre-Rfd for smart word definition mechanism (was: Another ...) |
| Message-ID | <279264af-cc07-4362-9ef8-db5bf2f3d70b@googlegroups.com> |
| In reply to | #60887 |
Am Samstag, 17. Juni 2017 09:26:34 UTC+2 schrieb JennyB: > I think Anton's point is that the classic interpreter loop > > > -1 = STATE @ AND IF COMPILE, ELSE EXECUTE THEN > > and it's variants should run without modification. But this cannot handle NCDS words unless STATE is also checked elsewhere, either in the word itself (STATE-smart words) or in FIND. > > Neither of these seems elegant or satisfactory, so any Forth that wants to use a 'clean' notation is going to have to re-write its outer interpeter anyway. > > So. > > FIND always returns the interpretation xt (which may raise an error for compile-only words) > EXECUTE executes that xt, so works for IMMEDIATE words or the interpretation semantics of > NDCS words. > COMPILE, compiles an optimised version of LITERAL EXECUTE > > Since we don't want FIND to return any different flags, it seems NDCS words should be returned with an immediate flag, but instead of EXECUTE while compiling we need a new factor. Call it PCS for 'perform compiling semantics'. > > : PCS ( xt -1|1 -- ) -1 = IF COMPILE, ELSE ... THEN ; > > So the interpreter loop is ... FIND ?DUP IF STATE @ IF PCS ELSE EXECUTE THEN ELSE ... > > This does not presume that the system can deduce the compilation semantics from the bare xt alone. If a system has FIND-NAME or something similar implemented to return an nt, then FIND could use that internally and cache the result for PCS. Assume a modified FIND, say NDFIND ( c-addr --- c-addr 0 | xt ct ) returning execution token xt and compilation token ct when found, the outer interpreter loop becomes dead simple. When not found, checking for literals can use similary LITERAL? ( c-addr --- c-addr 0 | ... ct ) to keep the outer interpreter dead simple also for literals. LITERAL? is a deferred word to allow for chained recognizing of different literal types. All this assumes that ct is never zero of course.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-17 15:24 +0000 |
| Subject | Re: pre-Rfd for smart word definition mechanism (was: Another ...) |
| Message-ID | <2017Jun17.172417@mips.complang.tuwien.ac.at> |
| In reply to | #60887 |
JennyB <jennybrien@googlemail.com> writes:
>I think Anton's point is that the classic interpreter loop
>
>
> -1 = STATE @ AND IF COMPILE, ELSE EXECUTE THEN
>
>and it's variants should run without modification. But this cannot handle NCDS words unless STATE is also checked elsewhere, either in the word itself (STATE-smart words) or in FIND.
>
>Neither of these seems elegant or satisfactory, so any Forth that wants to use a 'clean' notation is going to have to re-write its outer interpeter anyway.
>
>So.
>
> FIND always returns the interpretation xt (which may raise an error for compile-only words)
If you have NDCS: words and want to support existing user-defined text
interpreters, FIND's result must be state-dependent, for the reasons
given repeatedly. If you have FIND-NAME, a way to implement FIND is:
: find ( c-addr -- xt n | c-addr 0 )
dup count find-name ?dup if
nip dup name>interpret swap name>compile >r ( xti xt1 R: xt2 )
state @ if swap then drop ( xt R: xt2 )
r> ['] execute = ( xt 0|-1 ) -2 * 1- ( xt -1|1 )
then ;
This assumes that the xt2 produced by NAME>COMPILE is either the xt of
EXECUTE or the xt of COMPILE,. That is pretty natural for
NAME>COMPILE, especially if you also want to implement FIND.
If you put this FIND in the traditional text interpreter, and follow
the various cases (interpret/compile state, normal/immediate/NDCS:
words), you see that the result is equivalent to a modern text
interpreter:
2dup find-name ?dup if
nip nip state @ if
name>compile
else
name>interpret
then
execute
else
... deal with numbers etc. ...
then
- 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 | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2017-06-17 12:29 -0700 |
| Subject | Re: pre-Rfd for smart word definition mechanism (was: Another ...) |
| Message-ID | <6f0fb768-4180-4a64-9b35-3819b7b79367@googlegroups.com> |
| In reply to | #60910 |
On Saturday, 17 June 2017 16:49:51 UTC+1, Anton Ertl wrote:
> JennyB <jennybrien@googlemail.com> writes:
> If you have NDCS: words and want to support existing user-defined text
> interpreters, FIND's result must be state-dependent, for the reasons
> given repeatedly. If you have FIND-NAME, a way to implement FIND is:
>
> : find ( c-addr -- xt n | c-addr 0 )
> dup count find-name ?dup if
> nip dup name>interpret swap name>compile >r ( xti xt1 R: xt2 )
> state @ if swap then drop ( xt R: xt2 )
> r> ['] execute = ( xt 0|-1 ) -2 * 1- ( xt -1|1 )
> then ;
>
> This assumes that the xt2 produced by NAME>COMPILE is either the xt of
> EXECUTE or the xt of COMPILE,. That is pretty natural for
> NAME>COMPILE, especially if you also want to implement FIND.
>
It's natural, but it's not currently specified. I've seen implementations that have the interpretation xt as the second item on the stack (I don't know how common that is, but it is currently allowed.) If we want user-defined NDCS: words then we need to standardise, and the obvious thing it to have the extra semantics represented by a single and devise some other syntax for it to call the interpretation xt if needed.
A more strict specification of FIND then would be:
If the flag = -1 the xt returned
Or the flag =1 and interpreting
the xt returned represents the interpretation semantics
If the flag =1 and compiling then the xt represents the compilation
semantics, which may differ.
which I think holds true for all currently Standard Forths.
As you say, if you want to support existing user-written (compiling) text interpreters then this is the only way to write FIND.
But:
It may introduce unexpected corner cases to other uses of FIND
It duplicates a lot of the work of the interpreter and doesn't make it
any easier to write.
User-written compiling text interpreters are quite rare (even rarer are ones that need to compile NDCS words), and every one I've seen that uses FIND is an idiosyncratic mess. Perhaps there is a case of a factor that makes them more understandable, and announces that the interpreter can handle NDCS words if they are provided.
With a STATE-responsive FIND:
: PCS \ xt flag -- ; perform compilation semantics
-1 = IF COMPILE, ELSE EXECUTE THEN ;
With a STATE-dumb FIND PCS needs a way to have a way of finding the compilation xt from the interpretation xt.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-18 12:29 +0000 |
| Subject | Re: pre-Rfd for smart word definition mechanism (was: Another ...) |
| Message-ID | <2017Jun18.142939@mips.complang.tuwien.ac.at> |
| In reply to | #60921 |
JennyB <jennybrien@googlemail.com> writes:
>On Saturday, 17 June 2017 16:49:51 UTC+1, Anton Ertl wrote:
>> This assumes that the xt2 produced by NAME>COMPILE is either the xt of
>> EXECUTE or the xt of COMPILE,. That is pretty natural for
>> NAME>COMPILE, especially if you also want to implement FIND.
>>
>
>It's natural, but it's not currently specified. I've seen implementations t=
>hat have the interpretation xt as the second item on the stack (I don't kno=
>w how common that is, but it is currently allowed.)
NAME>COMPILE ( nt -- x xt )
You mean, x represents the interpretation semantics, and xt (called
xt2 above) first drops x, and then performs the compilation semantics?
That's possible, but makes it harder to implement FIND, because xt
would not be directly usable for FIND.
> If we want user-defined=
> NDCS: words then we need to standardise, and the obvious thing it to have =
>the extra semantics represented by a single and devise some other syntax fo=
>r it to call the interpretation xt if needed.
You lost me here. There is certainly a connection between the code
after NDCS: and NAME>COMPILE, but the Forth system can implement NDCS:
and NAME>COMPILE so that they fit together, and there are probably several
ways to do that. Do you suggest standardizing on one?
>A more strict specification of FIND then would be:
>
> If the flag =3D -1 the xt returned=20
> Or the flag =3D1 and interpreting=20
> the xt returned represents the interpretation semantics
Not necessarily. In the standard there are some words without
interpretation semantics and with default compilation semantics, such
as >R. For them, in compile state you typically want to return -1 and
the xt representing the execution semantics; in interpret state, you
might return the xt of a word producing an error message.
> If the flag =3D1 and compiling then the xt represents the compilation=20
> semantics, which may differ.=20
My take on this derives from the traditional user-defined text
interpreter:
In interpret state, the returned xt represents the interpretation
semantics, and the sign of the flag does not matter (but I implement
it to return the same flag as in compile state to have the most
traditional behaviour).
In compile state, you return an xt and 1/-1 such that the satisfy the
following:
If you return 1, EXECUTEing the xt performs the compilation semantics.
If you return -1, COMPILE,ing the xt performs the compilation semantics.
>As you say, if you want to support existing user-written (compiling) text i=
>nterpreters then this is the only way to write FIND.
>
>But:
>
> It may introduce unexpected corner cases to other uses of FIND
Gforth has had such a FIND for about two decades. I don't remember
any other uses of FIND coming up that were broken by it. The reason
is that these other uses are either never applied to words like S"
(for normal and immediate words, this FIND works like every
traditional FIND), or because they are only applied in a way that is
aligned with the behaviour of this FIND.
> It duplicates a lot of the work of the interpreter and doesn't make it=
>=20
> any easier to write.
Well, FIND is a legacy interface. If the users are worried about
making the interpreter more efficient, they can rewrite their text
interpreters to use FIND-NAME NAME>INTERPRET NAME>COMPILE (I doubt
that this will make much of a performance difference, though; it makes
the whole thing a lot cleaner, though).
As for "easy to write", a FIND that works that way is just a few lines
of code. That is a small price to pay in order to keep existing code
working.
>User-written compiling text interpreters are quite rare (even rarer are one=
>s that need to compile NDCS words),
I don't write them, but others apparently write quite a lot of them,
so YMMV. And if you have a user-defined text interpreter, you may
want to throw all kinds of Forth code at it, including code containing
S" or TO, so being able to work on NDCS words is a requirement, too.
>and every one I've seen that uses FIND =
>is an idiosyncratic mess.
That may be the case, and is something their maintainers have to worry
about. I worry about how to make them work as intended, messy or no.
> Perhaps there is a case of a factor that makes th=
>em more understandable, and announces that the interpreter can handle NDCS =
>words if they are provided.
>
>With a STATE-responsive FIND:
>
> : PCS \ xt flag -- ; perform compilation semantics
> -1 =3D IF COMPILE, ELSE EXECUTE THEN ;
>
>
>With a STATE-dumb FIND PCS needs a way to have a way of finding the compila=
>tion xt from the interpretation xt.=20
Given that existing user-defined text interpreters don't use PCS, we
have to implement FIND in a way that it works with PCS-less
interpreters. And if people rewrite their text interpreters, my
recommendation would be to use FIND-NAME NAME>INTERPRET NAME>COMPILE.
No PCS needed.
- 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]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web