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 1 of 5 [1] 2 3 4 5 Next page →
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-29 20:47 +0100 |
| Subject | Another recognizer discussion |
| Message-ID | <oghtli$kng$1@dont-email.me> |
A wordlist can be considered to be a form of extensible recognizer, and
there may be some mileage in exploring the similarities and differences
between FIND, FIND-NAME, SEARCH-WORDLIST and REC:NAME (the
pseudo-standarised name for the non-numeric recognizer).
The discussion is based on the recognizer proposal here.
http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf
http://amforth.sourceforge.net/pr/Recognizer-rfc-D.html
WF32 (see https://github.com/alextangent/wf32) extends WORDLISTs (and
their named variety VOCABULARYs) to include three object-like actions.
They are:
1. An xt to create an entry (used by : CREATE and so on).
2. An xt to traverse over the wordlist (used by TRAVERSE-WORDLIST)
3. An xt to search the wordlist for a specific entry (it's this
wordlist's own specific SEARCH-WORDLIST)
(The idea is to support transparently different wordlist structures; for
instance, case sensitive vs case insensitive header and searches, and
traversal over wordlists based on hashes, lists, DLLs, SQL tables etc.)
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).
FIND-NAME returns the NT ( c-addr u –- nt | 0 ) but searches the current
search order, not a single wordlist. As it stands, REC:NAME follows that
pattern and can in fact be implemented as
: rec:name ( addr u -- nt dt:name | dt:null )
find-name ?dup if dt:name else dt:null then ;
--
Alex
[toc] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-29 20:57 +0100 |
| Message-ID | <oghu89$mng$1@dont-email.me> |
| In reply to | #60025 |
On 5/29/2017 20:47, Alex wrote: > > A wordlist can be considered to be a form of extensible recognizer, and > there may be some mileage in exploring the similarities and differences > between FIND, FIND-NAME, SEARCH-WORDLIST and REC:NAME (the > pseudo-standarised name for the non-numeric recognizer). > > The discussion is based on the recognizer proposal here. > > http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf > http://amforth.sourceforge.net/pr/Recognizer-rfc-D.html > > WF32 (see https://github.com/alextangent/wf32) extends WORDLISTs (and > their named variety VOCABULARYs) to include three object-like actions. > They are: > > 1. An xt to create an entry (used by : CREATE and so on). > 2. An xt to traverse over the wordlist (used by TRAVERSE-WORDLIST) > 3. An xt to search the wordlist for a specific entry (it's this > wordlist's own specific SEARCH-WORDLIST) > > (The idea is to support transparently different wordlist structures; for > instance, case sensitive vs case insensitive header and searches, and > traversal over wordlists based on hashes, lists, DLLs, SQL tables etc.) > > 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). > > FIND-NAME returns the NT ( c-addr u –- nt | 0 ) but searches the current > search order, not a single wordlist. As it stands, REC:NAME follows that > pattern and can in fact be implemented as > > : rec:name ( addr u -- nt dt:name | dt:null ) > find-name ?dup if dt:name else dt:null then ; > > Dammit, early send. I think we need an analogous word to FIND-NAME to search a single wordlist; for two reasons. 1. Better support for systems that use NTs. 2. (on from 1) Support a more finely grained REC:NAME as right now only SEARCH-WORDLIST (which returns the wrong thing) can search an individual wordlist. (Yes, there's TRAVERSE-WORDLIST, but it may not be possible to efficiently implement it for individual word searches). 3. Make wordlists a more general purpose data structure with well-described facilities for managing them. (I leave aside how entries might be generated and what word might be suitable; that's for another discussion.) FIND-NAME is already taken, by de facto usage. How about FIND-IN-WORDLIST ( c-addr u wid -- 0 | nt ) ? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | peter.m.falth@gmail.com |
|---|---|
| Date | 2017-05-29 13:18 -0700 |
| Message-ID | <42176fc7-32a8-4e78-97a5-f9e12c482e19@googlegroups.com> |
| In reply to | #60026 |
On Monday, 29 May 2017 21:57:15 UTC+2, Alex wrote: > On 5/29/2017 20:47, Alex wrote: > > > > A wordlist can be considered to be a form of extensible recognizer, and > > there may be some mileage in exploring the similarities and differences > > between FIND, FIND-NAME, SEARCH-WORDLIST and REC:NAME (the > > pseudo-standarised name for the non-numeric recognizer). > > > > The discussion is based on the recognizer proposal here. > > > > http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf > > http://amforth.sourceforge.net/pr/Recognizer-rfc-D.html > > > > WF32 (see https://github.com/alextangent/wf32) extends WORDLISTs (and > > their named variety VOCABULARYs) to include three object-like actions. > > They are: > > > > 1. An xt to create an entry (used by : CREATE and so on). > > 2. An xt to traverse over the wordlist (used by TRAVERSE-WORDLIST) > > 3. An xt to search the wordlist for a specific entry (it's this > > wordlist's own specific SEARCH-WORDLIST) > > > > (The idea is to support transparently different wordlist structures; for > > instance, case sensitive vs case insensitive header and searches, and > > traversal over wordlists based on hashes, lists, DLLs, SQL tables etc.) > > > > 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). > > > > FIND-NAME returns the NT ( c-addr u –- nt | 0 ) but searches the current > > search order, not a single wordlist. As it stands, REC:NAME follows that > > pattern and can in fact be implemented as > > > > : rec:name ( addr u -- nt dt:name | dt:null ) > > find-name ?dup if dt:name else dt:null then ; > > > > > > Dammit, early send. > > I think we need an analogous word to FIND-NAME to search a single > wordlist; for two reasons. > > 1. Better support for systems that use NTs. > > 2. (on from 1) Support a more finely grained REC:NAME as right now only > SEARCH-WORDLIST (which returns the wrong thing) can search an individual > wordlist. (Yes, there's TRAVERSE-WORDLIST, but it may not be possible to > efficiently implement it for individual word searches). > > 3. Make wordlists a more general purpose data structure with > well-described facilities for managing them. (I leave aside how entries > might be generated and what word might be suitable; that's for another > discussion.) > > FIND-NAME is already taken, by de facto usage. How about > FIND-IN-WORDLIST ( c-addr u wid -- 0 | nt ) ? > > -- > Alex I have (SEARCH-WORDLIST) ( addr len wid -- nt |0) Your FIND-NAME I have as FINDHEADER ( c-addr n -- c-addr n 0| nt ) BR Peter
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-29 22:47 +0100 |
| Message-ID | <ogi4m5$cns$1@dont-email.me> |
| In reply to | #60028 |
On 5/29/2017 21:18, peter.m.falth@gmail.com wrote: > On Monday, 29 May 2017 21:57:15 UTC+2, Alex wrote: >> On 5/29/2017 20:47, Alex wrote: >>> >>> A wordlist can be considered to be a form of extensible recognizer, and >>> there may be some mileage in exploring the similarities and differences >>> between FIND, FIND-NAME, SEARCH-WORDLIST and REC:NAME (the >>> pseudo-standarised name for the non-numeric recognizer). >>> >>> The discussion is based on the recognizer proposal here. >>> >>> http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf >>> http://amforth.sourceforge.net/pr/Recognizer-rfc-D.html >>> >>> WF32 (see https://github.com/alextangent/wf32) extends WORDLISTs (and >>> their named variety VOCABULARYs) to include three object-like actions. >>> They are: >>> >>> 1. An xt to create an entry (used by : CREATE and so on). >>> 2. An xt to traverse over the wordlist (used by TRAVERSE-WORDLIST) >>> 3. An xt to search the wordlist for a specific entry (it's this >>> wordlist's own specific SEARCH-WORDLIST) >>> >>> (The idea is to support transparently different wordlist structures; for >>> instance, case sensitive vs case insensitive header and searches, and >>> traversal over wordlists based on hashes, lists, DLLs, SQL tables etc.) >>> >>> 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). >>> >>> FIND-NAME returns the NT ( c-addr u –- nt | 0 ) but searches the current >>> search order, not a single wordlist. As it stands, REC:NAME follows that >>> pattern and can in fact be implemented as >>> >>> : rec:name ( addr u -- nt dt:name | dt:null ) >>> find-name ?dup if dt:name else dt:null then ; >>> >>> >> >> Dammit, early send. >> >> I think we need an analogous word to FIND-NAME to search a single >> wordlist; for two reasons. >> >> 1. Better support for systems that use NTs. >> >> 2. (on from 1) Support a more finely grained REC:NAME as right now only >> SEARCH-WORDLIST (which returns the wrong thing) can search an individual >> wordlist. (Yes, there's TRAVERSE-WORDLIST, but it may not be possible to >> efficiently implement it for individual word searches). >> >> 3. Make wordlists a more general purpose data structure with >> well-described facilities for managing them. (I leave aside how entries >> might be generated and what word might be suitable; that's for another >> discussion.) >> >> FIND-NAME is already taken, by de facto usage. How about >> FIND-IN-WORDLIST ( c-addr u wid -- 0 | nt ) ? >> >> -- >> Alex > > I have (SEARCH-WORDLIST) ( addr len wid -- nt |0) (search-self) ( addr len vocwid -- 0 | nt ) > > Your FIND-NAME I have as FINDHEADER ( c-addr n -- c-addr n 0| nt ) The signature indicates it doesn't consume its arguments. My FIND-NAME is taken from Gforth's FIND-NAME ( c-addr n -- nt | 0). That's a good data point, thanks. I'm more interested in the (SEARCH-WORDLIST) type words that take a wordlist. They're more fundamental & factored; FIND-NAME analogs are simply an iteration using whatever the factor (SEARCH-WORDLIST) is called, over the search order. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-30 07:43 +0000 |
| Message-ID | <2017May30.094319@mips.complang.tuwien.ac.at> |
| In reply to | #60028 |
peter.m.falth@gmail.com writes:
>I have (SEARCH-WORDLIST) ( addr len wid -- nt |0)
That was the old name in Gforth, but for public consumption, we
decided to rename it into FIND-NAME-IN.
- 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-05-30 07:30 +0000 |
| Message-ID | <2017May30.093029@mips.complang.tuwien.ac.at> |
| In reply to | #60026 |
Alex <alex@rivadpm.com> writes:
>On 5/29/2017 20:47, Alex wrote:
>> WF32 (see https://github.com/alextangent/wf32) extends WORDLISTs (and
>> their named variety VOCABULARYs) to include three object-like actions.
>> They are:
>>
>> 1. An xt to create an entry (used by : CREATE and so on).
>> 2. An xt to traverse over the wordlist (used by TRAVERSE-WORDLIST)
>> 3. An xt to search the wordlist for a specific entry (it's this
>> wordlist's own specific SEARCH-WORDLIST)
Gforth has FIND-METHOD (3), REVEAL-METHOD (maybe 1), REHASH-METHOD,
and HASH-METHOD (and I wonder if HASH-METHOD and REHASH-METHOD are
ever different). For TRAVERSE-WORDLIST we use the linked list (i.e.,
every wordlist is a linked list for TRAVERSE-WORDLIST, and (if hashed)
for building a hash table from it.
>I think we need an analogous word to FIND-NAME to search a single
>wordlist
Gforth has
find-name-in ( c-addr u wid -- nt | 0 )
- 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 | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-30 09:53 +0200 |
| Message-ID | <ogj8db$bk0$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #60026 |
In article <oghu89$mng$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >On 5/29/2017 20:47, Alex wrote: >> >> A wordlist can be considered to be a form of extensible recognizer, and >> there may be some mileage in exploring the similarities and differences >> between FIND, FIND-NAME, SEARCH-WORDLIST and REC:NAME (the >> pseudo-standarised name for the non-numeric recognizer). >> >> The discussion is based on the recognizer proposal here. >> >> http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf >> http://amforth.sourceforge.net/pr/Recognizer-rfc-D.html >> >> WF32 (see https://github.com/alextangent/wf32) extends WORDLISTs (and >> their named variety VOCABULARYs) to include three object-like actions. >> They are: >> >> 1. An xt to create an entry (used by : CREATE and so on). >> 2. An xt to traverse over the wordlist (used by TRAVERSE-WORDLIST) >> 3. An xt to search the wordlist for a specific entry (it's this >> wordlist's own specific SEARCH-WORDLIST) >> >> (The idea is to support transparently different wordlist structures; for >> instance, case sensitive vs case insensitive header and searches, and >> traversal over wordlists based on hashes, lists, DLLs, SQL tables etc.) >> >> 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). >> >> FIND-NAME returns the NT ( c-addr u –- nt | 0 ) but searches the current >> search order, not a single wordlist. As it stands, REC:NAME follows that >> pattern and can in fact be implemented as >> >> : rec:name ( addr u -- nt dt:name | dt:null ) >> find-name ?dup if dt:name else dt:null then ; >> >> > >Dammit, early send. > >I think we need an analogous word to FIND-NAME to search a single >wordlist; for two reasons. > >1. Better support for systems that use NTs. > >2. (on from 1) Support a more finely grained REC:NAME as right now only >SEARCH-WORDLIST (which returns the wrong thing) can search an individual >wordlist. (Yes, there's TRAVERSE-WORDLIST, but it may not be possible to >efficiently implement it for individual word searches). > >3. Make wordlists a more general purpose data structure with >well-described facilities for managing them. (I leave aside how entries >might be generated and what word might be suitable; that's for another >discussion.) > >FIND-NAME is already taken, by de facto usage. How about >FIND-IN-WORDLIST ( c-addr u wid -- 0 | nt ) ? I've (FIND) ( c-addr u wid -- c-addr u 0 | c-addr u nt ) The reason to keep the string constant : you need the string for every iteration step within wid. you need the string for every wid. (One could drop it once the nt is found, but I hate the stack unbalance.) The basic word that searches a string constant in the whole search order and returns a dictionary entry address ( "name token") I called FOUND So NAME and FOUND instead of BL WORD and FIND are present in INTERPRET. > >-- >Alex Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-30 22:02 +0100 |
| Message-ID | <ogkmdp$prq$1@dont-email.me> |
| In reply to | #60026 |
On 5/29/2017 20:57, Alex wrote: > > I think we need an analogous word to FIND-NAME to search a single > wordlist; for two reasons. > > 1. Better support for systems that use NTs. > > 2. (on from 1) Support a more finely grained REC:NAME as right now only > SEARCH-WORDLIST (which returns the wrong thing) can search an individual > wordlist. (Yes, there's TRAVERSE-WORDLIST, but it may not be possible to > efficiently implement it for individual word searches). > > 3. Make wordlists a more general purpose data structure with > well-described facilities for managing them. (I leave aside how entries > might be generated and what word might be suitable; that's for another > discussion.) > > FIND-NAME is already taken, by de facto usage. How about > FIND-IN-WORDLIST ( c-addr u wid -- 0 | nt ) ? > Would there be any interest in an RfD to standardize this word? We have several names with the same signature ( c-addr n wid -- nt|0 ). wf32 Me (search-self) amforth Matthias Trute SEARCH-NAME ?? Peter Falth (SEARCH-WORDLIST) gforth Anton Ertl find-name-in Albert vd Horst has (FIND) but with the signature ( c-addr u wid -- c-addr u 0 | c-addr u nt ). I'm not aware of what VFX provides. I'd propose the commonly used signature ( c-addr n wid -- nt|0 ); it also adheres to the principle that words consume their arguments. The name I favour is amforth's SEARCH-NAME. I'd also propose we standardize FIND-NAME ( c-addr n -- nt|0 ) while we're at it. I can't find an RfD at forth200x.org; was one ever drafted? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | peter.m.falth@gmail.com |
|---|---|
| Date | 2017-05-31 01:27 -0700 |
| Message-ID | <6cf0dde3-52b5-4e7d-82e2-c1e006b9f1d7@googlegroups.com> |
| In reply to | #60080 |
On Tuesday, 30 May 2017 23:02:03 UTC+2, Alex wrote: > On 5/29/2017 20:57, Alex wrote: > > > > > I think we need an analogous word to FIND-NAME to search a single > > wordlist; for two reasons. > > > > 1. Better support for systems that use NTs. > > > > 2. (on from 1) Support a more finely grained REC:NAME as right now only > > SEARCH-WORDLIST (which returns the wrong thing) can search an individual > > wordlist. (Yes, there's TRAVERSE-WORDLIST, but it may not be possible to > > efficiently implement it for individual word searches). > > > > 3. Make wordlists a more general purpose data structure with > > well-described facilities for managing them. (I leave aside how entries > > might be generated and what word might be suitable; that's for another > > discussion.) > > > > FIND-NAME is already taken, by de facto usage. How about > > FIND-IN-WORDLIST ( c-addr u wid -- 0 | nt ) ? > > > > Would there be any interest in an RfD to standardize this word? We have > several names with the same signature ( c-addr n wid -- nt|0 ). > > wf32 Me (search-self) > amforth Matthias Trute SEARCH-NAME > ?? Peter Falth (SEARCH-WORDLIST) > gforth Anton Ertl find-name-in > > Albert vd Horst has (FIND) but with the signature ( c-addr u wid -- > c-addr u 0 | c-addr u nt ). > > I'm not aware of what VFX provides. > > I'd propose the commonly used signature ( c-addr n wid -- nt|0 ); it > also adheres to the principle that words consume their arguments. The > name I favour is amforth's SEARCH-NAME. > > I'd also propose we standardize FIND-NAME ( c-addr n -- nt|0 ) while > we're at it. I can't find an RfD at forth200x.org; was one ever drafted? > > -- > Alex I am fine with this. No problem to change names of (still) internal functions. I think this is a correct consequence of having traverse-wordlist that introduced the NT. My systems are called ntf/lxf (32 bit windows/linux) and ntf64/lxf64 for the 64 bit. Peter
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-31 15:12 +0100 |
| Message-ID | <ogmiqi$b5h$1@dont-email.me> |
| In reply to | #60093 |
On 5/31/2017 09:27, peter.m.falth@gmail.com wrote: > > I am fine with this. No problem to change names of (still) internal functions. > I think this is a correct consequence of having traverse-wordlist > that introduced the NT. > > My systems are called ntf/lxf (32 bit windows/linux) and ntf64/lxf64 > for the 64 bit. > Thanks. I'll add this to my notes. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-31 03:43 -0700 |
| Message-ID | <afd6bbc4-1cee-4cb8-9d5e-630302d42de5@googlegroups.com> |
| In reply to | #60080 |
Am Dienstag, 30. Mai 2017 23:02:03 UTC+2 schrieb Alex: > > FIND-NAME is already taken, by de facto usage. How about > > FIND-IN-WORDLIST ( c-addr u wid -- 0 | nt ) ? > > > > Would there be any interest in an RfD to standardize this word? We have > several names with the same signature ( c-addr n wid -- nt|0 ). > Nay from here. By principle considerations I am against standardizing internal system implementation words. Leave this to the implementers. There are just too many ways to implement a task for a particular environment. Just as an example: MinForth has _FIND ( a u wid -- 0 | xt xf ). xf is an extended flag meaning: -1 = normal word 0 = not found 1 = immediate 2 = compile-only other = compilation token ct for dual-xt words. It works, simple and flawless. To get nt's, you use >NAME ( xt|ct -- nt )
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-31 15:03 +0100 |
| Message-ID | <ogmi9p$9v8$1@dont-email.me> |
| In reply to | #60099 |
On 5/31/2017 11:43, minforth@arcor.de wrote: > Am Dienstag, 30. Mai 2017 23:02:03 UTC+2 schrieb Alex: >>> FIND-NAME is already taken, by de facto usage. How about >>> FIND-IN-WORDLIST ( c-addr u wid -- 0 | nt ) ? >>> >> >> Would there be any interest in an RfD to standardize this word? We >> have several names with the same signature ( c-addr n wid -- nt|0 >> ). >> > > Nay from here. > > By principle considerations I am against standardizing internal > system implementation words. Leave this to the implementers. There > are just too many ways to implement a task for a particular > environment. The proposal would add it to 16 The optional Search-Order word set. There, we have WORDLIST, FIND (returns XT) SEARCH-WORDLIST (returns XT) from ANS Forth; and TRAVERSE-WORDLIST (returns NT) as a recent addition. Wordlists would not be useful without SEARCH-WORDLIST. For Forths that use name tokens, wordlists need an equivalent search to return NTs, and wordlsists without such a word would be equally useless. So each of the Forths above has implemented a word with much the same signature that returns an NT, but each with a different name. I can't speak for every Forth, but it's probably to support FIND-NAME, something that has become a defacto standard. I see that you didn't explicitly object to FIND-NAME. Do you consider that an internal system implementation word or not? > > Just as an example: MinForth has _FIND ( a u wid -- 0 | xt xf ). xf > is an extended flag meaning: -1 = normal word 0 = not found 1 = > immediate 2 = compile-only other = compilation token ct for dual-xt > words. It works, simple and flawless. To get nt's, you use >NAME ( > xt|ct -- nt ) > There's no standard way for getting from XT to NT, only NT to XTs with NAME>COMPILE and NAME>INTERPRET. >NAME is not standardized. Gforth provides it, but doesn't make any guarantees of correctness. My Forth may give you back an alias or synonym rather than the original word, since although they are different NTs, they and the aliased/synonymed word have the same XT. Immediacy is a characteristic of the NT, not the XT, so this may produce errors while compiling. The requirement for a standardized wordlist search returning an NT is not pressing until you see what recognizers can do in simplifying to a significant degree the entire interpret/compile/postpone and words vs numbers parsing mess that we currently have. Plus, NTs are far more useful because they carry a larger amount of useful semantic information than a raw XT. I reckon SEARCH-WORDLIST will go the way of FIND; everyone providing it, but nobody using it. I can't find a single use in any of my code of either of them. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-31 16:46 +0000 |
| Message-ID | <2017May31.184644@mips.complang.tuwien.ac.at> |
| In reply to | #60099 |
minforth@arcor.de writes:
>Am Dienstag, 30. Mai 2017 23:02:03 UTC+2 schrieb Alex:
>> > FIND-NAME is already taken, by de facto usage. How about
>> > FIND-IN-WORDLIST ( c-addr u wid -- 0 | nt ) ?
>> >
>>
>> Would there be any interest in an RfD to standardize this word? We have
>> several names with the same signature ( c-addr n wid -- nt|0 ).
>>
>
>Nay from here.
>
>By principle considerations I am against standardizing internal system implementation words.
At least 4 systems have this word, so it is obviously not an internal
system implementation word.
>Just as an example:
>MinForth has _FIND ( a u wid -- 0 | xt xf ). xf is an extended flag meaning:
>-1 = normal word
>0 = not found
>1 = immediate
>2 = compile-only
>other = compilation token ct for dual-xt words.
>It works, simple and flawless. To get nt's, you use >NAME ( xt|ct -- nt )
I.e., in MinForth you can implement SEARCH-NAME (or whatever name we
reach agreement on). Good.
- 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-05-31 11:28 +0000 |
| Message-ID | <2017May31.132810@mips.complang.tuwien.ac.at> |
| In reply to | #60080 |
Alex <alex@rivadpm.com> writes:
>Would there be any interest in an RfD to standardize this word?
Yes.
>We have
>several names with the same signature ( c-addr n wid -- nt|0 ).
>
>wf32 Me (search-self)
>amforth Matthias Trute SEARCH-NAME
>?? Peter Falth (SEARCH-WORDLIST)
>gforth Anton Ertl find-name-in
I can also live with a name other than FIND-NAME-IN.
>I'd also propose we standardize FIND-NAME ( c-addr n -- nt|0 ) while
>we're at it. I can't find an RfD at forth200x.org; was one ever drafted?
No. I considered it, but never actually pursued it.
- 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-05-31 12:17 +0000 |
| Message-ID | <2017May31.141725@mips.complang.tuwien.ac.at> |
| In reply to | #60101 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Alex <alex@rivadpm.com> writes:
>>We have
>>several names with the same signature ( c-addr n wid -- nt|0 ).
>>
>>wf32 Me (search-self)
>>amforth Matthias Trute SEARCH-NAME
>>?? Peter Falth (SEARCH-WORDLIST)
>>gforth Anton Ertl find-name-in
>
>I can also live with a name other than FIND-NAME-IN.
SEARCH-NAME would have been an obvious name, but was not chosen for
Gforth, and there was a reason for that: Gforth already contains a
SEARCH-NAME. It's not a documented word, so we can rename it to
something else, and then provide SEARCH-NAME with the meaning above.
But there is one snag: The Forth-2012 way to determine the presence of
a word is [DEFINED]. If you do [DEFINED] SEARCH-NAME on Gforth 0.7,
you will get -1, even though the found SEARCH-NAME is not the one you
want to standardize. Will people actually test [DEFINED] SEARCH-NAME?
It's not that easy to replace SEARCH-NAME with replacement code, so
maybe not; in that case the snag will be of little consequence.
Interestingly, in an earlier discussion on this topic (from 2005), I
suggested SEARCH-NAME for the functionality above
<2005Aug19.160648@mips.complang.tuwien.ac.at>, and also noted that the
existing SEARCH-NAME in Gforth is doing something else
<2005Aug20.195632@mips.complang.tuwien.ac.at>.
- 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-05-31 15:10 +0100 |
| Message-ID | <ogmilq$bap$1@dont-email.me> |
| In reply to | #60101 |
On 5/31/2017 12:28, Anton Ertl wrote: > Alex <alex@rivadpm.com> writes: >> Would there be any interest in an RfD to standardize this word? > > Yes. > >> We have >> several names with the same signature ( c-addr n wid -- nt|0 ). >> >> wf32 Me (search-self) >> amforth Matthias Trute SEARCH-NAME >> ?? Peter Falth (SEARCH-WORDLIST) >> gforth Anton Ertl find-name-in > > I can also live with a name other than FIND-NAME-IN. > >> I'd also propose we standardize FIND-NAME ( c-addr n -- nt|0 ) while >> we're at it. I can't find an RfD at forth200x.org; was one ever drafted? > > No. I considered it, but never actually pursued it. > > - anton > Thanks. I'll wait a bit yet for any further early suggestions and objections. I'd be interested in Stepehn Pelc's & Marcel Hendrix's input. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-05-31 11:01 -0700 |
| Message-ID | <e12411c2-4edb-4a10-a0fb-2ed657e16807@googlegroups.com> |
| In reply to | #60106 |
On Wednesday, May 31, 2017 at 4:10:20 PM UTC+2, Alex wrote:
> On 5/31/2017 12:28, Anton Ertl wrote:
> > Alex <alex@rivadpm.com> writes:
> >> Would there be any interest in an RfD to standardize this word?
> >
> > Yes.
> >
> >> We have
> >> several names with the same signature ( c-addr n wid -- nt|0 ).
> >>
> >> wf32 Me (search-self)
> >> amforth Matthias Trute SEARCH-NAME
> >> ?? Peter Falth (SEARCH-WORDLIST)
> >> gforth Anton Ertl find-name-in
> >
> > I can also live with a name other than FIND-NAME-IN.
> >
> >> I'd also propose we standardize FIND-NAME ( c-addr n -- nt|0 ) while
> >> we're at it. I can't find an RfD at forth200x.org; was one ever drafted?
> >
> > No. I considered it, but never actually pursued it.
> >
> > - anton
> >
>
> Thanks. I'll wait a bit yet for any further early suggestions and
> objections. I'd be interested in Stepehn Pelc's & Marcel Hendrix's input.
>
> --
> Alex
iForth calls your "nt" a "dea" (dictionary entry address).
Almost everything can be queried with a dea, but searching
is not limited to a single wordlist (you would need to save
the current order, set-order the wid, <..code..> reset the
order).
I'm not at all sure what's your intention with this, but
here is a list. Note that it is not always possible to
go from an xt to a dea ( >HEAD ).
HEAD' IFORTH
( "name" -- dea )
Parse name delimited by a space, ignoring leading delimiters. If name
can be found using the current search order, leave its dictionary entry
address, else generate an error condition.
See also: '
HEAD> "head-from" IFORTH
( dea -- addr )
addr is the address where the execution token of the dictionary entry
corresponding to dea can be found.
HEAD>FLAGS IFORTH
( dea -- ffa )
ffa is the flag field address of the dictionary entry identified by dea.
It is considered as an array of flags denoting properties of the
dictionary entry. It can be manipulated using bit-masks.
For example: the phrase flags =ANSI AND =ANSI = leaves true if flags
are the flags from an ANS standard word.
See also: =ANSI =COMP =IMMEDIATE =MACRO =PRIVATE =VISIBLE
HEAD>FORGET "head-to-forget" IFORTH
( dea -- ffa )
ffa is the forget field address of the dictionary entry identified by
dea.
HEAD>HASH IFORTH
( dea -- hfa )
hfa is the hash field address of dictionary entry identified by dea.
HEAD>LINK IFORTH
( dea -- lfa )
lfa is the link field address of the dictionary entry identified by dea.
It contains the dea of the next entry in the dictionary.
HEAD>LOCATE "head-to-locate" IFORTH
( dea -- locfa )
locfa is the locate field address of the dictionary entry identified
by dea. It contains the "locate datum" of the next entry in the
dictionary. The locate datum is a special number composed of a file
identifier and the one-based line number in this file. For kernel
definitions the locate datum is 0 as no source files are provided.
The locate datum is processed by the xt in ADD-LOCATE
( dea -- locate_datum ), which computes the locate datum given the
dea currently being constructed. The default xt in ADD-LOCATE passes
the dea unmodified. This means that when the ./include/locate.frt
utility is not active, HEAD' name ( -- dea ) HEAD>LOCATE @ returns
either name's dea or zero.
See also: ADD-LOCATE
HEAD>NAME "head-to-name" IFORTH
( dea -- nfa )
nfa is the name field address of the dictionary entry identified by dea.
It contains a character string with the name of the dictionary entry.
HEAD>comp "head-to-compile-field" IFORTH
( dea -- cf )
cf is the compile field address of the dictionary entry identified by dea.
The compile field is used in compile state and makes it unnecessary that
such a word is IMMEDIATE . Not every word has this field.
See also: HEAD>exec
HEAD>exec "head-to-execute-field" IFORTH
( dea -- ef )
ef is the execution field address of the dictionary entry identified
by dea. The execution field is used in execution state and makes it
unnecessary that such a word is IMMEDIATE . TOKENIZEd words have this
field.
See also: HEAD>exec
>HEAD "to-head" IFORTH
( xt -- dea | 0 )
dea is the address of the dictionary entry whose execution token is xt .
If the conversion was not possible a 0 is returned.
@LATEST IFORTH
( -- dea )
Get the dictionary entry address of the latest header that was created
in the current wordlist (the one accessed with GET-CURRENT SET-CURRENT ).
LINK>HEAD "link-to-head" IFORTH
( lfa -- dea )
dea is the dictionary entry address of the word for which lfa is the
link field address.
NEAREST-HEAD IFORTH
( addr -- dea u )
Finds the Forth word whose code starts nearest to addr. If addr is
outside the code space the returned dea is the dictionary entry address
of the latest word defined. The offset of addr from the found word's xt
is returned as u. The dea of the latest word defined is used when no
suitable word is found. In that case u is a very large number.
See also: >HEAD
!LATEST "store-latest" IFORTH
( dea -- )
Make the routine identified by the dictionary entry address dea the last
routine defined in the wordlist in which new definitions are stored.
This wordlist is selected with <wid> SET-CURRENT or with DEFINITIONS .
See also: @LATEST
-marcel
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-05-31 22:55 +0000 |
| Message-ID | <592f46a8.632823078@news.eternal-september.org> |
| In reply to | #60106 |
>>> We have >>> several names with the same signature ( c-addr n wid -- nt|0 ). >>> >>> wf32 Me (search-self) >>> amforth Matthias Trute SEARCH-NAME >>> ?? Peter Falth (SEARCH-WORDLIST) >>> gforth Anton Ertl find-name-in >> >> I can also live with a name other than FIND-NAME-IN. >> >>> I'd also propose we standardize FIND-NAME ( c-addr n -- nt|0 ) while >>> we're at it. I can't find an RfD at forth200x.org; was one ever drafted? >Thanks. I'll wait a bit yet for any further early suggestions and >objections. I'd be interested in Stepehn Pelc's & Marcel Hendrix's input. 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. 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. If you have many SYNONYMs, just pick the first or last to be the definitive name - it really doesn't matter. If you have a lot of SYNONYMS something managerial has already gone wrong. 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. Other than for stepping through a wordlist, NTs offer nothing that cannot be provided by XTs. Stephen P.S. You asked for my input. -- 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-01 05:50 +0000 |
| Message-ID | <2017Jun1.075057@mips.complang.tuwien.ac.at> |
| In reply to | #60120 |
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.
>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?
>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.
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?
>Other than
>for stepping through a wordlist, NTs offer nothing that cannot be
>provided by XTs.
An NT provides access to interpretation and compilation semantics, and
to the word name.
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):
|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.
- 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-05-31 23:57 -0700 |
| Message-ID | <7a47ee44-bbc4-446d-a4df-e821fe8e17d7@googlegroups.com> |
| In reply to | #60126 |
Am Donnerstag, 1. Juni 2017 08:22:34 UTC+2 schrieb Anton Ertl: > 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). This is definitely not true. Such introspection is possible here because it is built into the header structure of dual-xt words.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web