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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-02 03:49 -0500 |
| Message-ID | <ELSdncIQzKOq1ZXEnZ2dnUU7-SXNnZ2d@supernews.com> |
| In reply to | #58404 |
Alex <alex@rivadpm.com> wrote: > > But it is counterproductive to have someone of Andrew's ability (and > I sincerely mean that; his contributions are generally observant and > well thought through) serve up little more than "I'm no likee this, > no siree" without justification. > > Perhaps he's explained himself elsewhere, since I understand he > wasn't a fan at the Bath 2015 EuroForth conference, something > Matthias Trute alluded to in his proposal. I'd appreciate hearing it > if so. I missed that conference, I think. My basic objection is that this proposal essntially turns the Forth interpreter inside out, with the dictionary search subservient to the recognizer loop. Such an extraordinary overhaul of the language, the most dramatic since ANS 94, IMO requires extraordinary justification. And that justification must be pulled by the needs of application writers, not pushed by implementers. More specifically: If libraries use recognizers, the client code of those libraries may also need to use recognizers provided by the library. This is fine as long as only one library adds recognizers. But there is no proposal for a way to control conflicting recognizers, and none may be possible. It could be argued that this is no worse than conflicting word names in libraries, but at least words can be renamed if they conflict. This isn't the case with recognizers, which define entire classes of names. The recognizer stack is a large slab of global state, and managing it will not be an easy problem to solve. The proposal allows recognizers to precede dictionary searches, so that even if a word would have been found it might not be executed because a recognizer got in there first. This will not help debugging; it is not a good thing. The proposal is too complex. It doesn't have the property of clarity and "just right" elegance that characterizes the Forth interpreter, and indeed good Forth in general. A solution to the problem of user-defined literal recognizers should have that property. Examples of the use of recognizers serve only to reinforce my disquiet. For example, the "0x" example recognizer does this: : plit postpone literal ; ' noop \ interpret: do nothing ' plit \ compile as a literal :noname plit postpone plit ; \ postpone a literal dt-token: dt:0x ( n -- ) The multi-level POSTPONE took me a little while to understand. And it's totally unnecessary because no application will ever need to POSTPONE 0x25 The above could be rewritten as ' noop \ interpret: do nothing :noname postpone literal ; \ compile as a literal ' abort \ WTF? dt-token: dt:0x ( n -- ) This is shorter, much easier to understand, and doesn't get carried away with pointless features. And that's the examples of its use all over: pointless features. More broadly, much of the discussion of recognizers reflects an obsession with syntax which is not in keeping with the spirit of Forth. Forth carefully eschews syntatctic minutiae and concentrates on semantics: THIS THAT OTHER does this then that the the other, and we know that's what it does. There's no superfluous punctuation. Literals are confined to simple numbers. This simplicity is a feature, not a bug. Where this general rule has been broken, for example as in TO, it has been a wart on the language. Getting changes into long-established languages is hard. That is how it should be. It is up to the proposers to present a convincing case that a change is really needed, and justify it with the needs of people writing applications. Better to take a step back, take a hard look at what is really required, and come up with something that can be described more easily, managed more easily, and is a reasonable solution in proportion to the magnitude of the problem. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-02 12:27 +0200 |
| Message-ID | <oe9mu8$u6b$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #58478 |
In article <ELSdncIQzKOq1ZXEnZ2dnUU7-SXNnZ2d@supernews.com>,
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>Alex <alex@rivadpm.com> wrote:
>>
>> But it is counterproductive to have someone of Andrew's ability (and
>> I sincerely mean that; his contributions are generally observant and
>> well thought through) serve up little more than "I'm no likee this,
>> no siree" without justification.
>>
>> Perhaps he's explained himself elsewhere, since I understand he
>> wasn't a fan at the Bath 2015 EuroForth conference, something
>> Matthias Trute alluded to in his proposal. I'd appreciate hearing it
>> if so.
>
>I missed that conference, I think.
>
>My basic objection is that this proposal essntially turns the Forth
>interpreter inside out, with the dictionary search subservient to the
>recognizer loop. Such an extraordinary overhaul of the language, the
>most dramatic since ANS 94, IMO requires extraordinary justification.
>And that justification must be pulled by the needs of application
>writers, not pushed by implementers.
>
>More specifically:
>
>If libraries use recognizers, the client code of those libraries may
>also need to use recognizers provided by the library. This is fine as
>long as only one library adds recognizers. But there is no proposal
>for a way to control conflicting recognizers, and none may be
>possible. It could be argued that this is no worse than conflicting
>word names in libraries, but at least words can be renamed if they
>conflict. This isn't the case with recognizers, which define entire
>classes of names. The recognizer stack is a large slab of global
>state, and managing it will not be an easy problem to solve.
>
>The proposal allows recognizers to precede dictionary searches, so
>that even if a word would have been found it might not be executed
>because a recognizer got in there first. This will not help
>debugging; it is not a good thing.
>
>The proposal is too complex. It doesn't have the property of clarity
>and "just right" elegance that characterizes the Forth interpreter,
>and indeed good Forth in general. A solution to the problem of
>user-defined literal recognizers should have that property.
>
>Examples of the use of recognizers serve only to reinforce my
>disquiet. For example, the "0x" example recognizer does this:
>
>: plit postpone literal ;
>
> ' noop \ interpret: do nothing
> ' plit \ compile as a literal
> :noname plit postpone plit ; \ postpone a literal
>dt-token: dt:0x ( n -- )
>
>The multi-level POSTPONE took me a little while to understand. And
>it's totally unnecessary because no application will ever need to
>
> POSTPONE 0x25
>
>The above could be rewritten as
>
> ' noop \ interpret: do nothing
> :noname postpone literal ; \ compile as a literal
> ' abort \ WTF?
>dt-token: dt:0x ( n -- )
>
>This is shorter, much easier to understand, and doesn't get carried
>away with pointless features. And that's the examples of its use all
>over: pointless features.
>
>More broadly, much of the discussion of recognizers reflects an
>obsession with syntax which is not in keeping with the spirit of
>Forth. Forth carefully eschews syntatctic minutiae and concentrates
>on semantics:
>
> THIS THAT OTHER
>
>does this then that the the other, and we know that's what it does.
>There's no superfluous punctuation. Literals are confined to simple
>numbers. This simplicity is a feature, not a bug. Where this general
>rule has been broken, for example as in TO, it has been a wart on the
>language.
>
>Getting changes into long-established languages is hard. That is how
>it should be. It is up to the proposers to present a convincing case
>that a change is really needed, and justify it with the needs of
>people writing applications.
>
>Better to take a step back, take a hard look at what is really
>required, and come up with something that can be described more
>easily, managed more easily, and is a reasonable solution in
>proportion to the magnitude of the problem.
Against my principles I've quoted the whole article,
because I agree with every bit of it and every bit is important.
Read it again carefully, then progress to the next section.
There is progress possible towards recognizing expressions.
Forth is nice because it is either words or numbers,
but numbers we don't really need.
Forth had always the extensibility to make small parsing
words that recognize of constant expressions like
tm: which prefixes 18:40:12 and leaves a "time in seconds literal".
Another example is S" that parses and compiles a constant string.
So: tm: 18:40:12 S" monkey"
Those words require some care in order to be used in both
interpretation and compilation mode, this is called state smartness. 1]
What we can do to get rid of the special status of numbers is require
each number to be preceeded by # . Not the
"recognizer" way but like so:
: test # 1 # 2 + . ;
This would make for an even simpler Forth because there would
never be a decision needed about whether something is a number.
(This is very similar to the way colorforth handles numbers,
they are just green or pink, whatever. A color is just a prefix
in disguise.)
So we arrive at:
Forth is nice because it is either a word, or a word that
parses and leaves a literal expression that is the same during
interpretation or compilation. So it is just words all the
way down.
Forth is nice because it is words and only words.
There is state smartness involved, but state smartness of constants
("literals" "denotations" or whatever they are called) is not
dangerous. We are so used to the statesmartness of numbers that
people get angry when you call them that. 1]
So if we need strings we introduce " that introduces a smart
string. No postponing of those literals! Constant are just what
they are, constants, not an action that could be done later.
Once you're used to
: test " we go to Rome!" TYPE CR ;
finally we can let the quarter drop (as the Dutch expression goes).
Maybe we can mark the " as special and leave out the space behind it.
We get
: test "we go to Rome!" TYPE CR ;
this is pleasing and is similar to what programmers in all languages
are used to: literals are recognized by their introductory characters:
[ a, b, c] in a Python list, 0x18AC in a C-hex constants,
17Hwe gaan ervoor! for FORTRAN strings ("HOlleriths") and 789 in numbers
with introductory characters respectively [ 0x and H and 7.
The introductory characters are part of the expression. (Forthers
call those expressions words).
As I've demonstrated a few times, that mechanism to recognize those
"prefixes" adds two lines in a Forth.
Once we have that mechanism we can use it for numbers too.
Because special casing around numbers can be dropped, there is a net
gain in simplicity, if not line count.
With such an alternative, the whole recognizer circus seems to be
part of a whole trend of making life more complicated for no good
reason.
>
>Andrew.
Groetjes Albert
1] State smartness means that Forth if it finds e.g. 12223
it has to inspect STATE in order to do the right thing.
--
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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-04 11:42 +0000 |
| Message-ID | <2017May4.134237@mips.complang.tuwien.ac.at> |
| In reply to | #58483 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>Forth is nice because it is either words or numbers,
>but numbers we don't really need.
>
>Forth had always the extensibility to make small parsing
>words that recognize of constant expressions like
>tm: which prefixes 18:40:12 and leaves a "time in seconds literal".
>Another example is S" that parses and compiles a constant string.
>So: tm: 18:40:12 S" monkey"
>Those words require some care in order to be used in both
>interpretation and compilation mode, this is called state smartness. 1]
>What we can do to get rid of the special status of numbers is require
>each number to be preceeded by # . Not the
>"recognizer" way but like so:
>: test # 1 # 2 + . ;
>This would make for an even simpler Forth because there would
>never be a decision needed about whether something is a number.
>(This is very similar to the way colorforth handles numbers,
>they are just green or pink, whatever. A color is just a prefix
>in disguise.)
>
>So we arrive at:
>Forth is nice because it is either a word, or a word that
>parses and leaves a literal expression that is the same during
>interpretation or compilation. So it is just words all the
>way down.
>
>Forth is nice because it is words and only words.
>
>There is state smartness involved, but state smartness of constants
>("literals" "denotations" or whatever they are called) is not
>dangerous. We are so used to the statesmartness of numbers that
>people get angry when you call them that. 1]
...
>1] State smartness means that Forth if it finds e.g. 12223
>it has to inspect STATE in order to do the right thing.
You are a hopeless case of Humpty-Dumpty-Behaviour. In many of your
postings you use words and terms not in their commonly-understood
meaning, but meaning something else. Your use of # above is one
example, your redefinition of STATE-smartness here is another one.
And for STATE-smartness it is particularly evil, because it's already
confusing to many when people use the commonly-understood terminology.
For all non-immediate words the text interpreter inspects STATE in
order to do the right thing. For STATE-smart words, the word inspects
STATE at its run-time in an attempt to do the right thing (but fails
in corner cases). Here's an example:
: a 5 ; \ not STATE-smart
: b STATE @ if 5 postpone literal else 5 then ; immediate \ STATE-smart
a cr .
b cr . \ interpretation: B works like A
: foo a . b . ; cr foo \ compilation: B works like A
: execute-in-compile-state ] execute postpone [ ;
' a execute-in-compile-state cr .
' b execute-in-compile-state cr . \ ticking: B does not work like A
: a1 postpone a ;
: b1 postpone b ;
: a2 [ a1 ] ; cr .s a2 .
: b2 [ b1 ] ; cr .s b2 . \ POSTPONE: B does not work like A
Let's see how a number behaves:
5 cr . \ interpretation: 5 works like A, B
: foo1 5 . ; cr foo1 \ compilation: 5 works like A, B
' 5 execute-in-compile-state cr . \ 5 cannot be ticked, unlike A, B
: c1 postpone 5 ; \ 5 cannot be POSTPONEd in standard Forth
: c2 [ c1 ] ; cr .s c2 . \ in Gforth with recognizers 5 works like A
So a number behaves like a normal word in interpretation and
compilation, cannot be ticked (and therefore does not behave like
either class of words when ticked), and POSTPONEing it either does not
work or it works like a normal word and unlike a STATE-smart word.
By contrast, a word like S" or the parsing # you propose above cannot
be implemented as a normal word. You either need to implement them as
a STATE-smart word (then it fails in corner cases), or you add a
mechanism like Gforth's INTERPET/COMPILE: to your simple Forth system
in order to get it right. Is the resulting system simpler than one
with recognizers and without INTERPRET/COMPILE:? Probably not
(probably not significantly more complex, either; both features are
not that complicated to implement).
Another alternative is to have S" and [S"], and # and [#] etc. That's
simple to implement, but inconvenient. Or maybe make S" and #
immediate and require S" abc" SLITERAL and # 123 LITERAL in compiled
code. Even simpler, but also inconvenient.
I have an experimental implementation of a recognizer feature (but
deviating from the proposal) where, say, using 5 creates a
word like
5 constant 5
(not inserted in any wordlist), and in that implementation one can
even tick numbers, and ' 5 behaves like ' A above (naturally, given
the implementation). This implementation offers the maximum of
homogenity between numbers and words, but that comes at a cost in
implementation complexity, which is totally anti-Forth. The Forth
spirit (at least as advocated by many here) is to simplify the
implementation without regard to usability and interface complexity.
I am more for a balanced approach, and I think that the present
proposal has a better balance of implemenation complexity, usability,
and chances of being adopted.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-02 11:41 +0100 |
| Message-ID | <oe9niu$7ld$1@dont-email.me> |
| In reply to | #58478 |
On 5/2/2017 09:49, Andrew Haley wrote: > > Getting changes into long-established languages is hard. That is how > it should be. It is up to the proposers to present a convincing case > that a change is really needed, and justify it with the needs of > people writing applications. > > Better to take a step back, take a hard look at what is really > required, and come up with something that can be described more > easily, managed more easily, and is a reasonable solution in > proportion to the magnitude of the problem. > > Andrew. > This is much better; thank you. Since it's also quite involved, I may take some time to discuss the points you raise (and I'll also try & address Albert's responses too, since they seem pertinent). -- Alex
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-05-02 12:13 +0100 |
| Message-ID | <MPG.33727a50fde10045989713@news.virginmedia.com> |
| In reply to | #58484 |
In article <oe9niu$7ld$1@dont-email.me>, alex@rivadpm.com says... > > On 5/2/2017 09:49, Andrew Haley wrote: > > > > > Getting changes into long-established languages is hard. That is how > > it should be. It is up to the proposers to present a convincing case > > that a change is really needed, and justify it with the needs of > > people writing applications. > > > > Better to take a step back, take a hard look at what is really > > required, and come up with something that can be described more > > easily, managed more easily, and is a reasonable solution in > > proportion to the magnitude of the problem. > > > > Andrew. > > > > This is much better; thank you. Since it's also quite involved, I may > take some time to discuss the points you raise (and I'll also try & > address Albert's responses too, since they seem pertinent). Perhaps a survey of applications - who is writing what with what forth flavour and to what end - are standards important etc. would be of benefit. I see a lot of people writing their own forth here - but the only applications writing seems to be elsewhere and largely limited to legacy concepts. Perhaps if stephen and elizabeth could be a bit more forthcoming on the fields of work their clients request that may also help (without breaching commercial confidentiality of course - that can be tricky I know) Carts and horses and all that.... -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-05-02 09:42 -1000 |
| Message-ID | <ldadna3xtvOofJXEnZ2dnUU7-L_NnZ2d@supernews.com> |
| In reply to | #58486 |
On 5/2/17 1:13 AM, john wrote: > In article <oe9niu$7ld$1@dont-email.me>, alex@rivadpm.com says... >> >> On 5/2/2017 09:49, Andrew Haley wrote: >> >>> >>> Getting changes into long-established languages is hard. That is how >>> it should be. It is up to the proposers to present a convincing case >>> that a change is really needed, and justify it with the needs of >>> people writing applications. >>> >>> Better to take a step back, take a hard look at what is really >>> required, and come up with something that can be described more >>> easily, managed more easily, and is a reasonable solution in >>> proportion to the magnitude of the problem. >>> >>> Andrew. >>> >> >> This is much better; thank you. Since it's also quite involved, I may >> take some time to discuss the points you raise (and I'll also try & >> address Albert's responses too, since they seem pertinent). > > Perhaps a survey of applications - who is writing what with what forth flavour and > to what end - are standards important etc. would be of benefit. > > I see a lot of people writing their own forth here - but the only applications > writing seems to be elsewhere and largely limited to legacy concepts. > Perhaps if stephen and elizabeth could be a bit more forthcoming on the > fields of work their clients request that may also help (without breaching > commercial confidentiality of course - that can be tricky I know) > > Carts and horses and all that.... > FORTH, Inc. has always specialized in scientific/industrial applications, although in the early years we did a few business/IT programs. Generally speaking, these involve controlling some sort of apparatus and acquiring/processing numeric data. For a number of years most of our business has been centered around SwiftX, supporting a number of microcontrollers. A number of our customers have large networks of instruments, such as the GE multiplexers that are used to control much of the power grid in North America https://www.forth.com/synchronous-optical-networking/ We have recently published app notes, with source code, for: * ColdFire CFV1CORE and Altera FPGA * Arduino Uno and Diecimila boards * TI LaunchPad and similar boards, with Morse code demo See www.forth.com for downloads and details. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-02 14:13 +0000 |
| Message-ID | <2017May2.161352@mips.complang.tuwien.ac.at> |
| In reply to | #58478 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>My basic objection is that this proposal essntially turns the Forth
>interpreter inside out, with the dictionary search subservient to the
>recognizer loop.
Currently, we have a semi-hard-coded text interpreter, with dictionary
search and integer conversion hard-coded in, and hooks for extending
this in various places. IIRC Stephen Pelc boasts five (or was it
seven?) hooks in various stages of the text interpreter for various
optional features.
The proposal is to make the interpreter flexible and general. No need
to have special-purpose hooks, no need for hard-coded parts of the
text interpreter.
Is this inside out? Is the dictionary search now "subservient" to the
integer number or some other recognizer? I don't think so. The
dictionary search is still working as a recognizer side by side with
the integer recognizer and the other recognizers.
>Such an extraordinary overhaul of the language, the
>most dramatic since ANS 94, IMO requires extraordinary justification.
>And that justification must be pulled by the needs of application
>writers, not pushed by implementers.
First of all, in Forth we typically value implementation simplicity
enough that we don't need to search for applications to justify
simplifying implementations in a way that does not break application
programs. Is a text interpreter with a hard-coded dictionary search
and then a call to the recognizers simpler than one that just calls
the recognizers? No. Does it make it impossible to call the
dictinary search first? No.
Concerning application needs, I am sure each of the hooks in VFX came
from an application need; IIRC when Stephen Pelc showed the source
code of the VFX interpreter loop, there was at least one hook that was
called before the hard-coded dictionary search. So at least among the
VFX customers there is an application need to have some other
recognizer precede the dictionary search.
Another application need is the meta/cross-compiler application
discussed elsewhere in this thread: One way to implement this is to
have a meta-compiler dictionary search recognizer, meta-compiler
number recognizers, etc., and put them on the recognizer stack before
(or instead of) the ordinary dictinary search etc. Sure one can also
do it in other ways, but are they simpler?
>More specifically:
>
>If libraries use recognizers, the client code of those libraries may
>also need to use recognizers provided by the library. This is fine as
>long as only one library adds recognizers. But there is no proposal
>for a way to control conflicting recognizers, and none may be
>possible.
The proposal contains GET-RECOGNIZERS and SET-RECOGNIZERS to control
the presence and order of recognizers. If an application uses two
libraries, each of which adds a recognizer, and the recognizers
conflict, the application has several options: Order the recognizers
in a convenient way, and use non-conflicting literals for the later
recognizer (just like in classical Forth we use 0ADD instead of ADD if
we want to specify a hex number); or reorder the recognizers as
appropriate (similar to using BASE in classical Forth; not a practice
I would recommend); or define non-conflicting recognizers based on the
conflicting ones, and use those (e.g., #123. and 123e for doubles and
FP numbers in Forth2012).
>It could be argued that this is no worse than conflicting
>word names in libraries, but at least words can be renamed if they
>conflict. This isn't the case with recognizers, which define entire
>classes of names.
You can also define a recognizer based on the conflicting recognizer
that does not conflict. It's a little more work than renaming a word,
but, OTOH, I expect that we will hardly, if ever, have the need for
it.
>The recognizer stack is a large slab of global
>state, and managing it will not be an easy problem to solve.
What's currently being proposed is in exactly the same style as the
search order words GET-ORDER and SET-ORDER, and there have been few
complaints about that yet (I don't remember any from you).
I have some ideas for an alternative, and have expressed them to
Matthias Trute (I don't want to bikeshed it to death with a public
discussion), but he seems to prefer sticking with the
GET-ORDER-inspired interface, and he may well be right: If it's good
enough for the search order, it should certainly be good enough for
the recognizer order which changes much more rarely. And sticking
with the same style of interface reduces the mental load on the
programmers of the interface and on the people reading the proposal.
>The proposal allows recognizers to precede dictionary searches, so
>that even if a word would have been found it might not be executed
>because a recognizer got in there first. This will not help
>debugging; it is not a good thing.
Yes, you can shoot yourself in the foot in Forth. The programmer is
responsible. The proposal is very much in the Forth spirit by
providing that possibility.
On the practical side, you have been able to put something else before
the search order for a while in Gforth, and it has not resulted in
problems yet. By contrast, I have tripped across a number of nasty
issues over the years:
* "2," being interpreted as double, not as word (VFX and SwiftForth do
it to this day).
* "1000000" interpreted as hex number (startup BASE was HEX). BASE is
a much bigger bug magnet in my experience than anything I have seen
done with recognizers yet.
* "u" (actually a typo) interpreted as FP number thanks to a too-loose
FP number recognizer, although that sat behind the search order;
this recognizer was written by the system implementor, so that can
occur even without standardized recognizers.
>The proposal is too complex. It doesn't have the property of clarity
>and "just right" elegance that characterizes the Forth interpreter,
>and indeed good Forth in general.
Please be more concrete. What's too complex?
Is it a problem with the proposal text or with the proposal content?
Admittedly the proposal text had the "tl;dr" effect on me at first,
and maybe it could benefit from being condensed into just the basic
proposal without the surrounding discussions on alternatives etc. But
then there would be complaints that the discussion is too short and
should cover this and that. Whatever he does, there will always be
complaints. But if you want a different presentation, you can read
either my EuroForth 2016 paper or watch my talk:
https://www.complang.tuwien.ac.at/anton/euroforth/ef16/papers/ertl-recognizers.pdf
https://wiki.forth-ev.de/lib/exe/fetch.php/events:recognizers.mp4
>Examples of the use of recognizers serve only to reinforce my
>disquiet. For example, the "0x" example recognizer does this:
>
>: plit postpone literal ;
>
> ' noop \ interpret: do nothing
> ' plit \ compile as a literal
> :noname plit postpone plit ; \ postpone a literal
>dt-token: dt:0x ( n -- )
That's actually the dt-token for all single-cell literals.
>The multi-level POSTPONE took me a little while to understand. And
>it's totally unnecessary because no application will ever need to
>
> POSTPONE 0x25
Sure, you can ask the application programmer to write
0x25 POSTPONE literal
instead, and do that every time he wants to postpone a literal. If
you prefer to write it this way, that recognizer won't stop you. But
I prefer to actually write
POSTPONE 0x25
or
]] 0x25 [[
instead. What's more, I prefer writing
]] dup 0x25 + [[
instead of
]] dup [[ 0x25 ]] literal + [[
or
POSTPONE dup 0x25 POSTPONE literal POSTPONE +
But sure, if you prefer writing the latter, or hardly use POSTPONE,
you may not care for the postponing part of a recognizer. But there
are those of us who do care for that. Not everybody has the same
taste or needs: some hate locals, some hate BASE, and some hate if
others are able to POSTPONE literals.
>The above could be rewritten as
>
> ' noop \ interpret: do nothing
> :noname postpone literal ; \ compile as a literal
> ' abort \ WTF?
>dt-token: dt:0x ( n -- )
>
>This is shorter, much easier to understand, and doesn't get carried
>away with pointless features.
You think that
0x25 POSTPONE literal
is easier to understand than
POSTPONE 0x25
? I don't.
>More broadly, much of the discussion of recognizers reflects an
>obsession with syntax which is not in keeping with the spirit of
>Forth. Forth carefully eschews syntatctic minutiae and concentrates
>on semantics:
>
> THIS THAT OTHER
>
>does this then that the the other, and we know that's what it does.
>There's no superfluous punctuation. Literals are confined to simple
>numbers. This simplicity is a feature, not a bug. Where this general
>rule has been broken, for example as in TO, it has been a wart on the
>language.
TO has been implemented as a word, long before the issue of
standardizing recognizers has ever been discussed, so it's a red
herring.
A more relevant issue is S". This follows exactly your dogma of
having only the search order and "simple numbers" in the text
interpreter. Words like these have given us STATE-smart words (which
break in corner cases), arbitrary combinations of interpretation and
compilation semantics in Forth-94/2012, it's implementation in Gforth
(not particularly complex, but not a poster example of simplicity,
either, but in any case, it also works correctly in corner cases), and
it's implementation in VFX (which breaks in different corner cases
than the STATE-smart implementation. Is that really the right way to
go? No!
By contrast, the Forth-94 floating-point wordset has not followed your
dogma; instead, systems have added an extra recognizer for them
(traditionally using a system-specific hook). Problems: Except for
the too-loose FP recognizer above, none have come to my attention.
And in contrast to the discussions about how to implement S"
(STATE-smartness etc.) that have existed since at least Forth-83, and
flare up regularly here, I don't remember any controversies about the
implementation of the FP recognizer.
In the long term, S" and other words with arbitrary combinations of
interpretation and compilation semantics could be replaced by
recognizers providing the same functionality, and eventually eliminate
these words, and all the bugs, complexity and controversies they
entail.
>Better to take a step back, take a hard look at what is really
>required, and come up with something that can be described more
>easily, managed more easily, and is a reasonable solution in
>proportion to the magnitude of the problem.
Yes, we have done that, and the result is in this proposal.
- 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 12:32 -0500 |
| Message-ID | <QbidnWhx4s0BX5XEnZ2dnUU7-a3NnZ2d@supernews.com> |
| In reply to | #58510 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > This follows exactly your dogma > By contrast, the Forth-94 floating-point wordset has not followed your > dogma; What is the point of using language like this? Is it merely to piss me off, or is there some other purpose? But in any case it's wrong: I'm not making an argument from authority, so to complain about dogma is inappropriate. I responded at length to Alex because he asked what my objection to the recognizers proposal was, in the hope of having a reasonable and flame-free discussion. I still think that may happen. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-02 18:55 +0100 |
| Message-ID | <oeagvm$qq$2@dont-email.me> |
| In reply to | #58511 |
On 5/2/2017 18:32, Andrew Haley wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> This follows exactly your dogma > >> By contrast, the Forth-94 floating-point wordset has not followed your >> dogma; > > What is the point of using language like this? Is it merely to piss > me off, or is there some other purpose? But in any case it's wrong: > I'm not making an argument from authority, so to complain about dogma > is inappropriate. > > I responded at length to Alex because he asked what my objection to > the recognizers proposal was, in the hope of having a reasonable and > flame-free discussion. I still think that may happen. > > Andrew. > Is a dogmatist like a bigot? Asking for a friend. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-02 13:05 -0500 |
| Message-ID | <csudnVPPoNnNV5XEnZ2dnUU7-b2dnZ2d@supernews.com> |
| In reply to | #58514 |
Alex <alex@rivadpm.com> wrote: > > Is a dogmatist like a bigot? Asking for a friend. LOL! Probably. :-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-04 13:18 +0000 |
| Message-ID | <2017May4.151816@mips.complang.tuwien.ac.at> |
| In reply to | #58511 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> This follows exactly your dogma
>
>> By contrast, the Forth-94 floating-point wordset has not followed your
>> dogma;
>
>What is the point of using language like this? Is it merely to piss
>me off, or is there some other purpose? But in any case it's wrong:
>I'm not making an argument from authority, so to complain about dogma
>is inappropriate.
Oh, another Andrew Haley tactic for evading a proper discussion with
real arguments: As response to a 262-line posting containing a number
of technical arguments, misinterpret a word as an excuse to walk off
in a huff.
Here's the first sentence from <https://en.wikipedia.org/wiki/Dogma>:
|Dogma is an English term transliterated in the 17th century from Latin
|(Latin dogma) meaning "philosophical tenet", derived from the Greek
|'dogma' [...] meaning literally "that which one thinks is
|true" and 'dokein' (Greek dokeo) "to seem good."[1][2]
- 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-04 08:55 -0500 |
| Message-ID | <j4udnT2pQsxar5bEnZ2dnUU7-S_NnZ2d@supernews.com> |
| In reply to | #58651 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> This follows exactly your dogma >> >>> By contrast, the Forth-94 floating-point wordset has not followed your >>> dogma; >> >>What is the point of using language like this? Is it merely to piss >>me off, or is there some other purpose? But in any case it's wrong: >>I'm not making an argument from authority, so to complain about dogma >>is inappropriate. > > Oh, another Andrew Haley tactic for evading a proper discussion with > real arguments: As response to a 262-line posting containing a number > of technical arguments, misinterpret a word as an excuse to walk off > in a huff. You might not have noticed that over here we're having a perfectly civilized conversation about the proposal, and at least reaching some common understanding of each other's position, while not agreeing about everything. You interjected. I also note that you didn't respond to my question. I suspect that its purpose was no more than to get a rise out of me, and it worked. > Here's the first sentence from <https://en.wikipedia.org/wiki/Dogma>: > > |Dogma is an English term transliterated in the 17th century from Latin > |(Latin dogma) meaning "philosophical tenet", derived from the Greek > |'dogma' [...] meaning literally "that which one thinks is > |true" and 'dokein' (Greek dokeo) "to seem good."[1][2] And now *you* are playing at Humpty Dumpty: the use of the word dogma in this context is grossly insulting, and you intended it to be, and it is not likely to result in any useful response. I refer you to a sentence in the next paragraph: "More generally it is applied to some strong belief that the ones adhering to are not willing to rationally discuss." I suspect that the later definition is the one that most readers would assume. Given that the rest of us are rationally discussing the subject, I believe that such an accusation is unreasonable. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-02 11:36 -0700 |
| Message-ID | <8ed1194f-6f21-490a-8cb1-90d5d530c690@googlegroups.com> |
| In reply to | #58510 |
> > What's currently being proposed is in exactly the same style as the > search order words GET-ORDER and SET-ORDER, and there have been few > complaints about that yet (I don't remember any from you). > > I have some ideas for an alternative, and have expressed them to > Matthias Trute (I don't want to bikeshed it to death with a public > discussion), but he seems to prefer sticking with the > GET-ORDER-inspired interface, and he may well be right: If it's good > enough for the search order, it should certainly be good enough for > the recognizer order which changes much more rarely. And sticking > with the same style of interface reduces the mental load on the > programmers of the interface and on the people reading the proposal. That indeed is the reason for this interface. Sure are different ways to manage the recognizers possible, but are they any better or are they simply different? Re-using existing and well understood patterns is something I consider a good thing (see REC-STACK that works like WORDLIST). On the other hand I think that DT-TOKEN(:) deserves a name and not only a number, Jenny Brien seems to see it this way too. Matthias
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2017-05-03 06:39 -0700 |
| Message-ID | <cea93723-a604-457b-b2e4-6024cd2319da@googlegroups.com> |
| In reply to | #58525 |
On Tuesday, 2 May 2017 19:36:56 UTC+1, Matthias Trute wrote: > > > > What's currently being proposed is in exactly the same style as the > > search order words GET-ORDER and SET-ORDER, and there have been few > > complaints about that yet (I don't remember any from you). > > > > I have some ideas for an alternative, and have expressed them to > > Matthias Trute (I don't want to bikeshed it to death with a public > > discussion), but he seems to prefer sticking with the > > GET-ORDER-inspired interface, and he may well be right: If it's good > > enough for the search order, it should certainly be good enough for > > the recognizer order which changes much more rarely. And sticking > > with the same style of interface reduces the mental load on the > > programmers of the interface and on the people reading the proposal. > > That indeed is the reason for this interface. Sure are different > ways to manage the recognizers possible, but are they any better or > are they simply different? Re-using existing and well understood > patterns is something I consider a good thing (see REC-STACK that > works like WORDLIST). On the other hand I think that DT-TOKEN(:) > deserves a name and not only a number, Jenny Brien seems to see it > this way too. > > Matthias True, I don't see much need for anonymous DT-Tokens. Anonymous wordlists, otoh, are very handy. My point was simply that where it is useful for an anonymous object to by named as a constant, it is also useful (for the programmer, not necessarily the program) to be able to derive the name of the constant from the object-id, in the same way that most systems can display the name of a definition given its xt.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-05-08 10:22 -0700 |
| Message-ID | <297bdc00-d330-4f55-805c-a4d6b6df84bc@googlegroups.com> |
| In reply to | #58510 |
On Tuesday, May 2, 2017 at 12:10:05 PM UTC-5, Anton Ertl wrote: ... > > The proposal is to make the interpreter flexible and general. No need > to have special-purpose hooks, no need for hard-coded parts of the > text interpreter. > ... If the basis of the recognizer proposal is to provide a standardized way of generalizing and extending the interpreter, that's fine. But, to base it on needing to interpret numbers seems to me like a weak rationale. In decades of Forth programming, for different types of applications, I've not had the need to consider using this type of "convenience". The following guidelines, particularly for library code, should help you avoid the need for such hacks: 1) Control your BASE. base @ \ Set your own base, e.g. DECIMAL \ Your code \ restore the base base ! 2) Use named constants when they are meaningful. It is suspect, but perhaps not entirely unavoidable, when numbers which are better represented in different bases appear in a single definition. Named constants make this use case much less probable. HEX \ GPIB command messages : 19 constant CMD_SPD \ serial poll disable 20 constant CMD_LAD \ value to be or'd to obtain listen address 3F constant CMD_UNL \ unlisten 40 constant CMD_TAD \ value to be or'd to obtain talk address : DECIMAL 3) Discontinue the awful use of the decimal point or comma or other notation for writing a double length integer, even if the Forth interpreter supports it. Use a portable parsing word, if necessary. I believe these practices will eliminate 90% of the motivation for using recognizers. The convenience for number interpretation is the not the reason to include recognizers in Forth. There may be other good reasons. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-08 11:52 -0700 |
| Message-ID | <7e9f5833-9917-46c6-a049-1ec742b3919e@googlegroups.com> |
| In reply to | #58851 |
> If the basis of the recognizer proposal is to provide a standardized way of > generalizing and extending the interpreter, that's fine. But, to base it on > needing to interpret numbers seems to me like a weak rationale. In decades of > Forth programming, for different types of applications, I've not had the need > to consider using this type of "convenience". The following guidelines, > particularly for library code, should help you avoid the need for such hacks: Recognizer are initially made for numbers, true. > > 1) Control your BASE. I prefer the number prefixes like $ for such tasks. BASE is great, but no longer part of the daily coding. > 3) Discontinue the awful use of the decimal point or comma or other notation > for writing a double length integer, even if the Forth interpreter supports > it. Use a portable parsing word, if necessary. I'd recommend the rec:dnum from http://theforth.net/package/recognizers/current-view/rec-num.4th > > I believe these practices will eliminate 90% of the motivation for using > recognizers. You are probably right for the "number only" point of view. > The convenience for number interpretation is the not the reason to include > recognizers in Forth. There may be other good reasons. IMHO the wide range of already existing recognizers tell this story pretty good. Numbers were only the midwifes of recognizers. Matthias
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-05-09 02:45 -0700 |
| Message-ID | <52f1cf52-4b5d-49b7-97f6-8c0fe7a3fad6@googlegroups.com> |
| In reply to | #58857 |
On Monday, May 8, 2017 at 1:52:18 PM UTC-5, Matthias Trute wrote: > > If the basis of the recognizer proposal is to provide a standardized way of > > generalizing and extending the interpreter, that's fine. ... > > The convenience for number interpretation is the not the reason to include > > recognizers in Forth. There may be other good reasons. > > IMHO the wide range of already existing recognizers tell this > story pretty good. Numbers were only the midwifes of recognizers. > Forth, on the desktop, is a versatile language for exploratory programming because of its extensibility. The ability to extend the interpreter enhances that mode of use, I think. It would be helpful to me to see examples, or even speculative examples, of use of recognizers for other than number or string constant parsing. Krishna
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-09 03:47 -0700 |
| Message-ID | <cc33aa0a-ffff-4cbe-9fe8-d098db6ea58b@googlegroups.com> |
| In reply to | #58879 |
Am Dienstag, 9. Mai 2017 11:45:40 UTC+2 schrieb krishna...@ccreweb.org: > On Monday, May 8, 2017 at 1:52:18 PM UTC-5, Matthias Trute wrote: > > > If the basis of the recognizer proposal is to provide a standardized way of > > > generalizing and extending the interpreter, that's fine. ... > > > The convenience for number interpretation is the not the reason to include > > > recognizers in Forth. There may be other good reasons. > > > > IMHO the wide range of already existing recognizers tell this > > story pretty good. Numbers were only the midwifes of recognizers. > > > > Forth, on the desktop, is a versatile language for exploratory programming because of its extensibility. The ability to extend the interpreter enhances that mode of use, I think. It would be helpful to me to see examples, or even speculative examples, of use of recognizers for other than number or string constant parsing. > > Krishna Although it does not really answer your question: Already in the 90s we could use remote service links to industrial controllers (and predecessors of smart transmitters) via modem. You could enter f.ex. Tnnnn.nn for temperatures, P.. for pressure, F.. for flow, K.. Q.. I.. D.. for controller parameters etc. CM entered the command shell for modem control and upload of diagnostic info. No need for recognizer stacks in the device.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-09 12:52 +0100 |
| Message-ID | <oesaba$s54$1@dont-email.me> |
| In reply to | #58879 |
On 5/9/2017 10:45, krishna.myneni@ccreweb.org wrote:
> On Monday, May 8, 2017 at 1:52:18 PM UTC-5, Matthias Trute wrote:
>>> If the basis of the recognizer proposal is to provide a standardized way of
>>> generalizing and extending the interpreter, that's fine. ...
>>> The convenience for number interpretation is the not the reason to include
>>> recognizers in Forth. There may be other good reasons.
>>
>> IMHO the wide range of already existing recognizers tell this
>> story pretty good. Numbers were only the midwifes of recognizers.
>>
>
> Forth, on the desktop, is a versatile language for exploratory programming because of its extensibility. The ability to extend the interpreter enhances that mode of use, I think. It would be helpful to me to see examples, or even speculative examples, of use of recognizers for other than number or string constant parsing.
>
> Krishna
>
>
>
>
Locals support demands that the locals words are found first in any
search; even before the standard Forth dictionaries.
Rather than insert, for example, a LOCALS vocabulary into the first slot
in the search order and having a forced search order like LOCALS FORTH
rather than just FORTH, use a recognizer that precedes all the others
like this;
wordlist constant locals
:noname -13 throw ;
:noname ( address the local ) ... ;
:noname -13 throw ;
dt-token value dt:local
: rec:local ( addr u -- xt flag dt:local | dt:null )
locals search-wordlist
?dup if dt:local else dt:null then ;
get-recognizers ' rec:local swap 1+ set-recognizers
There's still a LOCALS vocabulary or wordlist or list of some sort
(cleared out at ; semi-colon) but there's no locals vocabulary in the
search order. This simplifies the implementation since the optional
Locals word set is independent of the optional Search-Order word set,
and vice versa.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-09 10:38 -0700 |
| Message-ID | <21ccafac-d23d-4473-b653-8d0e23a1fe7d@googlegroups.com> |
| In reply to | #58884 |
> Locals support demands that the locals words are found first in any > search; even before the standard Forth dictionaries. > > Rather than insert, for example, a LOCALS vocabulary into the first slot > in the search order and having a forced search order like LOCALS FORTH > rather than just FORTH, use a recognizer that precedes all the others > like this; Every LOCAL| may create it's own anonymous wordlist, that is used. The ; (cooperates anyway for locals) can make this wordlist unavailable. Inspiring approach, wordlists are cheap. Matthias
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web