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 | 20 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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-10 15:10 +0200 |
| Message-ID | <86bmr0amdi.fsf@molnjunk.nocrew.org> |
| In reply to | #58969 |
Alex <alex@rivadpm.com> writes: > Perhaps (only slightly tongue in cheek) you need YOU-HAVE-A-GO before > your "recognizers" and a AH-WELL-ONE-LAST-TRY for when the default > parsing wheels fall off. I have PARSED right before the dictionary search. And NUMBER right after a failed directionary search.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-10 14:33 +0100 |
| Message-ID | <oev4kj$dvv$1@dont-email.me> |
| In reply to | #58978 |
On 5/10/2017 14:10, Lars Brinkhoff wrote: > Alex <alex@rivadpm.com> writes: >> Perhaps (only slightly tongue in cheek) you need YOU-HAVE-A-GO before >> your "recognizers" and a AH-WELL-ONE-LAST-TRY for when the default >> parsing wheels fall off. > > I have PARSED right before the dictionary search. > And NUMBER right after a failed directionary search. > Do PARSED and NUMBER point at the input buffer, or to a copy (for example in a counted string from WORD, that's perhaps been case adjusted to make FIND easier)? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-10 16:08 +0200 |
| Message-ID | <8637ccajpb.fsf@molnjunk.nocrew.org> |
| In reply to | #58982 |
Alex wrote: >> I have PARSED right before the dictionary search. >> And NUMBER right after a failed directionary search. > > Do PARSED and NUMBER point at the input buffer, or to a copy (for > example in a counted string from WORD, that's perhaps been case > adjusted to make FIND easier)? Interpreting a line looks much like this: : interpret ( -- ) begin parse-name dup while parsed repeat 2drop ; PARSE-NAME returns ( a u ) pointing into the input buffer. I don't accomodate FIND, because I don't have that in the kernel. I have FIND-NAME ( a u -- a u 0 | xt +-1 ). The default PARSED searches the dictionary and executes/compiles xts. If not found, NUMBER is called. Note: I'm not trying to argue much of anything. In particular, I'm not advocating for or against recognizers.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-10 16:02 +0100 |
| Message-ID | <oev9s0$g1$1@dont-email.me> |
| In reply to | #58984 |
On 5/10/2017 15:08, Lars Brinkhoff wrote: > Alex wrote: >>> I have PARSED right before the dictionary search. >>> And NUMBER right after a failed directionary search. >> >> Do PARSED and NUMBER point at the input buffer, or to a copy (for >> example in a counted string from WORD, that's perhaps been case >> adjusted to make FIND easier)? > > Interpreting a line looks much like this: > > : interpret ( -- ) begin parse-name dup while parsed repeat 2drop ; > > PARSE-NAME returns ( a u ) pointing into the input buffer. I don't > accomodate FIND, because I don't have that in the kernel. I have > FIND-NAME ( a u -- a u 0 | xt +-1 ). Gforth's FIND-NAME (as does mine in WF32) returns a name token ( c-addr u -– nt | 0 ). Ouch. Anton may find it difficult to get FIND-NAME standardized at this rate. > > The default PARSED searches the dictionary and executes/compiles xts. > If not found, NUMBER is called. > > Note: I'm not trying to argue much of anything. In particular, I'm not > advocating for or against recognizers. > Understood. Yet it is another data point of another incompatible approach to this issue. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-10 09:10 -0700 |
| Message-ID | <6faf2802-cc1d-4b9c-a409-5d61bfab3d5e@googlegroups.com> |
| In reply to | #58986 |
> > FIND-NAME ( a u -- a u 0 | xt +-1 ). > > Gforth's FIND-NAME (as does mine in WF32) returns a name token ( c-addr > u -– nt | 0 ). Ouch. Anton may find it difficult to get FIND-NAME > standardized at this rate. Amforth has it too. Same stack effect. Uses the search order stack for the wordlists to be checked. Matthias
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-10 18:38 +0200 |
| Message-ID | <86y3u48y6b.fsf@molnjunk.nocrew.org> |
| In reply to | #58986 |
Alex wrote: >> I have FIND-NAME ( a u -- a u 0 | xt +-1 ). > Gforth's FIND-NAME (as does mine in WF32) returns a name token ( > c-addr u -– nt | 0 ). Ouch. Anton may find it difficult to get > FIND-NAME standardized at this rate. I can change mine. The name or the stack effect. Xt = nt in my system. Stephen Pelc made a good case.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-08 04:03 -0500 |
| Message-ID | <f46dnZ08k7PPqY3EnZ2dnUU7-fPNnZ2d@supernews.com> |
| In reply to | #58797 |
Bernd Paysan <bernd@net2o.de> wrote: > Am Sun, 07 May 2017 03:54:43 -0500 schrieb Andrew Haley: > >>> But your objection is "people will be able to shoot into their foot if >>> they are not careful"! >> >> No, it's not. It's more that the proposal is more general than is >> needed and its most far-out features will not help and at worst will >> increase the burden of maintanance. > > What's the difference between "will increase the burden of maintenance" > and "people will be able to shoot into their foot"? Apart from the > wording? You have to read the whole sentence. I'm saying that the proposal is ill-thought-out with regard to its downsides, particularly with the difficulty of handling conflicting recognizers and the lack of any facility to handle them. And the only response to the downsides has been "Don't worry, people won't do that." [ Skip explanation that recognizers do everything that a redefinable interpreter needs, and some more too. I know. ] > We are already in the "here be dragons" country. You make lame > excuses that the dragon maybe is only a lizard, or a big bat or so, > and someone has lighted a campfire. No, the dragon is already > there, hiding behind a bunch of hooks. I am not making any excuses. I don't have to make excuses for anything, because I'm not making the proposal. > The only thing the recognizer proposal makes is to standardize these > already existing, but wildly incompatible interpreter hooks. And to > do that, without taking any of the existing capabilities away, it > must be as general as it is now. I totally agree. If you have a disparate range of facilities used for different purposes and you want to encompass them all in a single standard uber-structure, you are going to need a very broad and powerful one. I have never denied it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-08 13:32 +0000 |
| Message-ID | <oeps29$tkf$2@dont-email.me> |
| In reply to | #58814 |
Am Mon, 08 May 2017 04:03:14 -0500 schrieb Andrew Haley:
> Bernd Paysan <bernd@net2o.de> wrote:
>> Am Sun, 07 May 2017 03:54:43 -0500 schrieb Andrew Haley:
>> What's the difference between "will increase the burden of maintenance"
>> and "people will be able to shoot into their foot"? Apart from the
>> wording?
>
> You have to read the whole sentence. I'm saying that the proposal is
> ill-thought-out with regard to its downsides, particularly with the
> difficulty of handling conflicting recognizers and the lack of any
> facility to handle them. And the only response to the downsides has
> been "Don't worry, people won't do that."
Conflicting recognizers are handled like conflicting words (and maybe
numbers): The first match wins.
Just like if you switch into hex in your assembler, and ADD is both a
symbol and a number, you get around by using 0ADD or $ADD for the number.
With "recognizers can be anything", it is certainly not possible to say
how people will deal with that.
If you have two conflicting recognizers, you have to arrange or enable
them in a way that gets you what you want. Same as when you have two
conflicting words in two wordlists: you need to change the search order
to access the hidden word. Or use the scope recognizer... You could add
a meta recognizer to fix the conflict problem, which would work similar
to the scope recognizer: use the first part of the string to identify
which recognizer to use, and then pass the rest of the string to exactly
that recognizer.
You could say
word?add \ gives the symbol add
scope?asm:add \ uses the scope parser
num?add \ gives the hex number add
float?1. \ no, we don't mean double!
string?"add" \ parses the string "add"
to?->add \ uses the to-recognizer to add
dot?object.method \ uses some generic dot parser
moof2?.method \ use mini-oof2's dot parser
meta?word?add \ use the meta parser itself to meta-parse
all by splitting the string at the '?', and prepending rec: to the first
string part, searching for that word, and if it exists, executing it
(it's supposed to be a recognizer). This is just a few lines of code.
You need to add it first, because disambiguation only works reliable when
it is done first.
Good programmers use tools to solve their problems, bad programmers use
them to create new problems. Forth however has no helmets, seat belts,
and airbags for the bad programmers. That's on purpose.
> I am not making any excuses. I don't have to make excuses for anything,
> because I'm not making the proposal.
Arguments need substance. Hugh already loves your arguments.
>> The only thing the recognizer proposal makes is to standardize these
>> already existing, but wildly incompatible interpreter hooks. And to do
>> that, without taking any of the existing capabilities away, it must be
>> as general as it is now.
>
> I totally agree. If you have a disparate range of facilities used for
> different purposes and you want to encompass them all in a single
> standard uber-structure, you are going to need a very broad and powerful
> one. I have never denied it.
You said something about the "task at hand". What you perceive as "task
at hand". It's not the actual task at hand. And by limiting the
recognizer to one special purpose task ("more number literals"), it
doesn't actually get much smaller, it only gets less useful.
--
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 | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-08 16:11 +0200 |
| Message-ID | <oepuad$1vh$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #58797 |
In article <oeoatm$3p2$4@dont-email.me>, Bernd Paysan <bernd@net2o.de> wrote:
<SNIP>
>
>The only thing the recognizer proposal makes is to standardize these
>already existing, but wildly incompatible interpreter hooks. And to do
>that, without taking any of the existing capabilities away, it must be as
>general as it is now.
>
>Or maybe even more general, as SwiftForth's hooks also can replace the BL
>WORD or PARSE-NAME part of the outer interpreter. We have discussed
>whether each recognizer should do the parsing itself or leave it to the
>fixed part of the proposal, and decided for the second: Forth source is
>words, i.e. blank-separated stuff. The recognizer itself however can
>know that the addr u it gets is part of the current input buffer (i.e.
>SOURCE), and it is allowed to manipulate >IN if it recognizes something.
By replacing the sequence BL WORD COUNT or whatever the tokenizer is
(in ciforth it is called NAME) one can get anything.
If in NAME I replace
BLANK?
by
DUP BLANK? SWAP START? OR
and backup one character if a start has been found I can recognize
pascal tokens.
( START? tells whether a character is one of "-+/=<>:;.{}()[]," )
That is one method.
Another one is to demand that each Pascal keyword is surrounded by
blank space. This is what Chuck Moore does in his Tiny Basic.
Just preprocess a Pascal source .
The third one os with recognizers, each of the char's that start
a Pascal token could be a separate recognizer. It starts to look
like a recursive descent compiler.
The bottom line is who writes the simplest Pascal compiler?
I guess it'll be Chuck Moore.
>
>--
>Bernd Paysan
--
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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-05-04 20:29 +0000 |
| Message-ID | <590b8e84.716400521@news.eternal-september.org> |
| In reply to | #58657 |
On Thu, 04 May 2017 14:00:14 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >And for recognizers there is no whirl factor. This has been in the >works for some time, presented to committe members and the wider >community repeatedly, there are several implementations around, >including one for VFX (which Stephen Pelc refused to even look at). Bollocks. See Examples/Recogniser.fth in all versions of VFX Forth. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-07 14:55 +0000 |
| Message-ID | <2017May7.165512@mips.complang.tuwien.ac.at> |
| In reply to | #58682 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Thu, 04 May 2017 14:00:14 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>And for recognizers there is no whirl factor. This has been in the
>>works for some time, presented to committe members and the wider
>>community repeatedly, there are several implementations around,
>>including one for VFX (which Stephen Pelc refused to even look at).
>
>Bollocks. See Examples/Recogniser.fth in all versions of VFX Forth.
So have you tried it out?
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-02 02:47 -0500 |
| Message-ID | <jtednaRAmpoypJXEnZ2dnUU7-V_NnZ2d@supernews.com> |
| In reply to | #58403 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>It clearly indicates that something is wrong with the recognizer >>>>proposal >>> >>> It does? Can you elaborate on that? >> >>What for? It gets more and more tricky, with weird corner cases, and >>has gone far beyond a literal recognizer. > > A classical Andrew Haley. You have no argument, so you evade the > request to elaborate on your statement by throwing in more > unsubstantiated generalities. > > The only thing your responses in this thread show is that you have not > understood the original posting (probably because you did not invest > the time needed to understand it); but you took it as a good > opportunity to express your hatred of recognizers. I said that the complexity of the issues being discussed, which go far beyond what would be needed by a simple literal recognizer, show that something is wrong. That's a perfectly reasonable thing to say. It's not necessary to study how to cast a horoscope before pointing out that astrology is bogus. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-02 15:02 +0000 |
| Message-ID | <oea71c$mhn$2@dont-email.me> |
| In reply to | #58475 |
Am Tue, 02 May 2017 02:47:59 -0500 schrieb Andrew Haley: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > I said that the complexity of the issues being discussed, which go far > beyond what would be needed by a simple literal recognizer, show that > something is wrong. That's a perfectly reasonable thing to say. It's > not necessary to study how to cast a horoscope before pointing out that > astrology is bogus. Recognizers as proposed are not meant to be "a simple literal recognizer". They are meant to replace the non-standard hooks-everywhere extensible interpreters we see from systems like VFX. Being able to add your floating point recognizer when loading the floating point library, or the double recognizer when loading doubles is just replacing *one* of those many hook. Of course, we Germans have an untranslatable word for you: "Bedenkenträger". We are not going to deal with problems that come from bad choice of recognizer semantics. Just as we don't deal with things like "1 CONSTANT 0". My experience with recognizers is that the only "tough" thing is when you combine the effect of several recognizers. Can I do .->voc:value ? That starts with the dot parser, followed by the to-parser, and finally the scope-parser? In which order must I write these? Turns out that you can have ->voc:name and .voc:name, but not .-> or ->., because neither of them likes more complex data tokens. -- 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 | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-30 12:11 +0100 |
| Message-ID | <oe4gj7$9ha$1@dont-email.me> |
| In reply to | #58373 |
On 4/30/2017 04:21, minforth@arcor.de wrote:
>
> This complicated stuff
It's not. It simplifies enormously Forth parsing and compilation and
gets rid of some nasty side effects of the current classical methods. I
showed recently how to write a recognizer for 0x prefixed words.
: plit postpone literal ;
' noop \ interpret: do nothing
' plit \ compile as a literal
:noname plit postpone plit ; \ postpone a literal
dt-token: dt:0x ( n -- )
: rec:0x ( addr u -- n dt:number | dt:null )
dup 2 >= if
over 2 s" 0x" compare 0= if
base @ >r hex
2 /string 0 0 2swap >number \ n n addr len
r> base !
nip + dup 0= if
drop dt:0x exit
then
then
then 2drop dt:null ;
' rec:0x get-recognizers 1+ set-recognizers
It's hardly complex. How would you do this without recognizers?
> clearly indicates that recognizers are a tool for compiler makers.
Forth users aren't allowed to extend their systems? That's very
anti-Forthish.
>
> Rather worthless for 99.9% of all users
Unimaginative ones perhaps. But Forthers aren't (in my experience) like
that.
>
> Then recognizers should not be in the standard IMO.
If they are standardized (and they will almost certainly be optional,
like much of the standard beyond CORE), then any system that supports
recognizers can support 0x prefixed words. No special knowledge is
required.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-04-30 06:34 -0700 |
| Message-ID | <a5323e2f-02ec-4ebf-b9de-f2cab9288aa3@googlegroups.com> |
| In reply to | #58393 |
Am Sonntag, 30. April 2017 13:11:37 UTC+2 schrieb Alex: > On 4/30/2017 04:21, minforth@arcor.de wrote: > > > > > This complicated stuff > > It's not. It simplifies enormously Forth parsing and compilation and > gets rid of some nasty side effects of the current classical methods. I > showed recently how to write a recognizer for 0x prefixed words. > > : plit postpone literal ; > > ' noop \ interpret: do nothing > ' plit \ compile as a literal > :noname plit postpone plit ; \ postpone a literal > dt-token: dt:0x ( n -- ) > > : rec:0x ( addr u -- n dt:number | dt:null ) > dup 2 >= if > over 2 s" 0x" compare 0= if > base @ >r hex > 2 /string 0 0 2swap >number \ n n addr len > r> base ! > nip + dup 0= if > drop dt:0x exit > then > then > then 2drop dt:null ; > > ' rec:0x get-recognizers 1+ set-recognizers > > It's hardly complex. How would you do this without recognizers? > It is rather much easier than that in my (and I guess most other) Forths to check for a $ number prefix and an equivalent 0x number prefix. I won't post code here, but it's a one-liner more. I am (mostly) not that stupid to not being able to appreciate the usefulness of recognizers for DSL creation. However IMO they belong into a toolbelt, not into a standard. Over-generalization can also be counter-productive.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-04-30 06:59 -0700 |
| Message-ID | <0c9d813a-66a8-4d3b-b0ac-6b735da46343@googlegroups.com> |
| In reply to | #58400 |
On Sunday, April 30, 2017 at 8:34:09 AM UTC-5, minf...@arcor.de wrote: > I am (mostly) not that stupid to not being able to appreciate the usefulness of recognizers for DSL creation. However IMO they belong into a toolbelt, not into a standard. Over-generalization can also be counter-productive. The point of standardizing them is that they *can't* go in a toolbelt.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-30 15:04 +0100 |
| Message-ID | <oe4qmj$7un$1@dont-email.me> |
| In reply to | #58400 |
On 4/30/2017 14:34, minforth@arcor.de wrote:
> Am Sonntag, 30. April 2017 13:11:37 UTC+2 schrieb Alex:
>> On 4/30/2017 04:21, minforth@arcor.de wrote:
>
> It is rather much easier than that in my (and I guess most other)
> Forths to check for a $ number prefix and an equivalent 0x number
> prefix. I won't post code here, but it's a one-liner more.
You need to post the code, since I'm unconvinced on two scores; one,
that it's a one liner and two, that it's potentially portable.
>
> I am (mostly) not that stupid to not being able to appreciate the
> usefulness of recognizers for DSL creation. However IMO they belong
> into a toolbelt, not into a standard. Over-generalization can also be
> counter-productive.
>
Call it what you will; toolbelt, standard, addendum, application
extension; whatever it is, then someone, somewhere, will rather want it
to be universal. At that point, it's best that we have some way of
describing it and how it's used.
I'm finding it incredibly useful. It has simplified the parsing of
numbers and text in my Forth. This isolation of the code into specific
areas has made it much neater, easier to maintain, and extensible.
: pslit postpone sliteral ;
' noop
' pslit
:noname pslit postpone pslit ;
dt-token: dt:string
: rec:string ( addr len -- addr len' dt:string | dt:null )
over c@ '"' = if
drop 1+ source drop - >in ! \ step back in parse area
'"' parse dt:string \ get up to trailing "
else 2drop dt:null then ;
' rec:string get-recognizers 1+ set-recognizers
That parses (and compiles and postpones) strings of the form "text
string". It really doesn't get much easier than this to extend the
parser in new and useful directions, and in a standardised way.
I understand the over-generalization point. I also didn't mean to imply
stupidity on your part.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-04-30 09:38 -0700 |
| Message-ID | <266e7786-9236-4d79-87b6-993e454b1a2a@googlegroups.com> |
| In reply to | #58393 |
> > Then recognizers should not be in the standard IMO. > > If they are standardized (and they will almost certainly be optional, > like much of the standard beyond CORE) The proposal is about an optional wordset. Not an extension of CORE. I agree that the work to include it has to be done by the system implementors, but which wordset doesn't require their cooperation? Matthias
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-30 09:36 +0000 |
| Message-ID | <2017Apr30.113640@mips.complang.tuwien.ac.at> |
| In reply to | #58372 |
Alex <alex@rivadpm.com> writes:
>RFC-D spec http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf
>
>I'm finding DT-TOKEN: a bit restrictive.
>
>: dt-token: ( xt-interpret xt-compile xt-postpone "<spaces>name" -- )
> create swap rot , , , ;
>
> ' i-object
> ' c-object
> ' p-object
>dt-token: dt:object
>
>We write a recognizer REC:OBJECTS for objects; it returns DT:OBJECT on
>success.
>
>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.
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.
>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
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).
- 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 11:46 +0100 |
| Message-ID | <oe4f3q$54g$1@dont-email.me> |
| In reply to | #58386 |
On 4/30/2017 10:36, Anton Ertl wrote: > Alex <alex@rivadpm.com> writes: >> RFC-D spec http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf >> >> I'm finding DT-TOKEN: a bit restrictive. >> >> : dt-token: ( xt-interpret xt-compile xt-postpone "<spaces>name" -- ) >> create swap rot , , , ; >> >> ' i-object >> ' c-object >> ' p-object >> dt-token: dt:object >> >> We write a recognizer REC:OBJECTS for objects; it returns DT:OBJECT on >> success. >> >> 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. > > 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. 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?) 3. Make each of the actions a deferred word. Requires your DT:OBJECT has done it this way. (Are all the actions deferred? Only some? Would we have to standardize this?) 4. Borrow the recognizer, wrapper it and modify the result from DT:OBJECT to DT:ALTOBJECT. Add the new recognizer to the stack. Hmm. Ugly. Assumes that your recognizer has no side effects. Assumes that we can find where REC:OBJECTS is in the stack to precede it (see 1). Each of these demands that you write your recognizer in a specific way or it will lead to system specific coding & a lack of portability. I like none of the proposed alternatives for that reason. > >> 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 > > 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). Yes. -- Alex
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web