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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-05 22:03 +0100 |
| Message-ID | <mibb5p$ibh$1@dont-email.me> |
| In reply to | #38792 |
on 03/05/2015 15:30:31, JennyB wrote: > On Sunday, 3 May 2015 11:19:46 UTC+1, Alex McDonald wrote: >> on 02/05/2015 18:00:34, Anton wrote: >> > That is why recognizers are better than parsing words like >> > S"; no STATE-smartness or SET-COMPILER problems. >> >> From EuroForth 2014: "Recognizers: Matthias Trute is working on an RfD". >> Did it eever get written? I've looked on the Forth RfDs and not seen it. > > http://amforth.sourceforge.net/pr/Recognizer-rfc.pdf > Recognizers offer a way to respond to different patterns, such as a > prefix for alternative number formats. When they match, they return > <something> (probably) on the stack, and a key to how to interpret, > compile or postpone it. They are kinda-sorta like wordlists, and we've > had some discussion as to how or whether they should be part of the > Search Order. > > Although recognizers can deal with many patterns, the most common and > easie st to decode is a fixed prefix followed by variable text. Then, > for exampl e, you can write "HELLO WORLD" instead of S" HELLO WORLD", > so it is a poss ible replacement for dual words. > > You obviously can't tick a pattern, but it does make sense to POSTPONE > it, because all the parsing is done at compile time, which makes > compiler macro s a bit neater. ]] lions tigers bears "Oh My!" type [[ > > With a well-behaved POSTPONE S" , on the other hand, the parsing would > take place when the macro was executed. > I've reviewed the recognizer RfD and my first reaction is that it's too complex and too prescriptive. Win32Forth and my derivative use the following method; from the doc (note that chain is a singly linked list of XTs to be executed in sequence). <quote> "Each number conversion routine on the "number?-chain" chain is sent a string ( addr len) and can attempt to convert the number. If the conversion fails the routine performs a -1 THROW to indicate that it can't convert the string; the next routine is then tried until success or the chain is exhausted. If the chain is exhausted, then a -13 THROW (undefined) is executed. [Historical note] Earlier versions of Win32Forth used a similar chain technique, but carried a flag that was checked to see if the preceding routine had succesfully done the conversion. Performing a THROW on failure is much easier since it can be issued regardless of stack oontents as it automaticaly tidies up the stack before returning." </quote> The downsides of this are: (a) The exception wordset is required (b) It returns only a cell, two cells or a float with an appropriate flag (but this may be all that's needed) (b) It's a list of recognizers rather than a stack (but that can be rectified quite simply) However, it is simple, it is easy to implement new recognizers, and it has proved enormously flexible. It also supports MOPS-like object:method syntaxes. Windows has many constants. A recognizer provides lookup of constants in a provided DLL. Words such as WM_MOVE are resolved "automagically" so that they can be used without having to declare them as CONSTANT. I think the proposed system also introduces a number of new problems. (a) There is no proposal for what might be meant by POSTPONE 42 and other tokens (and it doesn't discuss it, but also what is meant by ' 42). (b) It introduces three XTs to deal with the recognised token: XT-INTERPRET XT-COMPILE XT-POSTPONE. This requires STATE in the interpreter, and causes extra complexity in dual XT systems where compilation vs interpretation is based on a programmatically maintained state rather than a tested variable.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-05 22:56 +0000 |
| Message-ID | <55494a93$0$21307$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #38848 |
In article <mibb5p$ibh$1@dont-email.me>,
Alex McDonald <blog@rivadpm.com> wrote:
>on 03/05/2015 15:30:31, JennyB wrote:
>> On Sunday, 3 May 2015 11:19:46 UTC+1, Alex McDonald wrote:
>>> on 02/05/2015 18:00:34, Anton wrote:
>>> > That is why recognizers are better than parsing words like
>>> > S"; no STATE-smartness or SET-COMPILER problems.
>>>
>>> From EuroForth 2014: "Recognizers: Matthias Trute is working on an RfD".
>>> Did it eever get written? I've looked on the Forth RfDs and not seen it.
>>
>> http://amforth.sourceforge.net/pr/Recognizer-rfc.pdf
>> Recognizers offer a way to respond to different patterns, such as a
>> prefix for alternative number formats. When they match, they return
>> <something> (probably) on the stack, and a key to how to interpret,
>> compile or postpone it. They are kinda-sorta like wordlists, and we've
>> had some discussion as to how or whether they should be part of the
>> Search Order.
>>
>> Although recognizers can deal with many patterns, the most common and
>> easie st to decode is a fixed prefix followed by variable text. Then,
>> for exampl e, you can write "HELLO WORLD" instead of S" HELLO WORLD",
>> so it is a poss ible replacement for dual words.
>>
>> You obviously can't tick a pattern, but it does make sense to POSTPONE
>> it, because all the parsing is done at compile time, which makes
>> compiler macro s a bit neater. ]] lions tigers bears "Oh My!" type [[
>>
>> With a well-behaved POSTPONE S" , on the other hand, the parsing would
>> take place when the macro was executed.
>>
>
>I've reviewed the recognizer RfD and my first reaction is that it's too
>complex and too prescriptive.
>
>Win32Forth and my derivative use the following method; from the doc (note
>that chain is a singly linked list of XTs to be executed in sequence).
>
><quote>
>"Each number conversion routine on the "number?-chain" chain is sent a
>string ( addr len) and can attempt to convert the number. If the
>conversion fails the routine performs a -1 THROW to indicate that it
>can't convert the string; the next routine is then tried until success or
>the chain is exhausted. If the chain is exhausted, then a -13 THROW
>(undefined) is executed.
>
>[Historical note] Earlier versions of Win32Forth used a similar chain
>technique, but carried a flag that was checked to see if the preceding
>routine had succesfully done the conversion. Performing a THROW on
>failure is much easier since it can be issued regardless of stack
>oontents as it automaticaly tidies up the stack before returning."
></quote>
>
>The downsides of this are:
>
>(a) The exception wordset is required
>
>(b) It returns only a cell, two cells or a float with an appropriate flag
>(but this may be all that's needed)
>
>(b) It's a list of recognizers rather than a stack (but that can be
>rectified quite simply)
>
>However, it is simple, it is easy to implement new recognizers, and it
>has proved enormously flexible. It also supports MOPS-like object:method
>syntaxes. Windows has many constants. A recognizer provides lookup of
>constants in a provided DLL. Words such as WM_MOVE are resolved
>"automagically" so that they can be used without having to declare them
>as CONSTANT.
>
>I think the proposed system also introduces a number of new problems.
>
>(a) There is no proposal for what might be meant by POSTPONE 42 and other
>tokens (and it doesn't discuss it, but also what is meant by ' 42).
>
>(b) It introduces three XTs to deal with the recognised token:
>XT-INTERPRET XT-COMPILE XT-POSTPONE. This requires STATE in the
>interpreter, and causes extra complexity in dual XT systems where
>compilation vs interpretation is based on a programmatically maintained
>state rather than a tested variable.
I started to promote denotations around 2000. They are recognizers but they
are deliberately limited. Only prefixes are allowed. A number is
something recognized by 0 1 2 3 4 5 6 7 8 or 9 . A string is recognized
by ". A dea ("name token") is recognized by '. A hex number is recognized
by $ or 0x.
A simple modification to FOUND finds prefixes: a word is recognized if
the prefix matches for its length. For the rest they are just ordinary
words. And a user can add them.
A recognizer is number like. It always generates a constant, the same
constant regardless of state, and it is only allowed to put the
constant on the stack during interpretation, or compile code to do
that during compilation.
The single addition PREFIX (like IMMEDIATE) allows to implement
numbers, strings and dea-expressions, and allow the user to add e.g.
$ prefixes in a portable way. It does away with far more code than
it adds.
I'm appalled of what has come from this idea to simplify the Forth
interpreter.
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 | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-05-06 02:30 -0700 |
| Subject | PREFIX |
| Message-ID | <92cff031-9ace-44fe-b821-c72bacf4dff3@googlegroups.com> |
| In reply to | #38849 |
On Tuesday, 5 May 2015 23:56:42 UTC+1, Albert van der Horst wrote:
> I started to promote denotations around 2000. They are recognizers but they
> are deliberately limited. Only prefixes are allowed. A number is
> something recognized by 0 1 2 3 4 5 6 7 8 or 9 . A string is recognized
> by ". A dea ("name token") is recognized by '. A hex number is recognized
> by $ or 0x.
> A simple modification to FOUND finds prefixes: a word is recognized if
> the prefix matches for its length. For the rest they are just ordinary
> words. And a user can add them.
That's important. It takes a lot of code to add a new recognizer. It's not
a simple substitute for STATE-smart words.
Is a prefix is an 'ordinary word,' where is it found in the search order?
Does it 'shadow' any previously defined word that happens to have the same
prefix, or are prefixes only searched after no match has been found
otherwise? In the latter case, are prefixes defined in a particular
wordlist found directly after that wordlist is searched, or after all
wordlists have been searched?
> A recognizer is number like. It always generates a constant, the same
> constant regardless of state, and it is only allowed to put the
> constant on the stack during interpretation, or compile code to do
> that during compilation.
>
In which case, providing FOUND can distinguish between prefixes and full
words, you have a pattern for POSTPONEing prefixes. You'd need a syntax
that factors out the literal-handling, for example:
'literal prefix: prefix interpretation ;
Then POSTPONE prefix/varies always does:
interpretation literal postpone literal
> The single addition PREFIX (like IMMEDIATE) allows to implement
> numbers, strings and dea-expressions, and allow the user to add e.g.
> $ prefixes in a portable way. It does away with far more code than
> it adds.
>
I particularly like 'name instead of ['] . I saves writing a lot of parsing
words when instead of foo name and [foo] name or its STATE-smart cousin,
you can have early-binding 'name foo and late-binding ' foo.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-06 12:23 +0000 |
| Subject | Re: PREFIX |
| Message-ID | <2015May6.142357@mips.complang.tuwien.ac.at> |
| In reply to | #38854 |
JennyB <jennybrien@googlemail.com> writes:
>I particularly like 'name instead of ['].
Getting the xt of a name is Certainly another candidate for
recognizers. The 'name pattern conflicts with the standard 'c' for
character literals, and (more frequently) with the non-standard 'c
(also for character literals). Solution: either use ' and ['] in the
conflicting cases, or use a different pattern. Any suggestions?
- 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-06 16:44 +0100 |
| Subject | Re: PREFIX |
| Message-ID | <midcrl$8mg$1@dont-email.me> |
| In reply to | #38856 |
on 06/05/2015 13:23:57, wrote: > JennyB <jennybrien@googlemail.com> writes: >>I particularly like 'name instead of [']. > > Getting the xt of a name is Certainly another candidate for > recognizers. The 'name pattern conflicts with the standard 'c' for > character literals, and (more frequently) with the non-standard 'c > (also for character literals). Solution: either use ' and ['] in the > conflicting cases, or use a different pattern. Any suggestions? Yes, let's not go there. There's no standard practice (one Forth?) and we're in danger of making the entire language prefix driven.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-06 16:03 +0000 |
| Subject | Re: PREFIX |
| Message-ID | <2015May6.180308@mips.complang.tuwien.ac.at> |
| In reply to | #38863 |
"Alex McDonald" <blog@rivadpm.com> writes:
>Yes, let's not go there. There's no standard practice (one Forth?) and
>we're in danger of making the entire language prefix driven.
I see replacing parsing words (even non-state-smart ones like ' ['])
with recognizers as beneficial rather than dangerous. It's just that
the patterns (whether prefixes or not) should avoid conflicts if
possible.
- 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-06 17:40 +0100 |
| Subject | Re: PREFIX |
| Message-ID | <midg2t$nt9$1@dont-email.me> |
| In reply to | #38864 |
on 06/05/2015 17:03:07, wrote:
> "Alex McDonald" <blog@rivadpm.com> writes:
>>Yes, let's not go there. There's no standard practice (one Forth?) and
>>we're in danger of making the entire language prefix driven.
>
> I see replacing parsing words (even non-state-smart ones like ' ['])
> with recognizers as beneficial rather than dangerous. It's just that
> the patterns (whether prefixes or not) should avoid conflicts if
> possible.
>
> - anton
A quick review of prefixes and graphic characters would be helpful, since
the patterns demand a bit more structure. We have chewed through
singletons and we're possibly chewing through doublets without much
regard that I can see to consistency. I was disappointed in {: :} (the
moustachioed locals) and I'm not sure about [: ;] either.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-06 19:44 +0000 |
| Subject | Re: PREFIX |
| Message-ID | <554a6f20$0$21227$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #38856 |
In article <2015May6.142357@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >JennyB <jennybrien@googlemail.com> writes: >>I particularly like 'name instead of [']. > >Getting the xt of a name is Certainly another candidate for >recognizers. The 'name pattern conflicts with the standard 'c' for >character literals, and (more frequently) with the non-standard 'c >(also for character literals). Solution: either use ' and ['] in the >conflicting cases, or use a different pattern. Any suggestions? Use &C for characters. 'c' for character constants is c-compatible for no good reason. > >- anton -- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-06 22:05 +0200 |
| Subject | Re: PREFIX |
| Message-ID | <mids3l$ckf$1@dont-email.me> |
| In reply to | #38869 |
Albert van der Horst wrote: > In article <2015May6.142357@mips.complang.tuwien.ac.at>, > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>JennyB <jennybrien@googlemail.com> writes: >>>I particularly like 'name instead of [']. >> >>Getting the xt of a name is Certainly another candidate for >>recognizers. The 'name pattern conflicts with the standard 'c' for >>character literals, and (more frequently) with the non-standard 'c >>(also for character literals). Solution: either use ' and ['] in the >>conflicting cases, or use a different pattern. Any suggestions? > > Use &C for characters. 'c' for character constants is c-compatible for > no good reason. &digits has been used for decimal in a number of systems. `foo is available. -- 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 | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-05-07 04:23 +0200 |
| Subject | Re: PREFIX |
| Message-ID | <mieiai$674$1@newsreader4.netcologne.de> |
| In reply to | #38870 |
Am 06.05.2015 um 22:05 schrieb Bernd Paysan: > Albert van der Horst wrote: > >> In article <2015May6.142357@mips.complang.tuwien.ac.at>, >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> JennyB <jennybrien@googlemail.com> writes: >>>> I particularly like 'name instead of [']. >>> >>> Getting the xt of a name is Certainly another candidate for >>> recognizers. The 'name pattern conflicts with the standard 'c' for >>> character literals, and (more frequently) with the non-standard 'c >>> (also for character literals). Solution: either use ' and ['] in the >>> conflicting cases, or use a different pattern. Any suggestions? >> >> Use &C for characters. 'c' for character constants is c-compatible for >> no good reason. > > &digits has been used for decimal in a number of systems. `foo is available. > What's wrong with char C / [char] C ? (Could also be extended with gforth's et. al. C-like escapes, e.g. "[char] \n", but clashes with established use since the 80s, namely that CHAR pushes the literal character code of the first character of the following word in the source (delimited by BL), which unfortunately has been standardized by ANS 94). Single character constants are commonly not used so frequently that a shortcut for them is urgently needed.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-08 11:48 +0000 |
| Subject | Re: PREFIX |
| Message-ID | <2015May8.134849@mips.complang.tuwien.ac.at> |
| In reply to | #38875 |
Bernd Linsel <bl1@gmx.com> writes:
>Am 06.05.2015 um 22:05 schrieb Bernd Paysan:
>What's wrong with char C / [char] C ?
Not very convenient.
>(Could also be extended with gforth's et. al. C-like escapes, e.g.
>"[char] \n", but clashes with established use since the 80s, namely that
>CHAR pushes the literal character code of the first character of the
>following word in the source (delimited by BL), which unfortunately has
>been standardized by ANS 94).
Yes. Also, \n may be more than one character, so better represent it
as string; you can do it with s\" \n" in Forth-2012.
For other control characters, their ASCII values are known, e.g., 10
for LF, 13 for CR. Gforth defines a number of constants like #lf and
#cr for these values, and using these makes the intent clearer (but
the program less portable).
- 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-08 12:04 +0000 |
| Subject | Re: PREFIX |
| Message-ID | <2015May8.140456@mips.complang.tuwien.ac.at> |
| In reply to | #38875 |
Bernd Linsel <bl1@gmx.com> writes:
>Single character constants are commonly not used so frequently that a
>shortcut for them is urgently needed.
From <http://www.forth200x.org/number-prefixes.html>:
|There was a claim that there are few uses of CHAR/[CHAR] so the
|'' syntax would save nothing. In response three corpi of code
|were searched for uses of [CHAR], CHAR, or '/''; the
|number of occurences were:
|
|[CHAR] CHAR 'x/'x'
| 245 141 443 Gforth sources
|1087 155 --- benchmarks collected by Anton Ertl
| 711 3982 6969 Marcel Hendrix' corpus <04153616153560@frunobulax.edu>
|
|So '' does not just have a large potential for use, it is
|already used a lot. For comparison, here are some frequencies of some
|CORE words that could be easily replaced with slightly longer
|sequences in the Gforth sources (829 occurences of character
|literals):
|
|298 1+
|223 1-
|132 2*
|345 2DROP
|401 2DUP
| 79 >
|107 NEGATE
|211 SPACE
- 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-08 11:55 +0000 |
| Subject | Re: PREFIX |
| Message-ID | <2015May8.135501@mips.complang.tuwien.ac.at> |
| In reply to | #38869 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>Use &C for characters. 'c' for character constants is c-compatible for
>no good reason.
That's water down the river. The number prefixes proposal was
accepted in 2007 and is now in Forth-2012. Get over it. It is based
on then-existing practice: From
<http://www.forth200x.org/number-prefixes.html>:
|Existing Practice
|
|Many Forth systems support various number prefixes already in the
|interpreter:
|
|#10 $10 %10 &10 0x10 0X10 10h 10H $f $F 'a 'a' input
| 10 16 2 - - - - - - 15 - 97 iforth 2.1.2541,
| CHForth 1.2.5, 1.3.9
| 10 16 2 10 - - - - 15 15 97 24871 bigFORTH rev. 2.1.6
| - 16 2 10 16 16 - - 15 15 - - PFE 0.33.34
| - 16 2 10 - - - - 15 15 97 24871 Gforth-0.6.2
| 10 16 2 10 16 16 - - 15 15 97 97 Gforth 0.6.9
| - 16 - - 16 16 - - 15 15 - 97 Win32Forth version 4.xxx
| 10 16 2 10 16 16 16 16 15 15 - 97 Win32Forth version 6.xx,
| Win32Forth-STC version 0.02.xx
| 10 16 2 8 - - - - 15 15 - - SwiftForth
| 10 16 2 - 16 16 16 16 15 15 - - VFX Forth 4.0.2 build 2428
| 10 16 2 8 - - - - 15 15 - - ntf/lxf
So &10 had a different meaning from your suggestion on many systems,
and 'a' had the later-standardized meaning on a number of systems.
- 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-06 14:20 +0100 |
| Subject | Re: PREFIX |
| Message-ID | <mid4ci$53m$1@dont-email.me> |
| In reply to | #38854 |
on 06/05/2015 10:30:25, JennyB wrote: > > I particularly like 'name instead of ['] . I saves writing a lot of > parsing words when instead of foo name and [foo] name or its > STATE-smart cousin, you can have early-binding 'name foo and > late-binding ' foo. > Unfortunately for this prefix, the Forth standards committee took the view that 'C' represented the ASCII numeric value of the single character enclosed. Define a word with a single character and trailing quote and this would be ambiguous at best. Another prefix is required.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-06 19:41 +0000 |
| Subject | Re: PREFIX |
| Message-ID | <554a6e4d$0$21227$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #38854 |
In article <92cff031-9ace-44fe-b821-c72bacf4dff3@googlegroups.com>,
JennyB <jennybrien@googlemail.com> wrote:
>On Tuesday, 5 May 2015 23:56:42 UTC+1, Albert van der Horst wrote:
>
>> I started to promote denotations around 2000. They are recognizers but they
>> are deliberately limited. Only prefixes are allowed. A number is
>> something recognized by 0 1 2 3 4 5 6 7 8 or 9 . A string is recognized
>> by ". A dea ("name token") is recognized by '. A hex number is recognized
>> by $ or 0x.
>> A simple modification to FOUND finds prefixes: a word is recognized if
>> the prefix matches for its length. For the rest they are just ordinary
>> words. And a user can add them.
>
>That's important. It takes a lot of code to add a new recognizer. It's not
>a simple substitute for STATE-smart words.
>
>Is a prefix is an 'ordinary word,' where is it found in the search order?
Yes
>Does it 'shadow' any previously defined word that happens to have the same
>prefix, or are prefixes only searched after no match has been found
>otherwise? In the latter case, are prefixes defined in a particular
Yes
>wordlist found directly after that wordlist is searched, or after all
>wordlists have been searched?
Normal prefixes (like recognizers for strings and numbers are in the
ONLY wordlist --yes only is a wordlist ) This is the same behaviour
as expected: numbers are recognized in the miminum search order.
apart from that they are normal words that are found in the same
way other words are found.
>
>
>> A recognizer is number like. It always generates a constant, the same
>> constant regardless of state, and it is only allowed to put the
>> constant on the stack during interpretation, or compile code to do
>> that during compilation.
>>
>
>In which case, providing FOUND can distinguish between prefixes and full
>words, you have a pattern for POSTPONEing prefixes. You'd need a syntax
>that factors out the literal-handling, for example:
>
>
> 'literal prefix: prefix interpretation ;
>
>Then POSTPONE prefix/varies always does:
>
> interpretation literal postpone literal
>
: 0x POSTPONE $ ; IMMEDIATE PREFIX
but easier
'$ ALIAS 0x
>> The single addition PREFIX (like IMMEDIATE) allows to implement
>> numbers, strings and dea-expressions, and allow the user to add e.g.
>> $ prefixes in a portable way. It does away with far more code than
>> it adds.
>>
>
>I particularly like 'name instead of ['] . I saves writing a lot of parsing
>words when instead of foo name and [foo] name or its STATE-smart cousin,
>you can have early-binding 'name foo and late-binding ' foo.
>
Yes. The idea must become that 'APE is a constant. The only constant
that defines APE. Especially: independant of compilation or interpretation
state.
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-06 12:29 +0000 |
| Message-ID | <2015May6.142937@mips.complang.tuwien.ac.at> |
| In reply to | #38848 |
"Alex McDonald" <blog@rivadpm.com> writes:
>I've reviewed the recognizer RfD and my first reaction is that it's too
>complex and too prescriptive.
>
>Win32Forth and my derivative use the following method; from the doc (note
>that chain is a singly linked list of XTs to be executed in sequence).
>
><quote>
>"Each number conversion routine on the "number?-chain" chain is sent a
>string ( addr len) and can attempt to convert the number. If the
>conversion fails the routine performs a -1 THROW to indicate that it
>can't convert the string; the next routine is then tried until success or
>the chain is exhausted. If the chain is exhausted, then a -13 THROW
>(undefined) is executed.
This only tells me what it does when it cannot convert the string.
What happens when it can?
>(b) It returns only a cell, two cells or a float with an appropriate flag
>(but this may be all that's needed)
That's what we had in Gforth, and it's a big ugly mess. It's better
to return the literals plus xts for processing them. The RfD takes
the approach of providing xts for interpretation, compilation, and
postponing; I suggested as alternative providing an xt for a delay
element (something like LITERAL), and one for the run-time (e.g., TYPE
for a ."string" recognizer). You can build interpretation,
compilation, and postpone actions from that.
>(a) There is no proposal for what might be meant by POSTPONE 42 and other
>tokens (and it doesn't discuss it, but also what is meant by ' 42).
"POSTPONE 42" is equivalent to "42 POSTPONE LITERAL". Last I looked
at the RfD, it enabled "POSTONE 42", but did not require it.
Concerning "' 42", if that worked, it would be equivalent to
:noname 42 ;
but the problem is that implementing that requires memory as long as
the xt exists, and we probably don't want to deal with that, so that's
not on the table.
>(b) It introduces three XTs to deal with the recognised token:
>XT-INTERPRET XT-COMPILE XT-POSTPONE. This requires STATE in the
>interpreter, and causes extra complexity in dual XT systems where
>compilation vs interpretation is based on a programmatically maintained
>state rather than a tested variable.
As long as we don't have an nt or xt for a recognized thing, we have
to treat recognizers separately from words in the text interpreter.
It may be simpler to treat them as words with nt/xt after all,
generating something like
: 42 42 ;
(outside of any wordlist, and not in the regular dictionary), using it
in the text interpreter, and then reclaiming the memory. If we
support "' 42", then that 42 word would not be reclaimed and would
live while the session lasts (probably not an option for small
embedded systems).
- 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-06 15:07 +0100 |
| Message-ID | <mid75f$fml$1@dont-email.me> |
| In reply to | #38857 |
on 06/05/2015 13:29:34, wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>I've reviewed the recognizer RfD and my first reaction is that it's too >>complex and too prescriptive. >> >>Win32Forth and my derivative use the following method; from the doc (note >>that chain is a singly linked list of XTs to be executed in sequence). >> >><quote> >>"Each number conversion routine on the "number?-chain" chain is sent a >>string ( addr len) and can attempt to convert the number. If the >>conversion fails the routine performs a -1 THROW to indicate that it >>can't convert the string; the next routine is then tried until success or >>the chain is exhausted. If the chain is exhausted, then a -13 THROW >>(undefined) is executed. > > This only tells me what it does when it cannot convert the string. > What happens when it can? If conversion succeeds, it returns to the caller having done ( c-addr u -- xd f ), a double number and a flag. The flag indicates whether the number is a single cell number (use D>S to get the number), a double (use asis) or a float (the double is zero and the float value is on the float stack). Forced base numbers (# $ %) are handled as prefixes that are stripped off, and then an attempt is made to convert the rest to a number or double using a temporary base. If that fails, the recognizer aborts and the next recognizer gets executed. The flag is used for a pair of CASEs; one in the interpreting code (D>S, nothing, 2DROP), and another in the compiling code (D>S LITERAL, 2LITERAL, 2DROP FLITERAL). There is no POSTPONE action. I have toyed with making it an XT. Currently I'm interested in simplicity and other parts of the compiler, so it's still CASE. Beyond numbers, I have experimental support for dotted objects object.method or .method where the object flag indicates xd is to be interpreted as an ( (object-addr | 0) method-xt ) pair. I've not yet used it to support "strings". > >>(b) It returns only a cell, two cells or a float with an appropriate flag >>(but this may be all that's needed) > > That's what we had in Gforth, and it's a big ugly mess. It's better > to return the literals plus xts for processing them. The RfD takes > the approach of providing xts for interpretation, compilation, and > postponing; I suggested as alternative providing an xt for a delay > element (something like LITERAL), and one for the run-time (e.g., TYPE > for a ."string" recognizer). You can build interpretation, > compilation, and postpone actions from that. See above; my description was perhaps a little too terse. > >>(a) There is no proposal for what might be meant by POSTPONE 42 and other >>tokens (and it doesn't discuss it, but also what is meant by ' 42). > > "POSTPONE 42" is equivalent to "42 POSTPONE LITERAL". Last I looked > at the RfD, it enabled "POSTONE 42", but did not require it. The supplied gforth implementation may have allowed it, but the proposal questioned its meaning along with recognizers for " and ` (POSTPONE "STRING" and POSTPONE `OS COMMMAND`). > > Concerning "' 42", if that worked, it would be equivalent to > >:noname 42 ; > > but the problem is that implementing that requires memory as long as > the xt exists, and we probably don't want to deal with that, so that's > not on the table. > >>(b) It introduces three XTs to deal with the recognised token: >>XT-INTERPRET XT-COMPILE XT-POSTPONE. This requires STATE in the >>interpreter, and causes extra complexity in dual XT systems where >>compilation vs interpretation is based on a programmatically maintained >>state rather than a tested variable. > > As long as we don't have an nt or xt for a recognized thing, we have > to treat recognizers separately from words in the text interpreter. I'm not fond of exceptions to the rule, and I would have liked recognizers to have none. OK, the proposal has fewer than we currently have, but at a price. > It may be simpler to treat them as words with nt/xt after all, > generating something like > >: 42 42 ; > > (outside of any wordlist, and not in the regular dictionary), using it > in the text interpreter, and then reclaiming the memory. If we support > "' 42", then that 42 word would not be reclaimed and would live while > the session lasts (probably not an option for small embedded systems). Which is where this would probably get shot down. So we can POSTPONE them but we can't tick them; I wouldn't even bother permitting POSTPONE since n POSTPONE LITERAL is hardly idiomatic or a burden to type when needed. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2015-05-09 03:02 -0700 |
| Message-ID | <ab70701e-b8a4-451f-a387-9bcff1847d18@googlegroups.com> |
| In reply to | #38848 |
Its a little late, sorry > > I think the proposed system also introduces a number of new problems. > > (a) There is no proposal for what might be meant by POSTPONE 42 and other > tokens (and it doesn't discuss it, but also what is meant by ' 42). since tick is only valid for dictionary lookups, the is no need to discuss tick for everything. Implementing tick using recognizers (the full stack) is ridiculous IMHO. It is suggested that postponing a literal should be seen as postponing the corresponding literal action. I have sympathy with that point of view. At the time the RFD was written, it was at least something to discuss. > (b) It introduces three XTs to deal with the recognised token: > XT-INTERPRET XT-COMPILE XT-POSTPONE. This requires STATE in the > interpreter, and causes extra complexity in dual XT systems where > compilation vs interpretation is based on a programmatically maintained > state rather than a tested variable. The three XT's are used for a whole class of recognized data. They are not related to whether the dictionary is dual-xt'ed or not. wrt to the state, I've written an interpreter that does not use STATE (quite similiar to the ones found in gforth and win32forth). Not everything I did fot part of the RFD since I want to ground it on plain CORE and what CORE has. Until now CORE has no dual-XT, has no postponing of numbers, has STATE, FIND and COMPILE,, has ambigous situations with state smart words etc pp. If CORE gets changed, recognizers can follow all changes easly. The chains of win32forth are a nice tool indeed. Thanks for inventing them. If I'm not mistaken they are a pretty combination of defers and lists. A little sidenote: I think that the recognizer stack could easily be written as a chain, but forth is stack oriented language, imagine a Forth-RFD that promotes lists instead of stacks. Blasphemy ;)
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-09 17:23 +0100 |
| Message-ID | <milc8p$is9$1@dont-email.me> |
| In reply to | #38907 |
on 09/05/2015 11:02:15, Matthias Trute wrote: Thanks for your reply. > The chains of win32forth are a nice tool indeed. Thanks for inventing > them. If I'm not mistaken they are a pretty combination of defers and > lists. A little sidenote: I think that the recognizer stack could > easily be written as a chain, but forth is stack oriented language, > imagine a Forth-RFD that promotes lists instead of stacks. Blasphemy > ;) > I can't claim to be the inventor of Win32Forth's chains. A list of deferred executions is very like an ITC style definition. A chain simply allows them to be not contiguous.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-11 08:07 +0100 |
| Subject | Recognizer RfD was Re: SET-COMPILER |
| Message-ID | <mipke4$7vn$1@dont-email.me> |
| In reply to | #38848 |
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.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web