Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #38642 > unrolled thread
| Started by | JennyB <jennybrien@googlemail.com> |
|---|---|
| First post | 2015-04-27 01:34 -0700 |
| Last post | 2015-05-03 20:38 +0200 |
| Articles | 20 on this page of 124 — 11 participants |
Back to article view | Back to comp.lang.forth
SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 01:34 -0700
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-27 14:52 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-27 21:17 +0200
Re: SET-COMPILER hughaguilar96@gmail.com - 2015-04-28 09:41 -0700
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 16:53 +0100
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 17:02 +0100
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 10:23 -0700
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 10:02 -0700
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-01 17:15 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 23:38 +0200
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 14:52 +0000
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 17:09 +0100
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 16:54 +0000
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-28 09:11 +0000
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-28 04:28 -0700
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-29 13:49 -0700
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-30 00:13 +0200
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-30 06:32 +0000
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-30 05:22 -0700
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-30 15:27 +0000
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-30 19:16 +0100
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-30 21:08 +0000
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-30 23:05 +0100
Re: SET-COMPILER hughaguilar96@gmail.com - 2015-04-30 15:47 -0700
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-01 12:29 +0100
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:25 +0000
Re: SET-COMPILER hughaguilar96@gmail.com - 2015-04-30 17:07 -0700
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-01 02:40 -0700
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-05-01 10:24 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 22:55 +0200
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-02 01:32 -0700
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 16:27 +0000
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-03 08:36 -0700
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:44 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:37 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 01:33 +0200
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-01 03:15 -0700
Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-01 12:47 +0000
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-01 10:29 -0700
Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-01 20:32 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:51 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:29 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 14:59 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:11 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 12:04 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 03:22 +0200
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 11:09 +0000
Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-02 12:30 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 16:58 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-02 20:42 +0200
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:28 +0000
Re: SET-COMPILER Mark Wills <markwills1970@gmail.com> - 2015-05-06 04:14 -0700
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 23:57 -0700
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 11:41 +0000
Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-02 12:51 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 17:00 +0000
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-03 11:19 +0100
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-03 07:30 -0700
Re: SET-COMPILER Coos Haak <chforth@hccnet.nl> - 2015-05-03 21:45 +0200
Re: SET-COMPILER Coos Haak <chforth@hccnet.nl> - 2015-05-03 21:48 +0200
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-05 22:03 +0100
Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-05 22:56 +0000
PREFIX JennyB <jennybrien@googlemail.com> - 2015-05-06 02:30 -0700
Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 12:23 +0000
Re: PREFIX "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 16:44 +0100
Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 16:03 +0000
Re: PREFIX "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 17:40 +0100
Re: PREFIX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-06 19:44 +0000
Re: PREFIX Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-06 22:05 +0200
Re: PREFIX Bernd Linsel <bl1@gmx.com> - 2015-05-07 04:23 +0200
Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 11:48 +0000
Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 12:04 +0000
Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 11:55 +0000
Re: PREFIX "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 14:20 +0100
Re: PREFIX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-06 19:41 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 12:29 +0000
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 15:07 +0100
Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-09 03:02 -0700
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-09 17:23 +0100
Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 08:07 +0100
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 11:20 +0100
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-12 10:05 -0700
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 18:34 +0100
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-12 12:07 -0700
Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-12 22:11 +0200
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 21:35 +0100
Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-13 01:31 +0200
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 16:20 +0000
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-13 12:20 -0700
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-13 22:24 +0100
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-14 11:26 +0000
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-14 11:00 -0700
Re: Recognizer RfD was Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-14 08:06 -0700
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 17:21 +0100
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-14 11:31 -0700
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 19:41 +0100
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-14 11:49 -0700
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 09:41 +0000
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-15 12:19 +0100
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 14:42 +0000
Re: Recognizer RfD was Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-15 10:37 -0700
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-15 23:00 +0100
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-16 13:52 +0000
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-16 19:24 +0100
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-16 13:26 -0700
Re: Recognizer RfD was Re: SET-COMPILER Coos Haak <chforth@hccnet.nl> - 2015-05-17 00:27 +0200
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-17 10:03 +0000
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-17 23:25 +0100
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 10:02 +0000
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-15 12:35 +0100
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 15:33 +0000
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 14:01 +0000
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 13:14 +0000
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 17:07 +0000
Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-14 03:27 +0200
Re: Recognizer RfD was Re: SET-COMPILER hughaguilar96@gmail.com - 2015-05-13 19:23 -0700
Re: Recognizer RfD was Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-14 01:08 -0700
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 14:30 +0000
Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-14 03:40 +0200
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 13:26 +0000
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 21:33 +0100
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-13 10:36 +0000
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 16:06 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-03 20:38 +0200
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-05-15 10:37 -0700 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <85428aba-212e-41a7-9988-d4a128ffb2c1@googlegroups.com> |
| In reply to | #39111 |
On Thursday, 14 May 2015 17:21:36 UTC+1, Alex McDonald wrote:
> on 14/05/2015 16:06:48, JennyB wrote:
> > Therefore:
> > A pattern contains all its parsing within itself. When a pattern is
>
> Does not further parse (read the input stream)? Or in the
> parse-string-for-semantics sense?
I thought the first, but then something like ."Hello World" does parse
further than the original pattern match of ."Hello , and you don't want that
parsing to be repeated when the POSTPONED code is run.
In Albert's syntax the action then (ignoring POSTPONEing) would be something
like:
&" PARSE STATE @ IF
POSTPONE SLITERAL POSTPONE TYPE ELSE
TYPE THEN
That's a literal-action pattern, so the recognizer equivalent could use a
generic R:table that expected the literal and the action on the stack:
&" PARSE 'SLITERAL 'TYPE R:LIT-DO
R:Lit-do Interpretation NIP EXECUTE
Compilation >R EXECUTE >R COMPILE,
Postpone >R DUP >R EXECUTE
R> COMPILE,
R> COMPILE,
Or, if you have a postpone state, you could turn it back into a definition
that is executed by the usual text interpreter:
&" PARSE 'SLITERAL 'TYPE R:LIT-DO OBEY
though that's just sugar-coated STATE-smartness. In fact, it's possible
that only two STATE-smart words are ever needed, to do what the interpreter
does with xts and literals.
DO-XT ( execute compile, postpone )
DO-LIT ( drop execute execute&compile, )
&" PARSE 'SLITERAL do-lit 'TYPE do-xt
But on the whole I prefer the idea of definitions and literal returning an
r:table so that all the STATE-smartness can be left to the interpreter.
> The second is to use a chain type number recognizer, which is what I do.
>
> library wincon.dll
> 3 import: wcFindWin32Constant
>
> : wincon-call ( a1 -- n f ) \ call to find constant
> >r 0 sp@ r> count swap wcFindWin32Constant ;
>
> :noname ( a1 n1 -- d ) \ find constant
> buf-allot dup>r place r@ ?uppercase \ uppercase a copy
> wincon-call 0= if \ find constant
> drop \ drop returned value
> s" A" r@ +place \ append an 'A'
> r@ wincon-call \ find it
> 0= throw \ can't find it
> then r>drop 0 \ make a double
> ; number?-chain chain+ \ chain it in
>
Does this add itself to the start or the end of the number?-chain, or does
it matter? I presume there must be a CATCH that tries the next candidate if
it THROWs?
> > As I see it, if you want a particular recognizer you also want a bunch
> > of other words relating to it. So with a Search Order, each wordlist
> > should keep a stack of the recognizers declared within it, which the
> > interpreter checks directly after the wordlist itself. If the word is
> > still not recognized, it searches the next wordlist in the search
> > order, and so on. It is, of course, possible to have a wordlist with
> > no definitions, only recognizers. In this way patterns that are
> > recognized 'work' exactly like dictionary definitions, except that a
> > pattern cannot 'shade' an earlier definition in the same wordlist.
> >
>
> This last paragraph gave me an anxiety attack. Fleas and lesser fleas to
> bite them and all that.
No need; it's just the same rule that would apply if you were to implement
prefixes with a dictionary search that didn't do a character-by-character
comparison. If a pattern-recognizer if set (using a word like chain+) when a
particular wordlist is CURRENT, then it is active whenever that wordlist is
in the search order.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-15 23:00 +0100 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mj5q80$kdg$1@dont-email.me> |
| In reply to | #39151 |
on 15/05/2015 18:37:17, JennyB wrote: > On Thursday, 14 May 2015 17:21:36 UTC+1, Alex McDonald wrote: >> on 14/05/2015 16:06:48, JennyB wrote: >> > Therefore: >> > A pattern contains all its parsing within itself. When a pattern is >> >> Does not further parse (read the input stream)? Or in the >> parse-string-for-semantics sense? > > I thought the first, but then something like ."Hello World" does parse > further than the original pattern match of ."Hello , and you don't > want that parsing to be repeated when the POSTPONED code is run. I didn't like ->value, but I presumed it wasn't -> value because of some parsing issue. > > > In Albert's syntax the action then (ignoring POSTPONEing) would be > something like: > > &" PARSE STATE @ IF > POSTPONE SLITERAL POSTPONE TYPE ELSE > TYPE THEN > > That's a literal-action pattern, so the recognizer equivalent could > use a generic R:table that expected the literal and the action on the > stack: > > &" PARSE 'SLITERAL 'TYPE R:LIT-DO > > R:Lit-do Interpretation NIP EXECUTE > Compilation >R EXECUTE >R COMPILE, > Postpone >R DUP >R EXECUTE > R> COMPILE, > R> COMPILE, > > Or, if you have a postpone state, you could turn it back into a > definition that is executed by the usual text interpreter: > > &" PARSE 'SLITERAL 'TYPE R:LIT-DO OBEY > > though that's just sugar-coated STATE-smartness. In fact, it's > possible that only two STATE-smart words are ever needed, to do what > the interpreter does with xts and literals. > > DO-XT ( execute compile, postpone ) > DO-LIT ( drop execute execute&compile, ) > > &" PARSE 'SLITERAL do-lit 'TYPE do-xt > > But on the whole I prefer the idea of definitions and literal > returning an r:table so that all the STATE-smartness can be left to > the interpreter. > > >> The second is to use a chain type number recognizer, which is what I do. >> >> library wincon.dll >> 3 import: wcFindWin32Constant >> >> : wincon-call ( a1 -- n f ) \ call to find constant >> >r 0 sp@ r> count swap wcFindWin32Constant ; >> >> :noname ( a1 n1 -- d ) \ find constant >> buf-allot dup>r place r@ ?uppercase \ uppercase a copy >> wincon-call 0= if \ find constant >> drop \ drop returned value >> s" A" r@ +place \ append an 'A' >> r@ wincon-call \ find it >> 0= throw \ can't find it >> then r>drop 0 \ make a double >> ; number?-chain chain+ \ chain it in >> > > Does this add itself to the start or the end of the number?-chain, or > does it matter? If it's uniquely identifying, then its position in the chain is jsut a matter of performance. CHAIN+ adds to the end. > I presume there must be a CATCH that tries the next > candidate if it THROWs? Yes. > >> > As I see it, if you want a particular recognizer you also want a bunch >> > of other words relating to it. So with a Search Order, each wordlist >> > should keep a stack of the recognizers declared within it, which the >> > interpreter checks directly after the wordlist itself. If the word is >> > still not recognized, it searches the next wordlist in the search >> > order, and so on. It is, of course, possible to have a wordlist with >> > no definitions, only recognizers. In this way patterns that are >> > recognized 'work' exactly like dictionary definitions, except that a >> > pattern cannot 'shade' an earlier definition in the same wordlist. >> > >> >> This last paragraph gave me an anxiety attack. Fleas and lesser fleas to >> bite them and all that. > > No need; it's just the same rule that would apply if you were to > implement prefixes with a dictionary search that didn't do a > character-by-character comparison. If a pattern-recognizer if set > (using a word like chain+) when a particular wordlist is CURRENT, then > it is active whenever that wordlist is in the search order. > Hmmm.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-16 13:52 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <2015May16.155208@mips.complang.tuwien.ac.at> |
| In reply to | #39162 |
"Alex McDonald" <blog@rivadpm.com> writes:
>I didn't like ->value, but I presumed it wasn't -> value because of some
>parsing issue.
No, a recognizer can parse on its own (necessary for recognizing
"bla bla"), but the idea is to make the whole thing look like a word.
If we wanted to have a space in between, we could just as well just
have TO VALUE. I think that would be a conforming implementation of
the standard TO.
The reason why I think that we should avoid extra parsing if we can is
that, while Forth programmers sometimes like to think of parsing words
and what they parse as one unit (and try to accomodate that with,
e.g., STATE-smart words), sometimes they (either different programmers
or in a different context) expect the word to stand for itself, and it
would be surprising to them if it included the parsed stuff. E.g., if
somebody writes
... postpone to v ...
it might be surprising to the programmer or readers of the program if
this postpones "to v" rather than "to". If somebody writes
... postpone ->v ...
I think that everybody expects ->V to be a unit. For the
... postpone "bla bla" ...
case, it's pretty obvious that "bla bla" is a unit, so the
expectations of the programmers should not be a problem for that.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-16 19:24 +0100 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mj81uj$j1j$1@dont-email.me> |
| In reply to | #39171 |
on 16/05/2015 14:52:04, wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>I didn't like ->value, but I presumed it wasn't -> value because of some >>parsing issue. > > No, a recognizer can parse on its own (necessary for recognizing > "bla bla"), but the idea is to make the whole thing look like a word. > > If we wanted to have a space in between, we could just as well just > have TO VALUE. I think that would be a conforming implementation of > the standard TO. > > The reason why I think that we should avoid extra parsing if we can is > that, while Forth programmers sometimes like to think of parsing words > and what they parse as one unit (and try to accomodate that with, > e.g., STATE-smart words), sometimes they (either different programmers > or in a different context) expect the word to stand for itself, and it > would be surprising to them if it included the parsed stuff. E.g., if > somebody writes > > ... postpone to v ... > > it might be surprising to the programmer or readers of the program if > this postpones "to v" rather than "to". If somebody writes > > ... postpone ->v ... > > I think that everybody expects ->V to be a unit. For the > > ... postpone "bla bla" ... > > case, it's pretty obvious that "bla bla" is a unit, so the > expectations of the programmers should not be a problem for that. > > - anton Perhaps parsing while postponing needs a visual indicator (here as |) to show the extent of the parse, a bit like ". We could have POSTPONE |TO| POSTPONE |TO V|
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2015-05-16 13:26 -0700 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <6d02b2a1-be8d-423f-a170-f74a9242f6b3@googlegroups.com> |
| In reply to | #39180 |
> Perhaps parsing while postponing needs a visual indicator (here as |) to > show the extent of the parse, a bit like ". We could have POSTPONE |TO| > POSTPONE |TO V| Isn't the [[ ]] notation for that?
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-05-17 00:27 +0200 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <4jddgbx7iubc$.1fgrwyi2p4a5z$.dlg@40tude.net> |
| In reply to | #39182 |
Op Sat, 16 May 2015 13:26:40 -0700 (PDT) schreef Matthias Trute: >> Perhaps parsing while postponing needs a visual indicator (here as |) to >> show the extent of the parse, a bit like ". We could have POSTPONE |TO| >> POSTPONE |TO V| > > Isn't the [[ ]] notation for that? That would be ]] [[ notation ;-) -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-17 10:03 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <2015May17.120341@mips.complang.tuwien.ac.at> |
| In reply to | #39180 |
"Alex McDonald" <blog@rivadpm.com> writes:
>Perhaps parsing while postponing needs a visual indicator (here as |) to
>show the extent of the parse, a bit like ". We could have POSTPONE |TO|
>POSTPONE |TO V|
And
]] |bla| |bla| |to v| |bla| |bla| [[
instead of
]] bla bla ->v bla bla [[
Somehow I like the ->v approach better: It's easier to use. It's also
easier to implement: No special parsing of |, no need to burden
POSTPONE or TO with being able to deal with different parse units.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-17 23:25 +0100 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mjb4f0$i0j$1@dont-email.me> |
| In reply to | #39188 |
on 17/05/2015 11:03:41, wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>Perhaps parsing while postponing needs a visual indicator (here as |) to >>show the extent of the parse, a bit like ". We could have POSTPONE |TO| >>POSTPONE |TO V| > > And > > ]] |bla| |bla| |to v| |bla| |bla| [[ > > instead of > > ]] bla bla ->v bla bla [[ > > Somehow I like the ->v approach better: It's easier to use. It's also > easier to implement: No special parsing of |, no need to burden > POSTPONE or TO with being able to deal with different parse units. > > - anton This is uncomfortable territory. Apropos of that; augmenting the parse is one thing, rewriting it is the job of a DSL. I think we need to step back and think about how these kind of features are enabled, rather than proposing (as Matthias Trute appears to do) a wholesale chopping in of the current model.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-15 10:02 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <5555c44f$0$2994$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #39109 |
In article <9d272b4e-d089-4661-937e-ecddf2a7961c@googlegroups.com>,
JennyB <jennybrien@googlemail.com> wrote:
>On Wednesday, 13 May 2015 20:20:54 UTC+1, Matthias Trute wrote:
>
>> If I'm not mistaken a missing common practice means that the feature
>> is really difficult to standardize. That means in turn that the developer
>> should have full control over what he does.
>
>It also means, if we are lucky, we can get a clean and understandable model
>that isn't obscured by the cruft of existing common practice. ;)
>
>>
>> The [[ ]] syntax is a good argument pro postponing numbers. Is the idea
>> of a postpone state already common practice? With an explicit postpone
>> action it is still straight forward to achieve it as well, no need to
>> eliminate postpone from the recognizers. Other use cases may see the
>> exception -48 (invalid postpone) more appropriate. See above: no common
>> practice; in fact: no practice at all?
>
>No practice, but the rules seem clear enough. What a recognizer recognizes
>(let's call it a pattern) is, in effect, a word with variable content. You
>would use it rather that a preceding parsing word when you want that content
>to be used at compile time.
>
>
>Therefore:
> A pattern contains all its parsing within itself. When a pattern is
>postponed, the resulting code, when run add exactly the same code (including
>parsed content) that would have been produced when the original pattern was
>compiled.
>
> POSTPONE 42 adds 42 LITERAL
> POSTPONE ."Hello World" adds Hello World SLITERAL TYPE
>
>All nice and regular, and you use the equivalent parsing words if you want
>later binding. I'm not sure if there's ever much need for "special
>postponing semantics" except, perhaps to demonstrate that it can be done.
>
>>
>> Don't get me wrong, but all suggestions so far try to narrow the capabilities
>> of recognizers without making them substantially easier or less complex.
>
>Albert's system has the virtue of simplicity, and a couple of nice features:
>
> Apart from adding an extra bit-flag in the header and modifying FIND to
> match prefixes, it doesn't require any change in legacy text
> interpreters. The new 'words' 'just work'.
>
> The test is implicit in the header. A prefix word is just another
> STATE-smart Immediate definition.
>
> Because of that, prefixes obey the normal search order rules.
> They are active as soon as they are defined, and they are inactive
> when the wordlist in which they are defined is no longer in the
> search order.
>
>But I like the way your recognizers factor out, and how they allow
>recognition, interpretation, compilation and postponement of things other
>than definitions in a regular manner.
>
>I'm not so keen on GET-RECOGNIZERS and SET-RECOGNIZERS. I've had a good
>look at getting rid of the Search Order words by replacing wordlists with
>recognizers, and it doesn't really work. It seems to me that as with
>prefixes) a recognizer is more like an individual definition in a wordlist
>than the wordlist than the wordlist itself.
>
>If all your recognizers were prefixes, then you could have your r:tables and
>regular postponing with just one STATE-smart word:
>
> : OBEY \ r:table -- i*x ; perform the requisite action
> STATE @ IF
> postponing? IF r>post ELSE r>comp ELSE r>int THEN THEN EXECUTE ;
>
>
> : PREFIXED \ recognizer -- ;
> CREATE prefix immediate ,
> DOES> @ EXECUTE OBEY ;
>
>Unfortunately, I don't see how PREFIX can work on Forths with hashed
>dictionaries (unless they hash solely on the first character) and perhaps
>there is a case for recognizers that recognize something other than
>prefixes, in which case they need to be searched after the dictionary.
>On a simple Forth with no Search Order DO-RECOGNIZERS replaces the literal-
>handling part of the text interpreter.
I've given that some thought. One can always do it, by shortening words
that can't be found until they are present in the hash. By imposing the
rule that it is not allowed to hide recognizers by longer recognizers
(e.g. first define prefix 0 then prefix 0x) one can start from the shorter
recognizers for speed. Both are O(n).
By remembering the length of the largest prefix that hides another one
(in this case 2), and shorten words from there you're also fine.
Example you encounter 02AD . It is not in the hash. Length of largest hiding
prefix is 2. So you look up ``02'' , It is not in the hash. So you
lookup 0. That is found as a prefix (you reject constant 0 as it is not a
prefix).
Bottomline:
It can always be done.
Graceful degradation for overlapping and large prefixes.
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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-15 12:35 +0100 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mj4lkq$6oc$1@dont-email.me> |
| In reply to | #39134 |
on 15/05/2015 11:02:58, albert vd horst wrote: > I've given that some thought. One can always do it, by shortening > words that can't be found until they are present in the hash. By > imposing the rule that it is not allowed to hide recognizers by longer > recognizers (e.g. first define prefix 0 then prefix 0x) one can start > from the shorter recognizers for speed. Both are O(n). > By remembering the length of the largest prefix that hides another one > (in this case 2), and shorten words from there you're also fine. > Example you encounter 02AD . It is not in the hash. Length of largest > hiding prefix is 2. So you look up ``02'' , It is not in the hash. So > you lookup 0. That is found as a prefix (you reject constant 0 as it > is not a prefix). > > Bottomline: > It can always be done. > Graceful degradation for overlapping and large prefixes. > What will this produce? prefix: dead \ returns -1 for all prefixed dead hex dead decimal .
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-15 15:33 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <555611af$0$2951$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #39139 |
In article <mj4lkq$6oc$1@dont-email.me>,
Alex McDonald <blog@rivadpm.com> wrote:
>on 15/05/2015 11:02:58, albert vd horst wrote:
>> I've given that some thought. One can always do it, by shortening
>> words that can't be found until they are present in the hash. By
>> imposing the rule that it is not allowed to hide recognizers by longer
>> recognizers (e.g. first define prefix 0 then prefix 0x) one can start
>> from the shorter recognizers for speed. Both are O(n).
>> By remembering the length of the largest prefix that hides another one
>> (in this case 2), and shorten words from there you're also fine.
>> Example you encounter 02AD . It is not in the hash. Length of largest
>> hiding prefix is 2. So you look up ``02'' , It is not in the hash. So
>> you lookup 0. That is found as a prefix (you reject constant 0 as it
>> is not a prefix).
>>
>> Bottomline:
>> It can always be done.
>> Graceful degradation for overlapping and large prefixes.
>>
>
>What will this produce?
>
>prefix: dead \ returns -1 for all prefixed dead
>hex dead decimal .
Let's stylize that. dead doesn't interfere with my hex numbers,
but DEAD does. Furthermore a prefix must eat the remainder or
it isn't a prefix. And it must produce a literal, i.e. it must also
work at compile time. Also you are allowed to put a blank between a
prefix and its prefixee. So "dead decimal" is not what you
probably expect. See below.
It is essential to the transparancy and the usability of a prefix
that it leaves the parse pointer (>IN) directly behind itself.
So with that DEAD becomes:
: DEAD PARSE-NAME 2DROP -1 POSTPONE LITERAL ; PREFIX IMMEDIATE
HEX
DEADape .
-1 OK
: test DEADape DEADBEEF BEEFDEAD ;
test . . .
BEEFDEAD -1 -1 OK
So DEAD hides all hex numbers starting with DEAD.
Perhaps unexpected:
DEADBEEF HEX DEAD DECIMAL . .
-1 DEADBEEF OK
What happens here DEAD considers itself prefixing DECIMAL
so DECIMAL is eaten and not executed.
So don't do that, instead do
DEADBEEF HEX DEADDECIMAL . .
In a hash situation:
DEADBEEF hashed no match
DEADBEE hashed no match
DEADBE hashed no match
DEADB hashed no match
DEAD hashed match.
execution: DEAD
BEEFDEAD hashed no match
BEEFDEA hashed no match
BEEFDE hashed no match
BEEFD hashed no match
..
B hashed match
execution: do the usual number thing:
backup a character
get word
convert according to base
This is without any optimisations.
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 | 2015-05-15 14:01 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <2015May15.160159@mips.complang.tuwien.ac.at> |
| In reply to | #39109 |
JennyB <jennybrien@googlemail.com> writes:
>On Wednesday, 13 May 2015 20:20:54 UTC+1, Matthias Trute wrote:
>
>> If I'm not mistaken a missing common practice means that the feature
>> is really difficult to standardize. That means in turn that the developer
>> should have full control over what he does.
>
>It also means, if we are lucky, we can get a clean and understandable model
>that isn't obscured by the cruft of existing common practice. ;)
Or, we might get a bad design that has not been vetted by adoption in
a large number of systems and programs (LOCALS| anyone?). And the
definition of common practice by some ("It is common practice if it is
implemented in my Forth system and is used by my customers") does not
quite cut it, as the LOCALS| example demonstrates.
>I'm not so keen on GET-RECOGNIZERS and SET-RECOGNIZERS. I've had a good
>look at getting rid of the Search Order words by replacing wordlists with
>recognizers, and it doesn't really work. It seems to me that as with
>prefixes) a recognizer is more like an individual definition in a wordlist
>than the wordlist than the wordlist itself.
The difference is that you cannot remove individual words from
wordlists, while you may want to remove individual recognizers; e.g.,
you may have a recognizer for 20:48:25 meaning time in one place, but
something else in another place. And even more so with really
domain-specific notations.
>As I see it, if you want a particular recognizer you also want a bunch of
>other words relating to it. So with a Search Order, each wordlist should
>keep a stack of the recognizers declared within it, which the interpreter
>checks directly after the wordlist itself.
That's a good point.
>It is, of course, possible to have a wordlist with no definitions, only
>recognizers.
Yes, that's one idea I had: recognizers behave like wordlists, except
that they cannot be used in SET-CURRENT. That would avoid the need
for having a separate recognizer stack. But what's not yet clear to
me is how to integrate that with the current search order, in
particular if a program sets a given search order explicitly.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-15 13:14 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <2015May15.151415@mips.complang.tuwien.ac.at> |
| In reply to | #39082 |
Matthias Trute <matthias.trute@gmail.com> writes:
>The [[ ]] syntax is a good argument pro postponing numbers. Is the idea
>of a postpone state already common practice?
]] ... [[ is supported by several systems, but not supported by more.
>With an explicit postpone
>action it is still straight forward to achieve it as well, no need to
>eliminate postpone from the recognizers.
You have to convince the system implementors of systems that don't
have ]] ... [[ that the postpone action is good for something and not
just a complication.
>you suggest a
>literal-only approach.
No, my suggestions also work for other uses, e.g., a TO replacement.
>> So a proposal that only provides an interface with
>> literal-like and final-action may have an easier time in the
>> discussion and in the committee than the current proposal.
>
>It's better to have an easy time after the discussion. IMHO.
I also think that it is easier to use (although probably harder to
understand at first): Three different, but related actions mean more
possibilities for bugs than two independent actions; e.g., if you mess
up either the literal-like or the final-action, you will probably
notice it both when you test compiling and when you test postponing,
while a bug in the postpone-action will show up only when you test
postponing, and on some systems you may not be able to test that.
>PS: thanks for the links to the pdf's at foth200x.org. I could easily
>provide html version as well, if you want/think it's the better format.
Plain text would be great, because that's easy to cite in discussions.
And one stable link for the newest version.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-13 17:07 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <2015May13.190717@mips.complang.tuwien.ac.at> |
| In reply to | #39049 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>That pattern works for literals and also for the to-recognizer, where the
>final action is just ! (however, which ! depends on the data type of the
>value... and the literal-like does so, too, so it's not that simple).
Yes, but that's a problem coming of wanting a to-recognizer, that,
like TO, applies to lots of different kinds of words. So you have to
make the recognizer polymorphic, like TO.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-14 03:27 +0200 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mj0tje$mv9$1@dont-email.me> |
| In reply to | #39080 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>That pattern works for literals and also for the to-recognizer, where the >>final action is just ! (however, which ! depends on the data type of the >>value... and the literal-like does so, too, so it's not that simple). > > Yes, but that's a problem coming of wanting a to-recognizer, that, > like TO, applies to lots of different kinds of words. So you have to > make the recognizer polymorphic, like TO. The current way is just reusing the polymorphic part of TO, which interprets or compiles the correct stuff. -- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-13 19:23 -0700 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <7c87ae75-758d-4985-b326-f051facf854a@googlegroups.com> |
| In reply to | #39093 |
On Wednesday, May 13, 2015 at 6:27:14 PM UTC-7, Bernd Paysan wrote: > Anton Ertl wrote: > > > Bernd Paysan <bernd.paysan@gmx.de> writes: > >>That pattern works for literals and also for the to-recognizer, where the > >>final action is just ! (however, which ! depends on the data type of the > >>value... and the literal-like does so, too, so it's not that simple). > > > > Yes, but that's a problem coming of wanting a to-recognizer, that, > > like TO, applies to lots of different kinds of words. So you have to > > make the recognizer polymorphic, like TO. > > The current way is just reusing the polymorphic part of TO, which interprets > or compiles the correct stuff. The Forth-200x committee makes even the simplest problem sooooooooo complicated! Rube Goldberg would be proud! Get rid of TO altogether. Make local variables provide an address. Make each local variable big enough to hold a char, single-cell, double-cell or float variable. Then store your data with c! ! 2! or F! --- as the "Thinking Forth" book says: "Let the dictionary do the deciding." Duh! > Bernd Paysan > "If you want it done right, you have to do it yourself" You should change your tag-line to read: "If you want it done in the most over-complicated and feature-bereft manner possible, you have to have Bernd do it!"
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-05-14 01:08 -0700 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <7b66acb7-9940-4cc1-9a36-c64c4547c3d4@googlegroups.com> |
| In reply to | #39049 |
On Wednesday, 13 May 2015 00:31:40 UTC+1, Bernd Paysan wrote:
>
> What could be helpful is a table creator for literal-like recognizer, which
> takes the single action needed there (put the literal into the dictionary),
> and creates the three table entries for interpretation (nothing),
> compilation (just that "put the literal into the table"), and postponing
> (put the literal in the dictionary and then append the literal-like action).
> That could help people to write literal recognizers. But that would be an
> additional feature, not a replacement.
>
Or you could do it the easy way: have the recognizer leave the literal-handling word on the stack. Then you need only one table for all literals
' DROP
' EXECUTE
:NONAME DUP >R EXECUTE >R POSTPONE LITERAL POSTPONE COMPILE, ;
RECOGNIZER: R:LIT
Similarly, for literal+action
:NONAME NIP EXECUTE ;
:NONAME >R EXECUTE R> COMPILE, ;
:NONAME >R DUP >R EXECUTE
>R POSTPONE LITERAL POSTPONE COMPILE,
>R POSTPONE LITERAL POSTPONE COMPILE, ;
RECOGNIZER: R:LIT-DO
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-13 14:30 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <2015May13.163016@mips.complang.tuwien.ac.at> |
| In reply to | #39041 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Matthias Trute wrote:
>
>> That may get solved automatically if we consider Anton's idea of
>> re-organizing the 3 methods of a recognizer into 2.
>
>I don't like Anton's approach. It's a good idea to have that two
>abstactions only if you want to create another literal recognizer, but for
>those recognizers which aren't literal-like, the approach doesn't work.
It works for the TO-replacement, too, and they are not literals. For
which recognizers you have in mind does it not work?
Anyway, here's another idea: The recognizer actually defines a word,
e.g.:
On recognizing "bla", the string literal recognizer defines a word
like
: "bla" s\" bla" ;
or, on recognizing ->BLA (where BLA is a VALUE), the TO-replacement
recognizer defines a word like
: ->bla $12345678 ! ;
where $12345678 is the address of the content of BLA.
The memory for these words can be reclaimed after processing if they
are used in the text interpreter in interpretation state. If these
words are reliably inlined, then the memory can also be reclaimed if
they are used in the text interpreter in compile state. For all other
uses (', POSTPONE, FIND-NAME), we have to keep them, but these uses
are relatively rare.
Advantages: 1) Conceptual simplicity: recognizers work more like
ordinary words than now. 2) You can do with these recognizer words
everything that you can do with explicitly defined words: Tick them
(and do everything you can do with xts), POSTPONE them, FIND-NAME them
and do, e.g. NAME>STRING.
Disadvantages: Implementation complexity: The implementor has to deal
with the memory for these possibly-temporary words, and should better
implement reliable inlining. More work for the computer during text
interpretation: For every recognized word, such a temporary word has
to be defined, and then possibly inlined, instead of the more direct
approaches used now.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-14 03:40 +0200 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mj0uce$p70$1@dont-email.me> |
| In reply to | #39075 |
Anton Ertl wrote:
> It works for the TO-replacement, too, and they are not literals. For
> which recognizers you have in mind does it not work?
What about the dot-parser? The one that wraps a method in >o <method> o>?
: >oo> ( xt -- ) postpone >o compile, postpone o> ;
:noname ( object xt -- ) swap >o execute o> ; \ interpreter
' >oo> \ compiler
:noname ( xt -- ) lit, postpone >oo> ; \ postponer
recognizer: r:moof2
You still can do that with an action, but at a performance cost.
> Anyway, here's another idea: The recognizer actually defines a word,
> e.g.:
>
> On recognizing "bla", the string literal recognizer defines a word
> like
>
> : "bla" s\" bla" ;
>
> or, on recognizing ->BLA (where BLA is a VALUE), the TO-replacement
> recognizer defines a word like
>
> : ->bla $12345678 ! ;
>
> where $12345678 is the address of the content of BLA.
>
> The memory for these words can be reclaimed after processing if they
> are used in the text interpreter in interpretation state. If these
> words are reliably inlined, then the memory can also be reclaimed if
> they are used in the text interpreter in compile state. For all other
> uses (', POSTPONE, FIND-NAME), we have to keep them, but these uses
> are relatively rare.
>
> Advantages: 1) Conceptual simplicity: recognizers work more like
> ordinary words than now. 2) You can do with these recognizer words
> everything that you can do with explicitly defined words: Tick them
> (and do everything you can do with xts), POSTPONE them, FIND-NAME them
> and do, e.g. NAME>STRING.
>
> Disadvantages: Implementation complexity: The implementor has to deal
> with the memory for these possibly-temporary words, and should better
> implement reliable inlining. More work for the computer during text
> interpretation: For every recognized word, such a temporary word has
> to be defined, and then possibly inlined, instead of the more direct
> approaches used now.
The TO-recognizer wants to work with locals. I suppose that
: foo { a b c } ... ->a ... ->b ;
: bar { b a } ->b ... ->a ;
will address the corresponding locals of foo and bar. The compilation of
those would be something like
: ->a laddr# 0 ! ;
and then only work when a is the first local.
--
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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-15 13:26 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <2015May15.152621@mips.complang.tuwien.ac.at> |
| In reply to | #39094 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> It works for the TO-replacement, too, and they are not literals. For
>> which recognizers you have in mind does it not work?
>
>What about the dot-parser? The one that wraps a method in >o <method> o>?
>
>: >oo> ( xt -- ) postpone >o compile, postpone o> ;
>:noname ( object xt -- ) swap >o execute o> ; \ interpreter
>' >oo> \ compiler
>:noname ( xt -- ) lit, postpone >oo> ; \ postponer
>recognizer: r:moof2
>
>You still can do that with an action, but at a performance cost.
You mean, the final-action
: moof2-final ( object xt -- ) swap >o execute o> ;
would result in slower code for the compile and postpone cases? Yes,
unless we assume extremely good compilers. So having the option for
the explicit interpret, compile, and postpone actions would still be
useful.
>> Anyway, here's another idea: The recognizer actually defines a word,
>> e.g.:
>>
>> On recognizing "bla", the string literal recognizer defines a word
>> like
>>
>> : "bla" s\" bla" ;
>>
>> or, on recognizing ->BLA (where BLA is a VALUE), the TO-replacement
>> recognizer defines a word like
>>
>> : ->bla $12345678 ! ;
>>
>> where $12345678 is the address of the content of BLA.
>>
>> The memory for these words can be reclaimed after processing if they
>> are used in the text interpreter in interpretation state. If these
>> words are reliably inlined, then the memory can also be reclaimed if
>> they are used in the text interpreter in compile state. For all other
>> uses (', POSTPONE, FIND-NAME), we have to keep them, but these uses
>> are relatively rare.
>>
>> Advantages: 1) Conceptual simplicity: recognizers work more like
>> ordinary words than now. 2) You can do with these recognizer words
>> everything that you can do with explicitly defined words: Tick them
>> (and do everything you can do with xts), POSTPONE them, FIND-NAME them
>> and do, e.g. NAME>STRING.
>>
>> Disadvantages: Implementation complexity: The implementor has to deal
>> with the memory for these possibly-temporary words, and should better
>> implement reliable inlining. More work for the computer during text
>> interpretation: For every recognized word, such a temporary word has
>> to be defined, and then possibly inlined, instead of the more direct
>> approaches used now.
>
>The TO-recognizer wants to work with locals. I suppose that
>
>: foo { a b c } ... ->a ... ->b ;
>: bar { b a } ->b ... ->a ;
>
>will address the corresponding locals of foo and bar. The compilation of
>those would be something like
>
>: ->a laddr# 0 ! ;
>
>and then only work when a is the first local.
Yes, something like that.
Having thought some more about this approach, I like it even more. A
major advantage is that the programmer of the recognizer only has to
specify the compile action (no interpret and postpone action, nor
literal-like and final-action), and the other two fall out from that,
reducing the effort of the programmer and the potential for bugs.
Because the programmer specifies the compile action, the performance
cost of the moof2 example above does not occur.
I have also thought about the "reliable inlining" requirement given
above: The recognizer programmer specifies the compile action, so if
we want the compilation semantics of the recognized word, instead of
COMPILE,ing that word (and relying on the inliner to avoid a reference
to that word), we could call the compile action of the recognizer, and
get the same effect. Disadvantage: the integration into text
interpreters may not be as nice as with the plain define-a-word
approach, but still not any worse than for the currently-proposed
recognizers.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web