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 | 20 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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-07-30 16:35 +0200 |
| Message-ID | <qscrz21zwh2w$.1p8mfst19tbng.dlg@40tude.net> |
| In reply to | #40934 |
Op Thu, 30 Jul 2015 03:31:04 +0200 schreef Bernd Linsel:
> On 30/07/2015 02:51, Elizabeth D. Rather wrote:
>> It's appropriate for a standard to avoid standardizing any name in a way
>> that conflicts with widespread usage, regardless of whether the usage is
>> of a commercial on non-comercial system.
>
> Widespread usage and common practice was writing { ... } for locals.
>
> Forth, Inc.'s proprietary syntax for multi-line-comments wasn't even"
> widespread" at all!
F-PC was one of them:
: } ( --- ) \ Skip all text between } and { .
I don't think that F-PC as follow-up to F83 (L&P) was an obscure
implementation in its time, early 1990s.
groet Coois
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-29 16:53 +0000 |
| Message-ID | <2015Jul29.185351@mips.complang.tuwien.ac.at> |
| In reply to | #40907 |
Bernd Linsel <bl1@gmx.com> writes:
>Before F200x, common practice was using {...} for locals, only Forth,
>Inc. deviated and used the braces for multi-line-comments. I still
>wonder how this abomination could make it into the 2012 "standard",
>aside from the theory that commercial interests actually could influence
>the committee's work...
Well, you just explained it. There is conflicting practice. So we
followed the successful practice of introducing new names that have no
conflicts. I guess that a conflict with a popular non-commercial
Forth system would have had the same effect. After all, specifying a
conflicting name means that the conflicting system will not implement
these words, and if that happens for a popular system, we would fail
to achieve true standardization (which is not just having a
specification, but being able to write programs that run on a large
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 | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-29 19:03 +0200 |
| Message-ID | <mpb11c$qj4$1@newsreader4.netcologne.de> |
| In reply to | #40903 |
On 29/07/2015 17:18, Alex McDonald wrote:> on 29/07/2015 15:44:03,
Raimond Dragomir wrote:
>>>
>>> That now means we have to standardise an XT that "must execute
within the
>>> scope of the caller and can't be saved for later". This is not how
>>> :NONAME and : work, and quotations are designed "to have the same
>>> privileges as words defined with : and :NONAME". Users and implementers
>>> are being advised here that supporting this type of XT is non-standard.
>>> But as is usual with Forth, they can do what they wish outside of the
>>> standard.
>>>
>> Why do you want to make it an umbiguous condition? Just say that the
>> outer locals are not visible and that's it. At least people will know
>> what the rule is. Compilers will throw an error that the "x" is an
>> unknown word and everybody is happy.
>
> Someone may wish to implement, as Hugh and I have done, a system that
> allow reference to outer locals as long as the quotation isn't executed
> out of the execution scope of its parent. Why would you want to disallow
> that? The way this proposal is worded allows systems to offer more than
> the standard or the standard alone.
Why not make a compromise?
Outer words' locals are visible, and when referenced within the
quotation, they are copied into a dedicated "static variable area" (term
borrowed from C, and "static" shall be understood as in C) belonging to
the quotation (and living as long as the quotation itself).
Subsequent changes to the variable made by the quotation don't affect
the parent's local, but the quotation's own 'static' copy.
The effect is that you can pass data into a quotation at definition time
that is valid as long as the code without having to deal with eventual
'quot-sys's on the stack.
The implementation shouldn't be any more complex than the current
GForth's capability of having nested locals being accessible from inner
levels.
THe simplest method would of course be to copy the parent's whole locals
frame just before the quotation's compiled thread, and map variable
references from within the quotation to that position.
Example:
: make-add-x+y { x y -- xt }
[: { x y } x dup y + to x + ;] ;
1 5 make-add-x constant foo
> 3 foo execute 4 ok
> 3 foo execute 9 ok
--
Regards,
Bernd Linsel
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-29 18:24 +0100 |
| Message-ID | <mpb25r$fg4$1@dont-email.me> |
| In reply to | #40909 |
on 29/07/2015 18:03:44, Bernd Linsel wrote: > On 29/07/2015 17:18, Alex McDonald wrote:> on 29/07/2015 15:44:03, > Raimond Dragomir wrote: > >>> > >>> That now means we have to standardise an XT that "must execute > within the > >>> scope of the caller and can't be saved for later". This is not how > >>> :NONAME and : work, and quotations are designed "to have the same > >>> privileges as words defined with : and :NONAME". Users and > implementers >>> are being advised here that supporting this type of > XT is non-standard. >>> But as is usual with Forth, they can do what > they wish outside of the >>> standard. > >>> > >> Why do you want to make it an umbiguous condition? Just say that > the >> outer locals are not visible and that's it. At least people > will know >> what the rule is. Compilers will throw an error that the > "x" is an >> unknown word and everybody is happy. > > > > Someone may wish to implement, as Hugh and I have done, a system > that > allow reference to outer locals as long as the quotation isn't > executed > out of the execution scope of its parent. Why would you > want to disallow > that? The way this proposal is worded allows > systems to offer more than > the standard or the standard alone. > > Why not make a compromise? > > Outer words' locals are visible, and when referenced within the > quotation, they are copied into a dedicated "static variable area" > (term borrowed from C, and "static" shall be understood as in C) > belonging to the quotation (and living as long as the quotation > itself). The quotation is code; it lives forever. The static copy would be a scoped global. We have those already as names of variables defined in wordlists. > > Subsequent changes to the variable made by the quotation don't affect > the parent's local, but the quotation's own 'static' copy. That is the same as using global variables. Locals fix a well understood problem when using globals; re-entrancy and recursion to name but two.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-30 01:38 +0200 |
| Message-ID | <mpbo6b$bkf$1@newsreader4.netcologne.de> |
| In reply to | #40911 |
Am 29.07.2015 um 19:24 schrieb Alex McDonald: > on 29/07/2015 18:03:44, Bernd Linsel wrote: >> On 29/07/2015 17:18, Alex McDonald wrote:> on 29/07/2015 15:44:03, >> Raimond Dragomir wrote: >>>>> >>>>> That now means we have to standardise an XT that "must execute >> within the >>>>> scope of the caller and can't be saved for later". This is not how >>>>> :NONAME and : work, and quotations are designed "to have the same >>>>> privileges as words defined with : and :NONAME". Users and >> implementers >>> are being advised here that supporting this type of >> XT is non-standard. >>> But as is usual with Forth, they can do what >> they wish outside of the >>> standard. >>>>> >>>> Why do you want to make it an umbiguous condition? Just say that >> the >> outer locals are not visible and that's it. At least people >> will know >> what the rule is. Compilers will throw an error that the >> "x" is an >> unknown word and everybody is happy. >>> >>> Someone may wish to implement, as Hugh and I have done, a system >> that > allow reference to outer locals as long as the quotation isn't >> executed > out of the execution scope of its parent. Why would you >> want to disallow > that? The way this proposal is worded allows >> systems to offer more than > the standard or the standard alone. >> >> Why not make a compromise? >> >> Outer words' locals are visible, and when referenced within the >> quotation, they are copied into a dedicated "static variable area" >> (term borrowed from C, and "static" shall be understood as in C) >> belonging to the quotation (and living as long as the quotation >> itself). > > The quotation is code; it lives forever. The static copy would be a > scoped global. We have those already as names of variables defined in > wordlists. > >> >> Subsequent changes to the variable made by the quotation don't affect >> the parent's local, but the quotation's own 'static' copy. > > That is the same as using global variables. Locals fix a well understood > problem when using globals; re-entrancy and recursion to name but two. > That's admittedly true. In fact, they are global variables, and not re-entrant. Just syntactic sugar, as quotations are as a whole.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-30 09:10 +0100 |
| Message-ID | <mpcm2n$gnf$1@dont-email.me> |
| In reply to | #40925 |
on 30/07/2015 00:38:52, Bernd Linsel wrote: > Am 29.07.2015 um 19:24 schrieb Alex McDonald: >> >> That is the same as using global variables. Locals fix a well understood >> problem when using globals; re-entrancy and recursion to name but two. >> > > That's admittedly true. > In fact, they are global variables, and not re-entrant. Just syntactic > sugar, as quotations are as a whole. > You are proposing "global locals"?
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-30 12:06 +0200 |
| Message-ID | <mpcsv0$1hu$1@newsreader4.netcologne.de> |
| In reply to | #40946 |
Am 30.07.2015 um 10:10 schrieb Alex McDonald: > on 30/07/2015 00:38:52, Bernd Linsel wrote: >> Am 29.07.2015 um 19:24 schrieb Alex McDonald: > >>> >>> That is the same as using global variables. Locals fix a well understood >>> problem when using globals; re-entrancy and recursion to name but two. >>> >> >> That's admittedly true. >> In fact, they are global variables, and not re-entrant. Just syntactic >> sugar, as quotations are as a whole. >> > > You are proposing "global locals"? [x] You do not understand what I've described lenghtily. For every child in the call chain of a function, the local variables of the functions above (invoked before) seem to be global, as all children are accessing the same instance of that parent's/grandparent's/grand-... local variable. (Presuming dynamic scoping or nested definitions, like quotations)
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-30 11:21 +0100 |
| Message-ID | <mpcto9$bkg$1@dont-email.me> |
| In reply to | #40953 |
on 30/07/2015 11:06:25, Bernd Linsel wrote: > Am 30.07.2015 um 10:10 schrieb Alex McDonald: >> on 30/07/2015 00:38:52, Bernd Linsel wrote: >>> Am 29.07.2015 um 19:24 schrieb Alex McDonald: >> >>>> >>>> That is the same as using global variables. Locals fix a well understood >>>> problem when using globals; re-entrancy and recursion to name but two. >>>> >>> >>> That's admittedly true. >>> In fact, they are global variables, and not re-entrant. Just syntactic >>> sugar, as quotations are as a whole. >>> >> >> You are proposing "global locals"? > > > [x] You do not understand what I've described lenghtily. You got me. > > For every child in the call chain of a function, the local variables > of the functions above (invoked before) seem to be global, as all > children are accessing the same instance of that > parent's/grandparent's/grand-... local variable. > (Presuming dynamic scoping or nested definitions, like quotations) > > Dynamic scoping? That's not what you said. <quote> To approximate this behaviour, I suggest making accessed parent's locals static copies, or if you prefer, globals with special scope, just visible withing the quotation. </quote> and <quote> - parent's locals become 'static locals' when accessed within the quotation, mainly because of the effect of being able to store state (what admittedly may equally be achieved by using globals). </quote> Can you provide an example or two? On reading agan the post that these come from, I would also like an example of the issues you raise there, since I don't understand it either. <quote> The suggested RfD lacks the possibility for a simple way to pass values into the quotation at creation time (if the parameter stack is used as compilation stack, as ISO 94 and 200x suggest / allow), and the possibility to create aggregating quotations without a global variable accessible and visible to the "outer world". </quote> Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-30 14:00 +0200 |
| Message-ID | <mpd3la$6fk$1@newsreader4.netcologne.de> |
| In reply to | #40955 |
Am 30.07.2015 um 12:21 schrieb Alex McDonald:> on 30/07/2015 11:06:25,
Bernd Linsel wrote:
>> For every child in the call chain of a function, the local variables
>> of the functions above (invoked before) seem to be global, as all
>> children are accessing the same instance of that
>> parent's/grandparent's/grand-... local variable.
>> (Presuming dynamic scoping or nested definitions, like quotations)
>
> Dynamic scoping? That's not what you said.
Normally, scope (symbol visibilty) and extent (variable lifetime) in
Forth don't impose great problems, because nested definitions are not
allowed. However, when quotations that can be invoked outside the
creating word's runtime, it must be considered.
Shortly outlined and drastically reduced:
- Static scope: Nested definitions have access to outer definitions' locals.
- Dynamic scope: Nested *invocations* have access to earlier invoked
functions' locals.
- Global Forth variables have infinite extent (their value stays valid
as long as the dictionary is not cleared).
- Local Forth variables have static extent (their value is valid from
their definition/initialization until the containing word returns).
Quotations in Forth suddenly introduce nested definitions.
And if a quotation (q) has somehow access to the locals of the word it
was defined in (p, for parent), you have a mix of static and dynamic
scoping:
Static, because q's definition is nested in p's definition. As long as
you call q from within p, q can just access p's locals stack frame.
But if p returns q (respectively an xt for q) and exits, then q is
invoked later, p's locals stack frame ceased to exist. Any reference to
p's locals is invalid. But in q's "history" there has been the
invocation of p that created q. So now you have a kind of dynamic
scoping -- iff there is a mechanism that keeps the locals of p alive in
order to let q access them even after p returned.
This is not straightforward dynamic scoping after the schoolbook, but in
the same category.
> <quote>
> To approximate this behaviour, I suggest making accessed parent's locals
> static copies, or if you prefer, globals with special scope, just
> visible withing the quotation.
> </quote>
>
> and
>
> <quote>
> - parent's locals become 'static locals' when accessed within the
> quotation, mainly because of the effect of being able to store state
> (what admittedly may equally be achieved by using globals).
> </quote>
>
> Can you provide an example or two?
>
> On reading agan the post that these come from, I would also like an
> example of the issues you raise there, since I don't understand it
> either.
>
> <quote>
> The suggested RfD lacks the possibility for a simple way to pass values
> into the quotation at creation time (if the parameter stack is used as
> compilation stack, as ISO 94 and 200x suggest / allow), and the
> possibility to create aggregating quotations without a global variable
> accessible and visible to the "outer world".
> </quote>
>
> Thanks.
>
#1 passing values into a quotation
The best example is currying, e.g. reducing the arity of a function by
providing some (but not all) arguments to it, creating another
"specialized" function:
: f ( x y -- z )
dup * \ x y²
swap * \ y² x²
+
;
: curry { xt1 x -- xt2 }
[: x swap xt1 execute :] ( y -- z )
;
# 3 4 f . \ => 25 ok
# defer f3 \ => ok
# ' f 3 curry is f3 \ => ok ( f3 is the same as 3 ? f )
4 f3 . \ => 25 ok ( 4 f3 is the same as 3 4 f )
#2 storing state within a quotation
: begin-sum ( -- xt )
0 { sum } \ create local state variable for the sum
[: sum + dup to sum :] ( n -- sum )
;
# defer sum-add \ => ok
# begin-sum is sum-add \ => ok
# 3 sum-add . \ => 3 ok
# 2 sum-add . \ => 5 ok
# 1 sum-add drop \ => ok ( sum=6 )
# 4 sum-add drop \ => ok ( sum=10 )
# 3 sum-add . \ => 13 ok
and...
# begin-sum is sum-add \ => ok ( new instance, sum=0 )
# : test
# 10 0 do
# i sum-add drop
# loop
# 0 sum-add ; \ => ok
# test . \ => 45 ok
#3 passing value into the quotation's definition
: begin-sum-with-start { sum -- xt } \ initial value not null but
provided by caller
[: sum + dup to sum :] ( n -- sum )
;
# 8 begin-sum-with-start is sum-add
# 1 sum-add drop
# 2 sum-add drop
# 3 sum-add . \ => 14 ok
Got the point?
--
Best regards,
Bernd
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-07-30 06:59 -0700 |
| Message-ID | <88258658-91ea-436a-a272-22968467e420@googlegroups.com> |
| In reply to | #40962 |
Le jeudi 30 juillet 2015 14:00:43 UTC+2, Bernd Linsel a écrit :
>
> #1 passing values into a quotation
>
> The best example is currying, e.g. reducing the arity of a function by
> providing some (but not all) arguments to it, creating another
> "specialized" function:
>
> : f ( x y -- z )
> dup * \ x y²
> swap * \ y² x²
> +
> ;
>
> : curry { xt1 x -- xt2 }
> [: x swap xt1 execute :] ( y -- z )
> ;
>
>
> # 3 4 f . \ => 25 ok
> # defer f3 \ => ok
> # ' f 3 curry is f3 \ => ok ( f3 is the same as 3 ? f )
> 4 f3 . \ => 25 ok ( 4 f3 is the same as 3 4 f )
>
>
Well, this works in Oforth, but memory is handled by a GC so this is
out of the scope of the quotations proposed into this RFD.
In fact, Oforth implements Smalltalk-like blocks, with the same syntax,
and values are copied into the block, but not statically.
: f // ( x y -- z )
{ sq swap sq + }
: curry(m, x) // ( x m -- aBlock )
{ #[ x m perform ] }
: g
3 4 f .
25
ok
3 #f curry Constant new: f3
ok
4 f3 perform .
25
ok
Regards,
Franck
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-31 10:53 +0100 |
| Message-ID | <mpfggi$9m4$1@dont-email.me> |
| In reply to | #40962 |
on 30/07/2015 13:00:46, Bernd Linsel wrote:
> Am 30.07.2015 um 12:21 schrieb Alex McDonald:> on 30/07/2015 11:06:25,
> Bernd Linsel wrote: >> For every child in the call chain of a
> function, the local variables >> of the functions above (invoked
> before) seem to be global, as all >> children are accessing the same
> instance of that >> parent's/grandparent's/grand-... local variable.
> >> (Presuming dynamic scoping or nested definitions, like quotations)
> >
> > Dynamic scoping? That's not what you said.
>
> Normally, scope (symbol visibilty) and extent (variable lifetime) in
> Forth don't impose great problems, because nested definitions are not
> allowed. However, when quotations that can be invoked outside the
> creating word's runtime, it must be considered.
>
> Shortly outlined and drastically reduced:
> - Static scope: Nested definitions have access to outer definitions'
> loca ls.
> - Dynamic scope: Nested *invocations* have access to earlier invoked
> functions' locals.
> - Global Forth variables have infinite extent (their value stays valid
> as long as the dictionary is not cleared). - Local Forth variables
> have static extent (their value is valid from their
> definition/initialization until the containing word returns).
>
> Quotations in Forth suddenly introduce nested definitions.
> And if a quotation (q) has somehow access to the locals of the word it
> was defined in (p, for parent), you have a mix of static and dynamic
> scoping:
>
> Static, because q's definition is nested in p's definition. As long as
> you call q from within p, q can just access p's locals stack frame.
>
> But if p returns q (respectively an xt for q) and exits, then q is
> invoked later, p's locals stack frame ceased to exist. Any reference
> to p's locals is invalid. But in q's "history" there has been the
> invocation of p that created q. So now you have a kind of dynamic
> scoping -- iff there is a mechanism that keeps the locals of p alive
> in order to let q access them even after p returned.
> This is not straightforward dynamic scoping after the schoolbook, but
> in
>
> the same category.
This is normally called a closure, hence my confusion.
>
> > <quote>
> > To approximate this behaviour, I suggest making accessed parent's
> loca ls
> > static copies, or if you prefer, globals with special scope, just
> > visible withing the quotation.
> > </quote>
> >
> > and
> >
> > <quote>
> > - parent's locals become 'static locals' when accessed within the
> > quotation, mainly because of the effect of being able to store state
> > (what admittedly may equally be achieved by using globals). >
> </quote> >
> > Can you provide an example or two?
> >
> > On reading agan the post that these come from, I would also like an
> > example of the issues you raise there, since I don't understand it
> > either.
> >
> > <quote>
> > The suggested RfD lacks the possibility for a simple way to pass
> value s
> > into the quotation at creation time (if the parameter stack is used
> as
>
> > compilation stack, as ISO 94 and 200x suggest / allow), and the
> > possibility to create aggregating quotations without a global
> variable
>
> > accessible and visible to the "outer world".
> > </quote>
> >
> > Thanks.
> >
>
> #1 passing values into a quotation
>
> The best example is currying, e.g. reducing the arity of a function by
> providing some (but not all) arguments to it, creating another
> "specialized" function:
>
>: f ( x y -- z )
> dup * \ x y²
> swap * \ y² x²
> +
> ;
>
>: curry { xt1 x -- xt2 }
> [: x swap xt1 execute :] ( y -- z )
> ;
>
>
> # 3 4 f . \ => 25 ok
> # defer f3 \ => ok
> # ' f 3 curry is f3 \ => ok ( f3 is the same as 3 ? f )
> 4 f3 . \ => 25 ok ( 4 f3 is the same as 3 4 f )
>
>
> #2 storing state within a quotation
>
>: begin-sum ( -- xt )
> 0 { sum } \ create local state variable for the sum
> [: sum + dup to sum :] ( n -- sum )
> ;
>
> # defer sum-add \ => ok
> # begin-sum is sum-add \ => ok
> # 3 sum-add . \ => 3 ok
> # 2 sum-add . \ => 5 ok
> # 1 sum-add drop \ => ok ( sum=6 )
> # 4 sum-add drop \ => ok ( sum=10 )
> # 3 sum-add . \ => 13 ok
>
> and...
>
> # begin-sum is sum-add \ => ok ( new instance, sum=0 )
> # : test
> # 10 0 do
> # i sum-add drop
> # loop
> # 0 sum-add ; \ => ok
> # test . \ => 45 ok
>
>
> #3 passing value into the quotation's definition
>
>: begin-sum-with-start { sum -- xt } \ initial value not null but
> provided by caller
> [: sum + dup to sum :] ( n -- sum )
> ;
>
> # 8 begin-sum-with-start is sum-add
> # 1 sum-add drop
> # 2 sum-add drop
> # 3 sum-add . \ => 14 ok
>
>
>
> Got the point?
I understand what you are illustrating; I don't understand your point. #1
Currying for example (modified from
http://rosettacode.org/wiki/Currying#Forth)
: curry { x xt1 -- xt2 }
:noname x postpone literal xt1 compile, postpone ; ;
5 ' + curry constant plus5
5 plus5 execute .
7 plus5 execute .
This doesn't require quotations.
#2 and #3 can use a global value or variable, and #3 additionally suffers
from a compilation problem I describe to you here
https://groups.google.com/forum/message/raw?
msg=comp.lang.forth/BMSyAsqtrB8/4cOA74DrCAAJ
>
> --
> Best regards,
> Bernd
>
>
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-29 10:35 -0700 |
| Message-ID | <87io92ooi3.fsf@jester.gateway.sonic.net> |
| In reply to | #40909 |
Bernd Linsel <bl1@gmx.com> writes:
> Why not make a compromise? Outer words' locals...are copied into a
> dedicated "static variable area"... living as long as the quotation
> itself... Example:
> : make-add-x+y { x y -- xt }
> [: { x y } x dup y + to x + ;] ;
1. I can't tell when the { x y } inside the local is supposed to shadow
the outer x and y.
2. How are you supposed know when the quotation's lifetime has ended, if
you've passed the xt to some other word that might have saved it
somewhere? Normally that's implemented with garbage collected closures,
but I don't think that's what you're describing.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-30 01:45 +0200 |
| Message-ID | <mpboi3$buj$1@newsreader4.netcologne.de> |
| In reply to | #40914 |
Am 29.07.2015 um 19:35 schrieb Paul Rubin:
> Bernd Linsel <bl1@gmx.com> writes:
>> Why not make a compromise? Outer words' locals...are copied into a
>> dedicated "static variable area"... living as long as the quotation
>> itself... Example:
>> : make-add-x+y { x y -- xt }
>> [: { x y } x dup y + to x + ;] ;
>
> 1. I can't tell when the { x y } inside the local is supposed to shadow
> the outer x and y.
Probably this example wasn't thought over thoroughly.
I had in mind: When encountering { x y } in the quotation, x and y are
taken from the parent's local frame and made 'static locals'.
Perhaps it is clearer to require writing [: x y { x y } ...
>
> 2. How are you supposed know when the quotation's lifetime has ended, if
> you've passed the xt to some other word that might have saved it
> somewhere? Normally that's implemented with garbage collected closures,
> but I don't think that's what you're describing.
>
It doesn't end, except you execute FORGET or a MARKER that includes the
quotations last definition.
I didn't want to address this problem; you do also have it with the
proposed RfD. Otherwise the xt would have to be reference-counted or
tracked in another way, or the quotation (and its associated data) must
be garbage-collected.
--
Regards
Bernd
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-30 03:17 +0200 |
| Message-ID | <mpbtv0$fm3$1@newsreader4.netcologne.de> |
| In reply to | #40926 |
Am 30.07.2015 um 01:45 schrieb Bernd Linsel:> Am 29.07.2015 um 19:35
schrieb Paul Rubin:
>> Bernd Linsel <bl1@gmx.com> writes:
>>> Why not make a compromise? Outer words' locals...are copied into a
>>> dedicated "static variable area"... living as long as the quotation
>>> itself... Example:
>>> : make-add-x+y { x y -- xt }
>>> [: { x y } x dup y + to x + ;] ;
>>
>> 1. I can't tell when the { x y } inside the local is supposed to shadow
>> the outer x and y.
>
> Probably this example wasn't thought over thoroughly.
> I had in mind: When encountering { x y } in the quotation, x and y are
> taken from the parent's local frame and made 'static locals'.
> Perhaps it is clearer to require writing [: x y { x y } ...
I'm still not lucky with this, while I reckon the copy-on-definition
approach still sufficient.
Rationale:
When accessing a parent's local (assuming that the containing stack
frame is still alive, however you accomplish that for this part of the
discussion...), this local variable looks like a global variable for all
active children in the call chain below the parent [that have access to
/ are in the scope of this local].
Though, a second, parallel call to the parent would provide another
instance of this local, again visible as a pseudo-global to all called
children [again, with respect to visibility rules/scoping]. The same is
true for a recursive invocation of the parent: Another instance of the
local variable is generated, which acts global for all children of this
invocation.
(Besides: Has anyone thought through the implications of a quotation
calling its parent "indirect" recursively? ...)
To approximate this behaviour, I suggest making accessed parent's locals
static copies, or if you prefer, globals with special scope, just
visible withing the quotation.
You lose:
- Multiple instances of the parent's local when executing quotations in
parallel produced by parallel instances (eg recursion) of the parent;
- Write access into the parent's instance of the local.
You gain:
- Easy read access from the quotation to locals in the call frame of the
parent that produced it. This is convenient when creating higher order
functions, aggregate functors etc.
Aside from that,
- a quotation's own locals should be true locals, i.e. allocated on
execution flow entry, and unlinked on exit, so you're safe when recursing.
- parent's locals become 'static locals' when accessed within the
quotation, mainly because of the effect of being able to store state
(what admittedly may equally be achieved by using globals).
True reentrancy is not needed, as long as you don't invoke a quotation
two or more times in parallel. Even a call to PAUSE from the quotation,
resulting in another invocation produces probably unpredictable results,
but no return stack mess.
If you don't copy, the parent's locals extent is bound to the parent's
execution, this is what Hugh's method suffers from: You can pass
quotations only down in the call-chain, as long as the parent's stack
frame is alive.
The suggested RfD lacks the possibility for a simple way to pass values
into the quotation at creation time (if the parameter stack is used as
compilation stack, as ISO 94 and 200x suggest / allow), and the
possibility to create aggregating quotations without a global variable
accessible and visible to the "outer world".
Smalltalk-80's blocks only had locals (in the Forth sense), but they
could access their generating object and all of its properties, so state
was stored there.
Emulating early LISP's or Scheme's closures or modern Smalltalk's blocks
(both "real" quotations) implies creating linked enviroments for each
function/word invocation, keeping them in memory as long as the word is
callable. I consider that infeasible without heap allocation,
discontinuous deallocation, and garbage collection.
Apart from that, I suppose no Forther would really want name-based
resolution, dynamic variable scope, and pseudo-infinite extent.
If so, I suggest you learn LISP.
Btw, in Common LISP they gave up generally scoping dynamically and made
local variables syntactically scoped by default.
--
Best regards,
Bernd Linsel
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-29 19:21 -0700 |
| Message-ID | <83b9b735-ea13-45db-bceb-06b115500026@googlegroups.com> |
| In reply to | #40933 |
On Wednesday, July 29, 2015 at 6:17:22 PM UTC-7, Bernd Linsel wrote: > If you don't copy, the parent's locals extent is bound to the parent's > execution, this is what Hugh's method suffers from: You can pass > quotations only down in the call-chain, as long as the parent's stack > frame is alive. I don't know what you mean by "copy." You can't copy the local-frame anywhere, because the whole point of having quotations access the parent function's local-frame is that the parent function accesses the same local-frame, and that is how the quotation communicates information back to the parent-function. The quotation can't be accessing a copy of the parent-function's local-frame --- they have to access the same local-frame. What Scheme/Lisp etc. do, is build the parent-function's local-frame in the heap rather than on the stack, and both the parent-function and the quotation access it, and it gets GC'd after both the parent-function and the quotation have exited (doesn't matter which one exits first). This requires GC though, which I consider a no-go in a micro-controller --- Pascal Bourguignon beat me up for saying that GC is a no-go in a micro-controller (https://groups.google.com/forum/#!topic/comp.lang.lisp/-nWfXAs_4ug) --- but, I don't see the Scheme/Lisp crowd making many inroads into the micro-controller world, so I think Pascal is mistaking fantasy for reality when he tells of "pause-less GC." Anyway, I don't think that my method suffers very much by only being able to pass quotations down the call-chain. My only goal is to support general-purpose data-structures --- the parent-function calls a higher-order function and it traverses the data-structure, executing the quotation for every node --- what I have is adequate for that, and it is efficient enough for a micro-controller, so I have succeeded. I'm not competing against Scheme/Lisp, I'm competing against C and ANS-Forth. I don't know what the big deal is about having quotations that can be executed after the parent-function has exited. All that you have really accomplished here is an OOP system in which the struct (actually the local-frame) has only one method attached to it. That is not very useful! Why not just build a struct and have some of the fields be pointers to functions --- then you can have more than one method attached to your struct --- all in all, the Scheme/Lisp method just allows you to access your data as local variables rather than as fields in a struct (this is just syntactic sugar), and it limits you to one method rather than several (so, in exchange for some syntactic sugar, you get an unnecessary limitation). The FMITE is a small 16-bit micro-controller intended to compete against the AVR and MSP-430 --- we are not going to have GC! --- this is supposed to be reality, not fantasy.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-29 23:04 -0700 |
| Message-ID | <87k2timb98.fsf@jester.gateway.sonic.net> |
| In reply to | #40933 |
Bernd Linsel <bl1@gmx.com> writes:
>> Perhaps it is clearer to require writing [: x y { x y } ...
> I'm still not lucky with this, while I reckon the copy-on-definition
> approach still sufficient.
If I understand it, you're saying that at compile time, the { x y } in
the quotation should permanently allocate two cells in the global
dictionary. Then on entry into the quotation, x and y from the parent
are pushed to the D stack, then popped to be stored in those two
dictionary cells. Do I have that right?
What happens if multiple instances of the quotation are active at the
same time, like in a multitasking system?
What happens if the quotation is recursive?
Is burning two dictionary cells permanently really better than using
global variables? Why not just push the inner locals onto the same
locals stack as the parent locals?
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-30 12:38 +0200 |
| Message-ID | <mpcurt$2us$1@newsreader4.netcologne.de> |
| In reply to | #40945 |
Am 30.07.2015 um 08:04 schrieb Paul Rubin:> Bernd Linsel <bl1@gmx.com>
writes:
>>> Perhaps it is clearer to require writing [: x y { x y } ...
>> I'm still not lucky with this, while I reckon the copy-on-definition
>> approach still sufficient.
>
> If I understand it, you're saying that at compile time, the { x y } in
> the quotation should permanently allocate two cells in the global
> dictionary. Then on entry into the quotation, x and y from the parent
> are pushed to the D stack, then popped to be stored in those two
> dictionary cells. Do I have that right?
That would be a clumsy realization, yes.
My example (and suggested syntax) is too complicated. I'll try again:
: bar { x y -- xt }
[: x dup y + to x + :] ; \ locals not needed (but possible)
Accessing bar's x and y within the quotation makes them 'inherited'
locals for the quotation and triggers copying them into the quotations'
static frame.
This makes sure that a reference to them stays valid, even when bar's
invocation ends and the original x and y cease to exist.
The downside of copying is that the quotation cannot alter bar's x or y,
even if bar is still running.
> What happens if multiple instances of the quotation are active at the
> same time, like in a multitasking system?
Without locking, it would just be unpredictable which invocation of the
quotation wins the contest who's writing x finally.
This problem arises likewise with full-fledged closure implementations
(Lisp, SmallTalk, PostScript, JavaScript) with multitasking. As x can be
written simultaneously, it should be regarded as shared resource, and
safeguarded with appropriate lock mechanisms.
> What happens if the quotation is recursive?
That's about the same. Nested function invocations with access to locals
in stack frames 'above' them must be aware that they are shared.
> Is burning two dictionary cells permanently really better than using
> global variables? Why not just push the inner locals onto the same
> locals stack as the parent locals?
A quotation's inner locals (unrelated to its parent's locals) may be
handled like any other local variables. It's just the 'inherited' ones
that need special treatment if you want to allow access to them after
the parent has exited -- what is what all my tattle is about...
--
Best regards
Bernd
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-30 12:09 +0100 |
| Message-ID | <mpd0hq$l2h$1@dont-email.me> |
| In reply to | #40957 |
on 30/07/2015 11:38:58, Bernd Linsel wrote:
> Am 30.07.2015 um 08:04 schrieb Paul Rubin:> Bernd Linsel <bl1@gmx.com>
> writes: >>> Perhaps it is clearer to require writing [: x y { x y }
> ... >> I'm still not lucky with this, while I reckon the
> copy-on-definition >> approach still sufficient.
> >
> > If I understand it, you're saying that at compile time, the { x y }
> in > the quotation should permanently allocate two cells in the global
> > dictionary. Then on entry into the quotation, x and y from the
> parent > are pushed to the D stack, then popped to be stored in those
> two > dictionary cells. Do I have that right?
>
> That would be a clumsy realization, yes.
>
> My example (and suggested syntax) is too complicated. I'll try again:
>
>: bar { x y -- xt }
> [: x dup y + to x + :] ; \ locals not needed (but possible)
>
> Accessing bar's x and y within the quotation makes them 'inherited'
> locals for the quotation and triggers copying them into the
> quotations' static frame.
>
> This makes sure that a reference to them stays valid, even when bar's
> invocation ends and the original x and y cease to exist.
>
Is this even possible?
It can't be done at compile time, since the values of X and Y aren't
known until run time. At run time, the values of X and Y aren't
available, since they are now out of scope when the quotation is executed
out of the scope of BAR.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-30 13:26 +0200 |
| Message-ID | <mpd1kq$4vf$1@newsreader4.netcologne.de> |
| In reply to | #40958 |
Am 30.07.2015 um 13:09 schrieb Alex McDonald:> on 30/07/2015 11:38:58,
Bernd Linsel wrote:
>> Am 30.07.2015 um 08:04 schrieb Paul Rubin:> Bernd Linsel <bl1@gmx.com>
>> writes: >>> Perhaps it is clearer to require writing [: x y { x y }
>> ... >> I'm still not lucky with this, while I reckon the
>> copy-on-definition >> approach still sufficient.
>>>
>>> If I understand it, you're saying that at compile time, the { x y }
>> in > the quotation should permanently allocate two cells in the global
>>> dictionary. Then on entry into the quotation, x and y from the
>> parent > are pushed to the D stack, then popped to be stored in those
>> two > dictionary cells. Do I have that right?
>>
>> That would be a clumsy realization, yes.
>>
>> My example (and suggested syntax) is too complicated. I'll try again:
>>
>> : bar { x y -- xt }
>> [: x dup y + to x + :] ; \ locals not needed (but possible)
>>
>> Accessing bar's x and y within the quotation makes them 'inherited'
>> locals for the quotation and triggers copying them into the
>> quotations' static frame.
>>
>> This makes sure that a reference to them stays valid, even when bar's
>> invocation ends and the original x and y cease to exist.
>>
>
> Is this even possible?
>
> It can't be done at compile time, since the values of X and Y aren't
> known until run time. At run time, the values of X and Y aren't
> available, since they are now out of scope when the quotation is executed
> out of the scope of BAR.
>
Surely:
The values aren't known, but the addresses relative to the frame pointer
are.
Remember that the parent must be executed to obtain an xt for the
quotation. You place the initialization of the referenced local's copy
into the parent's code, just where the quotation is defined in the
source (the address of the static copied local's frame is probably
somehow related to the quotation's xt, so calculating the correct
address shouldn't be too hard).
In the quotation's code, there must of course be a reference
(initialization of a 'static frame pointer' or something in this way) to
the same address. These addresses can be resolved by the compiler, as
the frame is created when encountering the quotation during the
compilation of the parent.
--
Best regards,
Bernd
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-31 09:47 +0100 |
| Message-ID | <mpfckq$sh5$1@dont-email.me> |
| In reply to | #40960 |
on 30/07/2015 12:26:21, Bernd Linsel wrote:
> Am 30.07.2015 um 13:09 schrieb Alex McDonald:> on 30/07/2015 11:38:58,
> Bernd Linsel wrote: >> Am 30.07.2015 um 08:04 schrieb Paul Rubin:>
> Bernd Linsel <bl1@gmx.com> >> writes: >>> Perhaps it is clearer to
> require writing [: x y { x y } >> ... >> I'm still not lucky with
> this, while I reckon the >> copy-on-definition >> approach still
> sufficient. >>>
> >>> If I understand it, you're saying that at compile time, the { x y
> } >> in > the quotation should permanently allocate two cells in the
> global >>> dictionary. Then on entry into the quotation, x and y from
> the >> parent > are pushed to the D stack, then popped to be stored in
> those >> two > dictionary cells. Do I have that right?
> >>
> >> That would be a clumsy realization, yes.
> >>
> >> My example (and suggested syntax) is too complicated. I'll try
> again: >>
> >> : bar { x y -- xt }
> >> [: x dup y + to x + :] ; \ locals not needed (but possible)
> >>
> >> Accessing bar's x and y within the quotation makes them 'inherited'
> >> locals for the quotation and triggers copying them into the >>
> quotations' static frame. >>
> >> This makes sure that a reference to them stays valid, even when
> bar's >> invocation ends and the original x and y cease to exist.
> >>
> >
> > Is this even possible?
> >
> > It can't be done at compile time, since the values of X and Y aren't
> > known until run time. At run time, the values of X and Y aren't >
> available, since they are now out of scope when the quotation is
> executed > out of the scope of BAR.
> >
>
> Surely:
>
> The values aren't known, but the addresses relative to the frame
> pointer are.
>
> Remember that the parent must be executed to obtain an xt for the
> quotation. You place the initialization of the referenced local's copy
> into the parent's code, just where the quotation is defined in the
> source (the address of the static copied local's frame is probably
> somehow related to the quotation's xt, so calculating the correct
> address shouldn't be too hard). In the quotation's code, there must of
> course be a reference (initialization of a 'static frame pointer' or
> something in this way) to the same address. These addresses can be
> resolved by the compiler, as the frame is created when encountering
> the quotation during the compilation of the parent.
>
> --
> Best regards,
> Bernd
>
Let's take the example you gave.
: bar { x y -- xt } [: ( called Q below ) x dup y + to x + :] ;
10 20 bar execute
There are the following events; BAR-COMPILE when BAR is compiled,
Q-COMPILE when the quotation is compiled (a part of BAR-COMPILE and in
the scope of BAR), BAR-EXECUTE when BAR is executed and Q- EXECUTE when
the quotation is executed.
Here's the information available at each phase, and what you would need
to do to make this scheme work.
BAR-COMPILE: X and Y addresses are known (A(X) and A(Y)), but not the
values.
Q-COMPILE: Same information as BAR-COMPILE, since it is done in the
context of compiling BAR. Reserve slots for X and Y (X-SLOT and Y-SLOT)
in the execution environment for Q.
BAR-EXECUTE: X and Y now have definite values. BAR uses X-SLOT and Y-SLOT
slots in Q to copy the values in the future execution scope for
Q-EXECUTE.
Critically, we have to pass compile time information about locals and
local-SLOTs (A(X), A(Y), X-SLOT and Y-SLOT) from Q-COMPILE through to
BAR-EXECUTE. How would you propose implementing this?
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web