Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #40881 > unrolled thread
| Started by | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| First post | 2015-07-28 21:22 +0100 |
| Last post | 2015-08-01 15:15 -0700 |
| Articles | 14 on this page of 114 — 15 participants |
Back to article view | Back to comp.lang.forth
RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-28 21:22 +0100
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 07:35 +0000
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 14:20 +0100
Re: RfD: Quotations Ron Aaron <rambamist@gmail.com> - 2015-07-29 13:44 +0300
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 13:42 +0100
Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 05:35 -0700
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 13:34 +0000
Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 07:35 -0700
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 15:05 +0000
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 16:19 +0100
Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-29 21:48 +0100
Re: RfD: Quotations mhx@iae.nl - 2015-07-29 11:13 -0700
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 13:04 +0000
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 15:07 +0100
Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 07:44 -0700
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 15:12 +0000
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 16:18 +0100
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-29 18:37 +0200
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 17:55 +0100
Re: RfD: Quotations "Elizabeth D. Rather" <erather@forth.com> - 2015-07-29 19:51 -0500
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 03:31 +0200
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-29 19:30 -0700
Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 21:19 -0700
Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 21:37 -0700
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 11:45 +0000
Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-30 08:07 -0700
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 10:54 +0000
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 12:48 +0100
Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-31 05:40 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 14:46 +0100
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 14:50 +0100
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 14:46 +0000
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-31 13:16 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 21:49 +0100
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-29 22:42 -0700
Re: RfD: Quotations "Elizabeth D. Rather" <erather@forth.com> - 2015-07-30 08:46 -0500
Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-29 21:40 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 10:01 +0100
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 12:00 +0200
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 11:10 +0100
Re: RfD: Quotations Coos Haak <chforth@hccnet.nl> - 2015-07-30 16:35 +0200
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 16:53 +0000
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-29 19:03 +0200
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 18:24 +0100
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 01:38 +0200
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 09:10 +0100
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 12:06 +0200
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 11:21 +0100
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 14:00 +0200
Re: RfD: Quotations franck.bensusan@gmail.com - 2015-07-30 06:59 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 10:53 +0100
Re: RfD: Quotations Paul Rubin <no.email@nospam.invalid> - 2015-07-29 10:35 -0700
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 01:45 +0200
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 03:17 +0200
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-29 19:21 -0700
Re: RfD: Quotations Paul Rubin <no.email@nospam.invalid> - 2015-07-29 23:04 -0700
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 12:38 +0200
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 12:09 +0100
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 13:26 +0200
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 09:47 +0100
Re: RfD: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-31 02:51 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 11:21 +0100
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 09:11 +0100
Re: RfD: Quotations Paul Rubin <no.email@nospam.invalid> - 2015-07-29 11:36 -0700
Re: RfD: Quotations Paul Rubin <no.email@nospam.invalid> - 2015-07-29 11:37 -0700
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 13:07 +0000
Re: RfD: Quotations Bernd Linsel <bl1@gmx.com> - 2015-07-30 16:25 +0200
Re: RfD: Quotations mhx@iae.nl - 2015-07-29 11:16 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 20:27 +0100
Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-29 21:57 +0100
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-29 22:48 +0100
Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-31 12:34 +0100
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 13:00 +0100
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 14:31 +0000
Re: RfD: Quotations mhx@iae.nl - 2015-07-31 11:32 -0700
Re: RfD: Quotations mhx@iae.nl - 2015-07-29 21:42 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 09:57 +0100
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-29 17:21 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 09:56 +0100
Re: RfD: Quotations franck.bensusan@gmail.com - 2015-07-30 04:15 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 12:30 +0100
Re: RfD: Quotations franck.bensusan@gmail.com - 2015-07-30 05:04 -0700
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-30 13:07 -0700
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-29 16:52 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 09:53 +0100
Re: RfD: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-30 21:45 +0200
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-30 13:25 -0700
Re: RfD: Quotations Julian Fondren <ayrnieu@gmail.com> - 2015-07-30 15:11 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 09:11 +0100
Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-31 12:04 +0100
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-30 22:51 +0100
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-07-30 22:38 -0700
Re: RfD: Quotations "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-31 02:10 -0400
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 09:01 +0100
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-08-01 14:59 -0700
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-08-01 23:36 +0100
Re: RfD: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-02 01:19 +0200
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-08-01 18:27 -0700
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-08-09 14:34 -0700
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 08:52 +0000
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 11:57 +0100
Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-31 21:42 +0100
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-07-31 22:25 +0100
Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-31 23:39 +0100
Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-01 10:59 +0100
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-01 14:18 +0000
Re: RfD: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-01 22:10 +0200
Re: RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-02 05:36 +0000
Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-03 16:40 +0100
Re: RfD: Quotations "Alex McDonald" <blog@rivadpm.com> - 2015-08-03 18:02 +0100
Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-03 20:22 +0100
Re: RfD: Quotations Coos Haak <chforth@hccnet.nl> - 2015-08-04 02:10 +0200
Re: RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-04 08:49 +0100
Re: RfD: Quotations hughaguilar96@gmail.com - 2015-08-01 15:15 -0700
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-31 11:57 +0100 |
| Message-ID | <mpfk8k$mdo$1@dont-email.me> |
| In reply to | #41002 |
on 31/07/2015 09:52:16, wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>[: ( -- c: nested-sys ) >>Compilation: suspends compiling to the current definition, starts a >>new nested definition, and compilation continues with this nested >>definition. It is an ambiguous condition if outer locals are visible >>and referred to in the nested definition. Locals may be defined in >>the nested definition. Inside the nested definition RECURSE applies >>to the nested definition. >> >>;] ( c: nested-sys -- ) >>Compilation: Ends the current nested definition, and resumes >>compilation to the previous current definition. This includes ending >>the action of DOES> if any. It appends the following run-time to the >>current definition: >> >>run-time: ( -- xt ) >>xt is the execution token to execute the nested definition. > > Interpretation semantics of [: and ;] are undefined if we follow the > practice of Forth-94 (for, e.g., ; or IF). I'll explcitly note. I've permitted interpreted [: ... ;] in my implementation as the equivalent of :NONAME ... ; There's a certain typographic elegance to it. > > Concerning RECURSE and DOES>, one could write the rest of the > definition in a way that the desired behaviour falls out from the > definitions of RECURSE and DOES>, so you don't need to mention it in > the normative part; you can mention it in the informative part to make > it more obvious. I think that the current formulation is mostly there. I'll do that in V2. > > The RfD is missing tests (including tests for RECURSE and DOES> inside > quotations). > I'm not up to speed on the test specification; but I'll do my best for Annex F. > - anton
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-07-31 21:42 +0100 |
| Message-ID | <mpgmfr$2dq$1@dont-email.me> |
| In reply to | #40881 |
On 28/07/2015 21:22, Alex McDonald wrote: > Stephen Pelc wrote this; see > > http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2012-07/msg00791.html > > I (Alex McDonald) have taken it and modified it as a proposed RfD, > and have removed the discussion of closures. http://www.forth200x.org/ > > RECURSE: Recursion is defined as recursing to the start of the > quotation, not the enclosing definition. > Yes, that's right, no need for MYSELF as discussed elsethread. > DOES>: As with a normal definition that closes the DOES> action with ; > (semi-colon), a DOES> in a quotation is closed at the terminating ;] > Use of RECURSE after DOES> is an ambiguous condition (which really ought to be resolved) so if : foo ... DOES> ... [: ... RECURSE ... ;] ... ; is permitted (as it should be), then the specification for RECURSE needs to be amended -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-31 22:25 +0100 |
| Message-ID | <mpgp1k$ba6$1@dont-email.me> |
| In reply to | #41027 |
on 31/07/2015 21:42:11, Gerry Jackson wrote: > On 28/07/2015 21:22, Alex McDonald wrote: >> Stephen Pelc wrote this; see >> >> http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2012-07/msg00791.html >> >> I (Alex McDonald) have taken it and modified it as a proposed RfD, >> and have removed the discussion of closures. http://www.forth200x.org/ >> >> RECURSE: Recursion is defined as recursing to the start of the >> quotation, not the enclosing definition. >> > Yes, that's right, no need for MYSELF as discussed elsethread. > >> DOES>: As with a normal definition that closes the DOES> action with ; >> (semi-colon), a DOES> in a quotation is closed at the terminating ;] >> > > Use of RECURSE after DOES> is an ambiguous condition (which really > ought to be resolved) so if >: foo ... DOES> ... [: ... RECURSE ... ;] ... ; > is permitted (as it should be), then the specification for RECURSE > needs to be amended > > : foo ... DOES> ... [: A RECURSE ... ;] ... ; RECURSE calls the definition at A, and DOES> encompasses "... [: A RECURSE ... ;] ...". As [: ;] is a nested definition, it requires no changes to the spec for DOES> and RECURSE. But if we have : foo ... [: ... DOES> A ;] ... ; then that is a problem. The RfD proposes that DOES> is closed by ;] which leaves a dangling [: Head scratching required.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-07-31 23:39 +0100 |
| Message-ID | <mpgtb7$tio$1@dont-email.me> |
| In reply to | #41029 |
On 31/07/2015 22:25, Alex McDonald wrote: > on 31/07/2015 21:42:11, Gerry Jackson wrote: >> On 28/07/2015 21:22, Alex McDonald wrote: >>> Stephen Pelc wrote this; see >>> >>> http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2012-07/msg00791.html >>> >>> I (Alex McDonald) have taken it and modified it as a proposed RfD, >>> and have removed the discussion of closures. http://www.forth200x.org/ >>> >>> RECURSE: Recursion is defined as recursing to the start of the >>> quotation, not the enclosing definition. >>> >> Yes, that's right, no need for MYSELF as discussed elsethread. >> >>> DOES>: As with a normal definition that closes the DOES> action with ; >>> (semi-colon), a DOES> in a quotation is closed at the terminating ;] >>> >> >> Use of RECURSE after DOES> is an ambiguous condition (which really >> ought to be resolved) so if >> : foo ... DOES> ... [: ... RECURSE ... ;] ... ; >> is permitted (as it should be), then the specification for RECURSE >> needs to be amended >> >> > > : foo ... DOES> ... [: A RECURSE ... ;] ... ; > > RECURSE calls the definition at A, and DOES> encompasses "... [: A > RECURSE ... ;] ...". As [: ;] is a nested definition, it requires no > changes to the spec for DOES> and RECURSE. Not to DOES>. But in the spec of RECURSE the last sentence is "An ambiguous condition exists if RECURSE appears in a definition after DOES>." In the definition of FOO the RECURSE appears in a definition (the quotation) after DOES>. So that sentence does need amendment as it is ambiguous. > > But if we have > > : foo ... [: ... DOES> A ;] ... ; > > then that is a problem. The RfD proposes that DOES> is closed by ;] which > leaves a dangling [: > Not to mention : foo ... [: ... DOES> A DOES> B DOES> C ;] ... ; > Head scratching required. > Why not do as it says at the start of the RfD i.e. : foo ... [: ... DOES> A ;] ... ; is equivalent to :noname ... DOES> A ; constant #temp# : foo ... #temp# ... ; -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-08-01 10:59 +0100 |
| Message-ID | <mpi57d$98t$1@dont-email.me> |
| In reply to | #41031 |
On 31/07/2015 23:39, Gerry Jackson wrote: > On 31/07/2015 22:25, Alex McDonald wrote: >> >> But if we have >> >> : foo ... [: ... DOES> A ;] ... ; >> >> then that is a problem. The RfD proposes that DOES> is closed by ;] which >> leaves a dangling [: >> > > Not to mention > : foo ... [: ... DOES> A DOES> B DOES> C ;] ... ; > >> Head scratching required. >> > > Why not do as it says at the start of the RfD i.e. > > : foo ... [: ... DOES> A ;] ... ; > is equivalent to > :noname ... DOES> A ; constant #temp# > : foo ... #temp# ... ; > If : foo ... [: ... DOES> A ;] ... ; has to behave exactly like : foo-does DOES> A ; : foo ... [: ... foo-does ;] ... ; then surely my suggestion is forced on you. I just tried it on my system and that's how it behaved. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-08-01 14:18 +0000 |
| Message-ID | <2015Aug1.161848@mips.complang.tuwien.ac.at> |
| In reply to | #41027 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 28/07/2015 21:22, Alex McDonald wrote:
>> Stephen Pelc wrote this; see
>>
>> http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2012-07/msg00791.html
>>
>> I (Alex McDonald) have taken it and modified it as a proposed RfD,
>> and have removed the discussion of closures. http://www.forth200x.org/
>>
>> RECURSE: Recursion is defined as recursing to the start of the
>> quotation, not the enclosing definition.
>>
>Yes, that's right, no need for MYSELF as discussed elsethread.
>
>> DOES>: As with a normal definition that closes the DOES> action with ;
>> (semi-colon), a DOES> in a quotation is closed at the terminating ;]
>>
>
>Use of RECURSE after DOES> is an ambiguous condition (which really ought
>to be resolved)
Yes. My vote would be for making it call the place right after the
DOES>. Should not be hard to implement on any Forth system. Rarely
useful, but still more useful than making it call the start of the
enclosing colon definition, which would be the other alternative.
> so if
>: foo ... DOES> ... [: ... RECURSE ... ;] ... ;
>is permitted (as it should be), then the specification for RECURSE needs
>to be amended
Well, one could argue that there is a definition after DOES>, and the
enclosing definition (with DOES>) therefore does not play a role, but
it would be nice if this was specified so clearly that we would not
need arguable arguments.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-08-01 22:10 +0200 |
| Message-ID | <mpj90s$5hp$1@dont-email.me> |
| In reply to | #41040 |
Anton Ertl wrote: >>Use of RECURSE after DOES> is an ambiguous condition (which really ought >>to be resolved) > > Yes. My vote would be for making it call the place right after the > DOES>. Should not be hard to implement on any Forth system. Current Gforth does so (after we changed DOES> internals considerably to get rid of the special-casing in how DOES> stuff is called). Test example: : test create , does> @ dup if '.' emit recurse then ; here 0 , here swap , here swap , here swap , test foo foo .... ok . 0 ok -- 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-08-02 05:36 +0000 |
| Message-ID | <2015Aug2.073624@mips.complang.tuwien.ac.at> |
| In reply to | #41046 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>>>Use of RECURSE after DOES> is an ambiguous condition (which really ought
>>>to be resolved)
>>
>> Yes. My vote would be for making it call the place right after the
>> DOES>. Should not be hard to implement on any Forth system.
>
>Current Gforth does so (after we changed DOES> internals considerably to get
>rid of the special-casing in how DOES> stuff is called). Test example:
>
>: test create , does> @ dup if '.' emit recurse then ;
>here 0 ,
>here swap ,
>here swap ,
>here swap ,
>test foo
>foo .... ok
>. 0 ok
And that's pretty much the only use case of this kind of recursion:
When the CREATEd word is the head of a recursive data structure, and
you want to walk it right in the DOES> part (instead of factoring the
walk out). Probably not really useful, but calling the named word is
also only useful for parlor tricks.
- 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-08-03 16:40 +0100 |
| Message-ID | <mpo1tm$i6m$1@dont-email.me> |
| In reply to | #41059 |
On 02/08/2015 06:36, Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> Anton Ertl wrote: >> >>>> Use of RECURSE after DOES> is an ambiguous condition (which really ought >>>> to be resolved) >>> >>> Yes. My vote would be for making it call the place right after the >>> DOES>. Should not be hard to implement on any Forth system. I agree. Given that factoring out the DOES> part of a CREATE ... DOES> definition should result in identical behaviour, recursing to the code after DOES> is surely the correct thing to do. >> >> Current Gforth does so (after we changed DOES> internals considerably to get >> rid of the special-casing in how DOES> stuff is called). Test example: >> >> : test create , does> @ dup if '.' emit recurse then ; >> here 0 , >> here swap , >> here swap , >> here swap , >> test foo >> foo .... ok >> . 0 ok > My system gives that result. > And that's pretty much the only use case of this kind of recursion: > When the CREATEd word is the head of a recursive data structure, and > you want to walk it right in the DOES> part (instead of factoring the > walk out). Probably not really useful, but calling the named word is > also only useful for parlor tricks. > A quick survey of a few systems indicates that for the above definition (with [CHAR] . replacing '.' VFX Forth issues an error message ERR: Invalid use of RECURSE. SwiftForth, Win32 Forth and iForth recurse to TEST If we factor out the DOES> part e.g. : bar does> @ dup if [char] . emit recurse then ; : test create , bar ; here 0 , here swap , here swap , here swap , test foo foo VFX Forth reports the same error when compiling BAR SwiftForth, Win32 Forth and iForth recurse to BAR (not the code after DOES>) emitting 1 '.' With Win32Forth re-executing FOO displays an increasing number of '.'s after the ok prompt. There's probably little chance of that ambiguous condition being removed -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-08-03 18:02 +0100 |
| Message-ID | <mpo6ou$68p$1@dont-email.me> |
| In reply to | #41075 |
on 03/08/2015 16:40:04, Gerry Jackson wrote: > On 02/08/2015 06:36, Anton Ertl wrote: >> Bernd Paysan <bernd.paysan@gmx.de> writes: >>> Anton Ertl wrote: >>> >>>>> Use of RECURSE after DOES> is an ambiguous condition (which really ought >>>>> to be resolved) >>>> >>>> Yes. My vote would be for making it call the place right after the >>>> DOES>. Should not be hard to implement on any Forth system. > > I agree. Given that factoring out the DOES> part of a CREATE ... DOES> > definition should result in identical behaviour, recursing to the code > after DOES> is surely the correct thing to do. > >>> >>> Current Gforth does so (after we changed DOES> internals considerably to get >>> rid of the special-casing in how DOES> stuff is called). Test example: >>> >>> : test create , does> @ dup if '.' emit recurse then ; >>> here 0 , >>> here swap , >>> here swap , >>> here swap , >>> test foo >>> foo .... ok >>> . 0 ok >> > > My system gives that result. What does you system give for this? : valn [: create , does> @ ;] swap 1+ swap ; 10 valn execute foo foo . > >> And that's pretty much the only use case of this kind of recursion: >> When the CREATEd word is the head of a recursive data structure, and >> you want to walk it right in the DOES> part (instead of factoring the >> walk out). Probably not really useful, but calling the named word is >> also only useful for parlor tricks. >> > > A quick survey of a few systems indicates that for the above > definition (with [CHAR] . replacing '.' > > VFX Forth issues an error message ERR: Invalid use of RECURSE. > > SwiftForth, Win32 Forth and iForth recurse to TEST > > If we factor out the DOES> part e.g. > >: bar does> @ dup if [char] . emit recurse then ; >: test create , bar ; > here 0 , > here swap , > here swap , > here swap , > test foo > foo > > VFX Forth reports the same error when compiling BAR > SwiftForth, Win32 Forth and iForth recurse to BAR (not the code after > DOES>) emitting 1 '.' > With Win32Forth re-executing FOO displays an increasing number of '.'s > after the ok prompt. > > There's probably little chance of that ambiguous condition being > removed > I believe there's a simple fix for Win32Forth; the variable LAST needs correctly set while compiling DOES> so that RECURSE COMPILE,s correctly. It should not affect any other code.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-08-03 20:22 +0100 |
| Message-ID | <mpoeuq$bje$1@dont-email.me> |
| In reply to | #41076 |
On 03/08/2015 18:02, Alex McDonald wrote: > What does you system give for this? > > : valn [: create , does> @ ;] swap 1+ swap ; > 10 valn execute foo > foo . : valn [: create , does> @ ;] swap 1+ swap ; ok 10 valn execute foo ok foo . 11 ok -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-08-04 02:10 +0200 |
| Message-ID | <1vvv3fr5a4grs$.3hw46ag7iv1x.dlg@40tude.net> |
| In reply to | #41075 |
Op Mon, 03 Aug 2015 16:40:05 +0100 schreef Gerry Jackson: > On 02/08/2015 06:36, Anton Ertl wrote: >> Bernd Paysan <bernd.paysan@gmx.de> writes: >>> Anton Ertl wrote: >>> >>>>> Use of RECURSE after DOES> is an ambiguous condition (which really ought >>>>> to be resolved) >>>> >>>> Yes. My vote would be for making it call the place right after the >>>> DOES>. Should not be hard to implement on any Forth system. > > I agree. Given that factoring out the DOES> part of a CREATE ... DOES> > definition should result in identical behaviour, recursing to the code > after DOES> is surely the correct thing to do. > >>> >>> Current Gforth does so (after we changed DOES> internals considerably to get >>> rid of the special-casing in how DOES> stuff is called). Test example: >>> >>> : test create , does> @ dup if '.' emit recurse then ; >>> here 0 , >>> here swap , >>> here swap , >>> here swap , >>> test foo >>> foo .... ok >>> . 0 ok >> > > My system gives that result. > >> And that's pretty much the only use case of this kind of recursion: >> When the CREATEd word is the head of a recursive data structure, and >> you want to walk it right in the DOES> part (instead of factoring the >> walk out). Probably not really useful, but calling the named word is >> also only useful for parlor tricks. >> > > A quick survey of a few systems indicates that for the above definition > (with [CHAR] . replacing '.' > > VFX Forth issues an error message ERR: Invalid use of RECURSE. > > SwiftForth, Win32 Forth and iForth recurse to TEST > > If we factor out the DOES> part e.g. > >: bar does> @ dup if [char] . emit recurse then ; >: test create , bar ; > here 0 , > here swap , > here swap , > here swap , > test foo > foo > > VFX Forth reports the same error when compiling BAR > SwiftForth, Win32 Forth and iForth recurse to BAR (not the code after > DOES>) emitting 1 '.' > With Win32Forth re-executing FOO displays an increasing number of '.'s > after the ok prompt. > > There's probably little chance of that ambiguous condition being removed If the conversion to this 'smart' RECURSE is not yet done, this should give the same result, assuming RECURSE already knows about quotations. : test create , does> [: @ dup if '.' emit recurse then ;] execute ; groet Coos
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-08-04 08:49 +0100 |
| Message-ID | <mppqn5$dg8$1@dont-email.me> |
| In reply to | #41084 |
On 04/08/2015 01:10, Coos Haak wrote: >> If we factor out the DOES> part e.g. >> > >> >: bar does> @ dup if [char] . emit recurse then ; >> >: test create , bar ; >> >here 0 , >> >here swap , >> >here swap , >> >here swap , >> >test foo >> >foo >> > >> >VFX Forth reports the same error when compiling BAR >> >SwiftForth, Win32 Forth and iForth recurse to BAR (not the code after >> >DOES>) emitting 1 '.' >> >With Win32Forth re-executing FOO displays an increasing number of '.'s >> >after the ok prompt. >> > >> >There's probably little chance of that ambiguous condition being removed > If the conversion to this 'smart' RECURSE is not yet done, > this should give the same result, assuming RECURSE already > knows about quotations. > > : test create , does> [: @ dup if '.' emit recurse then ;] execute ; It does. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-01 15:15 -0700 |
| Message-ID | <3a50d68f-df28-4b27-a9a5-61efeb4a0b67@googlegroups.com> |
| In reply to | #40881 |
On Tuesday, July 28, 2015 at 1:22:17 PM UTC-7, Alex McDonald wrote:
> The following notes on quotations and closures incorporate material
> from several people, including ...Elizabeth Rather.
> ...
> Locals: A quotation may not be able to access the locals of the outer
> word because it has no knowledge of when it might be executed and
> hence whether outer locals are still alive. It does permit defining and
> accessing its own locals.
>
> : foo ... [: {: a b :} a b + ;] ... ; \ unambiguous
> : bar {: a b :} ... [: a b + ;] ... ; \ ambiguous
Here is a fun Elizabeth Rather quote:
"I'd actually be grateful for a simple English explanation of what 'quotations' are, as I've heard the term used in various ways in this context [general-purpose data-structures], and have never seen an explanation that isn't along the lines of, 'Well, this is how {whatever} does it...'"
I think the reason why Alex McDonald listed Elizabeth Rather as his source, was to tell everybody that he already had permission from Forth Inc. for the Payson-faked quotations to become standard. Forth-200x is all about brown-nosing --- anybody can be a leader --- but only if they get permission first and they do exactly what they are told to do.
For the most part, Leon Wagner allows anything to become standard so long as it can be trivially implemented in SwiftForth without any change to SwiftForth, and without conflicting with existing SwiftForth legacy code. The Payson-faked quotations are totally useless, but they do fit Leon Wagner's requirements for triviality, so they are a slam-dunk.
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.forth
csiph-web