Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #20052 > unrolled thread
| Started by | Rob Sciuk <rob@controlq.com> |
|---|---|
| First post | 2013-02-26 17:03 -0500 |
| Last post | 2013-02-27 13:10 -1000 |
| Articles | 20 on this page of 115 — 20 participants |
Back to article view | Back to comp.lang.forth
MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-26 17:03 -0500
Re: MiniForth 0.1.18 has just been released ... "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-27 04:06 -0500
Re: MiniForth 0.1.18 has just been released ... Richard Owlett <rowlett@pcnetinc.com> - 2013-02-27 05:30 -0600
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-27 06:34 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-27 14:42 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-27 11:54 -0600
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-27 15:27 -0500
Re: MiniForth 0.1.18 has just been released ... Coos Haak <chforth@hccnet.nl> - 2013-02-27 21:58 +0100
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-27 16:33 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 17:23 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-02 15:12 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:30 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-03 14:49 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-07 16:58 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 16:35 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:29 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 12:17 -0600
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-28 00:17 +0100
Re: MiniForth 0.1.18 has just been released ... Paul Rubin <no.email@nospam.invalid> - 2013-02-28 01:04 -0800
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-28 17:10 +0100
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-28 11:20 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 16:54 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-02 15:38 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:43 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-03 15:05 -0600
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-03 23:14 +0100
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 03:41 -0600
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 11:00 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 12:47 +0000
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 16:27 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 19:27 +0000
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 20:46 +0000
Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-05 00:19 -0800
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 12:17 +0000
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 17:22 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 17:52 +0000
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 17:03 +0000
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-03-05 12:38 -0500
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-05 17:57 +0000
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-03-05 13:29 -0500
Re: MiniForth 0.1.18 has just been released ... Andy Valencia <user@vsta.org> - 2013-03-05 22:19 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 17:58 +0000
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 19:26 +0000
Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-05 11:19 -0800
Forth convergence with rest of world Andy Valencia <user@vsta.org> - 2013-03-05 22:17 +0000
Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-05 15:15 -0800
Re: Forth convergence with rest of world Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-06 17:35 +0100
Re: Forth convergence with rest of world albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-06 16:44 +0000
Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-06 17:39 +0000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-05 18:16 -0600
Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-06 13:49 -0500
Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-06 19:11 +0000
Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-06 14:24 -0500
Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-06 19:40 +0000
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 09:26 -1000
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 09:26 -1000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-06 15:34 -0600
Re: Forth convergence with rest of world Andy Valencia <user@vsta.org> - 2013-03-06 22:04 +0000
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 12:09 -1000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 04:24 -0600
Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-07 04:15 -0800
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 08:42 -0600
Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-07 13:50 -0800
Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-07 12:12 -0500
Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-07 18:36 +0000
Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-07 14:07 -0500
Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-07 19:43 +0000
Re: Forth convergence with rest of world anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:27 +0000
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-07 08:47 -1000
Re: Forth convergence with rest of world awegel@arcor.de (Alex Wegel) - 2013-03-07 21:42 +0100
Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-07 14:43 -0800
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-07 13:53 -1000
Re: Forth convergence with rest of world stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-07 12:38 +0000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 08:43 -0600
Re: Forth convergence with rest of world Syd Rumpo <usenet@nononono.co.uk> - 2013-03-08 18:04 +0000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 12:18 -0600
Re: Forth convergence with rest of world Syd Rumpo <usenet@nononono.co.uk> - 2013-03-08 18:36 +0000
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-08 14:30 -1000
Re: Forth convergence with rest of world Syd Rumpo <usenet@nononono.co.uk> - 2013-03-09 01:27 +0000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-09 02:43 -0600
Re: MiniForth 0.1.18 has just been released ... Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-05 01:19 -0800
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 12:01 +0000
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:02 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 12:45 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 11:58 -0600
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 19:34 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 15:15 -0600
Re: MiniForth 0.1.18 has just been released ... Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-03-04 23:31 +0100
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 17:07 +0000
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-03-05 12:11 -0500
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-05 00:32 +0100
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-07 17:00 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 16:52 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:32 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 12:25 -0600
Re: MiniForth 0.1.18 has just been released ... Brad Eckert <hwfwguy@gmail.com> - 2013-03-11 09:57 -0700
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-11 12:05 -0500
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-11 17:20 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-11 14:05 -0500
Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-11 14:35 -0700
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-12 00:21 +0100
Re: MiniForth 0.1.18 has just been released ... stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-12 12:13 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-11 19:16 +0000
Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-11 19:29 +0000
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-11 21:36 +0100
Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-11 20:52 +0000
Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-11 14:39 -0700
Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-11 21:52 +0000
Re: MiniForth 0.1.18 has just been released ... Coos Haak <chforth@hccnet.nl> - 2013-03-12 01:11 +0100
Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-12 00:41 +0000
Re: MiniForth 0.1.18 has just been released ... Coos Haak <chforth@hccnet.nl> - 2013-03-12 17:33 +0100
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-27 11:51 -0500
Re: MiniForth 0.1.18 has just been released ... "Elizabeth D. Rather" <erather@forth.com> - 2013-02-27 09:25 -1000
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-27 17:23 -0500
Re: MiniForth 0.1.18 has just been released ... "Elizabeth D. Rather" <erather@forth.com> - 2013-02-27 13:10 -1000
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2013-03-05 01:19 -0800 |
| Message-ID | <c7f8810f-6fb3-42f5-832d-4f3f621c5db0@g8g2000vbf.googlegroups.com> |
| In reply to | #20250 |
On Mar 4, 7:27 pm, alb...@spenarnc.xs4all.nl (Albert van der Horst) wrote: > In article <kh2hvp$ln...@dont-email.me>, > Gerry Jackson <ge...@jackson9000.fsnet.co.uk> wrote: > > > > > > >On 04/03/2013 12:47, Albert van der Horst wrote: > >> In article <kh1upe$93...@dont-email.me>, > >> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> wrote: > >>> On 04/03/2013 09:41, Andrew Haley wrote: > >>> [...] > > >>>> I take that point. Recognizers seem to me to be a far more sensible > >>>> idea than state-smartness, however it's achieved. I wonder if the > >>>> term "recognizer" isn't helping here, because it sounds like such a > >>>> big deal. As I understand the idea, it's just a way to add a word to > >>>> parse a literal and another word to compile the result. > > >>> As I understand it recognizers (I prefer to spell it recognisers) can be > >>> more than that. If implemented as a recognizer stack which can be > >>> manipulated by the user in much the same way as the search order (which > >>> GForth does I think) then the concept becomes more powerful. For example: > > >>> - a number recognizer could be above a word recogniser so that numbers > >>> can be handled before a dictionary search to avoid wasting time when > >>> compiling a lot of numbers > > >>> - a user definition written as a recognizer can use standard parsing > >>> words on the input source, removes the need for something like GForths > >>> EXECUTE-PARSING-FILE. > > >>> - [IF] can be written as a recognizer where coding is much simpler than > >>> the example given in the ANS Forth standard, including nesting of [IF]s > > >>> - a user can write an error handler for the text interpreter > > >>> If such a recognizer stack is used I agree a better name than recognizer > >>> is needed. > > >> Stack? YET ANOTHER STACK? > > >Yas. Well if that offends you, call it a list. > > >> My prefixes work the way you intend, using only the normal rules > >> of search order. > > >Why do you mention that? I never mentioned prefixes or said you couldn't > >do that. I imagine that other Forth systems that handle prefixes do the > >same as you. > > Prefixes are the recognizers Anton talks about. Only with me they are > just Forth words, that are found in the dictionary. > Look up > 0x78AB > in the dictionary and find a match at 0x , because it has the prefix bit > set. Now 0x is IMMEDIATE and at execution find >IN pointing just past > 0x, ready to parse the number. > The whole mechanism adds two lines in INTERPRET. > > > > >-- > >Gerry > > -- > Albert van der Horst, UTRECHT,THE NETHERLANDS > Economic growth -- being exponential -- ultimately falters. > albert@spe&ar&c.xs4all.nl &=nhttp://home.hccnet.nl/a.w.m.van.der.horst- Hide quoted text - > > - Show quoted text - But how would 0x be recognised as a word? It needs to be surrounded by spaces, doesn't it?
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-03-05 12:01 +0000 |
| Message-ID | <5135de8e$0$26868$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #20282 |
In article <c7f8810f-6fb3-42f5-832d-4f3f621c5db0@g8g2000vbf.googlegroups.com>, Mark Wills <markrobertwills@yahoo.co.uk> wrote: >On Mar 4, 7:27 pm, alb...@spenarnc.xs4all.nl (Albert van der Horst) >> >> Prefixes are the recognizers Anton talks about. Only with me they are >> just Forth words, that are found in the dictionary. >> Look up >> 0x78AB >> in the dictionary and find a match at 0x , because it has the prefix bit >> set. Now 0x is IMMEDIATE and at execution find >IN pointing just past >> 0x, ready to parse the number. >> The whole mechanism adds two lines in INTERPRET. >> >> >> >> >-- >> >Gerry >> >> -- >> Albert van der Horst, UTRECHT,THE NETHERLANDS >> Economic growth -- being exponential -- ultimately falters. >> albert@spe&ar&c.xs4all.nl >&=nhttp://home.hccnet.nl/a.w.m.van.der.horst- Hide quoted text - >> >> - Show quoted text - > >But how would 0x be recognised as a word? It needs to be surrounded by >spaces, doesn't it? 0x is not recognized. 0x78AB is looked up in the dictionary and recognized, because it matches the prefix 0x. Do you remember the trick to understand $4131 in figforth? You made a word $.... and set the length to 1 such that only the first character of a word is checked. This is similar. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-03-08 17:02 +0000 |
| Message-ID | <2013Mar8.180221@mips.complang.tuwien.ac.at> |
| In reply to | #20287 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>Do you remember the trick to understand $4131 in figforth?
>You made a word $.... and set the length to 1 such that only
>the first character of a word is checked. This is similar.
you would do something like
1 WIDTH !
: $.... [ 31 width ! ] ... ;
The length of $.... would be set to 5, but only the $ would be stored,
and every 5-char word that starts with a $ would match.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-03-04 12:45 +0000 |
| Message-ID | <5134976d$0$609$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #20234 |
In article <rZKdnYM5JYCn8anMnZ2dnUVZ_hSdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: <SNIP> > >I take that point. Recognizers seem to me to be a far more sensible >idea than state-smartness, however it's achieved. I wonder if the >term "recognizer" isn't helping here, because it sounds like such a >big deal. As I understand the idea, it's just a way to add a word to >parse a literal and another word to compile the result. A recognizer should generate a compile time constant, be it a number, fp number, execution token, or string. LITERAL and DLITERAL can take it from there. > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-04 11:58 -0600 |
| Message-ID | <BOudneWEMvUlfanMnZ2dnUVZ_sidnZ2d@supernews.com> |
| In reply to | #20242 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <rZKdnYM5JYCn8anMnZ2dnUVZ_hSdnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > <SNIP> >> >>I take that point. Recognizers seem to me to be a far more sensible >>idea than state-smartness, however it's achieved. I wonder if the >>term "recognizer" isn't helping here, because it sounds like such a >>big deal. As I understand the idea, it's just a way to add a word to >>parse a literal and another word to compile the result. > > A recognizer should generate a compile time constant, be it a number, > fp number, execution token, or string. > > LITERAL and DLITERAL can take it from there. And what would you do for Bernd's complex number example? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-03-04 19:34 +0000 |
| Message-ID | <5134f762$0$6329$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #20248 |
In article <BOudneWEMvUlfanMnZ2dnUVZ_sidnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >> In article <rZKdnYM5JYCn8anMnZ2dnUVZ_hSdnZ2d@supernews.com>, >> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> <SNIP> >>> >>>I take that point. Recognizers seem to me to be a far more sensible >>>idea than state-smartness, however it's achieved. I wonder if the >>>term "recognizer" isn't helping here, because it sounds like such a >>>big deal. As I understand the idea, it's just a way to add a word to >>>parse a literal and another word to compile the result. >> >> A recognizer should generate a compile time constant, be it a number, >> fp number, execution token, or string. >> >> LITERAL and DLITERAL can take it from there. > >And what would you do for Bernd's complex number example? I would require that complex numbers start with e.g. i# . That is just a word, and the remainder of a denotation for a complex number can be TBS. I reject that Forth should strive to look like other language. There is no better way to mess things up than to soup up Forth with mini-interpreters for all constructs find in any other programming language. > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-04 15:15 -0600 |
| Message-ID | <r6ednRa0C5l_k6jMnZ2dnUVZ_vadnZ2d@supernews.com> |
| In reply to | #20251 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <BOudneWEMvUlfanMnZ2dnUVZ_sidnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >>> In article <rZKdnYM5JYCn8anMnZ2dnUVZ_hSdnZ2d@supernews.com>, >>> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>> <SNIP> >>>> >>>>I take that point. Recognizers seem to me to be a far more sensible >>>>idea than state-smartness, however it's achieved. I wonder if the >>>>term "recognizer" isn't helping here, because it sounds like such a >>>>big deal. As I understand the idea, it's just a way to add a word to >>>>parse a literal and another word to compile the result. >>> >>> A recognizer should generate a compile time constant, be it a number, >>> fp number, execution token, or string. >>> >>> LITERAL and DLITERAL can take it from there. >> >>And what would you do for Bernd's complex number example? > > I would require that complex numbers start with e.g. i# . > That is just a word, and the remainder of a denotation for a > complex number can be TBS. That Seems right. > I reject that Forth should strive to look like other language. > > There is no better way to mess things up than to soup up Forth > with mini-interpreters for all constructs find in any other > programming language. I am rather relieved that I'm not the only one who thinks so. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Roelf Toxopeus <rt4all@notthis.hetnet.nl> |
|---|---|
| Date | 2013-03-04 23:31 +0100 |
| Message-ID | <rt4all-0C693A.23311204032013@[10.12.75.213]> |
| In reply to | #20258 |
In article <r6ednRa0C5l_k6jMnZ2dnUVZ_vadnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > > I reject that Forth should strive to look like other language. > > > > There is no better way to mess things up than to soup up Forth > > with mini-interpreters for all constructs find in any other > > programming language. > > I am rather relieved that I'm not the only one who thinks so. If it helps: you're certainly not alone ... ... but, yeah, what's the point? -roelf
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2013-03-05 17:07 +0000 |
| Message-ID | <kh58mh$g3h$1@dont-email.me> |
| In reply to | #20251 |
On 04/03/2013 19:34, Albert van der Horst wrote: [...] > I reject that Forth should strive to look like other language. Yet you use the C prefix 0x to specify hex numbers!! The Forth 200X prefix is $ -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Rob Sciuk <rob@controlq.com> |
|---|---|
| Date | 2013-03-05 12:11 -0500 |
| Message-ID | <alpine.BSF.2.00.1303051210370.69374@yoko.controlq.com> |
| In reply to | #20298 |
On Tue, 5 Mar 2013, Gerry Jackson wrote: > Date: Tue, 05 Mar 2013 17:07:42 +0000 > From: Gerry Jackson <gerry@jackson9000.fsnet.co.uk> > Newsgroups: comp.lang.forth > Subject: Re: MiniForth 0.1.18 has just been released ... > > On 04/03/2013 19:34, Albert van der Horst wrote: > [...] > > >> I reject that Forth should strive to look like other language. > > Yet you use the C prefix 0x to specify hex numbers!! The Forth 200X prefix is > $ -- MiniForth-Hosted alpha Version: 00.01.19D -- www.ControlQ.com ok $10 . 16 ok 0x10 . 16 ok And yet, with Forth you can have it all 8-} Cheers, Rob.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-03-05 00:32 +0100 |
| Message-ID | <kh3au6$3p8$1@online.de> |
| In reply to | #20234 |
Andrew Haley wrote: > Ok, ISWYM, but "smart macros" doesn't really address the duality of > such words. A macro is something that is executed at compile time only. Being smart means something more. > I take that point. Recognizers seem to me to be a far more sensible > idea than state-smartness, however it's achieved. I wonder if the > term "recognizer" isn't helping here, because it sounds like such a > big deal. As I understand the idea, it's just a way to add a word to > parse a literal and another word to compile the result. Yes, that's it, exactly that - using the smart compile, approach of the current development Gforth, the "another word to compile the result" is really just one word. With special compilation and postpone semantics ;-). And there is a recognizer stack, which contains the active words for parsing such literals, or the Forth words themselves. That's all. The rule for the outer interpreter is now that everything produces an xt; if it has additional stuff, this is underneath. The different modes of the compiler just change the way this xt is handled. During the various experiments with recognizers, they actually were a bigger deal than they are now in Gforth. As Blaise Pascal put it "I would have written a shorter program^Wletter, but I didn't have the time.", the recognizer needs some other stuff to become that simple. A clean way to identify the compilation semantics of an xt is one part. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-03-07 17:00 +0000 |
| Message-ID | <2013Mar7.180036@mips.complang.tuwien.ac.at> |
| In reply to | #20215 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>I thought "combined words" was the name of one implementation
>technique.
It isn't. In particular, if you look at the paper where I introduced
the term <http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz>, you
see in section 3 "Combined words" the following:
|I call these words combined words, because they combine the
|interpretation semantics of one word with the compilation semantics of
|a different word.
Then, later, in Section 5, I presented two different implementation
techniques for implementing combined words, so anybody who read that
paper should be aware that "combined words" is not a term for an
implementation technique.
> I'm looking for a word that names the idea of these words.
>"Janus words", perhaps?
Fine with me. Certainly better than "state-smart".
>It's not a matter of being nannyish: it's a matter of avoiding
>complexity for little advantage. We already have one of the most
>flexible and extensible languages, but its tradition is one that
>eschews complexity and insists that everything is there for a good
>reason.
Recognizers are there for a good reason.
>In this case you're adding scaffolding simply in order to
>void having to say XML: .
No, that is your straw man. I had not even thought about that. The
main reasons for recognizers are to avoid S" and to clean up the mess
of ad-hoc recognizers that lives in a full-featured standard system.
>>>> What horrors have you encountered?
>>>
>>>None, because they're not much used.
>>
>> Case closed.
>
>This makes no sense: a technique that is little used can have little
>evidence of its disadvantages, or advantages. The onus is not on me
>to prove that a techinique is bad, but on its proponents to show that
>it's not only worthwhile but substantally better than what we already
>have.
Yes, but if you claim horrors, and then have none to report, your
claim is a fallacy, and I guess you know its name better than I do
(but will you tell 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-07 16:52 -0600 |
| Message-ID | <xoidnVW6ete1h6TMnZ2dnUVZ_qGdnZ2d@supernews.com> |
| In reply to | #20402 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>I thought "combined words" was the name of one implementation >>technique. > > It isn't. In particular, if you look at the paper where I introduced > the term <http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz>, you > see in section 3 "Combined words" the following: > > |I call these words combined words, because they combine the > |interpretation semantics of one word with the compilation semantics of > |a different word. > > Then, later, in Section 5, I presented two different implementation > techniques for implementing combined words, so anybody who read that > paper should be aware that "combined words" is not a term for an > implementation technique. I see. I don't much like the term because it doesn't really convey the nature of such words, but each to their own. I didn't pay very much attention to the paper because it seemed to me to be describing a clever way to do something that should not be done. >> I'm looking for a word that names the idea of these words. >>"Janus words", perhaps? > > Fine with me. Certainly better than "state-smart". > >>It's not a matter of being nannyish: it's a matter of avoiding >>complexity for little advantage. We already have one of the most >>flexible and extensible languages, but its tradition is one that >>eschews complexity and insists that everything is there for a good >>reason. > > Recognizers are there for a good reason. I don't yet agree, but with some evidence of something actually useful in an application I may be persuaded. >>In this case you're adding scaffolding simply in order to >>void having to say XML: . > > No, that is your straw man. I had not even thought about that. The > main reasons for recognizers are to avoid S" and to clean up the mess > of ad-hoc recognizers that lives in a full-featured standard system. But there is not a mess of ad-hoc recognizers. There's two kinds of number and that's it: the rest can be done in the usual way with immediate words, modulo the usual argument about state-smart S" . >>>>> What horrors have you encountered? >>>> >>>>None, because they're not much used. >>> >>> Case closed. >> >>This makes no sense: a technique that is little used can have little >>evidence of its disadvantages, or advantages. The onus is not on me >>to prove that a techinique is bad, but on its proponents to show that >>it's not only worthwhile but substantally better than what we already >>have. > > Yes, but if you claim horrors, and then have none to report, your > claim is a fallacy, and I guess you know its name better than I do > (but will you tell it?). I pointed out that with recognizers you have another way to define arbitrary syntaxes that are in no way related to the rest of the Forth language. That is to say, the potential mess is unbounded, and they don't add much. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-03-08 17:32 +0000 |
| Message-ID | <2013Mar8.183232@mips.complang.tuwien.ac.at> |
| In reply to | #20418 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> I didn't pay very
>much attention to the paper because it seemed to me to be describing a
>clever way to do something that should not be done.
Maybe you should read it and pay attention. It does not just describe
the implementation of combined words, but discusses the problems why
people want combined words, some additional ideas etc.
Admittedly, if you don't even want to think about why people have not
flocked to your preferred solution (stateless Forth), you probably
won't get anything out of the paper.
>But there is not a mess of ad-hoc recognizers. There's two kinds of
>number and that's it
There are single and double numbers, and that was already very messy
in Gforth. And then there are FP numbers. And number prefixes.
> the rest can be done in the usual way with
>immediate words, modulo the usual argument about state-smart S" .
Actually numbers could also be done with (immediate) parsing words, e.g.
N# 1234 \ single
D# 1234 \ double
F# 1234 \ FP
H# 1234 \ hex single
: foo
[N#] 1234 \ single
[D#] 1234 \ double
[F#] 1234 \ FP
[H#] 1234 \ hex single
;
Instead, they are done with ad-hoc recognizers. I think that's good,
and using recognizers instead of parsing words is also a good idea for
strings and maybe xts.
>I pointed out that with recognizers you have another way to define
>arbitrary syntaxes that are in no way related to the rest of the Forth
>language. That is to say, the potential mess is unbounded,
The nanny argument.
> and they
>don't add much.
They provide an alternative to the seductions of combined (or worse,
STATE-smart) parsing words, that does not need us to change the
literals when we copy from interpreted to compiled code or vice versa
(the reason why people choose combined or STATE-smart words for the
purpose). I think that's enough benefit.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-08 12:25 -0600 |
| Message-ID | <bJSdnZ7dcMyFsKfMnZ2dnUVZ_oSdnZ2d@supernews.com> |
| In reply to | #20455 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>I didn't pay very much attention to the paper because it seemed to >>me to be describing a clever way to do something that should not be >>done. > > Maybe you should read it and pay attention. It does not just > describe the implementation of combined words, but discusses the > problems why people want combined words, some additional ideas etc. I already know why people want them. > Admittedly, if you don't even want to think about why people have not > flocked to your preferred solution (stateless Forth), you probably > won't get anything out of the paper. I've thought about it lots. Stateless forth is not required for my preferred solution, which is not to write any "combined words". That way, the current STATE can stay and it does no harm. >>But there is not a mess of ad-hoc recognizers. There's two kinds of >>number and that's it > > There are single and double numbers, and that was already very messy > in Gforth. And then there are FP numbers. And number prefixes. You don't need a separate recognizer for number prefixes or double words: it's just an integer recognizer. >> the rest can be done in the usual way with >>immediate words, modulo the usual argument about state-smart S" . > > Actually numbers could also be done with (immediate) parsing words, e.g. > > N# 1234 \ single > D# 1234 \ double > F# 1234 \ FP > H# 1234 \ hex single > > : foo > [N#] 1234 \ single > [D#] 1234 \ double > [F#] 1234 \ FP > [H#] 1234 \ hex single > ; > > Instead, they are done with ad-hoc recognizers. I think that's good, Indeed. > and using recognizers instead of parsing words is also a good idea for > strings and maybe xts. > >>I pointed out that with recognizers you have another way to define >>arbitrary syntaxes that are in no way related to the rest of the Forth >>language. That is to say, the potential mess is unbounded, > > The nanny argument. True enough. Maybe I'm a nanny. Maybe someone has to be! :-) >>and they don't add much. > > They provide an alternative to the seductions of combined (or worse, > STATE-smart) parsing words, But no-one needs need them, so... > that does not need us to change the literals when we copy from > interpreted to compiled code or vice versa (the reason why people > choose combined or STATE-smart words for the purpose). Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2013-03-11 09:57 -0700 |
| Message-ID | <82aeda64-aaac-4dcb-813a-26698c584634@googlegroups.com> |
| In reply to | #20418 |
On Thursday, March 7, 2013 3:52:24 PM UTC-7, Andrew Haley wrote: > >> No, that is your straw man. I had not even thought about that. The >> main reasons for recognizers are to avoid S" and to clean up the mess >> of ad-hoc recognizers that lives in a full-featured standard system. > > But there is not a mess of ad-hoc recognizers. There's two kinds of > number and that's it: the rest can be done in the usual way with > immediate words, modulo the usual argument about state-smart S" . > No mess in the standard. Some mess in a standard system. The vendor decides which recognizers to apply and what syntax each uses. The ad-hoc mess is a specification problem, probably best addressed by the 200x TC, such as it is.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-11 12:05 -0500 |
| Message-ID | <aIudncQby9Jxk6PMnZ2dnUVZ_oadnZ2d@supernews.com> |
| In reply to | #20549 |
Brad Eckert <hwfwguy@gmail.com> wrote: > On Thursday, March 7, 2013 3:52:24 PM UTC-7, Andrew Haley wrote: >> >>> No, that is your straw man. I had not even thought about that. The >>> main reasons for recognizers are to avoid S" and to clean up the mess >>> of ad-hoc recognizers that lives in a full-featured standard system. >> >> But there is not a mess of ad-hoc recognizers. There's two kinds of >> number and that's it: the rest can be done in the usual way with >> immediate words, modulo the usual argument about state-smart S" . >> > No mess in the standard. Some mess in a standard system. The vendor > decides which recognizers to apply and what syntax each uses. The > ad-hoc mess is a specification problem, probably best addressed by > the 200x TC, such as it is. Such as we are, yes. :-) I'm not sure that this conversation makes any sense, really. If the main reasons for recognizers are to avoid S" and to clean up the mess of ad-hoc recognizers that lives in a full-featured standard system, then it's of no concern to anyone except the implementor of that system. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-03-11 17:20 +0000 |
| Message-ID | <2013Mar11.182047@mips.complang.tuwien.ac.at> |
| In reply to | #20550 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>If the
>main reasons for recognizers are to avoid S" and to clean up the mess
>of ad-hoc recognizers that lives in a full-featured standard system,
>then it's of no concern to anyone except the implementor of that
>system.
1) If S" is to be avoided, programmers have to know about the
alternative. So it does concern the programmers of that system as
well as the implementors.
2) If there is a good way to clean up the mess of ad-hoc recognizers
that lives in a full-featured standard system, that's probably of
interest to implementors of other systems, too.
3) Sometimes programmers want to add a way to write a new kind of
literals (whatever their application needs) in their program.
Currently they tend to write STATE-smart parsing words for that. With
programmer-definable recognizers, they could avoid that.
4) If programmer-definable recognizers are a useful feature, it would
be good if we established common practice; and for that it's necessary
for implementors and programmers to know about this idea.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-11 14:05 -0500 |
| Message-ID | <adudncbNPv1nt6PMnZ2dnUVZ_sudnZ2d@supernews.com> |
| In reply to | #20551 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>If the >>main reasons for recognizers are to avoid S" and to clean up the mess >>of ad-hoc recognizers that lives in a full-featured standard system, >>then it's of no concern to anyone except the implementor of that >>system. > > 1) If S" is to be avoided, programmers have to know about the > alternative. So it does concern the programmers of that system as > well as the implementors. > > 2) If there is a good way to clean up the mess of ad-hoc recognizers > that lives in a full-featured standard system, that's probably of > interest to implementors of other systems, too. > > 3) Sometimes programmers want to add a way to write a new kind of > literals (whatever their application needs) in their program. > Currently they tend to write STATE-smart parsing words for that. I dispute that claim: I doubt very much that there is a substantial application need for such a thing. I'm sure that no-one ever needed it in any of the Forth applications I worked on. I suppose it's possible that applications have changed such that people do need such things, or that the applications I know about were untypical. But, of course, if anyone knows otherwise I'm happy ( :-) to be contradicted. I suspect that this is more of a Forth producer "isn't this cool" feature than anything else. > With programmer-definable recognizers, they could avoid that. > > 4) If programmer-definable recognizers are a useful feature, it would > be good if we established common practice; and for that it's necessary > for implementors and programmers to know about this idea. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2013-03-11 14:35 -0700 |
| Message-ID | <f3a1d246-4fb5-4141-9bf8-38fbdbb602ac@g16g2000vbf.googlegroups.com> |
| In reply to | #20552 |
On Mar 11, 7:05 pm, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote: > > Andrew Haley <andre...@littlepinkcloud.invalid> writes: > >>If the > >>main reasons for recognizers are to avoid S" and to clean up the mess > >>of ad-hoc recognizers that lives in a full-featured standard system, > >>then it's of no concern to anyone except the implementor of that > >>system. > > > 1) If S" is to be avoided, programmers have to know about the > > alternative. So it does concern the programmers of that system as > > well as the implementors. > > > 2) If there is a good way to clean up the mess of ad-hoc recognizers > > that lives in a full-featured standard system, that's probably of > > interest to implementors of other systems, too. > > > 3) Sometimes programmers want to add a way to write a new kind of > > literals (whatever their application needs) in their program. > > Currently they tend to write STATE-smart parsing words for that. > > I dispute that claim: I doubt very much that there is a substantial > application need for such a thing. I'm sure that no-one ever needed > it in any of the Forth applications I worked on. I suppose it's > possible that applications have changed such that people do need such > things, or that the applications I know about were untypical. But, of > course, if anyone knows otherwise I'm happy ( :-) to be contradicted. The XCHAR wordset. It could have done with a literal for xchars; not supporting it for codepoints is a shortcoming that was discussed at the time. For example, the number U+3B5 or \u3B5 for "ε", which would (for UTF-8 SET-ENCODING) create the correctly composed UTF-8 literal of $CE35. > > I suspect that this is more of a Forth producer "isn't this cool" > feature than anything else. > > > With programmer-definable recognizers, they could avoid that. > > > 4) If programmer-definable recognizers are a useful feature, it would > > be good if we established common practice; and for that it's necessary > > for implementors and programmers to know about this idea. > > Andrew.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web