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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-05 07:31 -0700 |
| Message-ID | <0a444032-5bec-4638-b301-36b6e4f4e192@googlegroups.com> |
| In reply to | #58698 |
Am Freitag, 5. Mai 2017 16:17:22 UTC+2 schrieb Andrew Haley: > Alex <alex@rivadpm.com> wrote: > > On 5/4/2017 18:21, Andrew Haley wrote: > >> Indeed it does. So let's see if it gets adopted. It is a new > >> feature, which has far-reaching consequences, and shouldn't be adopted > >> without widespread real-world testing. > > > > Actually, I reckon it has no significant consequences; since a system > > with recognizers for names, numbers, doubles, strings, floats etc is > > indistinguishable in operation (for all of interpret, compile, postpone > > and execute) as any other system without it. > > Well, yeah: as long as no application uses recognizers, they will have > no consequences to the user, but they will constrain the implementer > to write the text interpreter in a particular way. (Or at least, to > provide a text interpreter written in that way.) But in that case, if > no application is using the extension, there is no need to standardize > them. > > > WF32 with recognizers now passes the extended Hayes tester that Gerry > > Jackson put together (excepting floats; I still have to write it). > > > > I'm blowed if I can see what is far reaching about that. > > The problem occurs if people actually use recognizers to write > libraries, as I have pointed out. And I've explained why I think > there will be problems with libraries which use recognizers as part of > their interface. If anything, such libraries will be less portable > than now, and certainly (if libraries put their recognizers before the > dictionary search) they will break programs. > > But I have said this same thing five different ways already, so I > could be accused of using vain repetition. > > Andrew. For desktop systems, open hooks a hacker's delight. Create a recognizer with buffer overflow and bingo. ;-) For embedded systems I can only think of linking with pre-compiled libraries provided e.g. by the board OEM or C/Java libraries. Why would one use libraries in Forth source code, let alone with recognizers?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-05 10:27 -0500 |
| Message-ID | <ieqdnVpIT-1qBJHEnZ2dnUU7-cGdnZ2d@supernews.com> |
| In reply to | #58699 |
minforth@arcor.de wrote: > For embedded systems I can only think of linking with pre-compiled > libraries provided e.g. by the board OEM or C/Java libraries. Why > would one use libraries in Forth source code, let alone with > recognizers? Forth libraries are source code. There is no other mechanism, and no need for one. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-05 15:25 +0000 |
| Message-ID | <2017May5.172528@mips.complang.tuwien.ac.at> |
| In reply to | #58699 |
minforth@arcor.de writes:
>For desktop systems, open hooks a hacker's delight. Create a recognizer with buffer overflow and bingo. ;-)
Hacker's Delight is a book on bit manipulation and integer arithmetic.
If you want to say that recognizers introduce vulnerabilities that
would not be there otherwise, let's look at it in more detail:
First, your attack scenario is unclear (pretty common in fearmongering
with computer security).
If the attacker can create a recognizer with a buffer overflow and put
it in the recognizer stack, he already has full access to the system.
No need to introduce a buffer overflow to get there.
If you mean that a (trusted) programmer writes a recognizer that has a
buffer overflow, and after loading the recognizer, untrusted people
are let loose on the system, again these people can already do
everything, no need to exploit the buffer overflow to get there.
If you mean that we have a carefully hardened system (sealed
dictionary with only restricted words available), and a recognizer
with a buffer overflow vulnerability in the recognizer stack, and you
let untrusted users loose on the system, then yes, the attacker might
be able to do something he otherwise may not be able to do. However:
1) If the same care at hardening is applied to the recognizer as to
the words available to the attacker, it should not be any more
vulnerable than these words.
2) If you don't use recognizers, what do you use instead? If you use
a parsing word, as suggested as an alternative to recognizers, that
word is just as likely to contain a buffer overflow.
3) At least the basic recognizer functionality is unlikely to lead to
a vulnerability, because it only reads a string that is passed in
c-addr u form. Of course, if the recognizer fills a buffer elsewhere,
it may contain a buffer overflow vulnerability, but the same is true
of any word that fills a buffer.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-05 12:21 -0700 |
| Message-ID | <8101116d-5d92-4b0b-a390-b2e13a3a591f@googlegroups.com> |
| In reply to | #58708 |
Am Freitag, 5. Mai 2017 18:19:56 UTC+2 schrieb Anton Ertl: > minforth@arcor.de writes: > >For desktop systems, open hooks a hacker's delight. Create a recognizer with buffer overflow and bingo. ;-) > > Hacker's Delight is a book on bit manipulation and integer arithmetic. > > If you want to say that recognizers introduce vulnerabilities that > would not be there otherwise, let's look at it in more detail: > > First, your attack scenario is unclear (pretty common in fearmongering > with computer security). > > If the attacker can create a recognizer with a buffer overflow and put > it in the recognizer stack, he already has full access to the system. > No need to introduce a buffer overflow to get there. > > If you mean that a (trusted) programmer writes a recognizer that has a > buffer overflow, and after loading the recognizer, untrusted people > are let loose on the system, again these people can already do > everything, no need to exploit the buffer overflow to get there. > > If you mean that we have a carefully hardened system (sealed > dictionary with only restricted words available), and a recognizer > with a buffer overflow vulnerability in the recognizer stack, and you > let untrusted users loose on the system, then yes, the attacker might > be able to do something he otherwise may not be able to do. However: > > 1) If the same care at hardening is applied to the recognizer as to > the words available to the attacker, it should not be any more > vulnerable than these words. > > 2) If you don't use recognizers, what do you use instead? If you use > a parsing word, as suggested as an alternative to recognizers, that > word is just as likely to contain a buffer overflow. > > 3) At least the basic recognizer functionality is unlikely to lead to > a vulnerability, because it only reads a string that is passed in > c-addr u form. Of course, if the recognizer fills a buffer elsewhere, > it may contain a buffer overflow vulnerability, but the same is true > of any word that fills a buffer. > > - 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/ Didn't you recognize my smiley without recognizer? ;-)) No, I don't believe someone would be malevolent enough to tinker with a Forth system, no profit there, unless it controls a telling machine. IMO if the recognizer stack will be unwound within CATCH too, it's okay.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-06 16:37 +0000 |
| Message-ID | <2017May6.183733@mips.complang.tuwien.ac.at> |
| In reply to | #58712 |
minforth@arcor.de writes:
>Am Freitag, 5. Mai 2017 18:19:56 UTC+2 schrieb Anton Ertl:
>No, I don't believe someone would be malevolent enough to tinker with a Forth system, no profit there, unless it controls a telling machine.
From one extreme to the other. If your system is vulnerable, and
there are a lot of machines with it, it's already attractive for an
attacker to take it over just to be able to use the machine for a
distributed denial-of-service attack. And even PLCs that have no
direct internet connection have been targeted by attackers (Stuxnet).
>IMO if the recognizer stack will be unwound within CATCH too, it's okay.
That's not a security guarantee; in fact, I don't see how it increases
security at all.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-06 13:18 -0700 |
| Message-ID | <bf1336e1-bc4b-4e6d-be03-fecbc21ef71d@googlegroups.com> |
| In reply to | #58740 |
Am Samstag, 6. Mai 2017 18:49:50 UTC+2 schrieb Anton Ertl: > minforth@arcor.de writes: > >Am Freitag, 5. Mai 2017 18:19:56 UTC+2 schrieb Anton Ertl: > If your system is vulnerable, and > there are a lot of machines with it, it's already attractive for an > attacker to take it over just to be able to use the machine for a > distributed denial-of-service attack. And even PLCs that have no > direct internet connection have been targeted by attackers (Stuxnet). It's the other way round: why compromise a stable system by offering hooks to manipulate inner functions? Stuxnet is actually a good example. It added its own functions to the PLC's program flow to gain control. Recognizers are adding their own functions to Forth's interpreter loop. > >IMO if the recognizer stack will be unwound within CATCH too, it's okay. > > That's not a security guarantee; in fact, I don't see how it increases > security at all. Who dreamt of guarantees? But say a poorly written recognizer throws an exception, it would better to get rid of it altogether, and fall back to stable default behaviour. The exception frame is used to reset other stack pointers anyhow, so one stack pointer more in the frame is no big deal. That would solve the concern of recognizers in libraries mentioned by someone else too.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-05 20:32 +0100 |
| Message-ID | <oeijqv$er$1@dont-email.me> |
| In reply to | #58698 |
On 5/5/2017 15:17, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: >> On 5/4/2017 18:21, Andrew Haley wrote: >>> Indeed it does. So let's see if it gets adopted. It is a new >>> feature, which has far-reaching consequences, and shouldn't be adopted >>> without widespread real-world testing. >> >> Actually, I reckon it has no significant consequences; since a system >> with recognizers for names, numbers, doubles, strings, floats etc is >> indistinguishable in operation (for all of interpret, compile, postpone >> and execute) as any other system without it. > > Well, yeah: as long as no application uses recognizers, they will have > no consequences to the user, but they will constrain the implementer > to write the text interpreter in a particular way. (Or at least, to > provide a text interpreter written in that way.) That's a very weak argument. Most of Forth is like that. > But in that case, if > no application is using the extension, there is no need to standardize > them. That is not the point; and you know it. > >> WF32 with recognizers now passes the extended Hayes tester that Gerry >> Jackson put together (excepting floats; I still have to write it). >> >> I'm blowed if I can see what is far reaching about that. > > The problem occurs if people actually use recognizers to write > libraries, as I have pointed out. And I've explained why I think > there will be problems with libraries which use recognizers as part of > their interface. If anything, such libraries will be less portable > than now, and certainly (if libraries put their recognizers before the > dictionary search) they will break programs. Why would they do that? > > But I have said this same thing five different ways already, so I > could be accused of using vain repetition. I think we're going to have to disagree. That might save another round. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-06 01:06 +0000 |
| Message-ID | <oej7j8$j6c$2@dont-email.me> |
| In reply to | #58677 |
Am Thu, 04 May 2017 12:21:21 -0500 schrieb Andrew Haley: >> 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). The >> objections are not based on experience with the implementations, but on >> something else. > > Indeed. And I have spent time and effort trying to explain to you why > that is. He who has ears to hear, let him hear. But your objection is "people will be able to shoot into their foot if they are not careful"! Yes, indeed. I don't see that as a problem. People can extend Forth in surprising ways. The actual experience with recognizers is that they work pretty well, definitely better than the older solutions: We have shoot-in-your-foot solutions like parsing immediate state-smart words, which are definitely more troublesome than a recognizer doing the same thing. The other thing is that these dangerous capabilities have been there for decades. Just not in a standard way, but by system-specific hooks, or with standard tools that are considered more dangerous, like state-smart parsing words. -- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-07 03:54 -0500 |
| Message-ID | <BdKdnezS8sdOfZPEnZ2dnUU7-bfNnZ2d@supernews.com> |
| In reply to | #58722 |
Bernd Paysan <bernd@net2o.de> wrote: > Am Thu, 04 May 2017 12:21:21 -0500 schrieb Andrew Haley: > >>> 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). The >>> objections are not based on experience with the implementations, but on >>> something else. >> >> Indeed. And I have spent time and effort trying to explain to you why >> that is. He who has ears to hear, let him hear. > > 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. > Yes, indeed. I don't see that as a problem. People can extend > Forth in surprising ways. > > The actual experience with recognizers is that they work pretty > well, definitely better than the older solutions: We have > shoot-in-your-foot solutions like parsing immediate state-smart > words, which are definitely more troublesome than a recognizer doing > the same thing. I agree with that, but you know my answer already: get rid of STATE. Of course I would never seriously propose that because it breaks too much code. > The other thing is that these dangerous capabilities have been there > for decades. Just not in a standard way, but by system-specific > hooks, or with standard tools that are considered more dangerous, > like state-smart parsing words. I agree, but that's like demanding that someone choose between anthrax and leprosy. The question is: what really requires those state-smart parsing words? Is there no better way to do it? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-07 13:46 +0200 |
| Message-ID | <oen1eb$p5u$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #58758 |
In article <BdKdnezS8sdOfZPEnZ2dnUU7-bfNnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: <SNIP> >I agree, but that's like demanding that someone choose between anthrax >and leprosy. The question is: what really requires those state-smart >parsing words? Is there no better way to do it? No. Despite rumours to the contrary, if you want to have numbers in your system, you'll have to parse them. Also you have to be smart about them because sometimes they must be compiled and sometimes you can just leave them on the stack. > >Andrew. -- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-07 07:59 -0500 |
| Message-ID | <ns6dnanuUdq7h5LEnZ2dnUU7-bednZ2d@supernews.com> |
| In reply to | #58767 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > In article <BdKdnezS8sdOfZPEnZ2dnUU7-bfNnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > <SNIP> >>I agree, but that's like demanding that someone choose between anthrax >>and leprosy. The question is: what really requires those state-smart >>parsing words? Is there no better way to do it? > > No. Despite rumours to the contrary, if you want to have numbers > in your system, you'll have to parse them. Also you have to be > smart about them because sometimes they must be compiled and > sometimes you can just leave them on the stack. I don't understand the relevance of that reply to my point. Hint: numbers are not state-smart. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2017-05-07 11:31 -0700 |
| Message-ID | <3d960072-d73d-41ea-b9dd-7abff0d55bdf@googlegroups.com> |
| In reply to | #58769 |
Andrew Haley wrote:
> Hint: numbers are not state-smart.
Well they are compiled or left on the stack depending on STATE, and you
can't just COMPILE, them; you need a different storing word for each literal
type you want to recognize. You also need a way to parse the pattern and
put the literal on whatever stack you chose, but that is common to however you
implement literal types. - recognizers, STATE-smart parsing words, or extending
the text interpreter in some other way.
You seem to be under the impression that the Recognizer proposal also requires an explicit
POSTPONE method for each, but that is not necessary. All literal types can share the same
DT-TOKEN is we assume that the recogniser, on success, does the 'check and stack' that is
needed for interpretation, and then leaves the xt of the storing action on top of the stack
' DROP
' EXECUTE
: POST-LIT DUP >R EXECUTE R> COMPILE, ;
DT-TOKEN: DT-LITERAL
Likewise, the generic tokens for xts:
' EXECUTE
' COMPILE,
: POST-XT POSTPONE LITERAL ['] COMPILE, COMPILE, ;
DT-TOKEN: DT-XT
' EXECUTE
' EXECUTE
' COMPILE, DT-TOKEN: DT-IMMEDIATE
And for literal/action pairs:
:NONAME ( xn lit xt -- ? ) NIP EXECUTE ;
: COMP-LITXT (xn lit xt -- ) >R EXECUTE R> COMPILE, ;
:POST-LITXT (xn lit xt -- ) >R POST-LIT R> POST-XT ;
DT-TOKEN: DT-LITXT
And for the few dual words where interpret and compile actions differ:
:NONAME ( xn lit compxt intxt -- ? ) NIP NIP EXECUTE ;
:NONAME ( xn lit compxt intxt -- ) DROP COMP-LITXT ;
:NONAME ( xn lit compxt intxt -- ) DROP POST-LITXT ;
DT-TOKEN: DT-DUAL
<
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-07 20:22 +0100 |
| Message-ID | <oens01$r6o$1@dont-email.me> |
| In reply to | #58783 |
On 5/7/2017 19:31, JennyB wrote: > > Likewise, the generic tokens for xts: > > ' EXECUTE > ' COMPILE, > : POST-XT POSTPONE LITERAL ['] COMPILE, COMPILE, ; > DT-TOKEN: DT-XT > > ' EXECUTE > ' EXECUTE > ' COMPILE, DT-TOKEN: DT-IMMEDIATE Which emphasises another point that is troubling me; that for some recognizers, it may not be possible to standardize. Here is one that I think works for everyone (assuming we standardize on the name DT:NUM for this) that supports single cell numbers; : plit postpone literal ; ' noop ' plit :noname plit postpone plit ; dt-token value dt:num ( n -- ) But then; you've chosen to recognize XTs (separately as IMMEDIATE and non-IMMEDIATE), and I've chosen to recognize NTs (name tokens). :noname name>interpret execute ; :noname name>compile execute ; :noname name>compile swap plit compile, ; dt-token value dt:nt ( nt -- ) Hmmm. The question becomes; what set would be required to support 99% of cases? DT:NUM DT:DNUM DT:XT DT:NT DT:FLOAT (all from Matthias' proposal). Why both DT:XT and DT:NT? And is DT:XT enough, or do we need DT:IMMEDIATE as well? (As to the names, I dislike the use of colon in the name, and I notice you use a dash.) -- Alex
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2017-05-08 04:17 -0700 |
| Message-ID | <8f56a535-9104-46e5-80d1-dccdcbc93900@googlegroups.com> |
| In reply to | #58785 |
On Sunday, 7 May 2017 20:22:47 UTC+1, Alex wrote: > Which emphasises another point that is troubling me; that for some > recognizers, it may not be possible to standardize. To some degree it doesn't matter. Dt-tokens are meant to be used immediately not passed around. > > Hmmm. The question becomes; what set would be required to support 99% of > cases? DT:NUM DT:DNUM DT:XT DT:NT DT:FLOAT (all from Matthias' proposal). It's a pretty short list. Most other things that you might want to recognize (dates for example) reduce to one of these. > > Why both DT:XT and DT:NT? And is DT:XT enough, or do we need > DT:IMMEDIATE as well? I don't see much use for DT:NT in the 99%, because we seem to agree that STATE-Smart stuff should be not be handled by defining new parsing words. Curently the only Standard way to get an nt is thorough TRAVERSE-WORDLIST, and since both FIND and SEARCH-WORDLIST return an Immediate flag I think the combination of DT:XT and DT:IMMEDIATE is a better model. > > (As to the names, I dislike the use of colon in the name, and I notice > you use a dash.) I've no objection to the colon, but its easy enough to rename them. DT:XT CONSTANT ( or VALUE) DT-XT > > -- > Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-08 15:30 +0000 |
| Message-ID | <2017May8.173047@mips.complang.tuwien.ac.at> |
| In reply to | #58820 |
JennyB <jennybrien@googlemail.com> writes:
>I don't see much use for DT:NT in the 99%, because we seem to agree that ST=
>ATE-Smart stuff should be not be handled by defining new parsing words.
You lost me here.
>Cur=
>ently the only Standard way to get an nt is thorough TRAVERSE-WORDLIST,
It may be time to add FIND-NAME ( c-addr u -- nt|0 ).
> and=
> since both FIND and SEARCH-WORDLIST return an Immediate flag I think the c=
>ombination of DT:XT and DT:IMMEDIATE is a better model.=20
Caveats:
FIND takes a counted string and is therefore inconvenient to use in a
recognizer.
The xt returned by FIND can return a different xts depending on STATE;
what you get out is an xt that makes only sense for the interpretation
action *xor* the compilation action. For a full-blown FIND-based word
recognizer you have to call FIND once in interpret state, and once in
compile state.
SEARCH-WORDLIST searches only a wordlist and the xt it returns may
represent just the interpretation semantics (which may be undefined).
So SEARCH-WORDLIST is not fit for use in a text interpreter.
A FIND-based recognizer that works around these caveats would look
somewhat like this
: int-error -14 throw ; \ interpreting a compile-only word
:noname ( ... int-xt comp-xt comp-xt2 -- ... ) 2drop execute ;
:noname ( ... int-xt comp-xt comp-xt2 -- ... ) rot drop execute ;
:noname ( ... int-xt comp-xt comp-xt2 -- ... ) POSTPONE 2literal drop ;
dt-token: dt:find
: rec:find ( c-addr u -- int-xt comp-xt comp-xt2 dt:find | dt:null )
... convert to counted string ... ( c-addr1 )
state @ >r dup POSTPONE [ find 0= if
drop ['] int-error then
] find case ( int-xt comp-xt n )
0 of 2drop dt:null endof
1 of ['] execute dt:find endof
-1 of ['] compile, dt:find endof
endcase ;
For comparison, here's the same using FIND-NAME:
:noname ( nt -- ) name>interpret execute ; \ interpret
:noname ( nt -- ) name>compile execute ; \ compile
:noname ( nt -- ) postpone literal ; \ postpone
dt-token: dt:name
: rec:name ( addr len -- nt DT:NAME | DT:NULL )
find-name ?dup if dt:name else dt:null then ;
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-08 12:00 -0700 |
| Message-ID | <89b4297e-7187-4063-b43d-57b2b04384ab@googlegroups.com> |
| In reply to | #58820 |
> > I don't see much use for DT:NT in the 99%, The DT:NT is listed to illustrate that even execution tokens can be replaced with something else within a running system. At least name tokens are already part of the Forth 2012. Whether DT:IMMEDIATE is necessary, is a not a technical decision. The DT:XT simply follows FIND and SEARCH-WORDLIST that return the XT and the immedate flag. I see very little reason for a separate DT:IMMEDIATE. Matthias
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-08 13:50 +0000 |
| Message-ID | <2017May8.155007@mips.complang.tuwien.ac.at> |
| In reply to | #58783 |
JennyB <jennybrien@googlemail.com> writes:
>Andrew Haley wrote:
>
>> Hint: numbers are not state-smart.
>
>Well they are compiled or left on the stack depending on STATE
That does not make them STATE-smart.
: 5 5 ;
is not state-smart, and behaves exactly like a number in all cases
where numbers don't produce errors.
>and you
>can't just COMPILE, them; you need a different storing word for each literal
>type you want to recognize.
That does not make them STATE-smart, either. On the contrary, you can
COMPILE, the xt of STATE-smart words (it's just that the result
sucks).
>Likewise, the generic tokens for xts:
>
> ' EXECUTE
> ' COMPILE,
> : POST-XT POSTPONE LITERAL ['] COMPILE, COMPILE, ;
> DT-TOKEN: DT-XT
>
> ' EXECUTE
> ' EXECUTE
> ' COMPILE, DT-TOKEN: DT-IMMEDIATE
...
>And for the few dual words where interpret and compile actions differ:
>
> :NONAME ( xn lit compxt intxt -- ? ) NIP NIP EXECUTE ;
> :NONAME ( xn lit compxt intxt -- ) DROP COMP-LITXT ;
> :NONAME ( xn lit compxt intxt -- ) DROP POST-LITXT ;
> DT-TOKEN: DT-DUAL
These can all be subsumed by
:noname name>interpret execute ;
:noname name>compile execute ;
:noname name>compile swap plit compile, ;
dt-token value dt:nt ( nt -- )
>And for literal/action pairs:
>
> :NONAME ( xn lit xt -- ? ) NIP EXECUTE ;
> : COMP-LITXT (xn lit xt -- ) >R EXECUTE R> COMPILE, ;
> :POST-LITXT (xn lit xt -- ) >R POST-LIT R> POST-XT ;
> DT-TOKEN: DT-LITXT
What do you have in mind here? A TO-recognizer?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2017-05-08 09:51 -0700 |
| Message-ID | <f8b6ff5b-11c5-4c05-bf5c-5e8ba2733499@googlegroups.com> |
| In reply to | #58832 |
On Monday, 8 May 2017 14:58:50 UTC+1, Anton Ertl wrote: > JennyB <jennybrien@googlemail.com> writes: > >Andrew Haley wrote: > > > >> Hint: numbers are not state-smart. > > > >Well they are compiled or left on the stack depending on STATE > > That does not make them STATE-smart. > > : 5 5 ; > > is not state-smart, and behaves exactly like a number in all cases > where numbers don't produce errors. > > >and you > >can't just COMPILE, them; you need a different storing word for each literal > >type you want to recognize. > > That does not make them STATE-smart, either. On the contrary, you can > COMPILE, the xt of STATE-smart words (it's just that the result > sucks). You're right. What I was thinking was that normally if you want to use a number type that isn't built in to the interpreter then you need a STATE-Smart parsing prefix. The only currently Standard way to do that is with STATE @ IF. Using recognizers avoids the problems that come with that. If we have recognizers, is it possible to deprecate the STATE @ IF construction entirely, or are there some situations where a dual-action definition is still preferable? > > >Likewise, the generic tokens for xts: > > > > ' EXECUTE > > ' COMPILE, > > : POST-XT POSTPONE LITERAL ['] COMPILE, COMPILE, ; > > DT-TOKEN: DT-XT > > > > ' EXECUTE > > ' EXECUTE > > ' COMPILE, DT-TOKEN: DT-IMMEDIATE > ... > >And for the few dual words where interpret and compile actions differ: > > > > :NONAME ( xn lit compxt intxt -- ? ) NIP NIP EXECUTE ; > > :NONAME ( xn lit compxt intxt -- ) DROP COMP-LITXT ; > > :NONAME ( xn lit compxt intxt -- ) DROP POST-LITXT ; > > DT-TOKEN: DT-DUAL > > These can all be subsumed by > > :noname name>interpret execute ; > :noname name>compile execute ; > :noname name>compile swap plit compile, ; > dt-token value dt:nt ( nt -- ) That assumes some sort of wordllist search that has returned an nt. And there is currently no Standard way for name>compile to return anything but int-xt ' ' ' compile, or int-xt ' execute on a user-defined word. > > >And for literal/action pairs: > > > > :NONAME ( xn lit xt -- ? ) NIP EXECUTE ; > > : COMP-LITXT (xn lit xt -- ) >R EXECUTE R> COMPILE, ; > > :POST-LITXT (xn lit xt -- ) >R POST-LIT R> POST-XT ; > > DT-TOKEN: DT-LITXT > > What do you have in mind here? A TO-recognizer? > Yes, or anything where an action on the literal has to be performed/compiled. The dual version is for those rare examples like Bernd's oo-parser where the interpret action differs from the compile action.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-09 15:40 +0000 |
| Message-ID | <2017May9.174050@mips.complang.tuwien.ac.at> |
| In reply to | #58850 |
JennyB <jennybrien@googlemail.com> writes:
>The only currently Standard way to do that is with STATE @ IF. Using recogn=
>izers avoids the problems that come with that. If we have recognizers, is i=
>t possible to deprecate the STATE @ IF construction entirely, or are there =
>some situations where a dual-action definition is still preferable?=20
When writing the text interpreter, you need to decide whether to use
DT>INT, DT>COMP (or possibly DT>POST).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-09 16:32 +0200 |
| Message-ID | <oesjtk$aq0$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #58832 |
In article <2017May8.155007@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>JennyB <jennybrien@googlemail.com> writes:
>>Andrew Haley wrote:
>>
>>> Hint: numbers are not state-smart.
>>
>>Well they are compiled or left on the stack depending on STATE
>
>That does not make them STATE-smart.
>
>: 5 5 ;
>
>is not state-smart, and behaves exactly like a number in all cases
>where numbers don't produce errors.
>
That is interesting. You don't like the 'TASK of ciforth because
you find the ' prefix "state-smart" Yet I can retort in the same way.
( 'TASK in ciforth is a constant address, the xt of TASK. )
"
That does not make them STATE-smart.
: 'TASK 'TASK ;
is not state-smart, and behaves exactly like an xt in all cases
where xts don't produce errors.
"
>- anton
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web