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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-11 11:20 +0100 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mipvnm$ehi$1@dont-email.me> |
| In reply to | #38959 |
on 11/05/2015 08:07:52, "Alex McDonald" wrote:
> on 05/05/2015 22:03:56, "Alex McDonald" wrote:
>> I've reviewed the recognizer RfD and my first reaction is that it's
>> too complex and too prescriptive.
>
> http://amforth.sourceforge.net/pr/Recognizer-rfc.pdf
> http://amforth.sourceforge.net/pr/Recognizer2-en.pdf
>
> http://www.complang.tuwien.ac.at/anton/euroforth/ef12/papers/paysan-recognizers.pdf
>
> I've had an opportunity to do some coding and play around with the
> concepts in the RfD over the last few days. I still believe it's
> over-prescriptive but it could be reduced back to a smaller set of
> words. It's interesting in its relative simplicity and flexibility at
> core, and it's potential for orthogonal treatment of words and numbers
> during interpretation and compilation. Perhaps the only downside is
> the requirement to return a named token R:FAIL from recognizers.
> Win32Forth uses THROW for this purpose, which is not ideal either, but
> it does allow the stack to be in some disarray when failing. We had a
> fail flag before, and it caused quite a bit of a headache when parsing
> complex structures and having to balance the stack on exit. The
> solution then was to encapsulate with a CATCH, which led directly to
> using the THROW as a signal.
>
Second observation. I'm liking the proposal more as I work with it, but
not liking the way it's burying a related problem. Recognizers require a
new approach to FIND or FIND-NAME in terms of the information they
return. Yes, we can define REC:WORD and fudge out the issue by having it
as the first recognizer, but it doesn't strike me as very satisfactory
not to fix the base problem. Is there any appetite for fixing them first?
All the below is a workaround, REC:WOD is worse than FIND in its variable
return arguments, and there are also issues with the R:WORD POSTPONE
action as shown.
: immediate? ( flags -- true|false )
0> ;
:NONAME ( i*x XT flags -- j*y ) \ INTERPRET
DROP EXECUTE ;
:NONAME ( XT flags -- ) \ COMPILE
immediate? IF COMPILE, ELSE EXECUTE THEN ;
:NONAME ( XT flags -- ) \ POSTPONE
immediate? ate? IF COMPILE, ELSE POSTPONE LITERAL POSTPONE COMPILE, THEN
; RECOGNIZER: R:WORD
: REC:WORD ( addr len -- XT flags R:WORD | R:FAIL )
find-name ( addr len -- XT flags | 0 )
?DUP IF R:WORD ELSE R:FAIL THEN ;
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2015-05-12 10:05 -0700 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <d84f2721-5ab9-4e58-8888-5a31fb02f9d5@googlegroups.com> |
| In reply to | #38963 |
> Second observation. I'm liking the proposal more as I work with it, but > not liking the way it's burying a related problem. Recognizers require a > new approach to FIND or FIND-NAME in terms of the information they > return. Recognizers don't *require* a new approach, they enable it (them). I agree that FIND needs a modernization, but I don't see the Recognizers as the right place to do it. > Yes, we can define REC:WORD and fudge out the issue by having it > as the first recognizer, but it doesn't strike me as very satisfactory > not to fix the base problem. Is there any appetite for fixing them first? I wrote a recognizer that uses the Forth 2012 name tokens instead. Really interesting, but I suppose that they are not the final word here. Matthias
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-12 18:34 +0100 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mitdgh$ul2$1@dont-email.me> |
| In reply to | #39033 |
on 12/05/2015 18:05:28, Matthias Trute wrote: >> Second observation. I'm liking the proposal more as I work with it, but >> not liking the way it's burying a related problem. Recognizers require a >> new approach to FIND or FIND-NAME in terms of the information they >> return. > > Recognizers don't *require* a new approach, they enable it (them). > I agree that FIND needs a modernization, but I don't see the > Recognizers as the right place to do it. It will be another reason to do it. > >> Yes, we can define REC:WORD and fudge out the issue by having it >> as the first recognizer, but it doesn't strike me as very satisfactory >> not to fix the base problem. Is there any appetite for fixing them first? > > I wrote a recognizer that uses the Forth 2012 name tokens instead. A new word RECOGNIZE returning an NT-like thing that's an R:word requires no more than a very lightweight wrapper for gforth's FIND-NAME (which hasn't been standardised yet). I have such a beast, so the exercise is trivial. I just need to get my head round having a dual XT header, and what the standardised NAME>COMPILE and NAME>INTERPRET means in terms of _R>COMP and _R>INT in your proposal. I think they're identical. But there's no NAME>POSTPONE for _R>POST, so I'll need a bit of header work (or a flag or somesuch) for that. > Really interesting, but I suppose that they are not the final word > here. There's a pun in there somewhere. > > Matthias >
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2015-05-12 12:07 -0700 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <639f9058-b0ef-4e67-a9b0-d1a52a4fb1b0@googlegroups.com> |
| In reply to | #39035 |
> A new word RECOGNIZE returning an NT-like thing that's an R:word requires > no more than a very lightweight wrapper for gforth's FIND-NAME (which > hasn't been standardised yet). I called that recognizer R:NAME. > I just need to get my head round having a dual XT header, and > what the standardised NAME>COMPILE and NAME>INTERPRET means in terms of > _R>COMP and _R>INT in your proposal. I think they're identical. They are identical indeed. The code is taken verbatim from Forth 2012 :noname name>interpret execute ; :noname name>compile execute ; :noname name>compile swap postpone literal compile, ; recognizer: r:name The rec:name is much more system specific, I didn't try to make it portable. http://sourceforge.net/p/amforth/code/HEAD/tree/trunk/examples/rec-name.frt > But there's no NAME>POSTPONE for _R>POST, so I'll need a bit of header work > (or a flag or somesuch) for that. That may get solved automatically if we consider Anton's idea of re-organizing the 3 methods of a recognizer into 2. One consequence I've already mentioned: postpone 42. becomes possible. I updated the second round of the RFD at http://amforth.sourceforge.net/pr/Recognizer-rfc-B.pdf It is work in progress. Matthias
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-12 22:11 +0200 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mitmno$552$1@dont-email.me> |
| In reply to | #39040 |
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. -- 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-12 21:35 +0100 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mito3o$bf9$1@dont-email.me> |
| In reply to | #39041 |
on 12/05/2015 21:11:39, Bernd Paysan wrote: > 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. > Whcih approach is that? I may have missed something here.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-13 01:31 +0200 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <miu2eo$i63$1@dont-email.me> |
| In reply to | #39043 |
Alex McDonald wrote: > on 12/05/2015 21:11:39, Bernd Paysan wrote: >> 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. >> > > Whcih approach is that? I may have missed something here. That was on the mailing list: https://groups.yahoo.com/neo/groups/forth200x/conversations/messages/1190 Essentially, a recognizer would consist of the conversion part (which we already have now separated in the recognizer word), and two different actions: the "literal-like" which puts the data into a definition, and the "final-action", which does something on the literal (if any - if it's completely literal-like, final-action is a no-op). 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). 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. -- 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-13 16:20 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <2015May13.182009@mips.complang.tuwien.ac.at> |
| In reply to | #39049 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>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.
One could also have a table creator for recognizers with a run-time
portion, like the TO recognizer. That covers all applications of
recognizers that I know of. Do you know any that it doesn't?
> But that would be an
>additional feature, not a replacement.
Yes, that's a good idea in principle. However, I think that a
proposal that caters for postponing explicitly is going to have a hard
time being accepted, because postpone state or postponing numbers is
not common practice (as in: the majority of systems does not have this
feature). 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.
- 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 | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2015-05-13 12:20 -0700 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <00ad1695-d803-43b6-be24-39be1e0e87af@googlegroups.com> |
| In reply to | #39079 |
> One could also have a table creator for recognizers with a run-time > portion, like the TO recognizer. Alex McDonald already complained about complexity, so please keep it simple. Temporary words are not simple too. > Yes, that's a good idea in principle. However, I think that a > proposal that caters for postponing explicitly is going to have a hard > time being accepted, because postpone state or postponing numbers is > not common practice (as in: the majority of systems does not have this > feature). 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. 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? 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 van der Horst sees prefixes as good enough, you suggest a literal-only approach. > 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. Matthias 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.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-13 22:24 +0100 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mj0fd1$glr$1@dont-email.me> |
| In reply to | #39082 |
on 13/05/2015 20:20:49, Matthias Trute wrote: >> One could also have a table creator for recognizers with a run-time >> portion, like the TO recognizer. > > Alex McDonald already complained about complexity, so please keep > it simple. Temporary words are not simple too. Complaint is too strong a word for it! I've read a large tranch of posts here that I hadn't read before on recognizers, and reread the recent ones. Albert vd Horst's alternative solution is very simple. Andrew Haley (who hasn't been on clf for quite a while now) and Bernd Paysan have several criticisms that I need to think on. Anton Ertl makes a strong case for a future Forth that's different from what we have now, and your RfD is a start towards that. I need to try it out further, and I appreciate the acknowledgement.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-14 11:26 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <5554867e$0$23194$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #39082 |
In article <00ad1695-d803-43b6-be24-39be1e0e87af@googlegroups.com>, Matthias Trute <matthias.trute@gmail.com> wrote: >> One could also have a table creator for recognizers with a run-time >> portion, like the TO recognizer. > >Alex McDonald already complained about complexity, so please keep >it simple. Temporary words are not simple too. > >> Yes, that's a good idea in principle. However, I think that a >> proposal that caters for postponing explicitly is going to have a hard >> time being accepted, because postpone state or postponing numbers is >> not common practice (as in: the majority of systems does not have this >> feature). > >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. > >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? > >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 van der Horst sees prefixes as good enough, you suggest a >literal-only approach. I introduced prefixes a very long time ago by showing an implementation that adds two lines to a Forth system. Subsequent changes possible to number and strings words and elimination of S" C" and such amounts to a net simplification of a total Forth system. I've published yourforth that is a demonstration of what you can do in the direction of simplicity, if you sacrifice some compatibility. The only disadvantage of prefixes is that not all denotations invented by other languages can be emulated. So I don't agree with it if you say that the capabilities are narrowed down. My approach looses on secondary issues not on expressibility. In essence prefixes are a "literal-only approach" too but like all powerful concepts they can be abused. <SNIP> >Matthias <SNIP> -- 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 | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2015-05-14 11:00 -0700 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <7b5cf8be-8eb2-4995-8343-8f884e6240e5@googlegroups.com> |
| In reply to | #39106 |
> > The only disadvantage of prefixes is that not all denotations invented > by other languages can be emulated. I don't care much about other (pogramming) languages. Using the $dead notation is fine with me, adding 0xBEEF or a BEEFh is not what I intend. Please believe me that I don't want to upset you by saying that prefixes are "narrow" recognizers. What I look at are domain specific languages using the Forth command interpreter. Forth developers can be very creative and geniuse when they simply use the system. > So I don't agree with it if you > say that the capabilities are narrowed down. My approach looses on > secondary issues not on expressibility. No offense intended, really. I beg you pardon. Matthias
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-05-14 08:06 -0700 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <9d272b4e-d089-4661-937e-ecddf2a7961c@googlegroups.com> |
| In reply to | #39082 |
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.
In this case, is it enough for the recognizers to be set in the order in
which they are defined? Is there any need for need for GET-RECOGNIZER and
SET-RECOGNIZER?
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.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-14 17:21 +0100 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mj2i0c$80n$1@dont-email.me> |
| In reply to | #39109 |
on 14/05/2015 16:06:48, JennyB 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. ;)
There's existing practise of sorts; Albert's denotations and Win32Forth
(and my private Forth's) chain number conversion; and gforth has
recognizers.
>
>>
>> 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
Does not further parse (read the input stream)? Or in the
parse-string-for-semantics sense?
> 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.
It's nice and regular if you don't want to FIND or ' them. As Anton has
noted, that causes all sorts of issues & side effects, such as a
requirement for persistence that the original token didn't require.
>
>>
>> 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.
It has a downside. Win32Forth requires a very large list of Windows
constants to be available. I don't want them as source code defined as
CONSTANT (at 30k+ of them, that's a big chunk of source and a huge
wordlist in the megabyte range). What we want to have is (for instance)
WM_SIZE act like a constant and leave a cell literal on the stack or
compile one. There's the added annoyance of <name> sometimes being
<name>A for the ASCII version or <name>W for the widechar version; the
Windows doc only mentions the <name> since all this happens under the
covers when compiling with a C compiler and a big included set of
defines. I don't want application programmers to have to think about what
<name>X and it will also limit my Forth if and when it moves to full
widechars.
There are two ways to solve this. Wordlists in my Forth have user
definable definition words for the header, and for search and iteration
(to support CREATE & colon, FIND and TRAVERSE-WORLDIST respectively). As
the constants exist as a loadable and discardable DLL, I can create a
wordlist and provide these words, along with a dummy definition that's
updated on a match to return something that looks and acts like a
CONSTANT. Downside; the NT and XT are always the same, and there are
various side effects with optimisation that are undesirable. (I've tried
& rejected this.)
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
That's where a recognizer works and a prefix doesn't, since there isn't a
prefix.
>
> 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.
Agreed, these are as annoying as GET-ORDER and SET-ORDER. I much prefer
the abstracted ONLY ALSO PREVIOUS and so on, as 99 times out of a 100
it's a stack of wordlists, not a list.
>
> 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.
>
> In this case, is it enough for the recognizers to be set in the order
> in which they are defined? Is there any need for need for
> GET-RECOGNIZER and SET-RECOGNIZER?
I've never had any requirement to even think about changing the order
with the fix chains system. "Patterns" so far are unique and only match
one recognizer; any ambiguity would be undesirable, surely?
>
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2015-05-14 11:31 -0700 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <03e19bb6-0273-4c83-a81b-a97f98556894@googlegroups.com> |
| In reply to | #39111 |
> There's existing practise of sorts; Albert's denotations and Win32Forth > (and my private Forth's) chain number conversion; and gforth has > recognizers. I know that gforth can postpone literal numbers, the others too? > > 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. > > It's nice and regular if you don't want to FIND or ' them. As Anton has > noted, that causes all sorts of issues & side effects, such as a > requirement for persistence that the original token didn't require. I think a major part of the problem is that FIND and Co need a new design but nobody did so yet. Recognizers are IMHO the wrong place to discuss the various semantics and states etc. Until that is done, we may use recognizers to play with the variants, but cannot achieve a satisfacting solution. > > > > 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. > > Agreed, these are as annoying as GET-ORDER and SET-ORDER. I much prefer > the abstracted ONLY ALSO PREVIOUS and so on, Well, we can talk about >RECOGNIZER RECOGNIZER> etc (siee >ORDER, ORDER> @ORDER). A ONLY may be useful for emergency cases too. But please no ALSO and PREVIOUS. > I've never had any requirement to even think about changing the order > with the fix chains system. "Patterns" so far are unique and only match > one recognizer; any ambiguity would be undesirable, surely? With a DSL in place that may look differently. I've already swapped number and dictionary lookup to speed up compilation of larger tables. Not a valid business case, but thing went faster that way. Matthias
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-14 19:41 +0100 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mj2q6i$9ug$1@dont-email.me> |
| In reply to | #39119 |
on 14/05/2015 19:31:09, Matthias Trute wrote: >> There's existing practise of sorts; Albert's denotations and Win32Forth >> (and my private Forth's) chain number conversion; and gforth has >> recognizers. > > I know that gforth can postpone literal numbers, the others too? Win32Forth can't. > >> > 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. >> >> It's nice and regular if you don't want to FIND or ' them. As Anton has >> noted, that causes all sorts of issues & side effects, such as a >> requirement for persistence that the original token didn't require. > > I think a major part of the problem is that FIND and Co need a new > design but nobody did so yet. Recognizers are IMHO the wrong place to > discuss the various semantics and states etc. Until that is done, we > may use recognizers to play with the variants, but cannot achieve a > satisfacting solution. Yes, and it's my opinion that this needs discussed first. Here are some; NTs vs XTs, a better understanding of interpret vs compilation semantics, a resolution of what ' <name> COMPILE, does with immediate words, whether IMMEDIATE is dead & what replaces it, the standardisation of FIND-NAME; all would all be helpful. > >> > >> > 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. >> >> Agreed, these are as annoying as GET-ORDER and SET-ORDER. I much prefer >> the abstracted ONLY ALSO PREVIOUS and so on, > > Well, we can talk about >RECOGNIZER RECOGNIZER> etc (siee >ORDER, > ORDER> @ORDER). A ONLY may be useful for emergency cases too. But > please no ALSO and PREVIOUS. Why not?
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2015-05-14 11:49 -0700 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <bbc0af9d-781a-4cc6-b3a5-ce9e489ee24e@googlegroups.com> |
| In reply to | #39120 |
> > I think a major part of the problem is that FIND and Co need a new > > design but nobody did so yet. Recognizers are IMHO the wrong place to > > discuss the various semantics and states etc. Until that is done, we > > may use recognizers to play with the variants, but cannot achieve a > > satisfacting solution. > > Yes, and it's my opinion that this needs discussed first. Here are some; > NTs vs XTs, a better understanding of interpret vs compilation semantics, > a resolution of what ' <name> COMPILE, does with immediate words, whether > IMMEDIATE is dead & what replaces it, the standardisation of FIND-NAME; > all would all be helpful. Indeed. > >> > 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. > >> > >> Agreed, these are as annoying as GET-ORDER and SET-ORDER. I much prefer > >> the abstracted ONLY ALSO PREVIOUS and so on, > > > > Well, we can talk about >RECOGNIZER RECOGNIZER> etc (siee >ORDER, > > ORDER> @ORDER). A ONLY may be useful for emergency cases too. But > > please no ALSO and PREVIOUS. > > Why not? A matter of taste. ALSO is in fact DUP on another stack, PREVIOUS is DROP. *If* there would be a general tool set for such cases, fine. I'd use it. Forth can deal with many stacks at the same time. Matthias
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-15 09:41 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <5555bf4f$0$3002$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #39111 |
In article <mj2i0c$80n$1@dont-email.me>, Alex McDonald <blog@rivadpm.com> wrote: >on 14/05/2015 16:06:48, JennyB 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. ;) > >There's existing practise of sorts; Albert's denotations and Win32Forth >(and my private Forth's) chain number conversion; and gforth has >recognizers. > >> >>> >>> 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 > >Does not further parse (read the input stream)? Or in the >parse-string-for-semantics sense? > >> 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. > >It's nice and regular if you don't want to FIND or ' them. As Anton has >noted, that causes all sorts of issues & side effects, such as a >requirement for persistence that the original token didn't require. > >> >>> >>> 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. > >It has a downside. Win32Forth requires a very large list of Windows >constants to be available. I don't want them as source code defined as >CONSTANT (at 30k+ of them, that's a big chunk of source and a huge >wordlist in the megabyte range). What we want to have is (for instance) >WM_SIZE act like a constant and leave a cell literal on the stack or >compile one. There's the added annoyance of <name> sometimes being ><name>A for the ASCII version or <name>W for the widechar version; the >Windows doc only mentions the <name> since all this happens under the >covers when compiling with a C compiler and a big included set of >defines. I don't want application programmers to have to think about what ><name>X and it will also limit my Forth if and when it moves to full >widechars. > >There are two ways to solve this. Wordlists in my Forth have user >definable definition words for the header, and for search and iteration >(to support CREATE & colon, FIND and TRAVERSE-WORLDIST respectively). As >the constants exist as a loadable and discardable DLL, I can create a >wordlist and provide these words, along with a dummy definition that's >updated on a match to return something that looks and acts like a >CONSTANT. Downside; the NT and XT are always the same, and there are >various side effects with optimisation that are undesirable. (I've tried >& rejected this.) > >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 > >That's where a recognizer works and a prefix doesn't, since there isn't a >prefix. In practice prefixes are used a lot in the large namespace that Windows defines. For example I see that all constants that are had from MIDI.DLL have the prefix midi : midiOutOpen midiOutClose midiSendShortMessage So we could define a PREFIX "midi" and have it automatically couple to the MIDI.DLL library. I doubt that such would have much disadvantages, maybe a certain awareness what dll is being used. Now I see repetitive code: "midiOutOpen" 'WINMM DLL-ADDRESS: midiOutOpen "midiOutShortMsg" 'WINMM DLL-ADDRESS: midiOutShortMsg "midiOutClose" 'WINMM DLL-ADDRESS: midiOutClose This is reminiscent of 41 CONSTANT &A 42 CSONTANT &B 43 CSONTANT &C i.e. exactly the case where prefixes where invented for. <SNIP> Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-15 12:19 +0100 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mj4kmb$3dm$1@dont-email.me> |
| In reply to | #39133 |
on 15/05/2015 10:41:31, albert vd horst wrote: > Alex McDonald <blog@rivadpm.com> wrote: >> >>That's where a recognizer works and a prefix doesn't, since there isn't a >>prefix. > > In practice prefixes are used a lot in the large namespace that > Windows defines. > > For example I see that all constants that are had from MIDI.DLL have > the prefix midi : > midiOutOpen > midiOutClose > midiSendShortMessage > > So we could define a PREFIX "midi" and have it automatically couple to > the MIDI.DLL library. I doubt that such would have much disadvantages, > maybe a certain awareness what dll is being used. Now I see repetitive > code: > > "midiOutOpen" 'WINMM DLL-ADDRESS: midiOutOpen > "midiOutShortMsg" 'WINMM DLL-ADDRESS: midiOutShortMsg > "midiOutClose" 'WINMM DLL-ADDRESS: midiOutClose > > This is reminiscent of > 41 CONSTANT &A > 42 CSONTANT &B > 43 CSONTANT &C > > i.e. exactly the case where prefixes where invented for. The midi prefix you show is actually for function entry point names, not constants. My Forth and Win32Forth deal with them as words that happen to be case sensitive. They're not compiled as numbers to be EXECUTEd but as calls to the underlying OS. There are stack issues and parameters that simple literal constants don't have. Recognizers are a pretty good fit and greatly simplify this kind of complexity. I've looked at the constants, and I can assure you that doing this by prefix is not a practical solution. There are literally several 10s of thousands of constant names in Windows, with several hundred prefixes. I have a list of 69,000+ constants from Windows 7 that I can share with anyone who's interested; it's used to build an updated WINCON.DLL, a DLL that is used by SwiftForth for Windows and Win32Forth. > > <SNIP> > > Groetjes Albert
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-15 14:42 +0000 |
| Subject | Re: Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <555605bb$0$2954$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #39138 |
In article <mj4kmb$3dm$1@dont-email.me>, Alex McDonald <blog@rivadpm.com> wrote: >on 15/05/2015 10:41:31, albert vd horst wrote: > >> Alex McDonald <blog@rivadpm.com> wrote: >>> >>>That's where a recognizer works and a prefix doesn't, since there isn't a >>>prefix. >> >> In practice prefixes are used a lot in the large namespace that >> Windows defines. >> >> For example I see that all constants that are had from MIDI.DLL have >> the prefix midi : >> midiOutOpen >> midiOutClose >> midiSendShortMessage >> >> So we could define a PREFIX "midi" and have it automatically couple to >> the MIDI.DLL library. I doubt that such would have much disadvantages, >> maybe a certain awareness what dll is being used. Now I see repetitive >> code: >> >> "midiOutOpen" 'WINMM DLL-ADDRESS: midiOutOpen >> "midiOutShortMsg" 'WINMM DLL-ADDRESS: midiOutShortMsg >> "midiOutClose" 'WINMM DLL-ADDRESS: midiOutClose >> >> This is reminiscent of >> 41 CONSTANT &A >> 42 CSONTANT &B >> 43 CSONTANT &C >> >> i.e. exactly the case where prefixes where invented for. > >The midi prefix you show is actually for function entry point names, not >constants. My Forth and Win32Forth deal with them as words that happen to >be case sensitive. They're not compiled as numbers to be EXECUTEd but as >calls to the underlying OS. There are stack issues and parameters that >simple literal constants don't have. Recognizers are a pretty good fit >and greatly simplify this kind of complexity. > >I've looked at the constants, and I can assure you that doing this by >prefix is not a practical solution. There are literally several 10s of >thousands of constant names in Windows, with several hundred prefixes. I >have a list of 69,000+ constants from Windows 7 that I can share with >anyone who's interested; it's used to build an updated WINCON.DLL, a DLL >that is used by SwiftForth for Windows and Win32Forth. I see. Most of the constants are not function entry points. I was a bit over-enthusiastic. Also, although the things defined by DLL-ADDRESS: are constants for all practical purposes, they are not constant until run time. The trick that helps with that probably only works with indirect threaded code. A pity. 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]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web