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 5 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 16:19 +0000 |
| Message-ID | <2017May9.181906@mips.complang.tuwien.ac.at> |
| In reply to | #58892 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>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"
citation needed.
- 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 18:53 +0200 |
| Message-ID | <oess6n$c4k$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #58903 |
In article <2017May9.181906@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >>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" > >citation needed. That was my impression. You don't need a citation for things you've said yourself, so I conclude that you have no objections to the 'TASK construction using a recognizer that inspects STATE. > >- anton -- 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 | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-09 18:12 +0100 |
| Message-ID | <oest4h$vtu$1@dont-email.me> |
| In reply to | #58904 |
On 5/9/2017 17:53, Albert van der Horst wrote:
> In article <2017May9.181906@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>> 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"
>>
>> citation needed.
>
> That was my impression.
> You don't need a citation for things you've said yourself,
> so I conclude that you have no objections to the
> 'TASK construction using a recognizer that inspects STATE.
Well, the state is all done in the interpreter loop; the recognizer
doesn't inspect STATE. In fact, the recognizer shouldn't attempt to do
anything that's dependent on STATE.
: plit postpone literal ;
' noop
' plit ;
:noname plit postpone plit ;
dt-token value dt:single
: rec:tick ( addr u -- n dt:single| dt:null )
over c@ ''' = if
1 /string find-name ?dup if
name>interpret dt:single exit
then
else
2drop
then dt:null ;
' rec:tick get-recognizers 1+ set-recognizers
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-09 10:41 -0700 |
| Message-ID | <634efd10-09f2-416b-a58c-5d0bef061ac8@googlegroups.com> |
| In reply to | #58905 |
> Well, the state is all done in the interpreter loop; the recognizer > doesn't inspect STATE. In fact, the recognizer shouldn't attempt to do > anything that's dependent on STATE. Indeed. > ' rec:tick get-recognizers 1+ set-recognizers Here the recognizer stack id (FORTH-RECOGNIZER) is missing for the get/set-recognizers. In every example so far. Introduced in version 3 of the RFD to enable nested recognizer stacks and fast switching them. Andrew suggested such a feature, btw ;) Matthias
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-09 19:12 +0100 |
| Message-ID | <oet0jn$c8v$1@dont-email.me> |
| In reply to | #58909 |
On 5/9/2017 18:41, Matthias Trute wrote: >> Well, the state is all done in the interpreter loop; the recognizer >> doesn't inspect STATE. In fact, the recognizer shouldn't attempt to do >> anything that's dependent on STATE. > > Indeed. > > >> ' rec:tick get-recognizers 1+ set-recognizers > > Here the recognizer stack id (FORTH-RECOGNIZER) is > missing for the get/set-recognizers. In every example > so far. Introduced in version 3 of the RFD to enable > nested recognizer stacks and fast switching them. > Andrew suggested such a feature, btw ;) > > Matthias > He's welcome to it; I've yet to see the requirement. (Does that sound enough like Andrew? ;) But I will update to V4 shortly. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-07 22:46 +0000 |
| Message-ID | <oeo84d$3p2$2@dont-email.me> |
| In reply to | #58769 |
Am Sun, 07 May 2017 07:59:18 -0500 schrieb Andrew Haley: > I don't understand the relevance of that reply to my point. Hint: > numbers are not state-smart. No, numbers go through a recognizer. Whether that's what we formalize as "recognizer" in our proposal or the traditional interpreter structure doesn't matter: Even if hard-coded, it's a recognizer. If you don't have this recognizer, you would start with a parsing word to get your numbers back. And since you threw out STATE, there now must be another option to deal with them. Do you want D# and [D#] for interpretation and compilation of decimal numbers? -- 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-08 03:50 -0500 |
| Message-ID | <t9SdnaQbQbDFrI3EnZ2dnUU7-cOdnZ2d@supernews.com> |
| In reply to | #58795 |
Bernd Paysan <bernd@net2o.de> wrote: > Am Sun, 07 May 2017 07:59:18 -0500 schrieb Andrew Haley: >> I don't understand the relevance of that reply to my point. Hint: >> numbers are not state-smart. > > No, numbers go through a recognizer. Whether that's what we > formalize as "recognizer" in our proposal or the traditional > interpreter structure doesn't matter: Even if hard-coded, it's a > recognizer. > > If you don't have this recognizer, you would start with a parsing > word to get your numbers back. I don't want to change anything in this area. I certainly don't want to make number parsing in its current form go away. > And since you threw out STATE, there now must be another option to > deal with them. Do you want D# and [D#] for interpretation and > compilation of decimal numbers? Heavens, no. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-08 02:42 -0700 |
| Message-ID | <e9a74f2b-42c7-4c3c-b978-2c38acab7d38@googlegroups.com> |
| In reply to | #58811 |
Am Montag, 8. Mai 2017 10:50:37 UTC+2 schrieb Andrew Haley:
> Bernd Paysan <bernd@net2o.de> wrote:
> > Am Sun, 07 May 2017 07:59:18 -0500 schrieb Andrew Haley:
> >> I don't understand the relevance of that reply to my point. Hint:
> >> numbers are not state-smart.
> >
> > No, numbers go through a recognizer. Whether that's what we
> > formalize as "recognizer" in our proposal or the traditional
> > interpreter structure doesn't matter: Even if hard-coded, it's a
> > recognizer.
> >
> > If you don't have this recognizer, you would start with a parsing
> > word to get your numbers back.
>
> I don't want to change anything in this area. I certainly don't want
> to make number parsing in its current form go away.
>
> > And since you threw out STATE, there now must be another option to
> > deal with them. Do you want D# and [D#] for interpretation and
> > compilation of decimal numbers?
>
> Heavens, no.
>
> Andrew.
I second that. Since unknown times we have the deferred word LITERAL?
In the kernel it is simply defined as
DEFER LITERAL? ( a u 0 | x.. ct true -- ) \ convert text to integer numbers
:NONAME number? IF ['] , ELSE 0 THEN ;
: INTERPRET \ ( -- ) outer interpret/compile loop
BEGIN bl word dup c@
WHILE find ?dup IF
< .. interpret/compile words .. >
ELSE drop literal? ( a u 0 | x.. ct t -- ) not -13 ?throw
state @ IF execute ELSE drop THEN
THEN
REPEAT drop ;
When the Floating-Point Wordset is included, LITERAL? is extended
:NONAME \ ( a u -- a u 0 | x.. ct true ) add float literals to the interpreter
ACTION-OF literal? ?dup IF EXIT THEN
base @ 10 =
IF 2dup >float
IF 2drop ['] fliteral true EXIT THEN
THEN
0 ; IS LITERAL?
The same principle is used for double numbers and fixed point numbers.
This is so straightforward and simple that I really can't see any added benefit from recognizers.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-08 03:58 -0700 |
| Message-ID | <0adc0c35-c5b1-46d4-b6b0-9db214017aa8@googlegroups.com> |
| In reply to | #58818 |
Am Montag, 8. Mai 2017 11:42:41 UTC+2 schrieb minf...@arcor.de: > Am Montag, 8. Mai 2017 10:50:37 UTC+2 schrieb Andrew Haley: > > Bernd Paysan <bernd@net2o.de> wrote: > > > Am Sun, 07 May 2017 07:59:18 -0500 schrieb Andrew Haley: > > >> I don't understand the relevance of that reply to my point. Hint: > > >> numbers are not state-smart. > > > > > > No, numbers go through a recognizer. Whether that's what we > > > formalize as "recognizer" in our proposal or the traditional > > > interpreter structure doesn't matter: Even if hard-coded, it's a > > > recognizer. > > > > > > If you don't have this recognizer, you would start with a parsing > > > word to get your numbers back. > > > > I don't want to change anything in this area. I certainly don't want > > to make number parsing in its current form go away. > > > > > And since you threw out STATE, there now must be another option to > > > deal with them. Do you want D# and [D#] for interpretation and > > > compilation of decimal numbers? > > > > Heavens, no. > > > > Andrew. > > I second that. Since unknown times we have the deferred word LITERAL? > In the kernel it is simply defined as > > DEFER LITERAL? ( a u 0 | x.. ct true -- ) \ convert text to integer numbers > :NONAME number? IF ['] , ELSE 0 THEN ; > Oops, should have been :NONAME number? IF ['] literal ELSE 0 THEN ; IS LITERAL? of course
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-08 12:35 +0100 |
| Message-ID | <oepkv8$l4p$1@dont-email.me> |
| In reply to | #58818 |
On 5/8/2017 10:42, minforth@arcor.de wrote: > Am Montag, 8. Mai 2017 10:50:37 UTC+2 schrieb Andrew Haley: >> Bernd Paysan <bernd@net2o.de> wrote: >>> Am Sun, 07 May 2017 07:59:18 -0500 schrieb Andrew Haley: >>>> I don't understand the relevance of that reply to my point. Hint: >>>> numbers are not state-smart. >>> >>> No, numbers go through a recognizer. Whether that's what we >>> formalize as "recognizer" in our proposal or the traditional >>> interpreter structure doesn't matter: Even if hard-coded, it's a >>> recognizer. >>> >>> If you don't have this recognizer, you would start with a parsing >>> word to get your numbers back. >> >> I don't want to change anything in this area. I certainly don't want >> to make number parsing in its current form go away. >> >>> And since you threw out STATE, there now must be another option to >>> deal with them. Do you want D# and [D#] for interpretation and >>> compilation of decimal numbers? >> >> Heavens, no. >> >> Andrew. > > I second that. Since unknown times we have the deferred word LITERAL? > In the kernel it is simply defined as > > DEFER LITERAL? ( a u 0 | x.. ct true -- ) \ convert text to integer numbers > :NONAME number? IF ['] , ELSE 0 THEN ; You corrected this to :NONAME number? IF ['] literal ELSE 0 THEN ; IS LITERAL? What does NUMBER? do? I'm confused as to the stack diagram for this :NONAME; is it ( a u -- a u 0 | x.. ct true ) or something else? > > : INTERPRET \ ( -- ) outer interpret/compile loop > BEGIN bl word dup c@ > WHILE find ?dup IF > < .. interpret/compile words .. > > ELSE drop literal? ( a u 0 | x.. ct t -- ) not -13 ?throw > state @ IF execute ELSE drop THEN > THEN > REPEAT drop ; > > When the Floating-Point Wordset is included, LITERAL? is extended > > :NONAME \ ( a u -- a u 0 | x.. ct true ) add float literals to the interpreter > ACTION-OF literal? ?dup IF EXIT THEN Why is this here? If LITERAL? is not set (and I presume you set DEFERred words to 0), it's going to blow up INTERPRET as it tries to execute the length of the string. > base @ 10 = That's not standard. BASE not being decimal only affects 12.6.1.2143 REPRESENT, 12.6.2.1427 F., 12.6.2.1513 FE., 12.6.2.1613 FS. >FLOAT should work regardless of base. See http://forth-standard.org/standard/float/toFLOAT. > IF 2dup >float Also, read the rationale for >FLOAT; it is for data, not the text interpreter, the parse of which is specified in http://forth-standard.org/standard/float "12.3.7 Text interpreter input number conversion" > IF 2drop ['] fliteral true EXIT THEN > THEN > 0 ; IS LITERAL? > > The same principle is used for double numbers and fixed point numbers. > > This is so straightforward and simple that I really can't see any > added benefit from recognizers. It's exactly like a recognizer, except it only works on your Forth, has a fixed order set on a first come first served basis, and doesn't permit postponing literals. (And, if I'm being hyper critical here, has a bug or two.) -- Alex
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-08 05:49 -0700 |
| Message-ID | <8cadc102-38e0-4d49-8104-e394859b64da@googlegroups.com> |
| In reply to | #58821 |
Am Montag, 8. Mai 2017 13:35:10 UTC+2 schrieb Alex: > What does NUMBER? do? I'm confused as to the stack diagram for this > :NONAME; is it ( a u -- a u 0 | x.. ct true ) or something else? Sorry for the bugs and omissions, I wrote this too quickly out of memory cause I don't have the sources right here. So NUMBER? ( a u -- a u 0 | x.. ct ) converts a string ( a u ) to one or more integer numbers ( x.. ). If it cannot convert it indication 0 is added, if it succeeds the compilation token ct is added. > > :NONAME \ ( a u -- a u 0 | x.. ct true ) add float literals to the interpreter > > ACTION-OF literal? ?dup IF EXIT THEN > > Why is this here? If LITERAL? is not set (and I presume you set DEFERred > words to 0), it's going to blow up INTERPRET as it tries to execute the > length of the string. LITERAL? is already and always set in the kernel. It is only deferred to provide the hook for optional wordsets requiring their own literals compiled into the application after core. > > > base @ 10 = > > That's not standard. BASE not being decimal only affects 12.6.1.2143 > REPRESENT, 12.6.2.1427 F., 12.6.2.1513 FE., 12.6.2.1613 FS. >FLOAT > should work regardless of base. See > http://forth-standard.org/standard/float/toFLOAT. Your statement is not correct IMO. Read 12.3.7. and the condition concerning BASE. > > IF 2dup >float > > Also, read the rationale for >FLOAT; it is for data, not the text > interpreter, the parse of which is specified in > http://forth-standard.org/standard/float "12.3.7 Text interpreter input > number conversion" LOL! Why should one not use >FLOAT for interpreting fp-number input??? > > IF 2drop ['] fliteral true EXIT THEN > > THEN > > 0 ; IS LITERAL? > > > > The same principle is used for double numbers and fixed point numbers. > > > > This is so straightforward and simple that I really can't see any > > added benefit from recognizers. > It's exactly like a recognizer, except it only works on your Forth, has > a fixed order set on a first come first served basis, and doesn't permit > postponing literals. (And, if I'm being hyper critical here, has a bug > or two.) Yes, it is an excerpt out of one Forth. You are right. Yes, it allows chaining interpretation and compilation of various literal formats in a flexible way, first or last in the chain. That's the charm of having deferred words. In my last 40 years working with Forth I never needed to postpone LITERAL in the interpreter loop. Why should I start with it now? No, you are not hyper critical. Thanks a lot!
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-08 16:28 +0200 |
| Message-ID | <oepv9h$281$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #58826 |
In article <8cadc102-38e0-4d49-8104-e394859b64da@googlegroups.com>, <minforth@arcor.de> wrote: <SNIP> > >LITERAL? is already and always set in the kernel. It is only deferred >to provide the hook for optional wordsets requiring their own literals >compiled into the application after core. LITERAL? may be in the kernel of your Forth, but it is not a standard word, and it is not in any shape or form present in the kernel of ciforth. <SNIP> 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]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-08 07:54 -0700 |
| Message-ID | <a9c5bc21-4a0f-42d4-95bd-a3df1c715c1b@googlegroups.com> |
| In reply to | #58835 |
Am Montag, 8. Mai 2017 16:28:40 UTC+2 schrieb Albert van der Horst: > In article <8cadc102-38e0-4d49-8104-e394859b64da@googlegroups.com>, > <minforth@arcor.de> wrote: > <SNIP> > > > >LITERAL? is already and always set in the kernel. It is only deferred > >to provide the hook for optional wordsets requiring their own literals > >compiled into the application after core. > > LITERAL? may be in the kernel of your Forth, but it is not a standard > word, and it is not in any shape or form present in the kernel of ciforth. > > <SNIP> > > 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 Why should it mimick ciforth at all? Do you advocate ciforth as reference implementation? (I don't want to be pointed, I admire its compactness, really.) F83 had NUMBER? long ago, Win32Forth has the similar DOUBLE? today. LITERAL? just adds a compilation token for the specific scalar type. It is as simple as that.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-08 17:16 +0200 |
| Message-ID | <oeq23g$2g2$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #58838 |
In article <a9c5bc21-4a0f-42d4-95bd-a3df1c715c1b@googlegroups.com>,
<minforth@arcor.de> wrote:
>Am Montag, 8. Mai 2017 16:28:40 UTC+2 schrieb Albert van der Horst:
>> In article <8cadc102-38e0-4d49-8104-e394859b64da@googlegroups.com>,
>> <minforth@arcor.de> wrote:
>> <SNIP>
>> >
>> >LITERAL? is already and always set in the kernel. It is only deferred
>> >to provide the hook for optional wordsets requiring their own literals
>> >compiled into the application after core.
>>
>> LITERAL? may be in the kernel of your Forth, but it is not a standard
>> word, and it is not in any shape or form present in the kernel of ciforth.
>>
>> <SNIP>
>>
>> Groetjes Albert
>
>Why should it mimick ciforth at all? Do you advocate ciforth as
reference implementation? (I don't want to be pointed, I admire its
compactness, really.)
It can be a counter example without being a reference implementation.
>F83 had NUMBER? long ago, Win32Forth has the similar DOUBLE? today.
LITERAL? just adds a compilation token for the specific scalar type.
It is as simple as that.
>
ciforth has nothing similar. One counter example is sufficient to destroy
a theorem, in science.
(To be more precise, it avoids the situation that it has to look up which
or whether recognizer is applicable. The dictionary does the deciding.)
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]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-08 09:23 -0700 |
| Message-ID | <e65ab07d-f5ac-401d-9d1e-9a75ee101820@googlegroups.com> |
| In reply to | #58842 |
Am Montag, 8. Mai 2017 17:16:40 UTC+2 schrieb Albert van der Horst: > In article <a9c5bc21-4a0f-42d4-95bd-a3df1c715c1b@googlegroups.com>, > <minforth@arcor.de> wrote: > >Am Montag, 8. Mai 2017 16:28:40 UTC+2 schrieb Albert van der Horst: > >> In article <8cadc102-38e0-4d49-8104-e394859b64da@googlegroups.com>, > >> <minforth@arcor.de> wrote: > >> <SNIP> > >> > > >> >LITERAL? is already and always set in the kernel. It is only deferred > >> >to provide the hook for optional wordsets requiring their own literals > >> >compiled into the application after core. > >> > >> LITERAL? may be in the kernel of your Forth, but it is not a standard > >> word, and it is not in any shape or form present in the kernel of ciforth. > >> > >> <SNIP> > >> > >> Groetjes Albert > > > >Why should it mimick ciforth at all? Do you advocate ciforth as > reference implementation? (I don't want to be pointed, I admire its > compactness, really.) > > It can be a counter example without being a reference implementation. > > >F83 had NUMBER? long ago, Win32Forth has the similar DOUBLE? today. > LITERAL? just adds a compilation token for the specific scalar type. > It is as simple as that. > > > > ciforth has nothing similar. One counter example is sufficient to destroy > a theorem, in science. > (To be more precise, it avoids the situation that it has to look up which > or whether recognizer is applicable. The dictionary does the deciding.) > > 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 For sure there are many ways to Rome. I read about your "denotations". For my part they seem more complex than the traditional way, and if I understand them correctly one should avoid using words with reserved prefixes.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-08 16:31 +0000 |
| Message-ID | <2017May8.183127@mips.complang.tuwien.ac.at> |
| In reply to | #58818 |
minforth@arcor.de writes:
>Since unknown times we have the deferred word LITERAL?
>In the kernel it is simply defined as
>
>DEFER LITERAL? ( a u 0 | x.. ct true -- ) \ convert text to integer numbers
>:NONAME number? IF ['] , ELSE 0 THEN ;
Let's see:
[~:95212] sf
SwiftForth i386-Linux 3.6.3 29-Jun-2016
see literal? literal? ?
[~:95213] vfxlin
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
see literal?
Err# -13 ERR: Undefined word.
-> see literal?
^
bye [~:95214] gforth
Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
see literal?
:1: Undefined word
see >>>literal?<<<
Backtrace:
$7FD55C21C748 throw
>: INTERPRET \ ( -- ) outer interpret/compile loop
> BEGIN bl word dup c@
> WHILE find ?dup IF
> < .. interpret/compile words .. >
> ELSE drop literal? ( a u 0 | x.. ct t -- ) not -13 ?throw
> state @ IF execute ELSE drop THEN
> THEN
> REPEAT drop ;
>
>When the Floating-Point Wordset is included, LITERAL? is extended
>
>:NONAME \ ( a u -- a u 0 | x.. ct true ) add float literals to the interpreter
> ACTION-OF literal? ?dup IF EXIT THEN
> base @ 10 =
> IF 2dup >float
> IF 2drop ['] fliteral true EXIT THEN
> THEN
> 0 ; IS LITERAL?
>
>The same principle is used for double numbers and fixed point numbers.
>
>This is so straightforward and simple that I really can't see any added benefit from recognizers.
Benefits of the present proposal:
1) It is a proper proposal rather than just some unspecified
something. Still, even from this example I can see some advantages of
the recognizer proposal over this:
2) Recognizers are independent of each other, and can be arranged on
the recognizer stack as needed, including removing some recognizers.
3) I can POSTPONE recognized things.
- 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 | mhx@iae.nl |
|---|---|
| Date | 2017-05-08 11:14 -0700 |
| Message-ID | <fdd7e26b-ed21-47b3-bc6d-167235612fd1@googlegroups.com> |
| In reply to | #58849 |
On Monday, May 8, 2017 at 6:49:59 PM UTC+2, Anton Ertl wrote:
> minforth@arcor.de writes:
> >Since unknown times we have the deferred word LITERAL?
> >In the kernel it is simply defined as
> >
> >DEFER LITERAL? ( a u 0 | x.. ct true -- ) \ convert text to integer numbers
> >:NONAME number? IF ['] , ELSE 0 THEN ;
>
> Let's see:
>
> [~:95212] sf
> SwiftForth i386-Linux 3.6.3 29-Jun-2016
> see literal? literal? ?
>
> [~:95213] vfxlin
> VFX Forth for Linux IA32 Version: 4.72 [build 0555]
> see literal?
> Err# -13 ERR: Undefined word.
> -> see literal?
> ^
> bye [~:95214] gforth
> Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> see literal?
> :1: Undefined word
> see >>>literal?<<<
> Backtrace:
> $7FD55C21C748 throw
>
> >: INTERPRET \ ( -- ) outer interpret/compile loop
> > BEGIN bl word dup c@
> > WHILE find ?dup IF
> > < .. interpret/compile words .. >
> > ELSE drop literal? ( a u 0 | x.. ct t -- ) not -13 ?throw
> > state @ IF execute ELSE drop THEN
> > THEN
> > REPEAT drop ;
> >
> >When the Floating-Point Wordset is included, LITERAL? is extended
> >
> >:NONAME \ ( a u -- a u 0 | x.. ct true ) add float literals to the
> > interpreter ACTION-OF literal? ?dup IF EXIT THEN
> > base @ 10 =
> > IF 2dup >float
> > IF 2drop ['] fliteral true EXIT THEN
> > THEN
> > 0 ; IS LITERAL?
> >
> >The same principle is used for double numbers and fixed point numbers.
> >
> >This is so straightforward and simple that I really can't see any
> >added benefit from recognizers.
>
> Benefits of the present proposal:
>
> 1) It is a proper proposal rather than just some unspecified
> something. Still, even from this example I can see some advantages of
> the recognizer proposal over this:
>
> 2) Recognizers are independent of each other, and can be arranged on
> the recognizer stack as needed, including removing some recognizers.
>
> 3) I can POSTPONE recognized things.
>
> - anton
Maybe you should try NUMBER? and increase the
number of queried systems.
FORTH> help number?
NUMBER? "number-query" IFORTH
( c-addr u -- c-addr u 0 | n 1 | d 2 ) or ( c-addr u -- 9 ) ( F: -- r )
c-addr and u is the start address of a counted string. An attempt is
made to convert the string into a literal. First an attempt is made to
convert the string to a single number, then an attempt is made to convert
the string to a double number and finally it is attempted to convert the
string to a floating point number. If all conversions fail, return c-addr
u and the constant 0.
Otherwise place the value of the conversion on the appropriate stack and
push the constant 1, 2 or 9 for a single number, a double number or a
floating point number.
'NUMBER contains the execution token of NUMBER? when a standard iForth
system is booted. The system can be made to recognize additional number
types by defining the new word XNUMBERS? . This word first calls the
old NUMBER? and reacts on a ( c-addr u 0 ) with a special parsing
routine. The iForth compiler will compile as many literals as NUMBER?
tells it there are. So if XNUMBERS? returns ( c-addr u -- n1 n2 n3 3 )
the effect will be n1 LITERAL n2 LITERAL n3 LITERAL . The maximum number
of LITERALs that can be compiled in this way is 8. This setup does
not work for floating-point literals, so ( c-addr -- 10 ) ( F: -- r1 r2 )
will not result in r1 FLITERAL r2 FLITERAL , but generates an error
condition instead.
See also: >NUMBER CONVERT 'NUMBER
This has been available since at least 1996. I think it was
already in tForth.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-08 19:27 +0100 |
| Message-ID | <oeqd3f$fu1$1@dont-email.me> |
| In reply to | #58855 |
On 5/8/2017 19:14, mhx@iae.nl wrote: > On Monday, May 8, 2017 at 6:49:59 PM UTC+2, Anton Ertl wrote: >> minforth@arcor.de writes: >>> Since unknown times we have the deferred word LITERAL? >>> In the kernel it is simply defined as >>> >>> DEFER LITERAL? ( a u 0 | x.. ct true -- ) \ convert text to integer numbers >>> :NONAME number? IF ['] , ELSE 0 THEN ; >> >> Let's see: >> >> [~:95212] sf >> SwiftForth i386-Linux 3.6.3 29-Jun-2016 >> see literal? literal? ? >> >> [~:95213] vfxlin >> VFX Forth for Linux IA32 Version: 4.72 [build 0555] >> see literal? >> Err# -13 ERR: Undefined word. >> -> see literal? >> ^ >> bye [~:95214] gforth >> Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc. >> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' >> Type `bye' to exit >> see literal? >> :1: Undefined word >> see >>>literal?<<< >> Backtrace: >> $7FD55C21C748 throw >> >>> : INTERPRET \ ( -- ) outer interpret/compile loop >>> BEGIN bl word dup c@ >>> WHILE find ?dup IF >>> < .. interpret/compile words .. > >>> ELSE drop literal? ( a u 0 | x.. ct t -- ) not -13 ?throw >>> state @ IF execute ELSE drop THEN >>> THEN >>> REPEAT drop ; >>> >>> When the Floating-Point Wordset is included, LITERAL? is extended >>> >>> :NONAME \ ( a u -- a u 0 | x.. ct true ) add float literals to the >>> interpreter ACTION-OF literal? ?dup IF EXIT THEN >>> base @ 10 = >>> IF 2dup >float >>> IF 2drop ['] fliteral true EXIT THEN >>> THEN >>> 0 ; IS LITERAL? >>> >>> The same principle is used for double numbers and fixed point numbers. >>> >>> This is so straightforward and simple that I really can't see any >>> added benefit from recognizers. >> >> Benefits of the present proposal: >> >> 1) It is a proper proposal rather than just some unspecified >> something. Still, even from this example I can see some advantages of >> the recognizer proposal over this: >> >> 2) Recognizers are independent of each other, and can be arranged on >> the recognizer stack as needed, including removing some recognizers. >> >> 3) I can POSTPONE recognized things. >> >> - anton > > Maybe you should try NUMBER? and increase the > number of queried systems. > > FORTH> help number? > NUMBER? "number-query" IFORTH > ( c-addr u -- c-addr u 0 | n 1 | d 2 ) or ( c-addr u -- 9 ) ( F: -- r ) > c-addr and u is the start address of a counted string. An attempt is > made to convert the string into a literal. First an attempt is made to > convert the string to a single number, then an attempt is made to convert > the string to a double number and finally it is attempted to convert the > string to a floating point number. If all conversions fail, return c-addr > u and the constant 0. > Otherwise place the value of the conversion on the appropriate stack and > push the constant 1, 2 or 9 for a single number, a double number or a > floating point number. > 'NUMBER contains the execution token of NUMBER? when a standard iForth > system is booted. The system can be made to recognize additional number > types by defining the new word XNUMBERS? . This word first calls the > old NUMBER? and reacts on a ( c-addr u 0 ) with a special parsing > routine. The iForth compiler will compile as many literals as NUMBER? > tells it there are. So if XNUMBERS? returns ( c-addr u -- n1 n2 n3 3 ) > the effect will be n1 LITERAL n2 LITERAL n3 LITERAL . The maximum number > of LITERALs that can be compiled in this way is 8. This setup does > not work for floating-point literals, so ( c-addr -- 10 ) ( F: -- r1 r2 ) > will not result in r1 FLITERAL r2 FLITERAL , but generates an error > condition instead. > See also: >NUMBER CONVERT 'NUMBER > > This has been available since at least 1996. I think it was > already in tForth. > > -marcel > win32Forth has a complete different NUMBER? that returns 2 cells and a flag ( addr len -- d f ). The flag indicates single cell, double cell or float. Floats are converted off stack. The conversions are on a chain (a list) that is run through one by one; and THROW is used to indicate failure (a bit like DT:NULL in the present proposal). Conversions get added to the end of the list. It works OK, but it's nowhere as clean. The one advantage is being able to THROW rather than stack tidy and DT:NULL to indicate failure. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-09 16:39 +0200 |
| Message-ID | <oeskam$ark$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #58855 |
In article <fdd7e26b-ed21-47b3-bc6d-167235612fd1@googlegroups.com>, <mhx@iae.nl> wrote: >On Monday, May 8, 2017 at 6:49:59 PM UTC+2, Anton Ertl wrote: >> minforth@arcor.de writes: >> >Since unknown times we have the deferred word LITERAL? >> >In the kernel it is simply defined as >> > >> >DEFER LITERAL? ( a u 0 | x.. ct true -- ) \ convert text to integer numbers >> >:NONAME number? IF ['] , ELSE 0 THEN ; >> >> Let's see: >> >> [~:95212] sf >> SwiftForth i386-Linux 3.6.3 29-Jun-2016 >> see literal? literal? ? >> >> [~:95213] vfxlin >> VFX Forth for Linux IA32 Version: 4.72 [build 0555] >> see literal? >> Err# -13 ERR: Undefined word. >> -> see literal? >> ^ >> bye [~:95214] gforth >> Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc. >> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' >> Type `bye' to exit >> see literal? >> :1: Undefined word >> see >>>literal?<<< >> Backtrace: >> $7FD55C21C748 throw >> >> >: INTERPRET \ ( -- ) outer interpret/compile loop >> > BEGIN bl word dup c@ >> > WHILE find ?dup IF >> > < .. interpret/compile words .. > >> > ELSE drop literal? ( a u 0 | x.. ct t -- ) not -13 ?throw >> > state @ IF execute ELSE drop THEN >> > THEN >> > REPEAT drop ; >> > >> >When the Floating-Point Wordset is included, LITERAL? is extended >> > >> >:NONAME \ ( a u -- a u 0 | x.. ct true ) add float literals to the >> > interpreter ACTION-OF literal? ?dup IF EXIT THEN >> > base @ 10 = >> > IF 2dup >float >> > IF 2drop ['] fliteral true EXIT THEN >> > THEN >> > 0 ; IS LITERAL? >> > >> >The same principle is used for double numbers and fixed point numbers. >> > >> >This is so straightforward and simple that I really can't see any >> >added benefit from recognizers. >> >> Benefits of the present proposal: >> >> 1) It is a proper proposal rather than just some unspecified >> something. Still, even from this example I can see some advantages of >> the recognizer proposal over this: >> >> 2) Recognizers are independent of each other, and can be arranged on >> the recognizer stack as needed, including removing some recognizers. >> >> 3) I can POSTPONE recognized things. >> >> - anton > >Maybe you should try NUMBER? and increase the >number of queried systems. > >FORTH> help number? >NUMBER? "number-query" IFORTH > ( c-addr u -- c-addr u 0 | n 1 | d 2 ) or ( c-addr u -- 9 ) ( F: -- r ) > c-addr and u is the start address of a counted string. An attempt is > made to convert the string into a literal. First an attempt is made to > convert the string to a single number, then an attempt is made to convert > the string to a double number and finally it is attempted to convert the > string to a floating point number. If all conversions fail, return c-addr > u and the constant 0. > Otherwise place the value of the conversion on the appropriate stack and > push the constant 1, 2 or 9 for a single number, a double number or a > floating point number. > 'NUMBER contains the execution token of NUMBER? when a standard iForth > system is booted. The system can be made to recognize additional number > types by defining the new word XNUMBERS? . This word first calls the > old NUMBER? and reacts on a ( c-addr u 0 ) with a special parsing > routine. The iForth compiler will compile as many literals as NUMBER? > tells it there are. So if XNUMBERS? returns ( c-addr u -- n1 n2 n3 3 ) > the effect will be n1 LITERAL n2 LITERAL n3 LITERAL . The maximum number > of LITERALs that can be compiled in this way is 8. This setup does > not work for floating-point literals, so ( c-addr -- 10 ) ( F: -- r1 r2 ) > will not result in r1 FLITERAL r2 FLITERAL , but generates an error > condition instead. > See also: >NUMBER CONVERT 'NUMBER > >This has been available since at least 1996. I think it was >already in tForth. It is, and I was going to present this as a precursor to the current proposal of recognizers. I hope Anton Ertl will comment on the differences and relative merits. > >-marcel -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-09 14:53 +0000 |
| Message-ID | <2017May9.165338@mips.complang.tuwien.ac.at> |
| In reply to | #58855 |
mhx@iae.nl writes:
>On Monday, May 8, 2017 at 6:49:59 PM UTC+2, Anton Ertl wrote:
>> minforth@arcor.de writes:
>> >Since unknown times we have the deferred word LITERAL?
[not in SwiftForth, VFX, or Gforth]
>Maybe you should try NUMBER? and increase the
>number of queried systems.
Well, at least a word with that name is present in SwiftForth and VFX.
In VFX its stack effect is ( addr -- d 2 | n 1 | 0 ); note the absence
of the u. It also is documented to convert FP numbers if the FP
wordset is present, but it does not document the stack effect in this
case.
In SwiftForth it has the stack effect ( addr u -- 0 | n 1 | d 2 ), and
it does not work for FP numbers (at least that's not documented).
>FORTH> help number?
>NUMBER? "number-query" IFORTH
> ( c-addr u -- c-addr u 0 | n 1 | d 2 ) or ( c-addr u -- 9 ) ( F: -- r )
> c-addr and u is the start address of a counted string. An attempt is
> made to convert the string into a literal. First an attempt is made to
> convert the string to a single number, then an attempt is made to convert
> the string to a double number and finally it is attempted to convert the
> string to a floating point number. If all conversions fail, return c-addr
> u and the constant 0.
> Otherwise place the value of the conversion on the appropriate stack and
> push the constant 1, 2 or 9 for a single number, a double number or a
> floating point number.
> 'NUMBER contains the execution token of NUMBER? when a standard iForth
> system is booted. The system can be made to recognize additional number
> types by defining the new word XNUMBERS? . This word first calls the
> old NUMBER? and reacts on a ( c-addr u 0 ) with a special parsing
> routine. The iForth compiler will compile as many literals as NUMBER?
> tells it there are. So if XNUMBERS? returns ( c-addr u -- n1 n2 n3 3 )
> the effect will be n1 LITERAL n2 LITERAL n3 LITERAL . The maximum number
> of LITERALs that can be compiled in this way is 8. This setup does
> not work for floating-point literals, so ( c-addr -- 10 ) ( F: -- r1 r2 )
> will not result in r1 FLITERAL r2 FLITERAL , but generates an error
> condition instead.
This word is another good reason to go for the recognizers proposal.
All the reasons that resulted in this horrible stack effect is nicely
factored into the dt-token in the proposal.
So you can have several recognizers, each with a nicer stack effect:
rec:single ( c-addr u -- n dt:single | dt:null )
rec:double ( c-addr u -- d dt:double | dt:null )
rec:float ( c-addr u -- r dt:float | dt:null )
And let's see what happens if we add, say, string recognition: For
NUMBER?, you have to add another result tag, e.g., 19. But now every
place that calls NUMBER? has to be upgraded to be able to deal with
this 19 tage and call SLITERAL when compiling.
By contrast, with the recognizer proposal, every place that calls
RECOGNIZE does the right thing for every new data type that you throw
at it automatically. That's because the right action is provided by
the recogizer through dt-token.
In other words, RECOGNIZE is a better-factored version of NUMBER?.
- 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]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web