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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-09 20:43 -0700 |
| Message-ID | <4f34e8c9-f0fc-4337-afa8-365f2f2707f6@googlegroups.com> |
| In reply to | #58896 |
On Wednesday, May 10, 2017 at 12:32:07 AM UTC+9, Anton Ertl wrote: > mhx@somewhere writes: > >On Monday, May 8, 2017 at 6:49:59 PM UTC+2, Anton Ertl wrote: > >> minforth@somewhere 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?. Okay, now I see what this conversation is all about. I had just thought of recognizing 1.014e-7 as just being a little more work than recognizing the sign character. Still, if we aren't careful, we could end up with a push-back parametered macro text substitution engine shoe-horned into EXPECT or whatever the standard word for EXPECT is. I've been stuck in that conundrum several times, but that doesn't mean there isn't a way out of it. If we want to put a "back door" in the interpreter for generalized infix syntax, that's probably the place to put it. And it's going to be a cause for security concerns. It might need something to turn it off, or alternative interpreters that don't do it, for hostile input environments. -- Joel Rees Delusions of reinventing the industry all by myself: http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-08 15:02 -0700 |
| Message-ID | <7f7df85d-33dc-45e3-b33e-e3526dca5e3e@googlegroups.com> |
| In reply to | #58849 |
Am Montag, 8. Mai 2017 18:49:59 UTC+2 schrieb Anton Ertl: > 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. > Sounds to me as useful as illuminated tyres on a car. But there is a market for everything.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-09 12:24 +0100 |
| Message-ID | <oes8mp$mjr$1@dont-email.me> |
| In reply to | #58866 |
On 5/8/2017 23:02, minforth@arcor.de wrote: > Am Montag, 8. Mai 2017 18:49:59 UTC+2 schrieb Anton Ertl: > >> 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. >> > > Sounds to me as useful as illuminated tyres on a car. > But there is a market for everything. > Tron. Terrible film, lots of illuminated tyres. “This is the biggest fool thing we have ever done. The bomb will never go off, and I speak as an expert in explosives.” — Admiral William D. Leahy. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-07 23:34 +0000 |
| Message-ID | <oeoatm$3p2$4@dont-email.me> |
| In reply to | #58758 |
Am Sun, 07 May 2017 03:54:43 -0500 schrieb Andrew Haley: >> But your objection is "people will be able to shoot into their foot if >> they are not careful"! > > No, it's not. It's more that the proposal is more general than is > needed and its most far-out features will not help and at worst will > increase the burden of maintanance. What's the difference between "will increase the burden of maintenance" and "people will be able to shoot into their foot"? Apart from the wording? And about "more general than needed": Not according to my researches. The existing hooks cover everything including a full replacement of the Forth interpreter, which is why I actually can implement recognizers as proposed on VFX (and could do the same on SwiftForth, which is probably the next thing I do). Every single hook that went into VFX went there, because one particular customer or implementer asked for one particular, limited-scope extension of the interpreter. And it grew to exactly the same "everything is possible" situation we have with recognizers. With the exception that each hook has its own special-purpose task and limitation, with the exception of the "replace the entire interpreter"-hook. The same is true for SwiftForth. Forth Inc. did not add as many hooks, but decided to add the general-purpose "replace everything" hook early on (COMPILING and INTERPRETING are the two deferred words), and by doing so likely muted any further request for special-purpose hooks. We are already in the "here be dragons" country. You make lame excuses that the dragon maybe is only a lizard, or a big bat or so, and someone has lighted a campfire. No, the dragon is already there, hiding behind a bunch of hooks. The only thing the recognizer proposal makes is to standardize these already existing, but wildly incompatible interpreter hooks. And to do that, without taking any of the existing capabilities away, it must be as general as it is now. Or maybe even more general, as SwiftForth's hooks also can replace the BL WORD or PARSE-NAME part of the outer interpreter. We have discussed whether each recognizer should do the parsing itself or leave it to the fixed part of the proposal, and decided for the second: Forth source is words, i.e. blank-separated stuff. The recognizer itself however can know that the addr u it gets is part of the current input buffer (i.e. SOURCE), and it is allowed to manipulate >IN if it recognizes something. -- 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 | pahihu <pahihu@gmail.com> |
|---|---|
| Date | 2017-05-08 01:17 -0700 |
| Message-ID | <ef09e180-51e7-4d36-90cc-88cb810554dc@googlegroups.com> |
| In reply to | #58797 |
> The same is true for SwiftForth. Forth Inc. did not add as many hooks, > but decided to add the general-purpose "replace everything" hook early on > (COMPILING and INTERPRETING are the two deferred words), and by doing so > likely muted any further request for special-purpose hooks. Isn't the deferred words COMPILING/INTERPRETING simpler than the recognizers proposal ? pahihu
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-08 12:30 +0000 |
| Message-ID | <oepod9$tkf$1@dont-email.me> |
| In reply to | #58806 |
Am Mon, 08 May 2017 01:17:29 -0700 schrieb pahihu: >> The same is true for SwiftForth. Forth Inc. did not add as many hooks, >> but decided to add the general-purpose "replace everything" hook early >> on (COMPILING and INTERPRETING are the two deferred words), and by >> doing so likely muted any further request for special-purpose hooks. > > Isn't the deferred words COMPILING/INTERPRETING simpler than the > recognizers proposal ? No, because it requires the user to completely reimplement the outer interpreter on every extension he wants to make. This is a lot more complex, and the factors used for the outer interpreter already available in the system are non-standard, too. -- 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 | pahihu <pahihu@gmail.com> |
|---|---|
| Date | 2017-05-08 07:49 -0700 |
| Message-ID | <443902c9-fe65-414e-812d-117fd3241bcc@googlegroups.com> |
| In reply to | #58824 |
2017. május 8., hétfő 14:33:52 UTC+2 időpontban Bernd Paysan a következőt írta: > Am Mon, 08 May 2017 01:17:29 -0700 schrieb pahihu: > > >> The same is true for SwiftForth. Forth Inc. did not add as many hooks, > >> but decided to add the general-purpose "replace everything" hook early > >> on (COMPILING and INTERPRETING are the two deferred words), and by > >> doing so likely muted any further request for special-purpose hooks. > > > > Isn't the deferred words COMPILING/INTERPRETING simpler than the > > recognizers proposal ? > > No, because it requires the user to completely reimplement the outer > interpreter on every extension he wants to make. This is a lot more > complex, and the factors used for the outer interpreter already available > in the system are non-standard, too. My thinking was along the words "...by doing so likely muted any further request for special-purpose hooks". Is there a standard way to implement the outer interpreter ? If there is you could implement it using recognizers. pahihu
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-08 10:58 -0500 |
| Message-ID | <0tCdnZzDtpINCI3EnZ2dnUU7-SmdnZ2d@supernews.com> |
| In reply to | #58837 |
pahihu <pahihu@gmail.com> wrote: > My thinking was along the words > "...by doing so likely muted any further request for special-purpose hooks". > > Is there a standard way to implement the outer interpreter ? There nearly is. It's been the subject of much discussion over the years, but it's generally accepted that it should be possible to write a standard-conforming test interpreter in Standard Forth. I think that there is a way to interpret the standard in which this wouldn't work, but AFAIK nobody does so. > If there is you could implement it using recognizers. I think so. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-08 11:44 +0000 |
| Message-ID | <2017May8.134427@mips.complang.tuwien.ac.at> |
| In reply to | #58806 |
pahihu <pahihu@gmail.com> writes:
>> The same is true for SwiftForth. Forth Inc. did not add as many hooks,
>> but decided to add the general-purpose "replace everything" hook early on
>> (COMPILING and INTERPRETING are the two deferred words), and by doing so
>> likely muted any further request for special-purpose hooks.
>
>Isn't the deferred words COMPILING/INTERPRETING simpler than the recognizers
>proposal ?
No. INTERPRETING and COMPILING parse and process a whole line (or
until the state changes). Looks wrongly factored to me, possibly a
remnant of the time when [ was the compiler loop.
Closer to the functionality of recognizers you have IS-KNOWN? (for
dictionary search) and IS-NUMBER? (for other recognizers), where
IS-NUMBER? is deferred, and IS-KNOWN? has a hook (FINDEXT) running
before dictionary search.
Is that simpler? Maybe.
Is it as capable? No.
Does it have a better chance of being standarized? I have my doubts.
E.g., it does not work as nicely with ]] ... [[, which is supported by
several systems, and I don't know if you can use it to do everything
that VFX's interpreter hooks can do.
But if you think we should standardize on that, go ahead and produce a
proposal.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | pahihu <pahihu@gmail.com> |
|---|---|
| Date | 2017-05-08 08:04 -0700 |
| Message-ID | <1e139225-3735-458b-b8d2-fde65fed0bc9@googlegroups.com> |
| In reply to | #58825 |
> > Is it as capable? No. > > Does it have a better chance of being standarized? I have my doubts. > E.g., it does not work as nicely with ]] ... [[, which is supported by > several systems, and I don't know if you can use it to do everything > that VFX's interpreter hooks can do. I see that the proposal is very capable and I like very much the interpret/compile/postpone distinctions. There is no way to replace the outer interpreter which uses recognizers in a standard way ? > But if you think we should standardize on that, go ahead and produce a > proposal. > No, thanks. I am using FiCL since 2005 or so and it has parse-steps. pahihu
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-08 17:30 +0000 |
| Message-ID | <2017May8.193009@mips.complang.tuwien.ac.at> |
| In reply to | #58840 |
pahihu <pahihu@gmail.com> writes:
>There is no way to replace the outer interpreter which uses recognizers
>in a standard way ?
If your question is if there is a standard mechanism to replace the
text interpreter, so that we can replace it with a recognizer-based
text interpreter, then no. However, the majority of systems have
several hooks in the text interpreter, and usually one can be used to
plug in a recognizer-based text interpreter (in a system-specific
way).
- 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 | pahihu <pahihu@gmail.com> |
|---|---|
| Date | 2017-05-10 04:07 -0700 |
| Message-ID | <768e8435-91e6-4ad9-9f80-2566a46d4c75@googlegroups.com> |
| In reply to | #58852 |
2017. május 8., hétfő 19:34:45 UTC+2 időpontban Anton Ertl a következőt írta: > If your question is if there is a standard mechanism to replace the > text interpreter, so that we can replace it with a recognizer-based > text interpreter, then no. Yes, I read thru the c.l.f archives and found J.Thomas and J.Brien in 1998 as trying to replace it with a standard text interpreter. Thomas proposed the EVALUATE hack - modifying the buffer after EVALUATE is called. In one of your 1998 papers you provided a standard solution to avoid STATE-smartness, so the current standard is already capable of doing that. > However, the majority of systems have > several hooks in the text interpreter, and usually one can be used to > plug in a recognizer-based text interpreter (in a system-specific > way). Why not standardize then the text interpreter hook for "unrecognized" words ? It is much less than recognizers, and combined with your 1998 solution to avoid STATE-smartness it is available now. If the majority of the systems already support this type of hook, why not standardize that ? Of course, it is less capable than the current recognizers proposal. Although I like the recognizer proposal as a generic solution, it feels that it mandates a specific implementation for the text interpreter loop and the interpreter/compiler/postpone semantics. pahihu
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-05-10 14:11 +0300 |
| Message-ID | <oeusb5$hdm$1@dont-email.me> |
| In reply to | #58962 |
On 05/10/17 14:07, pahihu wrote: > Why not standardize then the text interpreter hook for "unrecognized" > words ? It is much less than recognizers, and combined with your 1998 > solution to avoid STATE-smartness it is available now. That's exactly what 8th does. If it can't figure out what the thing it parsed is supposed to be, it invokes "???" with the string of the thing in question. Since "???" is deferred, the user can put whatever there.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-10 13:59 +0200 |
| Message-ID | <86fugcapnm.fsf@molnjunk.nocrew.org> |
| In reply to | #58963 |
Ron Aaron wrote: > That's exactly what 8th does. If it can't figure out what the thing it > parsed is supposed to be, it invokes "???" with the string of the thing > in question. Since "???" is deferred, the user can put whatever there. In my Forth, that deferred word is called NUMBER ( a u -- ). You can probably guess what the default action is.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-10 14:04 +0100 |
| Message-ID | <oev2u1$867$1@dont-email.me> |
| In reply to | #58968 |
On 5/10/2017 12:59, Lars Brinkhoff wrote: > Ron Aaron wrote: >> That's exactly what 8th does. If it can't figure out what the thing it >> parsed is supposed to be, it invokes "???" with the string of the thing >> in question. Since "???" is deferred, the user can put whatever there. > > In my Forth, that deferred word is called NUMBER ( a u -- ). You can > probably guess what the default action is. > Yes, I can. If someone is using it when I try and replace the deferred word NUMBER, I guess the combined action is potential failure. None of the "just use this hook in the interpreter" have had (so far) proposed 1. a standard signature 2. a standard mechanism for interpreting, compiling or postponing the result 3. a formal way of accommodating two or more parses. I suspect no-one will put forward a proposal based on defining a LAST-CHANCE_SALOON. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-10 14:06 +0100 |
| Message-ID | <oev329$867$2@dont-email.me> |
| In reply to | #58975 |
On 5/10/2017 14:04, Alex wrote: > On 5/10/2017 12:59, Lars Brinkhoff wrote: >> Ron Aaron wrote: >>> That's exactly what 8th does. If it can't figure out what the thing it >>> parsed is supposed to be, it invokes "???" with the string of the thing >>> in question. Since "???" is deferred, the user can put whatever there. >> >> In my Forth, that deferred word is called NUMBER ( a u -- ). You can >> probably guess what the default action is. >> > > Yes, I can. If someone is using it when I try and replace the deferred > word NUMBER, I guess the combined action is potential failure. > > None of the "just use this hook in the interpreter" have had (so far) > proposed > I must stop typing at speed. But you get the gist. > 1. a standard signature > 2. a standard mechanism for interpreting, compiling or postponing the > result > 3. a formal way of accommodating two or more parses. > > I suspect no-one will put forward a proposal based on defining a > LAST-CHANCE_SALOON. > -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-10 13:02 +0100 |
| Message-ID | <oeuva3$r9u$1@dont-email.me> |
| In reply to | #58963 |
On 5/10/2017 12:11, Ron Aaron wrote: > > > On 05/10/17 14:07, pahihu wrote: > >> Why not standardize then the text interpreter hook for "unrecognized" >> words ? It is much less than recognizers, and combined with your 1998 >> solution to avoid STATE-smartness it is available now. > > That's exactly what 8th does. If it can't figure out what the thing it > parsed is supposed to be, it invokes "???" with the string of the thing > in question. Since "???" is deferred, the user can put whatever there. > That's fine if you want to be last and you're happy for someone else to have figured it out for you. Not so great if you would like to be first (to avoid system X's handling of "quoted strings" ruining your DSL like JSON parse) or if you are meta-pootering (of which meta-compiling is one application). Perhaps (only slightly tongue in cheek) you need YOU-HAVE-A-GO before your "recognizers" and a AH-WELL-ONE-LAST-TRY for when the default parsing wheels fall off. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | pahihu <pahihu@gmail.com> |
|---|---|
| Date | 2017-05-10 06:07 -0700 |
| Message-ID | <629ee77a-f263-4e01-b2b2-824e85ae6366@googlegroups.com> |
| In reply to | #58969 |
2017. május 10., szerda 14:02:18 UTC+2 időpontban Alex a következőt írta:
> Not so great if you would like to be first
> (to avoid system X's handling of "quoted strings" ruining your DSL like
> JSON parse)
I don't see any advantage to parse the following snippet with a JSON parser implemented using recognizers, except if I could replace BL WORD/PARSE-NAME
with my own version.
pahihu
[{"a":{"e":{"e":161,"a":"blue","d":{"e":-14,"a":"red","d":{"c":"yellow","a":[-35
,0],"b":"orange","d":{"e":70,"a":"green","d":"blue","j":12,"c":69,"h":"orange","
b":92,"g":"yellow","f":"green","i":121}},"c":"blue","h":14,"b":46,"g":62,"f":[17
9]},"j":{"e":133,"c":"violet","a":"orange","b":"blue","d":"violet"}
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-10 14:30 +0100 |
| Message-ID | <oev4er$dcb$1@dont-email.me> |
| In reply to | #58977 |
On 5/10/2017 14:07, pahihu wrote:
> 2017. május 10., szerda 14:02:18 UTC+2 időpontban Alex a következőt írta:
>> Not so great if you would like to be first
>> (to avoid system X's handling of "quoted strings" ruining your DSL like
>> JSON parse)
>
> I don't see any advantage to parse the following snippet with a JSON parser implemented using recognizers, except if I could replace BL WORD/PARSE-NAME
> with my own version.
>
> pahihu
>
>
> [{"a":{"e":{"e":161,"a":"blue","d":{"e":-14,"a":"red","d":{"c":"yellow","a":[-35
> ,0],"b":"orange","d":{"e":70,"a":"green","d":"blue","j":12,"c":69,"h":"orange","
> b":92,"g":"yellow","f":"green","i":121}},"c":"blue","h":14,"b":46,"g":62,"f":[17
> 9]},"j":{"e":133,"c":"violet","a":"orange","b":"blue","d":"violet"}
>
In your recognizer, parse the input buffer as you like (the tokeniser
for JSON is rather simple) and drive another set of recognizers for each
element. Or even employ existing recognizers, say for quoted strings and
numbers.
The advantage is that you can parse (even across white space, and you
can REFILL too) and recognize as you see fit; and then have a consistent
set of ways to interpret, compile and postpone the result.
Doing this in a Forth without recognizers will require hooking in
differently for each, and reusing the parse (say, for numbers) will
probably be difficult to impossible.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-10 11:59 -0700 |
| Message-ID | <3e7e8e10-3793-4448-b027-8221095e5ac6@googlegroups.com> |
| In reply to | #58977 |
Am Mittwoch, 10. Mai 2017 15:07:23 UTC+2 schrieb pahihu: > 2017. május 10., szerda 14:02:18 UTC+2 időpontban Alex a következőt írta: > > Not so great if you would like to be first > > (to avoid system X's handling of "quoted strings" ruining your DSL like > > JSON parse) > > I don't see any advantage to parse the following snippet with a JSON parser > implemented using recognizers, except if I could replace BL WORD/PARSE-NAME > with my own version. Despite rumors, recognizers are not a hammer that sees every problem as nails. Matthias
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web