Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58497 > unrolled thread
| Started by | Alex <alex@rivadpm.com> |
|---|---|
| First post | 2017-05-02 15:27 +0100 |
| Last post | 2017-05-04 10:07 -0700 |
| Articles | 20 on this page of 177 — 26 participants |
Back to article view | Back to comp.lang.forth
Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 15:27 +0100
Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 07:52 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-02 08:19 -0700
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 08:27 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:55 +0100
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-03 02:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:16 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:05 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:23 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:26 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:03 -0500
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 12:44 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:36 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:28 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:13 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 12:35 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 18:53 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:10 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:22 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:53 +0000
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-03 07:39 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 10:58 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:53 +0000
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-06 01:21 +0000
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 00:22 -0700
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-06 23:05 +0100
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 22:36 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:38 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 04:49 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 05:03 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 09:02 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 07:45 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:24 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:45 -0700
Re: Recognizers discussion Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-03 10:08 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:56 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:37 +0100
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 11:07 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 20:55 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:47 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:07 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 07:59 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:38 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:42 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:43 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:05 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:10 +0300
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:25 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:33 +0300
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 08:05 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:54 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 11:10 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:49 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 16:14 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 13:02 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-05 23:29 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:56 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 22:42 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:08 -0500
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 08:51 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:38 -0700
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 09:59 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 10:16 -0700
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 22:04 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 22:09 -0700
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-07 19:50 -0700
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-07 21:33 -1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:12 -0500
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:21 -0700
FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 12:35 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:50 -0700
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 03:39 -0500
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-09 20:59 -0700
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:03 -0700
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:10 +0100
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:24 -1000
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:37 -0700
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 22:53 -1000
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:53 +0100
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:00 +0300
Re: FP stack Paul Rubin <no.email@nospam.invalid> - 2017-05-10 01:02 -0700
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:06 +0300
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:58 +0000
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 14:17 +0300
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 13:09 +0100
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 15:05 +0000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 11:43 +0200
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-10 18:34 +1000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:45 +0000
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-11 19:13 +1000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:50 -0500
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:18 +0000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 12:12 -0500
Re: FP stack stephen@mpeforth.com (Stephen Pelc) - 2017-05-11 13:53 +0000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 15:43 +0000
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-12 08:48 -0700
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:31 +0000
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 10:18 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 15:37 -0500
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 17:25 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 22:55 -0500
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-13 14:24 +1000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-13 13:44 +0200
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-10 05:58 -0500
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 13:50 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 00:25 -0700
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 11:39 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 11:49 -0700
Re: FP stack (was: Recognizers discussion) "HAA" <someone@microsoft.com> - 2017-05-09 21:15 +1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-09 14:16 +1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 08:57 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 07:54 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:30 -0500
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 14:05 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:42 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:51 -0500
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-04 22:29 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:41 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:06 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 07:36 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:21 +0000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:24 +0000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-04 20:17 +0200
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-05 11:03 +1000
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 00:16 -0700
Re: Recognizers discussion JUERGEN <epldfpga@aol.com> - 2017-05-05 13:15 -0700
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-06 16:49 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-05 21:00 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 14:17 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-09 15:46 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:50 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 13:11 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 13:49 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 15:57 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:17 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 09:25 -1000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 01:19 +0200
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-05 15:50 +0000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-08 11:43 +1000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-08 19:17 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 14:25 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:22 -1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-13 13:33 +1000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-12 21:32 -1000
Re: Recognizers discussion Howerd <howerdo@yahoo.co.uk> - 2017-05-13 07:12 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:30 +0000
Re: Recognizers discussion rickman <gnuarm@gmail.com> - 2017-05-04 11:37 -0400
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:51 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-05 07:31 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-05 20:35 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 12:27 -0700
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-05 15:03 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:26 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 18:17 +0100
Re: Recognizers discussion Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:26 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 21:39 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:58 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-07 10:39 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:39 +0000
Re: Recognizers discussion Paul Rubin <no.email@nospam.invalid> - 2017-05-07 17:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:40 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:25 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-08 16:25 +0200
Flash (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 10:51 +0000
Re: Flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 08:06 -0500
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 13:57 +0000
Re: Flash Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-07 16:46 +0200
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 16:31 +0100
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:16 +0000
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:18 +0100
Re: Flash albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 21:45 +0200
Re: Flash Matthias Trute <matthias.trute@gmail.com> - 2017-05-07 12:54 -0700
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:33 +0100
Re: Flash Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-07 08:50 -0700
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:21 +0000
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-04 10:07 -0700
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-05-03 07:39 +0100 |
| Message-ID | <oebtop$slh$1@dont-email.me> |
| In reply to | #58541 |
On 02/05/2017 23:53, Bernd Paysan wrote: > And one important factor for a clean design is that you have rules, but > no exceptions. The dictionary search is just one recognizer, nothing > special (people suggested that it's actually a stack of recognizers, with > each vocabulary in the search order being one recognizer). If this view of recognizers is taken wouldn't be better to extend words like SET-ORDER to include recognizers instead of having a new set of words with equivalents like SET-RECOGNIZERS -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-03 10:58 +0100 |
| Message-ID | <oec9de$1bo$1@dont-email.me> |
| In reply to | #58554 |
On 5/3/2017 07:39, Gerry Jackson wrote:
> On 02/05/2017 23:53, Bernd Paysan wrote:
>> And one important factor for a clean design is that you have rules, but
>> no exceptions. The dictionary search is just one recognizer, nothing
>> special (people suggested that it's actually a stack of recognizers, with
>> each vocabulary in the search order being one recognizer).
>
> If this view of recognizers is taken wouldn't be better to extend words
> like SET-ORDER to include recognizers instead of having a new set of
> words with equivalents like SET-RECOGNIZERS
>
The proposal suggests a route to this that doesn't clutter up a single
stack (the ORDER stack) with many number or extended recognizers by
having multiple stacks and re-driving the recognizer.
A stack for names would be driven by REC:ALLNAMES (this is shown as just
a simple wrapper for REC:FIND and FIND-NAME, see below, but is
extensible) and a stack for numbers driven by REC:ALLNUMS; then a system
wide stack that drives the entire parse (FORTH-RECOGNIZER).
\ recognize numbers
: rec:char ( addr len -- n dt:num | dt:null ) ... ;
: rec:snum ( addr len -- n dt:num | dt:null ) ... ;
: rec:dnum ( addr len -- d dt:dnum | dt:null ) ... ;
\ set up a stack for numbers
10 recognizer constant recstack:numbers
' rec:char ' rec:snum ' rec:dnum 3 recstack:numbers set-recognizers
\ driving the numbers recognizer; a super REC:
: rec:allnums ( addr len -- n dt:num | d dt:dnum | dt:null )
recstack:numbers recognize ;
\ recognize names
: rec:find ( addr u -- nt dt:name | dt:null )
find-name ?dup if dt:name else dt:null then ;
\ set up a stack for names qv ORDER
10 recognizer constant recstack:names
' rec:find 1 recstack:names set-recognizers
\ driving the names recognizer; a super REC:
: rec:allnames ( addr len -- n dt:num | d dt:dnum | dt:null )
recstack:names recognize ;
\ bring it all together
' rec:allnums ' rec:allnames 2 forth-recognizer set-recognizers
Now, you could replace REC:FIND with a recognizer for each vocabulary.
(Apropos this, my WF32 has an object-like wordlist; each provides
SEARCH-WORDLIST, header definition and iteration to support
TRAVERSE-WORDLIST pointers. SEARCH_WORDLIST is just a recognizer.)
Replace RECSTACK:NAMES stack with the ORDER stack; and now you have a
100% recognizer based system that is 100% compatible with ORDER ALSO
ONLY etc. In my system, invoking the vocabulary name (as in ALSO FORTH)
would take the FORTH vocabulary SEARCH-WORDLIST and add it to the
recognizer stack REC:ALLNAMES.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-04 13:53 +0000 |
| Message-ID | <2017May4.155349@mips.complang.tuwien.ac.at> |
| In reply to | #58554 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 02/05/2017 23:53, Bernd Paysan wrote:
>> And one important factor for a clean design is that you have rules, but
>> no exceptions. The dictionary search is just one recognizer, nothing
>> special (people suggested that it's actually a stack of recognizers, with
>> each vocabulary in the search order being one recognizer).
>
>If this view of recognizers is taken wouldn't be better to extend words
>like SET-ORDER to include recognizers instead of having a new set of
>words with equivalents like SET-RECOGNIZERS
That would be nice for a clean-sheet design, but it's hard to
reconcile with backwards compatibility. E.g., if you write
APP-WORDLIST 1 SET-ORDER
as a way of sealing the search order, the standard guarantees that
locals are still found first and that numbers (of all sorts) are still
found afterwards. If you want to be able to add something behind the
number recognizer, using SET-ORDER won't cut it.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-06 01:21 +0000 |
| Message-ID | <oej8e9$j6c$3@dont-email.me> |
| In reply to | #58554 |
Am Wed, 03 May 2017 07:39:39 +0100 schrieb Gerry Jackson: > On 02/05/2017 23:53, Bernd Paysan wrote: >> And one important factor for a clean design is that you have rules, but >> no exceptions. The dictionary search is just one recognizer, nothing >> special (people suggested that it's actually a stack of recognizers, >> with each vocabulary in the search order being one recognizer). > > If this view of recognizers is taken wouldn't be better to extend words > like SET-ORDER to include recognizers instead of having a new set of > words with equivalents like SET-RECOGNIZERS No, because SET-ORDER only affects what FIND can find, and FIND is not supposed to do the number parts of the recognizer. We however made sure that the word walking a recognizer stack has the same stack effect (plus taking the recognizer stack itself on TOS) as any other recognizer, so you can wrap a recognizer stack into a recognizer without problems. -- 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-06 00:22 -0700 |
| Message-ID | <c05cdb89-f3fe-4435-bf2f-90cc98a7c6bd@googlegroups.com> |
| In reply to | #58554 |
Off Topic: LexGen Hi, Are you Garry Jackson of LexGen fame ? Could you tell me where can I download the sources of LexGen on the net ? Thank you, Andras Pahi
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-05-06 23:05 +0100 |
| Message-ID | <oelh58$fa0$1@dont-email.me> |
| In reply to | #58727 |
On 06/05/2017 08:22, pahihu wrote: > Off Topic: LexGen > > Hi, > > Are you Garry Jackson of LexGen fame ? > Could you tell me where can I download the sources of LexGen on the net ? > It can be downloaded from http://qlikz.org/forth/archive/lexgen2.2.zip -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | pahihu <pahihu@gmail.com> |
|---|---|
| Date | 2017-05-06 22:36 -0700 |
| Message-ID | <9753dcaa-ae81-4d44-9dc3-59bc73312c74@googlegroups.com> |
| In reply to | #58752 |
> It can be downloaded from http://qlikz.org/forth/archive/lexgen2.2.zip > > > -- > Gerry Thank you! Andras Pahi
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-03 04:38 -0500 |
| Message-ID | <dJidnfwN9rGQOJTEnZ2dnUU7-amdnZ2d@supernews.com> |
| In reply to | #58541 |
Bernd Paysan <bernd@net2o.de> wrote: > Am Tue, 02 May 2017 13:10:07 -0500 schrieb Andrew Haley: > >> Alex <alex@rivadpm.com> wrote: >>> On 5/2/2017 18:35, Andrew Haley wrote: >>> >>> >>>>> The only difference will be the inability to add recognizers, >>>>> simple, literal or otherwise, in a standard way. >>>> >>>> I don't understand this last sentence. >>> >>> I mean that we will not be able, in a standard way, to extend number >>> recognition. Matthias proposes recognizers, and having built a system >>> that employs them, I can attest to their simplicity and universality. >> >> Yes, but you don't need recognizing numbers to come before the >> dictionary search in order to do that. > > You are still locked into thinking that the recognizer is for numbers > only. It isn't. Get out of your box. Recognizers can be dot parsers, > can be scope parsers (scope:word), and where they sit in the recognizer > order depends on the job. I get that, I really do. But user-defined recognizers for literals have so far been the only reasonable use for them I've seen. > Literal recognizers will certainly be added after the dictionary > search. Unless you want to parse a ton of literals quickly, then > you reverse that temporarily. > > And one important factor for a clean design is that you have rules, > but no exceptions. The dictionary search is just one recognizer, > nothing special (people suggested that it's actually a stack of > recognizers, with each vocabulary in the search order being one > recognizer). I get that too. The question is whether it's a good thing or a bad thing. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-03 04:49 -0700 |
| Message-ID | <6c191e71-1a1c-4b13-9c92-e82e0c836788@googlegroups.com> |
| In reply to | #58564 |
Am Mittwoch, 3. Mai 2017 11:38:26 UTC+2 schrieb Andrew Haley: > Bernd Paysan <bernd@net2o.de> wrote: > > Am Tue, 02 May 2017 13:10:07 -0500 schrieb Andrew Haley: > > > >> Alex <alex@rivadpm.com> wrote: > >>> On 5/2/2017 18:35, Andrew Haley wrote: > >>> > >>> > >>>>> The only difference will be the inability to add recognizers, > >>>>> simple, literal or otherwise, in a standard way. > >>>> > >>>> I don't understand this last sentence. > >>> > >>> I mean that we will not be able, in a standard way, to extend number > >>> recognition. Matthias proposes recognizers, and having built a system > >>> that employs them, I can attest to their simplicity and universality. > >> > >> Yes, but you don't need recognizing numbers to come before the > >> dictionary search in order to do that. > > > > You are still locked into thinking that the recognizer is for numbers > > only. It isn't. Get out of your box. Recognizers can be dot parsers, > > can be scope parsers (scope:word), and where they sit in the recognizer > > order depends on the job. > > I get that, I really do. But user-defined recognizers for literals > have so far been the only reasonable use for them I've seen. > > > Literal recognizers will certainly be added after the dictionary > > search. Unless you want to parse a ton of literals quickly, then > > you reverse that temporarily. > > > > And one important factor for a clean design is that you have rules, > > but no exceptions. The dictionary search is just one recognizer, > > nothing special (people suggested that it's actually a stack of > > recognizers, with each vocabulary in the search order being one > > recognizer). > > I get that too. The question is whether it's a good thing or a bad > thing. > > Andrew. In my world there are users (customers) and implementers (engineers). Users will never touch recognizers or even know they exist. Software engineers are clever enough to extend NUMBER? in a small Forth System by a few lines of code to recognize application-specific formats. They really don't need recognizers. However things are not so easy when the Forth system source is not disclosed,, e.g. encrypted or protected by some other means. Then recognizers offer hooks to "crippled implementors" of new data formats while maintaining core system source protection. On the other hand recognizers are nice backdoor for incrementing target system vulnerability. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-05-03 05:03 -0700 |
| Message-ID | <77b0ca53-6bf4-4c73-a426-2504cb959544@googlegroups.com> |
| In reply to | #58577 |
On Wednesday, 3 May 2017 12:49:25 UTC+1, minf...@arcor.de wrote: > Am Mittwoch, 3. Mai 2017 11:38:26 UTC+2 schrieb Andrew Haley: > > Bernd Paysan <bernd@net2o.de> wrote: > > > Am Tue, 02 May 2017 13:10:07 -0500 schrieb Andrew Haley: > > > > > >> Alex <alex@rivadpm.com> wrote: > > >>> On 5/2/2017 18:35, Andrew Haley wrote: > > >>> > > >>> > > >>>>> The only difference will be the inability to add recognizers, > > >>>>> simple, literal or otherwise, in a standard way. > > >>>> > > >>>> I don't understand this last sentence. > > >>> > > >>> I mean that we will not be able, in a standard way, to extend number > > >>> recognition. Matthias proposes recognizers, and having built a system > > >>> that employs them, I can attest to their simplicity and universality. > > >> > > >> Yes, but you don't need recognizing numbers to come before the > > >> dictionary search in order to do that. > > > > > > You are still locked into thinking that the recognizer is for numbers > > > only. It isn't. Get out of your box. Recognizers can be dot parsers, > > > can be scope parsers (scope:word), and where they sit in the recognizer > > > order depends on the job. > > > > I get that, I really do. But user-defined recognizers for literals > > have so far been the only reasonable use for them I've seen. > > > > > Literal recognizers will certainly be added after the dictionary > > > search. Unless you want to parse a ton of literals quickly, then > > > you reverse that temporarily. > > > > > > And one important factor for a clean design is that you have rules, > > > but no exceptions. The dictionary search is just one recognizer, > > > nothing special (people suggested that it's actually a stack of > > > recognizers, with each vocabulary in the search order being one > > > recognizer). > > > > I get that too. The question is whether it's a good thing or a bad > > thing. > > > > Andrew. > > In my world there are users (customers) and implementers (engineers). Users will never touch recognizers or even know they exist. Software engineers are clever enough to extend NUMBER? in a small Forth System by a few lines of code to recognize application-specific formats. They really don't need recognizers. > > However things are not so easy when the Forth system source is not disclosed,, e.g. encrypted or protected by some other means. > > Then recognizers offer hooks to "crippled implementors" of new data formats while maintaining core system source protection. On the other hand recognizers are nice backdoor for incrementing target system vulnerability. ;-) Primary uses I see for them are: 1) Nice way to recognise and deal with floating point numbers in source code. I.e. Instead of >f 3.141 we can just have 3.141 or (if your system produces doubles from a number with a decimal point (WTAF?) just f3.141 2) Nice dotted OOP syntax
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-03 09:02 -0500 |
| Message-ID | <qqWdnRvCDcNAf5TEnZ2dnUU7-VudnZ2d@supernews.com> |
| In reply to | #58580 |
Mark Wills <markwills1970@gmail.com> wrote: > > Primary uses I see for them are: > > 1) Nice way to recognise and deal with floating point numbers in source > code. I.e. Instead of >f 3.141 we can just have 3.141 or (if your > system produces doubles from a number with a decimal point (WTAF?) > just f3.141 > > 2) Nice dotted OOP syntax I'm not convinced by 2). Forth's obvious equivalent of a.b.c or a.b.c() is A B C . It's not at all obvious to me that the dotted equivalent is better. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-05-03 07:45 -0700 |
| Message-ID | <c2d8153b-bd31-4f7b-9c39-879593fbac56@googlegroups.com> |
| In reply to | #58584 |
On Wednesday, 3 May 2017 15:02:10 UTC+1, Andrew Haley wrote: > Mark Wills <markwills1970@gmail.com> wrote: > > > > Primary uses I see for them are: > > > > 1) Nice way to recognise and deal with floating point numbers in source > > code. I.e. Instead of >f 3.141 we can just have 3.141 or (if your > > system produces doubles from a number with a decimal point (WTAF?) > > just f3.141 > > > > 2) Nice dotted OOP syntax > > I'm not convinced by 2). Forth's obvious equivalent of a.b.c or > a.b.c() is A B C . It's not at all obvious to me that the dotted > equivalent is better. > > Andrew. I agree that A B C is more Forthy, however, I'd argue it's less readable; it's less obvious that C is a method of instance B etc. TRUE button1 font bold TRUE button1.font.bold (IMO) the latter of the two examples is slightly more intuitive, as it's clear you're passing TRUE to the bold property of the font of button1. Without the dots, they could be class members, but they might just be plain old colon defs.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-03 11:24 -0500 |
| Message-ID | <CNydnXpq7pPYmZfEnZ2dnUU7-UHNnZ2d@supernews.com> |
| In reply to | #58585 |
Mark Wills <markwills1970@gmail.com> wrote: > On Wednesday, 3 May 2017 15:02:10 UTC+1, Andrew Haley wrote: >> Mark Wills <markwills1970@gmail.com> wrote: >> >> Forth's obvious equivalent of a.b.c or a.b.c() is A B C . It's not >> at all obvious to me that the dotted equivalent is better. > > I agree that A B C is more Forthy, however, I'd argue it's less readable; > it's less obvious that C is a method of instance B etc. > > TRUE button1 font bold > TRUE button1.font.bold > > (IMO) the latter of the two examples is slightly more intuitive, as it's > clear you're passing TRUE to the bold property of the font of button1. > > Without the dots, they could be class members, but they might just be > plain old colon defs. But you're not taking advantage of Forth's punctuation. It'd be more like true button1 @font >bold or somesuch, depending on your naming convention. Which is at least as readable as button1.font.setBold(true); This point is somewhat related to my earlier comment about an obsession with syntax: people write magic parsers in order to make Forth look more like Language X rather than Forth. And you don't end up with something that looks like better Forth, but like a really bad version of Language X. Only written backwards. :-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-05-03 09:45 -0700 |
| Message-ID | <980229d1-6470-4800-afd8-f2a684a24a11@googlegroups.com> |
| In reply to | #58592 |
On Wednesday, 3 May 2017 17:24:42 UTC+1, Andrew Haley wrote: > Mark Wills <markwills1970@gmail.com> wrote: > > On Wednesday, 3 May 2017 15:02:10 UTC+1, Andrew Haley wrote: > >> Mark Wills <markwills1970@gmail.com> wrote: > >> > >> Forth's obvious equivalent of a.b.c or a.b.c() is A B C . It's not > >> at all obvious to me that the dotted equivalent is better. > > > > I agree that A B C is more Forthy, however, I'd argue it's less readable; > > it's less obvious that C is a method of instance B etc. > > > > TRUE button1 font bold > > TRUE button1.font.bold > > > > (IMO) the latter of the two examples is slightly more intuitive, as it's > > clear you're passing TRUE to the bold property of the font of button1. > > > > Without the dots, they could be class members, but they might just be > > plain old colon defs. > > But you're not taking advantage of Forth's punctuation. It'd be more > like > > true button1 @font >bold > Yes, that's quite a lot nicer. > or somesuch, depending on your naming convention. Which is at least > as readable as > > button1.font.setBold(true); > > This point is somewhat related to my earlier comment about an > obsession with syntax: people write magic parsers in order to make > Forth look more like Language X rather than Forth. And you don't end > up with something that looks like better Forth, but like a really bad > version of Language X. Only written backwards. :-) > > Andrew. Indeed. I've made this "error" myself when I was newer to Forth. For a long time the command on my system to make a blocks file on disk was MKBLK FILENAME SIZE E.g. MKBLK C:\BLOCKS\MY-BLOCKS 80 Which would produce a file called MY-BLOCKS 80KB in size. If you come a from a DOS world, it's very nice and is very clear. But MKBLK had to do its own parsing. Now, the syntax is: 80 S" C:\BLOCKS\MY-BLOCKS" MKBLK Vastly reducing the complexity of MKBLK. That's Forth.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-03 10:08 -0700 |
| Message-ID | <55f12b50-7700-4bf6-9b6e-fb949945f938@googlegroups.com> |
| In reply to | #58595 |
> Indeed. I've made this "error" myself when I was newer to Forth. For a > long time the command on my system to make a blocks file on disk was > MKBLK FILENAME SIZE > > E.g. MKBLK C:\BLOCKS\MY-BLOCKS 80 > > Which would produce a file called MY-BLOCKS 80KB in size. > > If you come a from a DOS world, it's very nice and is very clear. But > MKBLK had to do its own parsing. > > Now, the syntax is: > > 80 S" C:\BLOCKS\MY-BLOCKS" MKBLK > > Vastly reducing the complexity of MKBLK. That's Forth. Probably the best forth-like implementation would be: 80 MKBLK C:\BLOCKS\MY-BLOCKS Forth had always had parsing words, and this example is in fact very easy. In my forth implementations, the file system words are done this way. I'm using two type of forths, all of my own: one type that don't have compile, used only as a shell for an application. The second one has compiling but is just an embedded scripting language for an application. All written in C for C applications. All for embedded (microcontroller class, not linux) systems, although the second one has a PC version which I use for simple scripting on the PC (Windows) host (although command line only).
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-05-09 15:56 +0000 |
| Message-ID | <xn0kps4jvq4uhi6005@nntp.aioe.org> |
| In reply to | #58595 |
Mark Wills wrote: > On Wednesday, 3 May 2017 17:24:42 UTC+1, Andrew Haley wrote: > > Mark Wills <markwills1970@gmail.com> wrote: > > > On Wednesday, 3 May 2017 15:02:10 UTC+1, Andrew Haley wrote: > > >> Mark Wills <markwills1970@gmail.com> wrote: > > > > > > >> Forth's obvious equivalent of a.b.c or a.b.c() is A B C . It's > > not >> at all obvious to me that the dotted equivalent is better. > > > > > > I agree that A B C is more Forthy, however, I'd argue it's less > > > readable; it's less obvious that C is a method of instance B etc. > > > > > > TRUE button1 font bold > > > TRUE button1.font.bold > > > > > > (IMO) the latter of the two examples is slightly more intuitive, > > > as it's clear you're passing TRUE to the bold property of the > > > font of button1. > > > > > > Without the dots, they could be class members, but they might > > > just be plain old colon defs. > > > > But you're not taking advantage of Forth's punctuation. It'd be > > more like > > > > true button1 @font >bold > > > Yes, that's quite a lot nicer. > > > or somesuch, depending on your naming convention. Which is at least > > as readable as > > > > button1.font.setBold(true); > > > > This point is somewhat related to my earlier comment about an > > obsession with syntax: people write magic parsers in order to make > > Forth look more like Language X rather than Forth. And you don't > > end up with something that looks like better Forth, but like a > > really bad version of Language X. Only written backwards. :-) > > > > Andrew. > > Indeed. I've made this "error" myself when I was newer to Forth. For a > long time the command on my system to make a blocks file on disk was > MKBLK FILENAME SIZE > > E.g. MKBLK C:\BLOCKS\MY-BLOCKS 80 > > Which would produce a file called MY-BLOCKS 80KB in size. > > If you come a from a DOS world, it's very nice and is very clear. But > MKBLK had to do its own parsing. > > Now, the syntax is: > > 80 S" C:\BLOCKS\MY-BLOCKS" MKBLK > > Vastly reducing the complexity of MKBLK. That's Forth. But that would still have the parsing. It would just happen in a different place. -- Rudy Velthuis http://www.rvelthuis.de "I'm Jewish. I don't work out. If God had wanted us to bend over, He would have put diamonds on the floor." -- Joan Rivers.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-03 18:37 +0100 |
| Message-ID | <oed4bh$lno$1@dont-email.me> |
| In reply to | #58592 |
On 5/3/2017 17:24, Andrew Haley wrote: > Mark Wills <markwills1970@gmail.com> wrote: >> On Wednesday, 3 May 2017 15:02:10 UTC+1, Andrew Haley wrote: >>> Mark Wills <markwills1970@gmail.com> wrote: >>> >>> Forth's obvious equivalent of a.b.c or a.b.c() is A B C . It's not >>> at all obvious to me that the dotted equivalent is better. >> >> I agree that A B C is more Forthy, however, I'd argue it's less readable; >> it's less obvious that C is a method of instance B etc. >> >> TRUE button1 font bold >> TRUE button1.font.bold >> >> (IMO) the latter of the two examples is slightly more intuitive, as it's >> clear you're passing TRUE to the bold property of the font of button1. >> >> Without the dots, they could be class members, but they might just be >> plain old colon defs. > > But you're not taking advantage of Forth's punctuation. It'd be more > like > > true button1 @font >bold > > or somesuch, depending on your naming convention. Which is at least > as readable as > > button1.font.setBold(true); > > This point is somewhat related to my earlier comment about an > obsession with syntax: people write magic parsers in order to make > Forth look more like Language X rather than Forth. And you don't end > up with something that looks like better Forth, but like a really bad > version of Language X. Only written backwards. :-) > > Andrew. > There are some specific occasions when this doesn't work. How about object A with method CUT and object B with method CUT. A CUT B CUT How does CUT know how to find the CUT method in the object? Can we efficiently compile this? We're forced into duck typing (bleuch!) and the truly awful object method system that Win32Forth uses. People end up writing ugly hacks to get around Forth's dumb white space delimited parser (a blessing in some cases, but not all). -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-05-03 11:07 -0700 |
| Message-ID | <86f8db2c-9a5c-4495-bdab-6fd3152be254@googlegroups.com> |
| In reply to | #58603 |
On Wednesday, 3 May 2017 18:37:57 UTC+1, Alex wrote: > On 5/3/2017 17:24, Andrew Haley wrote: > > Mark Wills <markwills1970@gmail.com> wrote: > >> On Wednesday, 3 May 2017 15:02:10 UTC+1, Andrew Haley wrote: > >>> Mark Wills <markwills1970@gmail.com> wrote: > >>> > >>> Forth's obvious equivalent of a.b.c or a.b.c() is A B C . It's not > >>> at all obvious to me that the dotted equivalent is better. > >> > >> I agree that A B C is more Forthy, however, I'd argue it's less readable; > >> it's less obvious that C is a method of instance B etc. > >> > >> TRUE button1 font bold > >> TRUE button1.font.bold > >> > >> (IMO) the latter of the two examples is slightly more intuitive, as it's > >> clear you're passing TRUE to the bold property of the font of button1. > >> > >> Without the dots, they could be class members, but they might just be > >> plain old colon defs. > > > > But you're not taking advantage of Forth's punctuation. It'd be more > > like > > > > true button1 @font >bold > > > > or somesuch, depending on your naming convention. Which is at least > > as readable as > > > > button1.font.setBold(true); > > > > This point is somewhat related to my earlier comment about an > > obsession with syntax: people write magic parsers in order to make > > Forth look more like Language X rather than Forth. And you don't end > > up with something that looks like better Forth, but like a really bad > > version of Language X. Only written backwards. :-) > > > > Andrew. > > > > There are some specific occasions when this doesn't work. How about > object A with method CUT and object B with method CUT. > > A CUT > B CUT > > How does CUT know how to find the CUT method in the object? Can we > efficiently compile this? We're forced into duck typing (bleuch!) and > the truly awful object method system that Win32Forth uses. > > People end up writing ugly hacks to get around Forth's dumb white space > delimited parser (a blessing in some cases, but not all). > > -- > Alex I thought the "conventional wisdom" would be that A puts its object id on the stack and CUT consumes it? I agree though, it's not nice, and fraught with the possibility of very hard to find errors through typo's/brain farts.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-03 20:55 +0100 |
| Message-ID | <oedce1$jmc$1@dont-email.me> |
| In reply to | #58607 |
On 5/3/2017 19:07, Mark Wills wrote: >> There are some specific occasions when this doesn't work. How about >> object A with method CUT and object B with method CUT. >> >> A CUT >> B CUT >> >> How does CUT know how to find the CUT method in the object? Can we >> efficiently compile this? We're forced into duck typing (bleuch!) and >> the truly awful object method system that Win32Forth uses. >> >> People end up writing ugly hacks to get around Forth's dumb white space >> delimited parser (a blessing in some cases, but not all). >> >> -- >> Alex > I thought the "conventional wisdom" would be that A puts its object id > on the stack and CUT consumes it? Yes, but CUT has to find the method for CUT in A, and potentially a different CUT in object B. That could mean having a wordlist associated with A and one with B, and we search for CUT in the appropriate wordlist. Probably at run time; early binding is complex. > > I agree though, it's not nice, and fraught with the possibility of very > hard to find errors through typo's/brain farts. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-04 02:47 -0500 |
| Message-ID | <kOSdnSzPQK0GQZfEnZ2dnUU7-IOdnZ2d@supernews.com> |
| In reply to | #58607 |
Mark Wills <markwills1970@gmail.com> wrote: > On Wednesday, 3 May 2017 18:37:57 UTC+1, Alex wrote: >> There are some specific occasions when this doesn't work. How about >> object A with method CUT and object B with method CUT. >> >> A CUT >> B CUT >> >> How does CUT know how to find the CUT method in the object? Can we >> efficiently compile this? We're forced into duck typing (bleuch!) and >> the truly awful object method system that Win32Forth uses. >> >> People end up writing ugly hacks to get around Forth's dumb white space >> delimited parser (a blessing in some cases, but not all). >> > I thought the "conventional wisdom" would be that A puts its object id > on the stack and CUT consumes it? Yes, of course. This is Forth, and that's how it should work. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web