Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58372 > unrolled thread
| Started by | Alex <alex@rivadpm.com> |
|---|---|
| First post | 2017-04-30 03:31 +0100 |
| Last post | 2017-05-02 15:10 +0000 |
| Articles | 19 on this page of 159 — 19 participants |
Back to article view | Back to comp.lang.forth
Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 03:31 +0100
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-04-29 20:21 -0700
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-30 03:30 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-30 09:51 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-30 07:50 -0500
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 14:05 +0100
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-30 08:11 -0500
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 14:18 +0100
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-30 14:01 +0000
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 15:36 +0100
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-01 01:48 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-01 11:13 +0100
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-01 04:40 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-01 18:01 +0100
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-01 11:42 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-01 20:47 +0100
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-01 13:56 -0700
Re: Recognizers and DT-TOKEN: Julian Fondren <julian.fondren@gmail.com> - 2017-05-01 14:07 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-01 23:17 +0100
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-01 22:33 +0100
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 03:49 -0500
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-02 12:27 +0200
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 11:42 +0000
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-02 11:41 +0100
Re: Recognizers and DT-TOKEN: john <anon@example.com> - 2017-05-02 12:13 +0100
Re: Recognizers and DT-TOKEN: "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 09:42 -1000
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-02 14:13 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 12:32 -0500
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-02 18:55 +0100
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:05 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:18 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 08:55 -0500
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 11:36 -0700
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-03 06:39 -0700
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-08 10:22 -0700
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-08 11:52 -0700
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-09 02:45 -0700
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-09 03:47 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-09 12:52 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-09 10:38 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 11:08 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 08:33 -0500
Re: Recognizers and DT-TOKEN: Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-09 15:39 +0200
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 09:14 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 16:40 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-10 05:48 -0500
Re: Recognizers and DT-TOKEN: Joel Rees <joel.rees@gmail.com> - 2017-05-12 07:47 -0700
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 11:10 -0700
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 11:47 -0700
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:47 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:31 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:01 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:10 -0500
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:29 -0500
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-03 12:27 -0700
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:35 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 14:00 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:21 -0500
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-04 19:14 +0100
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-05 09:17 -0500
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-05 07:31 -0700
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-05 10:27 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-05 15:25 +0000
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-05 12:21 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:37 +0000
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-06 13:18 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-05 20:32 +0100
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-06 01:06 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:54 -0500
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 13:46 +0200
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 07:59 -0500
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-07 11:31 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-07 20:22 +0100
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-08 04:17 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 15:30 +0000
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-08 12:00 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:50 +0000
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-08 09:51 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 15:40 +0000
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-09 16:32 +0200
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 16:19 +0000
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-09 18:53 +0200
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-09 18:12 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-09 10:41 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-09 19:12 +0100
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-07 22:46 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 03:50 -0500
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 02:42 -0700
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 03:58 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-08 12:35 +0100
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 05:49 -0700
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-08 16:28 +0200
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 07:54 -0700
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-08 17:16 +0200
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 09:23 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 16:31 +0000
Re: Recognizers and DT-TOKEN: mhx@iae.nl - 2017-05-08 11:14 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-08 19:27 +0100
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-09 16:39 +0200
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 14:53 +0000
Re: Recognizers and DT-TOKEN: Joel Rees <joel.rees@gmail.com> - 2017-05-09 20:43 -0700
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 15:02 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-09 12:24 +0100
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:34 +0000
Re: Recognizers and DT-TOKEN: pahihu <pahihu@gmail.com> - 2017-05-08 01:17 -0700
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-08 12:30 +0000
Re: Recognizers and DT-TOKEN: pahihu <pahihu@gmail.com> - 2017-05-08 07:49 -0700
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 10:58 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 11:44 +0000
Re: Recognizers and DT-TOKEN: pahihu <pahihu@gmail.com> - 2017-05-08 08:04 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 17:30 +0000
Re: Recognizers and DT-TOKEN: pahihu <pahihu@gmail.com> - 2017-05-10 04:07 -0700
Re: Recognizers and DT-TOKEN: Ron Aaron <rambamist@gmail.com> - 2017-05-10 14:11 +0300
Re: Recognizers and DT-TOKEN: Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-10 13:59 +0200
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 14:04 +0100
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 14:06 +0100
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 13:02 +0100
Re: Recognizers and DT-TOKEN: pahihu <pahihu@gmail.com> - 2017-05-10 06:07 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 14:30 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-10 11:59 -0700
Re: Recognizers and DT-TOKEN: Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-10 15:10 +0200
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 14:33 +0100
Re: Recognizers and DT-TOKEN: Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-10 16:08 +0200
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 16:02 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-10 09:10 -0700
Re: Recognizers and DT-TOKEN: Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-10 18:38 +0200
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:03 -0500
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-08 13:32 +0000
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-08 16:11 +0200
Re: Recognizers and DT-TOKEN: stephen@mpeforth.com (Stephen Pelc) - 2017-05-04 20:29 +0000
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 14:55 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 02:47 -0500
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-02 15:02 +0000
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 12:11 +0100
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-04-30 06:34 -0700
Re: Recognizers and DT-TOKEN: Julian Fondren <julian.fondren@gmail.com> - 2017-04-30 06:59 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 15:04 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-04-30 09:38 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-30 09:36 +0000
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 11:46 +0100
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-30 14:12 +0000
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 16:39 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-04-30 09:25 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-30 16:23 +0000
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-04-30 09:06 -0700
Re: Recognizers and DT-TOKEN: Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-04-30 18:00 +0100
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-01 01:30 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-02 13:06 +0000
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-02 06:24 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:13 +0000
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-03 04:20 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:17 +0000
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-02 12:46 +0000
Re: Recognizers and DT-TOKEN: Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-03 07:58 +0100
Re: Recognizers and DT-TOKEN: mhx@iae.nl - 2017-05-03 10:52 -0700
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-04-30 08:51 -0700
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-04-30 22:54 +0000
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-01 01:01 -0700
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-02 15:10 +0000
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-30 14:12 +0000 |
| Message-ID | <2017Apr30.161214@mips.complang.tuwien.ac.at> |
| In reply to | #58391 |
Alex <alex@rivadpm.com> writes:
>On 4/30/2017 10:36, Anton Ertl wrote:
>> You can make I-OBJECT, C-OBJECT, and P-OBJECT deferred words, and
>> change what they do. Or you can make DT:OBJECT a deferred word, and
>> change them all at once. Or you can make a new REC:OBJECTS-ALT
>> recognizer (which presumable would reuse some code used by
>> REC:OBJECTS) and put that on the recognizer stack before or instead of
>> REC:OBJECTS.
>
>
>1. Find your compiler's REC:OBJECT on the recognizer stack and replace
>it. Complex; some recognizers may be using nested recognizer stacks, or
>dynamically switching recognizers in and out of use.
Putting REC:OBJECTS-ALT before REC:OBJECT is sufficient and avoids this need.
>2. Make DT:OBJECT a deferred word requires that it is a deferred word in
>the supplied system. (Are all the tokens deferred? Only some? Would we
>have to standardize this?)
Likewise, with DT-TOKENS producing a handle DT:OBJECT have to be a
value rather than a constant. Are all these words values? Only some?
Would we have to standardize this?
I expect that people normally won't use deferred words with the
presently proposed scheme and (if we switch to DT-TOKENS) normally
will use constants. And I don't expect problems from it, even in
situations involving libraries that you don't want to touch.
The application programmer has enough control over the recognizer
order to allow to use either of these solutions, or some other
variations. If a library adds something to the recognizer stack
itself, a proper library documents that, and the application
programmer can do the corrections he wants right after loading the
library (or maybe something also before). If the library just
provides the recognizer, and leaves it to the application program to
add it to the recognizer order, the application program has even more
control over the situation.
In the example case of a debugging variation of an OO recognizer I
expect even less problems: If it's a one-off, the application
programmer can just deal with the situation at hand; if it's a
generally useful variation which is in use for a longer time, I expect
that the OO package will incorporate it itself or at least avoid
breaking it in later releases.
- 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-04-30 16:39 +0100 |
| Message-ID | <oe509i$p8d$1@dont-email.me> |
| In reply to | #58405 |
On 4/30/2017 15:12, Anton Ertl wrote: > Alex <alex@rivadpm.com> writes: >> On 4/30/2017 10:36, Anton Ertl wrote: >>> You can make I-OBJECT, C-OBJECT, and P-OBJECT deferred words, and >>> change what they do. Or you can make DT:OBJECT a deferred word, and >>> change them all at once. Or you can make a new REC:OBJECTS-ALT >>> recognizer (which presumable would reuse some code used by >>> REC:OBJECTS) and put that on the recognizer stack before or instead of >>> REC:OBJECTS. >> >> >> 1. Find your compiler's REC:OBJECT on the recognizer stack and replace >> it. Complex; some recognizers may be using nested recognizer stacks, or >> dynamically switching recognizers in and out of use. > > Putting REC:OBJECTS-ALT before REC:OBJECT is sufficient and avoids this need. How do we determine "before"? That implies we can find it. > >> 2. Make DT:OBJECT a deferred word requires that it is a deferred word in >> the supplied system. (Are all the tokens deferred? Only some? Would we >> have to standardize this?) > > Likewise, with DT-TOKENS producing a handle DT:OBJECT have to be a > value rather than a constant. Are all these words values? Only some? > Would we have to standardize this? This is meant as a question, and is not a rhetorical device. > > I expect that people normally won't use deferred words with the > presently proposed scheme and (if we switch to DT-TOKENS) normally > will use constants. And I don't expect problems from it, even in > situations involving libraries that you don't want to touch. Mattias hinted at a larger problem in the proposal (see A.XY.4 Naming Conventions), and this type discussion is a subset of a bigger problem to do with the names, which are not standardized but (almost) recommended if portability is to be supported. It applies to both tokens and recognizers. The only mandated name is the rather unsatisfactory DT:NULL. At least, I read it that way, as they are mentioned in a non-normative section appendix. I would prefer normative text (but not the names selected) and a specification of type (core and user modifiable like VALUE). > > The application programmer has enough control over the recognizer > order to allow to use either of these solutions, or some other > variations. If a library adds something to the recognizer stack > itself, a proper library documents that, and the application > programmer can do the corrections he wants right after loading the > library (or maybe something also before). If the library just > provides the recognizer, and leaves it to the application program to > add it to the recognizer order, the application program has even more > control over the situation. > > In the example case of a debugging variation of an OO recognizer I > expect even less problems: If it's a one-off, the application > programmer can just deal with the situation at hand; if it's a > generally useful variation which is in use for a longer time, I expect > that the OO package will incorporate it itself or at least avoid > breaking it in later releases. The use case I am experiencing issues with is meta compilation (and to a lesser degree, optimization & the automatic insertion of debugging code); the object case was for convenience of understanding. But, yes, the same requirements apply there too. In the meta compilation case, not finding words is not an error, definitions are recorded in several wordlists, their compilation is not the usual COMPILE, but rather an EXECUTE etc. All the DT-TOKEN: actions need replaced; the unsatisfactory alternative is to copy all the recognizers and tokens and maintain meta compiler versions. As I told Mattias, I find the proposal incredibly useful; they are minor nits I've encountered, and I'm going to continue to experiment with it. I feel it could be simplified further. For instance, by specifying token layout and ditching DT>xxx words; and perhaps by not mandating a stack for recognizers. Thanks for the commentary. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-04-30 09:25 -0700 |
| Message-ID | <c70b47b9-2a58-486b-b53f-95288b8cc0b2@googlegroups.com> |
| In reply to | #58408 |
> Mattias hinted at a larger problem in the proposal (see A.XY.4 Naming > Conventions), and this type discussion is a subset of a bigger problem > to do with the names, which are not standardized but (almost) > recommended if portability is to be supported. It applies to both tokens > and recognizers. The only mandated name is the rather unsatisfactory > DT:NULL. Yeah, but R:FAIL is worse. In fact: R:FAIL came to it's name because of the action it triggered (the failure action like -13 throw). But: The parser that returns this token does not cause this error, but wants to return a flag "not-my-world". Someone suggested to use the literal 0 as this flag, what I consider redundant. But I renamed the R:FAIL to DT:NULL to say "no information available". That very same reason lead to the DT names too. There is a data type "execution token" that contains the XT and the immediate flag (see FIND). You get the picture I hope. The R:* Names saw the world from the interpreter point of view, the DT names see them from the parser actions. The tokens with their respective actions simply simplify the standard use case: identify the data and do some actions in the interpreter. An intermediate ID that later maps to the action set used by the interpreter is : The parser (REC:*) returns the data and a DT:* ID (a number). The interpreter or whoever else take this DT:* ID and do some magic to perform it's action on the data. The DT Tokens from the RFD combine this into one token. If someone want another action set replace the token and keep the data. > As I told Mattias, I find the proposal incredibly useful; they are minor > nits I've encountered, and I'm going to continue to experiment with it. Thank you, and I highly appreciate your comments. > I feel it could be simplified further. For instance, by specifying token > layout and ditching DT>xxx words; never underestimate the ability of Forther's to make things worse, if you understand the current gforth implementation you're a Guru ;) (Bernd, Anton: No offense intended) > and perhaps by not mandating a stack > for recognizers. Forth is *the* stack language. What else do you want to use? Lists? Go To LISP ;) Matthias
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-30 16:23 +0000 |
| Message-ID | <2017Apr30.182326@mips.complang.tuwien.ac.at> |
| In reply to | #58408 |
Alex <alex@rivadpm.com> writes:
>On 4/30/2017 15:12, Anton Ertl wrote:
>> Alex <alex@rivadpm.com> writes:
>>> On 4/30/2017 10:36, Anton Ertl wrote:
>>>> You can make I-OBJECT, C-OBJECT, and P-OBJECT deferred words, and
>>>> change what they do. Or you can make DT:OBJECT a deferred word, and
>>>> change them all at once. Or you can make a new REC:OBJECTS-ALT
>>>> recognizer (which presumable would reuse some code used by
>>>> REC:OBJECTS) and put that on the recognizer stack before or instead of
>>>> REC:OBJECTS.
>>>
>>>
>>> 1. Find your compiler's REC:OBJECT on the recognizer stack and replace
>>> it. Complex; some recognizers may be using nested recognizer stacks, or
>>> dynamically switching recognizers in and out of use.
>>
>> Putting REC:OBJECTS-ALT before REC:OBJECT is sufficient and avoids this need.
>
>How do we determine "before"? That implies we can find it.
No. If you want to have REC:NAME recognizer first, REC:OBJECT-ALT
second, and then the rest, you can do
get-recognizers ' rec:objects-alt ' rec:word rot 2 + set-recognizers
>>> 2. Make DT:OBJECT a deferred word requires that it is a deferred word in
>>> the supplied system. (Are all the tokens deferred? Only some? Would we
>>> have to standardize this?)
>>
>> Likewise, with DT-TOKENS producing a handle DT:OBJECT have to be a
>> value rather than a constant. Are all these words values? Only some?
>> Would we have to standardize this?
>
>This is meant as a question, and is not a rhetorical device.
My point is that DT-TOKENS does not solve the problem you pose.
Library programmers are likely to use CONSTANT with DT-TOKENS (in
accordance with the no-hooks dogma of Forth), and you still have to
resort to the solutions I outlined, instead of just doing a TO DT:OBJECT.
>Mattias hinted at a larger problem in the proposal (see A.XY.4 Naming
>Conventions), and this type discussion is a subset of a bigger problem
>to do with the names, which are not standardized but (almost)
>recommended if portability is to be supported.
Yes, I needed REC:NAME above, so maybe we should standardize the names
of the recognizers that exist in the current standard: words, singles,
doubles (or maybe a combined single/double recognizer), floats.
>In the meta compilation case, not finding words is not an error,
>definitions are recorded in several wordlists, their compilation is not
>the usual COMPILE, but rather an EXECUTE etc. All the DT-TOKEN: actions
>need replaced; the unsatisfactory alternative is to copy all the
>recognizers and tokens and maintain meta compiler versions.
If they all need to be replaced, then finding the right one in the
recognizer order is even less of an issue: You just create the
recognizer order with the meta compiler versions.
Do you want the meta/cross compiler to be a standard program? If it
just needs to run on your system, you can make the DT words deferred.
If it is intended to run on all systems with recognizers, then reusing
the system's REC: parts with different DT: parts would lead to
different behaviours on different systems; e.g., "2," would be
recognized as double on SwiftForth, but not in Gforth. That may be
what you want, or maybe not. In any case, you would need to
standardize all the DT: words; and in that case you can standardize
them as deferred, which would solve your problem.
- 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 | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-04-30 09:06 -0700 |
| Message-ID | <686efc22-a5fd-4b5c-a59c-783a79e4d550@googlegroups.com> |
| In reply to | #58391 |
> 1. Find your compiler's REC:OBJECT on the recognizer stack and replace > it. Complex; some recognizers may be using nested recognizer stacks, or > dynamically switching recognizers in and out of use. The parsing action is not responsible for what the interpreter does with the data afterwards. It can be complex or simple, the result is always some data and a matching data type information. Traditionally as "simple" as ( XT +/-1 | 0 ) or as systematic as the suggested DT:* tokens. This DT Token can be replaced easily. Matthias
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-04-30 18:00 +0100 |
| Message-ID | <oe550o$9i1$1@dont-email.me> |
| In reply to | #58386 |
On 30/04/2017 10:36, Anton Ertl wrote: > Having a constructor word that puts a handle on the stack instead of > creating a named word is generally good practice, and Forth-94 > followed it with WORDLIST (where the named alternative is VOCABULARY). A pity they didn't provide a way of naming a wordlist such that its name is displayed by ORDER. And yes I know that in Gforth after e.g. wordlist constant wl ORDER displays wl at the head of the search order but other systems don't, just displaying an unhelpful address. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2017-05-01 01:30 -0700 |
| Message-ID | <eb90b04e-cbf8-49b1-a05e-0597bdfb1203@googlegroups.com> |
| In reply to | #58413 |
> On 30/04/2017 10:36, Anton Ertl wrote:
>> Having a constructor word that puts a handle on the stack instead of
>> creating a named word is generally good practice, and Forth-94
>> followed it with WORDLIST (where the named alternative is VOCABULARY).
> A pity they didn't provide a way of naming a wordlist such that its name
> is displayed by ORDER. And yes I know that in Gforth after e.g.
> wordlist constant wl
> ORDER displays wl at the head of the search order but other systems
> don't, just displaying an unhelpful address.
The problem with using CONSTANT to name a handle or other anonymous abject
is that there is no way to get from the constant value back to the name.
I'm wondering is there any common practice to deal with this?
Perhaps something like:
unique-value NAMED value-name
where NAMED acts like CONSTANT, but the value it stores is now a valid
parameter for NAME>STRING or so similar word.
Thus, VOCABULARY defined using wordlist, allowing a high level ORDER to be written:
: VOCABULARY >IN @ WORDLIST DUP named SWAP >IN !
CREATE , DOES> >R GET-ORDER 1+ R> SWAP SET-ORDER ;
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-02 13:06 +0000 |
| Message-ID | <2017May2.150643@mips.complang.tuwien.ac.at> |
| In reply to | #58434 |
JennyB <jennybrien@googlemail.com> writes:
>> On 30/04/2017 10:36, Anton Ertl wrote:
>>> Having a constructor word that puts a handle on the stack instead of
>>> creating a named word is generally good practice, and Forth-94
>>> followed it with WORDLIST (where the named alternative is VOCABULARY).
>
>> A pity they didn't provide a way of naming a wordlist such that its name
>> is displayed by ORDER. And yes I know that in Gforth after e.g.
>
>> wordlist constant wl
>
>> ORDER displays wl at the head of the search order but other systems
>> don't, just displaying an unhelpful address.
>
>The problem with using CONSTANT to name a handle or other anonymous abject
>is that there is no way to get from the constant value back to the name.
In Gforth, in the case of ORDER, we know that we want to pront a
wordlist name, so we look right behind the memory for the wordlist for
a constant that points to that wordlist.
For general constants, you could search through all words, looking for
constants that have that value.
If that's too slow for your needs (and you have memory to burn): Every
CONSTANT inserts a <value,nt> pair into a lookup table (implemented,
e.g., as hash table), where the value is the key, and you use that to
translate from the value to the constant name if available.
- 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-02 06:24 -0700 |
| Message-ID | <335968a5-ae0d-40c0-9458-d72d43ec3240@googlegroups.com> |
| In reply to | #58492 |
Am Dienstag, 2. Mai 2017 15:14:54 UTC+2 schrieb Anton Ertl: > JennyB <jennybrien@googlemail.com> writes: > >> On 30/04/2017 10:36, Anton Ertl wrote: > >>> Having a constructor word that puts a handle on the stack instead of > >>> creating a named word is generally good practice, and Forth-94 > >>> followed it with WORDLIST (where the named alternative is VOCABULARY). > > > >> A pity they didn't provide a way of naming a wordlist such that its name > >> is displayed by ORDER. And yes I know that in Gforth after e.g. > > > >> wordlist constant wl > > > >> ORDER displays wl at the head of the search order but other systems > >> don't, just displaying an unhelpful address. > > > >The problem with using CONSTANT to name a handle or other anonymous abject > >is that there is no way to get from the constant value back to the name. > > In Gforth, in the case of ORDER, we know that we want to pront a > wordlist name, so we look right behind the memory for the wordlist for > a constant that points to that wordlist. > > For general constants, you could search through all words, looking for > constants that have that value. > > If that's too slow for your needs (and you have memory to burn): Every > CONSTANT inserts a <value,nt> pair into a lookup table (implemented, > e.g., as hash table), where the value is the key, and you use that to > translate from the value to the constant name if available. > > - 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/ That table smells strongly of a class implementation for constants.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-04 13:13 +0000 |
| Message-ID | <2017May4.151302@mips.complang.tuwien.ac.at> |
| In reply to | #58494 |
minforth@arcor.de writes:
>Am Dienstag, 2. Mai 2017 15:14:54 UTC+2 schrieb Anton Ertl:
[printing the name of a constant when seeing the value]
>> If that's too slow for your needs (and you have memory to burn): Every
>> CONSTANT inserts a <value,nt> pair into a lookup table (implemented,
>> e.g., as hash table), where the value is the key, and you use that to
>> translate from the value to the constant name if available.
>>
>> - 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/
>
>
>That table smells strongly of a class implementation for constants.
I have no idea what you mean by that.
Please trim quoted material.
- 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-05-03 04:20 -0700 |
| Message-ID | <9d4b1829-8607-4012-854f-4134f6623912@googlegroups.com> |
| In reply to | #58492 |
Am Dienstag, 2. Mai 2017 15:14:54 UTC+2 schrieb Anton Ertl: > JennyB <jenny...@googlemail.com> writes: > >> On 30/04/2017 10:36, Anton Ertl wrote: > >>> Having a constructor word that puts a handle on the stack instead of > >>> creating a named word is generally good practice, and Forth-94 > >>> followed it with WORDLIST (where the named alternative is VOCABULARY). > > > >> A pity they didn't provide a way of naming a wordlist such that its name > >> is displayed by ORDER. And yes I know that in Gforth after e.g. > > > >> wordlist constant wl > > > >> ORDER displays wl at the head of the search order but other systems > >> don't, just displaying an unhelpful address. > > > >The problem with using CONSTANT to name a handle or other anonymous abject > >is that there is no way to get from the constant value back to the name. > > In Gforth, in the case of ORDER, we know that we want to pront a > wordlist name, so we look right behind the memory for the wordlist for > a constant that points to that wordlist. > > For general constants, you could search through all words, looking for > constants that have that value. > > If that's too slow for your needs (and you have memory to burn): Every > CONSTANT inserts a <value,nt> pair into a lookup table (implemented, > e.g., as hash table), where the value is the key, and you use that to > translate from the value to the constant name if available. > All those are possible of course, and this is simply a possible debugging tool that has no affect on working code, but explicitly using NAMED means that you don't have to search or make a table for all constants. I see it as akin to your COMPILE-ONLY - it makes the intent of the code clearer and the job of the debugger easier, but if a compiler does not support it then it can easily be redefined: : COMPILE-ONLY ; IMMEDIATE : NAMED CONSTANT ;
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-04 15:17 +0000 |
| Message-ID | <2017May4.171748@mips.complang.tuwien.ac.at> |
| In reply to | #58575 |
JennyB <jennybrien@googlemail.com> writes:
>Am Dienstag, 2. Mai 2017 15:14:54 UTC+2 schrieb Anton Ertl:
>> If that's too slow for your needs (and you have memory to burn): Every
>> CONSTANT inserts a <value,nt> pair into a lookup table (implemented,
>> e.g., as hash table), where the value is the key, and you use that to
>> translate from the value to the constant name if available.
>>
>
>All those are possible of course, and this is simply a possible debugging tool
>that has no affect on working code, but explicitly using NAMED means that you
>don't have to search or make a table for all constants.
It means I either have to search all NAMED definitions, or make such a
lookup table of all NAMED definitions.
Of course, this probably saves some time/memory if NAMED is used
rarely.
However, my view is that, on a big platform, the major cost of the
feature is the effor to implement it, not the memory, and if I
implement it, I want it available without further ado, even for
constants that were defined unaware of NAMED. On small platforms the
feature is unlikely to be implemented at all. I would have some way
of defining a constant without reverse-lookup, for cases where I use a
wordlist as a lookup table.
- 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-02 12:46 +0000 |
| Message-ID | <2017May2.144612@mips.complang.tuwien.ac.at> |
| In reply to | #58413 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 30/04/2017 10:36, Anton Ertl wrote:
>> Having a constructor word that puts a handle on the stack instead of
>> creating a named word is generally good practice, and Forth-94
>> followed it with WORDLIST (where the named alternative is VOCABULARY).
>
>A pity they didn't provide a way of naming a wordlist such that its name
>is displayed by ORDER. And yes I know that in Gforth after e.g.
>
>wordlist constant wl
>
>ORDER displays wl at the head of the search order but other systems
>don't, just displaying an unhelpful address.
For now that's a quality-of-implementation issue, as they say. If
enough users complain to their system implementors that they want
ORDER to show the name of wordlists defined with the idiom "WORDLIST
CONSTANT <name>", or switch to a system that has this feature, system
implementors will implement this feature. If enough systems have this
feature, it becomes common practice and a proposal for standardization
should not be controversial. However, I thaught that about 1 CHARS=1,
and yet it met resistance. So you might just as well make a proposal
for more guaranteed functionality in ORDER right away.
- 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-05-03 07:58 +0100 |
| Message-ID | <oebus1$voc$1@dont-email.me> |
| In reply to | #58490 |
On 02/05/2017 13:46, Anton Ertl wrote: > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes: >> On 30/04/2017 10:36, Anton Ertl wrote: >>> Having a constructor word that puts a handle on the stack instead of >>> creating a named word is generally good practice, and Forth-94 >>> followed it with WORDLIST (where the named alternative is VOCABULARY). >> >> A pity they didn't provide a way of naming a wordlist such that its name >> is displayed by ORDER. And yes I know that in Gforth after e.g. >> >> wordlist constant wl >> >> ORDER displays wl at the head of the search order but other systems >> don't, just displaying an unhelpful address. > > For now that's a quality-of-implementation issue, as they say. If > enough users complain to their system implementors that they want > ORDER to show the name of wordlists defined with the idiom "WORDLIST > CONSTANT <name>", or switch to a system that has this feature, system > implementors will implement this feature. If enough systems have this > feature, it becomes common practice and a proposal for standardization > should not be controversial. However, I thaught that about 1 CHARS=1, > and yet it met resistance. So you might just as well make a proposal > for more guaranteed functionality in ORDER right away. > If only one system (GForth) has found it necessary or desirable to implement ORDER that way in 23 years then there clearly can't be a huge demand for it. I've always thought it an unnecessary gap in the language - it's just an irritation to see an address (presumably a wid) in the search order and to have to fiddle around to identify it. I'm hoping that if recognisers are standardised and have an equivalent to ORDER that a similar gap won't be left. All that is needed is a word, such as Jenny suggested, that associates a wid with a name. The same word could be used for recognisers so it could be included in the recogniser proposal. Assuming a constant holds the name is not a good idea as it may be held in a variable, value, some user defined data structure or even a colon definition. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-05-03 10:52 -0700 |
| Message-ID | <f350ca39-5043-4026-a915-9ac2fa83a700@googlegroups.com> |
| In reply to | #58555 |
On Wednesday, May 3, 2017 at 8:58:13 AM UTC+2, Gerry wrote:
> On 02/05/2017 13:46, Anton Ertl wrote:
> > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> >> On 30/04/2017 10:36, Anton Ertl wrote:
> >>> Having a constructor word that puts a handle on the stack instead of
> >>> creating a named word is generally good practice, and Forth-94
> >>> followed it with WORDLIST (where the named alternative is VOCABULARY).
> >>
> >> A pity they didn't provide a way of naming a wordlist such that its name
> >> is displayed by ORDER. And yes I know that in Gforth after e.g.
> >>
> >> wordlist constant wl
> >>
> >> ORDER displays wl at the head of the search order but other systems
> >> don't, just displaying an unhelpful address.
> >
> > For now that's a quality-of-implementation issue, as they say. If
> > enough users complain to their system implementors that they want
> > ORDER to show the name of wordlists defined with the idiom "WORDLIST
> > CONSTANT <name>", or switch to a system that has this feature, system
> > implementors will implement this feature. If enough systems have this
> > feature, it becomes common practice and a proposal for standardization
> > should not be controversial. However, I thaught that about 1 CHARS=1,
> > and yet it met resistance. So you might just as well make a proposal
> > for more guaranteed functionality in ORDER right away.
> >
>
> If only one system (GForth) has found it necessary or desirable to
> implement ORDER that way in 23 years then there clearly can't be a huge
> demand for it. I've always thought it an unnecessary gap in the language
> - it's just an irritation to see an address (presumably a wid) in the
> search order and to have to fiddle around to identify it.
>
> I'm hoping that if recognisers are standardised and have an equivalent
> to ORDER that a similar gap won't be left. All that is needed is a word,
> such as Jenny suggested, that associates a wid with a name. The same
> word could be used for recognisers so it could be included in the
> recogniser proposal. Assuming a constant holds the name is not a good
> idea as it may be held in a variable, value, some user defined data
> structure or even a colon definition.
>
> --
> Gerry
Or something like this.
FORTH> order
Search list:
FORTH
ONLY
Definitions:
FORTH ok
FORTH> wordlist constant WL1 ok
FORTH> get-order wl1 swap 1+ set-order ok
$050F2CC1> order
Search list:
$050F2CC1
FORTH
ONLY
Definitions:
FORTH ok
$050F2CC1> previous ok
FORTH> vocabulary WL2 ok
FORTH> ALSO WL2 ok
WL2> order
Search list:
WL2
FORTH
ONLY
Definitions:
FORTH ok
-marcel
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-04-30 08:51 -0700 |
| Message-ID | <adc9ced8-1bf3-49bd-b89d-c99a512bfa51@googlegroups.com> |
| In reply to | #58372 |
> We've separated out the parsing from the action on a token, but we're > restricted as to what we can do with the token actions. The recognizer > and the token are tightly bound. Modifying them requires something along > the lines of DT>INT! DT>COMP! and DT>POST!. DT:TOKENs are supposed to be > opaque. > > Problem: There's no way of modifying what DT-TOKEN:s do without either > extra supporting words or per-implementation carnal knowledge. Let me re-word your thoughts. The DT:Object provides three methods that a Forth interpreter can do with a certain data type. What you suggest is, that you want to modify these actions but keep the data itself (e.g. the number). I see tight links to cross-compilers, btw. > > Solution: I propose replacing DT-TOKEN: with DT-TOKENS, for example > defined as; > > : dt-tokens ( xt-interpret xt-compile xt-postpone -- val ) > here 2>r swap , , r> r> , ; > > ' i-object > ' c-object > ' p-object > dt-tokens value dt:object > > Now we can save DT:OBJECT and set new actions. Since DT:TOKENS are opaque, they can be very well be implemented as VALUE's. Nice idea. > No other changes are required to the proposal. To tightly bind REC:X to > DT:X as is currently done, use a CONSTANT instead of a VALUE. Another way to deal with such things may be a mapping like DT:XT <-> DT:XT:CROSS. For that you exchange the DT information returned from the parsing actions with your desired data type set. Matthias
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-04-30 22:54 +0000 |
| Message-ID | <oe5pui$g8i$1@dont-email.me> |
| In reply to | #58372 |
Am Sun, 30 Apr 2017 03:31:37 +0100 schrieb Alex: > No other changes are required to the proposal. To tightly bind REC:X to > DT:X as is currently done, use a CONSTANT instead of a VALUE. I'm ok with that suggestion, and indeed, the last word in RECOGNIZER: in Gforth (which has been renamed to DT-TOKEN: in the most recent proposal, which is not yet propagated to Gforth) is "CONSTANT". The name should be "DT-TOKEN", as it is creating *one* token, with three actions. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-01 01:01 -0700 |
| Message-ID | <bef37c46-04b4-4e96-8558-cc40798b63f4@googlegroups.com> |
| In reply to | #58423 |
Am Montag, 1. Mai 2017 00:57:25 UTC+2 schrieb Bernd Paysan: > Am Sun, 30 Apr 2017 03:31:37 +0100 schrieb Alex: > > > No other changes are required to the proposal. To tightly bind REC:X to > > DT:X as is currently done, use a CONSTANT instead of a VALUE. > > I'm ok with that suggestion, and indeed, the last word in RECOGNIZER: in > Gforth (which has been renamed to DT-TOKEN: in the most recent proposal, > which is not yet propagated to Gforth) is "CONSTANT". The RFD uses an XT as this ID, created with CREATE, which is more implicit a number. > > The name should be "DT-TOKEN", as it is creating *one* token, with three > actions. turning the sequence ... DT-TOKEN: some-name into .... DT-TOKEN CONSTANT some-name (or VALUE or whatever else to give a name to a number) more or less complicated now? Matthias
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-02 15:10 +0000 |
| Message-ID | <oea7gm$mhn$3@dont-email.me> |
| In reply to | #58433 |
Am Mon, 01 May 2017 01:01:44 -0700 schrieb Matthias Trute: > The RFD uses an XT as this ID, created with CREATE, which is more > implicit a number. Yes, but that's just a reference implementation. Using : dt-token ( xti xtc xtp -- dt ) align here >r rot swap , , , r> ; is also easy to write. >> The name should be "DT-TOKEN", as it is creating *one* token, with >> three actions. > > turning the sequence ... DT-TOKEN: some-name into .... DT-TOKEN CONSTANT > some-name (or VALUE or whatever else to give a name to a number) > > more or less complicated now? Same. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [standalone]
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
Back to top | Article view | comp.lang.forth
csiph-web