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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-09 11:08 +0000 |
| Message-ID | <2017May9.130807@mips.complang.tuwien.ac.at> |
| In reply to | #58879 |
krishna.myneni@ccreweb.org writes:
>Forth, on the desktop, is a versatile language for exploratory programming =
>because of its extensibility. The ability to extend the interpreter enhance=
>s 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 s=
>tring constant parsing.
Isn't that enough? What we have had has led us to having S", which is
implemented in some systems as a STATE-smart word (with problems in
corner cases), and in VFX to a solution with problems in other corner
cases. By switching to a string recognizer we can replace S", and
eventually get rid of a bunch of STATE-smart words.
Another example is dates: We often hear from Forth, Inc., how their
Forth systems allow you to input dates by supporting /, -, and . as
double number indicators. Let's see how this works out:
9.5.2017 cr d. \ customary in Austria
09.05.2017 cr d. \ alternative
2017-05-09 cr d. \ ISO format
05/09/2017 cr d. \ customary in the USA
This produces 4 different numbers for the same date, and what's worse,
different dates can produce the same number. By contrast, if we have
a date recognizer (or one for each format), it can use the separator
to decide in which format the date is in, deal with the leading zeros
problem, and produce a result in a common representation (e.g., the
modified Julian Day number). If you are so inclined, you could even
have a date recognizer that understands "9May2017".
I think you can think of various other recognizers for
application-specific data.
Getting back to the issue of STATE-smart words, another word that is
widely implemented as STATE-smart is TO. You can have a recognizer
that replaces it. You could even have that recognizer actually
recognize
TO word
But that might be confusing (TO looks too much like a word of its
own), so Gforth has a recognizer that recognizes ->word.
Another way to avoid the problem of STATE-smartness has been taken in
the pair ' [']. That has the disadvantage that you cannot copy it
between compiled and interpreted code. If you have a recognizer that
recognizes '<word>, you get rid of that problem. Unfortunately there
exist words with a name starting with "'", and I think even pairs of
words, onbe with ' and one without, so it's probably better to use a
different pattern for a recognizer that produces the xt.
The scope recognizer is another example. Instead of writing
also voc bla previous
you can write voc:bla.
Another recognizer (one that has been used for quite some time in VFX,
implemented in a VFX-specific way) is the dot-parser. It allows to
access fields of objects, e.g., "myline.end", can be used with a class
name in a way similar to the scope recognizer, e.g., "point.x", and
also supports doing that to several levels, e.g., "myline.end.x".
- 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-09 08:33 -0500 |
| Message-ID | <pv2dnUjtbbWMWIzEnZ2dnUU7-N3NnZ2d@supernews.com> |
| In reply to | #58886 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Another way to avoid the problem of STATE-smartness has been taken
> in the pair ' [']. That has the disadvantage that you cannot copy
> it between compiled and interpreted code. If you have a recognizer
> that recognizes '<word>, you get rid of that problem. Unfortunately
> there exist words with a name starting with "'", and I think even
> pairs of words, onbe with ' and one without, so it's probably better
> to use a different pattern for a recognizer that produces the xt.
One person's disadvantage is another's feature: the difference in
behaviour between ['] and ' desrves a different name, IMO.
All this business of the pain of "copying between compiled and
interpreted code" has always struck me as odd. After all, it's never
been hard to do
: { :noname ;
: } postpone ; execute ; immediate ok
{ 10 0 do i . loop } 0 1 2 3 4 5 6 7 8 9 ok
{ ." hello" } hello ok
{ s" foo bar baz" } type foo bar baz ok
1 2 3 4 { >r >r dup r> r> } .s
1 2 2 3 4 <-Top ok
This is a general solution for keyboard experimentation and debugging
almost anything which is restricted to compiled code. And the
beginner, presented with this solution, might learn something instead
of having different words with superficially identical actions hidden
behind a recognizer.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-09 15:39 +0200 |
| Message-ID | <86tw4ub146.fsf@molnjunk.nocrew.org> |
| In reply to | #58887 |
Andrew Haley wrote:
> After all, it's never been hard to do
>
> : { :noname ;
> : } postpone ; execute ; immediate ok
> { 10 0 do i . loop } 0 1 2 3 4 5 6 7 8 9 ok
Cue ciforth "NEEDS SCRIPTING". Or something like that.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-09 09:14 -0500 |
| Message-ID | <g7idnYN7tJlcU4zEnZ2dnUU7-a-dnZ2d@supernews.com> |
| In reply to | #58888 |
Lars Brinkhoff <lars.spam@nocrew.org> wrote:
> Andrew Haley wrote:
>> After all, it's never been hard to do
>>
>> : { :noname ;
>> : } postpone ; execute ; immediate ok
>> { 10 0 do i . loop } 0 1 2 3 4 5 6 7 8 9 ok
>
> Cue ciforth "NEEDS SCRIPTING". Or something like that.
:-)
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-09 16:40 +0000 |
| Message-ID | <2017May9.184023@mips.complang.tuwien.ac.at> |
| In reply to | #58887 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>> Another way to avoid the problem of STATE-smartness has been taken
>> in the pair ' [']. That has the disadvantage that you cannot copy
>> it between compiled and interpreted code. If you have a recognizer
>> that recognizes '<word>, you get rid of that problem. Unfortunately
>> there exist words with a name starting with "'", and I think even
>> pairs of words, onbe with ' and one without, so it's probably better
>> to use a different pattern for a recognizer that produces the xt.
>
>One person's disadvantage is another's feature: the difference in
>behaviour between ['] and ' desrves a different name, IMO.
>
>All this business of the pain of "copying between compiled and
>interpreted code" has always struck me as odd. After all, it's never
>been hard to do
>
>: { :noname ;
>: } postpone ; execute ; immediate ok
It has not been hard, but it has not been done. Why not?
{ create mytable ['] . , :noname 1+ . ; ,
1 mytable @ execute
1 mytable cell+ @ execute
}
This does not work.
We have had many proposals of compilation with instant execution
instead of interpretation over the years, and while it solves some
problems (e.g., ' vs. [']), it opens up others, so this has never
caught on widely.
>This is a general solution for keyboard experimentation and debugging
>almost anything which is restricted to compiled code. And the
>beginner, presented with this solution, might learn something instead
>of having different words with superficially identical actions hidden
>behind a recognizer.
So are I# [I#] preferable for integer literals over the integer
recognizer in the text interpreter in your opinion? If not, why
should that approach be preferable for other cases?
Actually, applying the same principle to dealing with words, we get to
something like <http://www.complang.tuwien.ac.at/forth/colorforth-bw>.
You then write code as follows
[: gen-innerproduct [( a[row][*] -- xt )
[\ xt is of type ( b[*][column] -- n )
[\ this would be a candidate for using ]] ... [[
_>r _:noname _r>
]0 ]SWAP
_row-size _0 [do
]dup ]@
_dup _@ _literal ]* ]under+
]cell+ _row-byte-size _+
[loop
_drop
]drop _;
[;
This means you cannot cut and paste code verbatim between
interpretation and compiled code at all, but according to you, working
around that restriction is not that hard, and the beginner might learn
something instead of having different words with superficially
identical actions hidden behind a text interpreter.
BTW, this code is an example of how malleable existing Forth systems
are even before incorporating recognizers, and in this case, even
without using a hook. If, as you fear, Forth programmers are keen to
use recognizers to shoot themselves in the foot, they would have done
it already, without recognizers, using the multitude of existing
possibilities for it.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-10 05:48 -0500 |
| Message-ID | <io2dnXO_Qo-abY_EnZ2dnUU7-bXNnZ2d@supernews.com> |
| In reply to | #58906 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>
>>> Another way to avoid the problem of STATE-smartness has been taken
>>> in the pair ' [']. That has the disadvantage that you cannot copy
>>> it between compiled and interpreted code. If you have a recognizer
>>> that recognizes '<word>, you get rid of that problem. Unfortunately
>>> there exist words with a name starting with "'", and I think even
>>> pairs of words, onbe with ' and one without, so it's probably better
>>> to use a different pattern for a recognizer that produces the xt.
>>
>>One person's disadvantage is another's feature: the difference in
>>behaviour between ['] and ' desrves a different name, IMO.
>>
>>All this business of the pain of "copying between compiled and
>>interpreted code" has always struck me as odd. After all, it's never
>>been hard to do
>>
>>: { :noname ;
>>: } postpone ; execute ; immediate ok
>
> It has not been hard, but it has not been done. Why not?
>
> { create mytable ['] . , :noname 1+ . ; ,
> 1 mytable @ execute
> 1 mytable cell+ @ execute
> }
>
> This does not work.
Indeed not. Guess what? It doesn't work with the interpreted
language. It's not suposed to.
>>This is a general solution for keyboard experimentation and debugging
>>almost anything which is restricted to compiled code. And the
>>beginner, presented with this solution, might learn something instead
>>of having different words with superficially identical actions hidden
>>behind a recognizer.
>
> So are I# [I#] preferable for integer literals over the integer
> recognizer in the text interpreter in your opinion? If not, why
> should that approach be preferable for other cases?
Because I have no problem with the way that integer literals work at
present: I am not trying to construct a totally orthogonal damn-the-
implementation-it's-consistent-principles-that-matter version of
Forth.
> Actually, applying the same principle to dealing with words, we get to
> something like <http://www.complang.tuwien.ac.at/forth/colorforth-bw>.
> You then write code as follows
>
> [: gen-innerproduct [( a[row][*] -- xt )
> [\ xt is of type ( b[*][column] -- n )
> [\ this would be a candidate for using ]] ... [[
> _>r _:noname _r>
> ]0 ]SWAP
> _row-size _0 [do
> ]dup ]@
> _dup _@ _literal ]* ]under+
> ]cell+ _row-byte-size _+
> [loop
> _drop
> ]drop _;
> [;
Is there any actual point to this? As far as I can see it's unrolling
an inner loop, but I only know that because I read the POSTPONE-heavy
version.
> This means you cannot cut and paste code verbatim between
> interpretation and compiled code at all, but according to you, working
> around that restriction is not that hard, and the beginner might learn
> something instead of having different words with superficially
> identical actions hidden behind a text interpreter.
I never suggested that you couldn't tie yourself in knots if you tried
really hard. If you futz around enough you'll break things. A
sufficiently devious and clever programmer can break anything.
> BTW, this code is an example of how malleable existing Forth systems
> are even before incorporating recognizers, and in this case, even
> without using a hook. If, as you fear, Forth programmers are keen
> to use recognizers to shoot themselves in the foot, they would have
> done it already, without recognizers, using the multitude of
> existing possibilities for it.
My point isn't that people can't already shoot themselves in the foot.
If I'd intended to say that, I surely would have done so. There are
lots of ways of doing that in Forth, obviously. That's why style
matters so much.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-12 07:47 -0700 |
| Message-ID | <4c81a30b-f67d-46b1-b3df-331ddb8d390d@googlegroups.com> |
| In reply to | #58886 |
On Tuesday, May 9, 2017 at 9:32:23 PM UTC+9, Anton Ertl wrote: > krishna.myneni@ccreweb.org writes: > >Forth, on the desktop, is a versatile language for exploratory programming = > >because of its extensibility. The ability to extend the interpreter enhance= > >s 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 s= > >tring constant parsing. > > Isn't that enough? What we have had has led us to having S", which is > implemented in some systems as a STATE-smart word (with problems in > corner cases), and in VFX to a solution with problems in other corner > cases. By switching to a string recognizer we can replace S", and > eventually get rid of a bunch of STATE-smart words. > > Another example is dates: We often hear from Forth, Inc., how their > Forth systems allow you to input dates by supporting /, -, and . as > double number indicators. Let's see how this works out: > > 9.5.2017 cr d. \ customary in Austria > 09.05.2017 cr d. \ alternative For what it's worth, in the Japanese context, we tend to write those 2017.05.09 or, using the national era, 29.5.9 > 2017-05-09 cr d. \ ISO format > 05/09/2017 cr d. \ customary in the USA > > This produces 4 different numbers for the same date, and what's worse, > different dates can produce the same number. By contrast, if we have > a date recognizer (or one for each format), it can use the separator > to decide in which format the date is in, deal with the leading zeros > problem, and produce a result in a common representation (e.g., the > modified Julian Day number). If you are so inclined, you could even > have a date recognizer that understands "9May2017". I'm not sure what I should add at this point, other than that such a date recognizer is going to require a huge hidden locale mechanism to get right. If that's okay with you, then go ahead. > I think you can think of various other recognizers for > application-specific data. > > Getting back to the issue of STATE-smart words, another word that is > widely implemented as STATE-smart is TO. You can have a recognizer > that replaces it. You could even have that recognizer actually > recognize > > TO word > > But that might be confusing (TO looks too much like a word of its > own), so Gforth has a recognizer that recognizes ->word. > > Another way to avoid the problem of STATE-smartness has been taken in > the pair ' [']. That has the disadvantage that you cannot copy it > between compiled and interpreted code. If you have a recognizer that > recognizes '<word>, you get rid of that problem. Unfortunately there > exist words with a name starting with "'", and I think even pairs of > words, onbe with ' and one without, so it's probably better to use a > different pattern for a recognizer that produces the xt. > > The scope recognizer is another example. Instead of writing > > also voc bla previous > > you can write voc:bla. > > Another recognizer (one that has been used for quite some time in VFX, > implemented in a VFX-specific way) is the dot-parser. It allows to > access fields of objects, e.g., "myline.end", can be used with a class > name in a way similar to the scope recognizer, e.g., "point.x", and > also supports doing that to several levels, e.g., "myline.end.x". ... prefix field syntax for a postfix world. Let's get busy and write a near-C interpreter, instead. ;) -- Joel Rees Delusions of being a novelist: http://reiisi.blogspot.jp/p/novels-i-am-writing.html
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-02 11:10 -0700 |
| Message-ID | <f13713b2-c31a-4967-83c7-d70113a92b8d@googlegroups.com> |
| In reply to | #58478 |
> My basic objection is that this proposal essntially turns the Forth > interpreter inside out, with the dictionary search subservient to the > recognizer loop. I had a use case where I compiled a rather large number into the dictionary. With the old interpreter it took considerably longer time to do it. Why? It first walked through the dictionary only to find out that 1234 is not there and then started the number conversion. When I swapped these two steps in the interpreter, the work was done much faster. Checking whether , (comma) is a number is faster than searching a dictionary. > Such an extraordinary overhaul of the language, the > most dramatic since ANS 94, IMO requires extraordinary justification. I don't see it as an extraordinary change to the language. IMHO it is a long overdue task to make the interpreter as flexible as the compiler. If it opens some roads to other changes, well fine with me. It only tells me that the idea I had in mind has other benefits too. It makes possibilities, and does not create restrictions. > And that justification must be pulled by the needs of application > writers, not pushed by implementers. That is somewhat difficult since no system except my amforth fully supports them. So there is very little not-by-me experience. Is http://amforth.sourceforge.net/Projects/RS485/RS485Bus.html worth to be mentioned? Some more examples (ok, mostly written by me) are at theforth.net e.g. http://theforth.net/package/recognizers/current-view/rec-double-paren.4th that implements a multiline comment with active elements inside. > > 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. Than why do you ask for one? > 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. Indeed. > > 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. It may well be an requirement from the application. I've seen use cases where the command lookup should be disabled at all (sealed). before you mention it: Everything can be done without recognizers. With them these task may be done more elegant. What leads directly to > 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. ok, here we leave the world of technical arguments. clarity and elegance lie in the eyes of the beholder, so you are as right as I am. The RFD text is approx 20 pages long now. The "normative" text part is much shorter, the reference implementation fits on a single page, with some less nice formatting maybe a single screen. The reference implementation for the exceptions is much more guru code, IMHO. > 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 Don't get me wrong, but that argument reminds me to "no one will ever need more than 640KB of RAM". The [[ ]] postpone macros are already mentioned. > 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. Indeed. It's like a chicken-and-egg problem. No system implementor will ever think about changes they consider fundamental if no user demands them. And no user will use them if no system provides them. This is the death of every change, may it for the worse or may it be for the better. A static language is a dead language. See Latin. It is my understanding that the Forth 202x team thinks about experimental wordsets. They are not part of the standard but can be seen as candidates? Is this still so? Than I'd ask for such an experimental wordset approval. > > 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. I think that the way the recognizers already went in the past 5 or years is pretty far. The first ideas were much more worse and never really saw the light of the open stage. Which is is good thing. Matthias
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-02 11:47 -0700 |
| Message-ID | <af593ca3-1a02-4cbb-8b38-7dd5652dfcb3@googlegroups.com> |
| In reply to | #58519 |
Am Dienstag, 2. Mai 2017 20:10:54 UTC+2 schrieb Matthias Trute: > > My basic objection is that this proposal essntially turns the Forth > > interpreter inside out, with the dictionary search subservient to the > > recognizer loop. > > I had a use case where I compiled a rather large number into I meant a large set of numbers. Sorry.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-02 22:47 +0000 |
| Message-ID | <oeb2a2$tsb$1@dont-email.me> |
| In reply to | #58519 |
Am Tue, 02 May 2017 11:10:52 -0700 schrieb Matthias Trute: > It may well be an requirement from the application. I've seen use cases > where the command lookup should be disabled at all (sealed). A very obvious example is the config parser I use for net2o (it's a pretty generic .ini-style parser). There, the values assigned to variables are all literals, so you don't want to search for names. And the variable names are all inside a particular vocabulary, there you want to search for names only. Of course, the syntax of .ini files are not Forth syntax. But the recognizer approach allows to reuse Forth components with ease for this job. I could even add a recognizer for var=<value> style assignments, and have only that recognizer active, and use INCLUDED to load the config files; though I didn't go that far. One reason is that I don't want the parsing of a .ini file stop when it sees one wrong line; just report that line as buggy, keep the sane default for it, and go on parsing. That's what I see as the Forth way: To solve a problem, extend Forth to solve your problem. If it's a parsing problem, change the parser. -- 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-03 04:31 -0500 |
| Message-ID | <dJidncIN9rHmPpTEnZ2dnUU7-amdnZ2d@supernews.com> |
| In reply to | #58540 |
Bernd Paysan <bernd@net2o.de> wrote: > > That's what I see as the Forth way: To solve a problem, extend Forth to > solve your problem. If it's a parsing problem, change the parser. Sure, but it doesn't have to be the standard parser + hooks: it could simply be another parser. Writing Forth parsers is easy, and that's better than a single parser with lotsa hooks, IMO. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-04 15:01 +0000 |
| Message-ID | <2017May4.170135@mips.complang.tuwien.ac.at> |
| In reply to | #58562 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd@net2o.de> wrote:
>>
>> That's what I see as the Forth way: To solve a problem, extend Forth to
>> solve your problem. If it's a parsing problem, change the parser.
>
>Sure, but it doesn't have to be the standard parser + hooks: it could
>simply be another parser. Writing Forth parsers is easy, and that's
>better than a single parser with lotsa hooks, IMO.
And yet, VFX has lotsa hooks, SwiftForth has a relatively elaborate
hook system (halfway to the present proposal), Gforth, AmForth, WF32
etc. have recognizers. Why did they not follow your idea, and let
those who want more recognizers write another parser?
1) You would need to rewrite the whole parser to add another
recognizer. That's not the simplest way to do it.
2) Writing another parser does not compose: If I write a parser that
recognizes locals, words, integers, and FP numbers in order to get FP
numbers, and you write one for recognizing locals, words, integers,
and dates, how do I get one that recognizes locals, words, integers,
FP numbers, and dates? I have to start from scratch. While the
systems in VFX and SwiftForth are not great on composability, they are
better.
3) How do I get my shiny new parser to be called by QUIT, INCLUDED,
LOAD, and EVALUATE? That's probably not a problem for a system
implementor (just use carnal knowledge), but how does somebody who
wants to write a portable program do it?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-04 12:10 -0500 |
| Message-ID | <X4mdnfJiKfIe_ZbEnZ2dnUU7-WHNnZ2d@supernews.com> |
| In reply to | #58664 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Bernd Paysan <bernd@net2o.de> wrote: >>> >>> That's what I see as the Forth way: To solve a problem, extend Forth to >>> solve your problem. If it's a parsing problem, change the parser. >> >>Sure, but it doesn't have to be the standard parser + hooks: it could >>simply be another parser. Writing Forth parsers is easy, and that's >>better than a single parser with lotsa hooks, IMO. > > And yet, VFX has lotsa hooks, SwiftForth has a relatively elaborate > hook system (halfway to the present proposal), Gforth, AmForth, WF32 > etc. have recognizers. Why did they not follow your idea, and let > those who want more recognizers write another parser? Because I did not suggest that they should, and that does not represent my idea. It's perfectly reasonable for them to use hooks or recognizers in any form in their systems as they wish, and I never suggested that they should take them out. I repeat: it's up to the proponents of the recognizer scheme to convince people to use it, on its own merits. If implementers find that it's a good way to organize their system, I have no objection. > 1) You would need to rewrite the whole parser to add another > recognizer. That's not the simplest way to do it. > > 2) Writing another parser does not compose: If I write a parser that > recognizes locals, words, integers, and FP numbers in order to get FP > numbers, and you write one for recognizing locals, words, integers, > and dates, how do I get one that recognizes locals, words, integers, > FP numbers, and dates? I have to start from scratch. While the > systems in VFX and SwiftForth are not great on composability, they are > better. The recognizer proposal doesn't compose either. If you're lucky the recognizers won't collide and won't interfere with each other's expectations; if not, they will. There are obvious collisions between data formats and number formats, for example. > 3) How do I get my shiny new parser to be called by QUIT, INCLUDED, > LOAD, and EVALUATE? That's probably not a problem for a system > implementor (just use carnal knowledge), but how does somebody who > wants to write a portable program do it? I didn't understand that to be what we were talking about, which was as I understand it to change the parser in order to parse some kind of DSL. Bernd did say that "the parser needed to be changed", and a pefectly reasonable esponse is "so change it, then." I do not know that hooks such as this proposal are a good way to achieve the change he has in mind, whatever that is. Maybe, maybe not. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-03 04:29 -0500 |
| Message-ID | <dJidncMN9rGNPpTEnZ2dnUU7-anNnZ2d@supernews.com> |
| In reply to | #58519 |
Matthias Trute <matthias.trute@gmail.com> wrote: >> My basic objection is that this proposal essntially turns the Forth >> interpreter inside out, with the dictionary search subservient to the >> recognizer loop. > > I had a use case where I compiled a rather large number into the > dictionary. With the old interpreter it took considerably longer > time to do it. Why? It first walked through the dictionary only to > find out that 1234 is not there and then started the number > conversion. When I swapped these two steps in the interpreter, the > work was done much faster. That does indicate a very broken dictionary search! There are algorithms which will do a fast query for set membership for strings. They are not terribly complicated. >> Such an extraordinary overhaul of the language, the >> most dramatic since ANS 94, IMO requires extraordinary justification. > > I don't see it as an extraordinary change to the language. Yes, I get that. This is all IMO. >> And that justification must be pulled by the needs of application >> writers, not pushed by implementers. > > That is somewhat difficult since no system except my amforth fully > supports them. So there is very little not-by-me experience. Is > http://amforth.sourceforge.net/Projects/RS485/RS485Bus.html worth > to be mentioned? IMO, extensions to forth should be adopted by implementers before being seriously proposed for standardization. If the extensions are good they will be widely adopted, regardless of whether they are standard or not. >> 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. > > Than why do you ask for one? Because without a way to control conflicting recognizers, the result will be a disaster. IMO. >> 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. > > ok, here we leave the world of technical arguments. clarity and > elegance lie in the eyes of the beholder, so you are as right as I > am. I agree. >> 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 > > Don't get me wrong, but that argument reminds me to "no one will > ever need more than 640KB of RAM". The [[ ]] postpone macros are > already mentioned. That's a fair comment. My view is that extending recognizers with a POSTPONE action is an excessive "Hey! Isn't that a neat trick?" feature. > Indeed. It's like a chicken-and-egg problem. No system implementor > will ever think about changes they consider fundamental if no user > demands them. And no user will use them if no system provides them. > This is the death of every change, may it for the worse or may it be > for the better. A static language is a dead language. See Latin. I agree, but standardization is completely the wrong way to approach this. If by the end of all this discussion serious system implementers and Forth vendors report a successful adoption of this technique I won't stand in the way. Hey, if people really use it in applications I'll probably even vote in favour. When changes to the standard language have been made by fiat without wide deployment experience it hasn't always worked out well. I cite the FORTH-83 DO ... +LOOP as the poster child of standardization disasters. It was dreamt up, presented to the committee, and standardized in a whirl, and we're still living with it. > It is my understanding that the Forth 202x team thinks about > experimental wordsets. Yes. I suggested experimental wordsets at the last meeting. Other people might have suggested them as well; I don't know. > They are not part of the standard but can be seen as candidates? Is > this still so? Than I'd ask for such an experimental wordset > approval. I don't think that we decided to have experimental wordsets. I still think that it might be a good idea. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-03 12:27 -0700 |
| Message-ID | <729064ab-7290-479d-afed-d7efd49547d5@googlegroups.com> |
| In reply to | #58561 |
> That does indicate a very broken dictionary search! There are > algorithms which will do a fast query for set membership for strings. > They are not terribly complicated. Very true. But nobody can convince me that a list of words (say 100 items and more) is processed faster than the decision "number or not". Esp when the restrictions of a very small microcontroller are in place too. > IMO, extensions to forth should be adopted by implementers before > being seriously proposed for standardization. If the extensions are > good they will be widely adopted, regardless of whether they are > standard or not. Ok, I think that's your major concern: Recognizers are nothing that everybody already uses but I suggest to make them part of the standard. Got it. > Because without a way to control conflicting recognizers, the result > will be a disaster. IMO. IMHO the way of control goes through the brain of the people using it. > My view is that extending recognizers with a > POSTPONE action is an excessive "Hey! Isn't that a neat trick?" > feature. That feature was not part of the very first recognizers (the ones, nobody but me cared about). Did I mention that the current RFD is the result of some years of work? > I agree, but standardization is completely the wrong way to approach > this. If by the end of all this discussion serious system > implementers and Forth vendors report a successful adoption of this > technique I won't stand in the way. Hey, if people really use it in > applications I'll probably even vote in favour. Funny, other languages first define new features and implement them afterwards. Forth is a rare exception it seems. > I don't think that we decided to have experimental wordsets. I still > think that it might be a good idea. google introduced the +1 synatx to support opinions. Here's mine on that topic: +1 Matthias
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-04 02:35 -0500 |
| Message-ID | <9aCdnXCNLO5FRJfEnZ2dnUU7-T3NnZ2d@supernews.com> |
| In reply to | #58610 |
Matthias Trute <matthias.trute@gmail.com> wrote: > >> That does indicate a very broken dictionary search! There are >> algorithms which will do a fast query for set membership for strings. >> They are not terribly complicated. > > Very true. But nobody can convince me that a list of words (say 100 items > and more) is processed faster than the decision "number or not". Esp > when the restrictions of a very small microcontroller are in place too. Perhaps so, but I don't think there would be much difference. >> My view is that extending recognizers with a POSTPONE action is an >> excessive "Hey! Isn't that a neat trick?" feature. > > That feature was not part of the very first recognizers (the ones, nobody > but me cared about). Did I mention that the current RFD is the result of > some years of work? You don't need to mention that. >> I agree, but standardization is completely the wrong way to approach >> this. If by the end of all this discussion serious system >> implementers and Forth vendors report a successful adoption of this >> technique I won't stand in the way. Hey, if people really use it in >> applications I'll probably even vote in favour. > > Funny, other languages first define new features and implement them > afterwards. Forth is a rare exception it seems. Forth has a different history from most languages, and for the first decate or two the process always was that a language feature would be invented, tried in several applications, and if it turned out to be generally useful it would be absorbed into the language. There have been exceptions to this, and they have been of distinctly mixed success. But Forth isn't totally exceptional in this regard: for example GCC sometimes takes proposals for language changes and incorporates them in a release. Atomic accesses, for example, were trialled for several years. This is the best process to follow. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-04 14:00 +0000 |
| Message-ID | <2017May4.160014@mips.complang.tuwien.ac.at> |
| In reply to | #58561 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>IMO, extensions to forth should be adopted by implementers before
>being seriously proposed for standardization. If the extensions are
>good they will be widely adopted, regardless of whether they are
>standard or not.
In this case the extension has been widely adopted, far more widely
than <http://www.forth200x.org/n-to-r.html>,
<http://www.forth200x.org/text-substitution.txt>, and
<http://www.forth200x.org/xchar.html> before they were standardized.
Every major system has had "number parsing hooks" and possibly other
hooks in the text interpreter for decades. The recognizer proposal
proposes standardizing these features.
Of course, because these hooks were all different, you cannot just
take the documentation of one system and propose that system's feature
for standardization, just like Forth-94 could not just standardize
NOT, or use one system's file words, or use one system's
address-computation words. So, what we get is a proposal for an
existing feature that uses new words, just like Forth-94 introduced
the new words INVERT, OPEN-FILE, and CELL+ (etc.).
>Because without a way to control conflicting recognizers, the result
>will be a disaster. IMO.
If you think so, propose a way for controlling conflict, but don't
complain about complexity then.
E.g., I can imagine trying all the recognizers on the string, and
producing a warning if more than one matches. This would even trigger
on existing cases like
HEX ADD
but unfortunately not on the "2," case above.
>My view is that extending recognizers with a
>POSTPONE action is an excessive "Hey! Isn't that a neat trick?"
>feature.
I find it a useful feature that makes Forth easier to understand,
teach, and use. It's no longer necessary to explain to students that
they cannot
POSTPONE 123
but have to use the magic incantation
123 POSTPONE literal
instead. And it's no longer necessary to write
]] bla bla [[ 123 ]] literal bla bla [[
which does not contribute to clarity at all. Instead, I can then
write
]] bla bla 123 bla bla [[
>> Indeed. It's like a chicken-and-egg problem. No system implementor
>> will ever think about changes they consider fundamental if no user
>> demands them. And no user will use them if no system provides them.
>> This is the death of every change, may it for the worse or may it be
>> for the better. A static language is a dead language. See Latin.
>
>I agree, but standardization is completely the wrong way to approach
>this. If by the end of all this discussion serious system
>implementers and Forth vendors report a successful adoption of this
>technique I won't stand in the way.
System implementors and Forth vendors have had this feature in some
form or other for a long time; of course, because it was not
standardized, they diverged in the implementation and the interfaces.
The present proposal proposes a common interface.
>Hey, if people really use it in
>applications I'll probably even vote in favour.
The system implementors and Forth vendors did not put the hooks into
their systems for no reason; they are used in applications.
>When changes to the standard language have been made by fiat without
>wide deployment experience it hasn't always worked out well. I cite
>the FORTH-83 DO ... +LOOP as the poster child of standardization
>disasters. It was dreamt up, presented to the committee, and
>standardized in a whirl, and we're still living with it.
If we are still living with it 34 years later, it obviously was not a
disaster. If it had been a disaster, it would have been removed or
replaced in Forth-94. As it is, there is not even a proposal for
removing or replacing it around now, not even from you.
A better example would be LOCALS|. It's so unpopular that is became
obsolescent at the next opportunity and replaced with "{:". And yet
the Forth-94 locals wordset provided progress: It includes (LOCAL),
which allows to define the "{:" in Forth-94, and describes the
behaviour of locals themselves.
But there were also examples of features that were added without much
prior adoption and usage, and they are very successful: CELL+ and
COMPILE, are similar to recognizers in that they were present in all
systems in some other form. CATCH and THROW are an example of a
feature that was not widely implemented and used in Forth systems
before being standardized.
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.
- 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 12:21 -0500 |
| Message-ID | <ZOKdnZcItf2M_pbEnZ2dnUU7-UHNnZ2d@supernews.com> |
| In reply to | #58657 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>IMO, extensions to forth should be adopted by implementers before
>>being seriously proposed for standardization. If the extensions are
>>good they will be widely adopted, regardless of whether they are
>>standard or not.
>
> In this case the extension has been widely adopted,
No it hasn't. This is a proposal for a new extension, and you cannot
ride on the coat-tails of any existing scheme of interpreter hooks.
>>Because without a way to control conflicting recognizers, the result
>>will be a disaster. IMO.
>
> If you think so, propose a way for controlling conflict, but don't
> complain about complexity then.
If I think a feature is broken, I'll say so; if I think it's too
complex I will say so. If I think there is no easy way to fix its
problems, I will say so.
> System implementors and Forth vendors have had this feature in some
> form or other for a long time; of course, because it was not
> standardized, they diverged in the implementation and the interfaces.
> The present proposal proposes a common interface.
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.
>>When changes to the standard language have been made by fiat without
>>wide deployment experience it hasn't always worked out well. I cite
>>the FORTH-83 DO ... +LOOP as the poster child of standardization
>>disasters. It was dreamt up, presented to the committee, and
>>standardized in a whirl, and we're still living with it.
>
> If we are still living with it 34 years later, it obviously was not a
> disaster.
LOL! Obviously. Disasters are in the eye of the beholder, I suppose.
:-) But the awfulness of that DO ... +LOOP is well known, and I have
no intention of rehashing it here. It would be very hard to replace
it now without serious code breakage, and I would not advocate that.
> A better example would be LOCALS|. It's so unpopular that is became
> obsolescent at the next opportunity and replaced with "{:". And yet
> the Forth-94 locals wordset provided progress: It includes (LOCAL),
> which allows to define the "{:" in Forth-94, and describes the
> behaviour of locals themselves.
LOCALS| isn't a disaster at all, because no-one uses it. Even if they
did use it, it would do little harm. It is of no consequence
whatsoever.
> 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.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-04 19:14 +0100 |
| Message-ID | <oefqss$2r5$1@dont-email.me> |
| In reply to | #58677 |
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. 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. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-05 09:17 -0500 |
| Message-ID | <X-CdnUUA5q7xFJHEnZ2dnUU7-QfNnZ2d@supernews.com> |
| In reply to | #58681 |
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.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web