Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #40342 > unrolled thread
| Started by | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| First post | 2015-07-05 22:35 -0700 |
| Last post | 2016-06-09 17:18 +0000 |
| Articles | 20 on this page of 107 — 15 participants |
Back to article view | Back to comp.lang.forth
Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 22:35 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2015-07-05 23:03 -0700
Re: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 23:21 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2015-07-06 00:00 -0700
Re: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-06 00:10 -0700
Re: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-06 09:39 +0100
Re: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-06 05:28 -0700
Re: Quotations franck.bensusan@gmail.com - 2015-07-06 15:02 -0700
Re: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-06 22:43 -0700
Re: Quotations Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-07-06 23:06 -0700
Re: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-07 01:27 -0700
Re: Quotations Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-07-07 03:40 -0700
Re: Quotations franck.bensusan@gmail.com - 2015-07-07 04:08 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2015-07-10 02:34 -0700
Re: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-14 11:30 -0700
Re: Quotations franck.bensusan@gmail.com - 2015-07-16 03:28 -0700
Re: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-16 09:11 -0700
Re: Quotations Paul Rubin <no.email@nospam.invalid> - 2015-07-08 12:04 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-28 13:06 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-29 02:22 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-29 10:41 -0700
Re: Quotations franck.bensusan@gmail.com - 2016-05-29 12:38 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-29 23:03 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-30 00:34 -0700
Re: Quotations franck.bensusan@gmail.com - 2016-05-30 03:04 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-30 03:41 -0700
Re: Quotations franck.bensusan@gmail.com - 2016-05-30 08:26 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-30 08:46 -0700
Re: Quotations Cecil Bayona <cbayona@cbayona.com> - 2016-05-30 10:01 -0500
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-30 08:33 -0700
Re: Quotations franck.bensusan@gmail.com - 2016-05-30 00:44 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-30 01:03 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-06-02 22:07 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-06-02 23:11 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-06-03 05:18 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-06-03 05:28 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-06-03 05:56 -0700
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-30 15:24 +0000
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-30 11:33 -0700
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-01 14:23 +0000
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-30 11:46 -0700
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-01 14:27 +0000
Re: Quotations hughaguilar96@gmail.com - 2016-06-01 07:53 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-30 12:43 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-31 13:25 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-05-31 16:57 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-05-31 19:33 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-06-01 03:20 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-06-01 03:15 -0700
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-01 14:29 +0000
Re: Quotations hughaguilar96@gmail.com - 2016-06-01 08:20 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-06-01 18:59 -0700
Re: Quotations "WJ" <w_a_x_man@yahoo.com> - 2016-06-02 06:05 +0000
Re: Quotations alex@rivadpm.com - 2016-06-09 09:59 -0700
Re: Quotations "WJ" <w_a_x_man@yahoo.com> - 2016-06-09 17:47 +0000
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-06-01 09:12 -0700
Re: Quotations "HAA" <someone@microsoft.com> - 2016-06-02 12:45 +1000
Re: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-02 04:42 -0500
Re: Quotations Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-06-02 05:08 -0700
Re: Quotations Paul Rubin <no.email@nospam.invalid> - 2016-06-02 06:53 -0700
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-02 13:54 +0000
Re: Quotations hughaguilar96@gmail.com - 2016-06-02 13:09 -0700
Re: Quotations "HAA" <someone@microsoft.com> - 2016-06-04 12:45 +1000
Re: Quotations hughaguilar96@gmail.com - 2016-06-03 20:52 -0700
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-04 15:05 +0000
Re: Quotations hughaguilar96@gmail.com - 2016-06-06 01:41 -0700
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-06 13:12 +0000
Re: Quotations hughaguilar96@gmail.com - 2016-06-06 08:29 -0700
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-07 06:06 +0000
Re: Quotations mhx@iae.nl - 2016-06-06 10:51 -0700
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-07 06:36 +0000
Re: Quotations hughaguilar96@gmail.com - 2016-06-07 00:44 -0700
Re: Quotations mhx@iae.nl - 2016-06-07 11:35 -0700
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-08 07:14 +0000
Re: Quotations hughaguilar96@gmail.com - 2016-06-09 00:58 -0700
Re: Quotations "WJ" <w_a_x_man@yahoo.com> - 2016-06-09 11:37 +0000
Re: Quotations Paul Rubin <no.email@nospam.invalid> - 2016-06-07 12:37 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-06-07 19:03 -0700
Re: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-02 11:12 -0500
Re: Quotations Paul Rubin <no.email@nospam.invalid> - 2016-06-02 09:42 -0700
Re: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-03 02:53 -0500
Re: Quotations Paul Rubin <no.email@nospam.invalid> - 2016-06-03 23:00 -0700
Re: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-04 04:37 -0500
Re: Quotations Paul Rubin <no.email@nospam.invalid> - 2016-06-05 19:12 -0700
Re: Quotations Paul Rubin <no.email@nospam.invalid> - 2016-06-05 21:20 -0700
Re: Quotations franck.bensusan@gmail.com - 2016-06-09 02:55 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-06-09 19:20 -0700
Re: Quotations franck.bensusan@gmail.com - 2016-06-10 07:00 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-06-10 10:00 -0700
Re: Quotations franck.bensusan@gmail.com - 2016-06-10 10:56 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-06-10 17:56 -0700
Re: Quotations Mark Wills <markwills1970@gmail.com> - 2016-06-14 05:18 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-06-26 16:12 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-06-02 12:41 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-06-02 13:03 -0700
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-02 13:37 +0000
Re: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-08 04:33 -0500
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-08 09:39 +0000
Re: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-08 05:53 -0500
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-08 11:30 +0000
Re: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-08 08:11 -0500
Re: Quotations hughaguilar96@gmail.com - 2016-06-09 01:09 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-30 08:54 -0700
Re: Quotations hughaguilar96@gmail.com - 2016-05-31 12:06 -0700
Re: Quotations humptydumpty <ouatubi@gmail.com> - 2016-05-31 13:41 -0700
Re: Quotations "WJ" <w_a_x_man@yahoo.com> - 2016-05-31 21:09 +0000
Lambdas (closures) "WJ" <w_a_x_man@yahoo.com> - 2016-06-09 17:18 +0000
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-02 13:54 +0000 |
| Message-ID | <2016Jun2.155422@mips.complang.tuwien.ac.at> |
| In reply to | #47729 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>
>> One problem with this approach is the lifetime of the quotations.
>> There's no garbage collection, so we have to put the captured locals
>
>Who said the parent's locals should be captured? Local variables are
>"local" variables. When parent exits, its locals are gone. Simple as that.
So you want Pascal-like behaviour. This brings us back to the
question of usefulness (and efficiency, see below): I have seen one or
two examples where Pascal locals provided something that could not be
achieved without outer locals, and these examples were not production
code. And the victory of C (which does not have nested functions)
over Pascal indicates that access to outer locals with the Pascal
limitation is not a decisive benefit.
OTOH, I have seen lots of nice examples of using full-blown closures
where locals live on after the function where they were defined has
exited. But we probably don't want to go there in Forth because of
garbage-management issues.
Anyway, if we first standardize quotations without access to outer
locals (leaving such accesses ambiguous), systems can provide extended
versions of that with such access, and if programmers find that
useful, it will spread, and when there is common practice, that can be
standardized as well.
>The mechanism is so simple and easy to implement... Did you hear about frame pointers?
And static link chains (or displays), if you want to implement access
to outer locals. Which means additional overhead and implementation
complexity, especially if you want to reduce the overhead for those
cases where the frame pointers etc. are not needed.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-02 13:09 -0700 |
| Message-ID | <30c8ba49-2561-423a-b0ed-758e47090736@googlegroups.com> |
| In reply to | #47737 |
On Thursday, June 2, 2016 at 7:10:42 AM UTC-7, Anton Ertl wrote:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >
> >> One problem with this approach is the lifetime of the quotations.
> >> There's no garbage collection, so we have to put the captured locals
> >
> >Who said the parent's locals should be captured? Local variables are
> >"local" variables. When parent exits, its locals are gone. Simple as that.
>
> So you want Pascal-like behaviour. This brings us back to the
> question of usefulness (and efficiency, see below): I have seen one or
> two examples where Pascal locals provided something that could not be
> achieved without outer locals, and these examples were not production
> code. And the victory of C (which does not have nested functions)
> over Pascal indicates that access to outer locals with the Pascal
> limitation is not a decisive benefit.
Voting doesn't always result in an smart solution --- certainly, dumb people out-number smart people by a wide margin --- maybe that explains the "victory of C."
> OTOH, I have seen lots of nice examples of using full-blown closures
> where locals live on after the function where they were defined has
> exited. But we probably don't want to go there in Forth because of
> garbage-management issues.
Nobody thinks this is a good idea.
> Anyway, if we first standardize quotations without access to outer
> locals (leaving such accesses ambiguous), systems can provide extended
> versions of that with such access, and if programmers find that
> useful, it will spread, and when there is common practice, that can be
> standardized as well.
Standardizing the Paysan-faked quotations is totally chickening out. You know that Leon Wagner will not give you permission for anything other than the Paysan-faked quotations, so you want to just standardize that. You are kicking the can down the road --- a year later you will say: "Well, the Forth community never came up with anything else, nor demanded anything else, so we will stick with the Paysan-faked quotations." By "Forth community" you mean your pocket boys, such as Andrew Haley.
How difficult would it be to standardize this (currently written in VFX) in Forth-200x?
: rexit ( -- ) rdrop ;
: (r:) ( -- r ) r@ 5 + ; \ 5 is the size of a JMP instruction in 32-bit x86
: r[ ( -- r ) postpone (r:) postpone ahead ; immediate
: ]r ( -- ) postpone rexit postpone then ; immediate
code rex ( r -- ) \ HumptyDumpty called this RCALL --- REX means "R execute"
push edi \ this is the HOF's LF which won't be used by the quotation
mov edi, 0 [edi] \ this is the parent's LF which will be used by the quotation
call ' execute
pop edi \ restore HOF's LF
next, end-code
The answer is --- beyond difficult; in fact, quite impossible --- Leon Wagner will not give you permission, and no amount of begging will change his mind.
The solution is to abandon ANS-Forth and Forth-200x because they were just Forth Inc. marketing gimmicks --- tell Leon Wagner that you won't be his pocket boy anymore and that he should go fuck himself --- start a new standard called Straight Forth.
Before this can be done however, every Forth-200x committee member needs to do something important --- grow a spine!
> >The mechanism is so simple and easy to implement... Did you hear about frame pointers?
>
> And static link chains (or displays), if you want to implement access
> to outer locals. Which means additional overhead and implementation
> complexity, especially if you want to reduce the overhead for those
> cases where the frame pointers etc. are not needed.
I am aware of display-pointer chains from my book on Pascal-S compilation. I read that book when I was 18 years old. I still have the book and reread it a few years ago when the issue of quotations first came up (I learned about quotations when I was learning Factor). I originally considered this for Forth but found it unacceptably complicated so I wondered how it could be simplified --- the result was the LFT (local fall through) idea.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-06-04 12:45 +1000 |
| Message-ID | <nitf9k$e0d$1@gioia.aioe.org> |
| In reply to | #47737 |
Anton Ertl wrote: > Raimond Dragomir <raimond.dragomir@gmail.com> writes: > > > >> One problem with this approach is the lifetime of the quotations. > >> There's no garbage collection, so we have to put the captured locals > > > >Who said the parent's locals should be captured? Local variables are > >"local" variables. When parent exits, its locals are gone. Simple as that. > > So you want Pascal-like behaviour. This brings us back to the > question of usefulness (and efficiency, see below): Let's do. In the context of why Forth might find quotations useful i.e. one line code fragments that don't deserve a separate definition, name, testing or own locals - can you give a simple example of a quotation where accessing the parent's locals would have dire consequences? As for implementing such quotations, it should be easy - load the quotations code before the locals code. There will be things you can't do inside such quotations e.g. EXIT but then ANS locals came with usage restrictions, so what. I can accept quotations with restrictions - but quotations that couldn't access the parent's locals I would regard as useless.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-03 20:52 -0700 |
| Message-ID | <925d0f67-5221-4707-9ff4-920d19e0f8d5@googlegroups.com> |
| In reply to | #47808 |
On Friday, June 3, 2016 at 7:44:15 PM UTC-7, HAA wrote:
> As for implementing such quotations, it should be easy - load the
> quotations code before the locals code. There will be things you
> can't do inside such quotations e.g. EXIT but then ANS locals
> came with usage restrictions, so what. I can accept quotations
> with restrictions - but quotations that couldn't access the parent's
> locals I would regard as useless.
I don't know what you mean when you say: "load the quotations code before the locals code."
The important point is that we do stick with the rule that all of a function's locals are defined at the beginning of the function. ANS-Forth (section 13.3.3) says:
"The position in program source at which the sequence of (LOCAL) messages is sent, referred to here as the point at which locals are declared, shall not lie within the scope of any control structure;"
This is a good rule that needs to be followed. This means that quotations can't have their own locals (that would involve defining locals inside of AHEAD THEN which is a control-structure).
C does not follow this rule. This is a big part of the reason why C does not support quotations.
Anton Ertl doesn't follow this rule either in gForth --- most likely because he is trying to make gForth as similar to C as possible
It is important to know when to break the rules and when to follow the rules. Pretty much, you have to make your own rules, and they have to make sense. In ANS-Forth, we have this rule (section 3.2.3.3.):
"A program shall not access values on the return stack (using R@, R>, 2R@ or 2R>) that it did not place there using >R or 2>R"
HumptyDumpty breaks this rule. Here is his code (slightly enhanced by me):
: rexit ( -- ) rdrop ;
: (r:) ( -- r ) r@ 5 + ; \ 5 is the size of a JMP instruction in 32-bit x86
: r[ ( -- r ) postpone (r:) postpone ahead ; immediate
: ]r ( -- ) postpone rexit postpone then ; immediate
code rex ( r -- ) \ HumptyDumpty called this RCALL --- REX means "R execute"
push edi \ this is the HOF's LF which won't be used by the quotation
mov edi, 0 [edi] \ this is the parent's LF which will be used by the quotation
call ' execute
pop edi \ restore HOF's LF
next, end-code
This code works fine. The parent function can have locals, and the HOF can have locals. The quotation can not have locals of its own, but it will access the parent function's locals.
It is not a good idea to break this rule willy-nilly without understanding it though. In the VFX manual (section 19.3), Stephen Pelc provides this code:
: || if r> drop 1 then ;
He is breaking the rule, but he doesn't understand why the rule is there, and the result is a bug in his code:
: testA 1 || ; ok
testA ok-1
. 1 ok
: testB 9 locals| bbb | 1 || ; ok
testB
Err# -57005 ERR: Windows exception
-> testB
^
Pelc should have written his code like this:
macro: || if 1 exit then ;
This code does not break the rule and it is fully ANS-Forth compatible --- MACRO: is in the novice-package and is ANS-Forth, as is everything in the novice package.
If he had used the novice-package and stuck with ANS-Forth, his code would work:
: testA 1 || ;
TESTA is redefined ok
testA ok-1
. 1 ok
: testB 9 locals| bbb | 1 || ;
TESTB is redefined ok
testB ok-1
. 1 ok
With ANS-Forth, nothing useful can be done without breaking the rules, because most of the rules were just arbitrary barriers put in the programmer's path by an idiot (you know who!). If you break the rules willy-nilly though (as Stephen Pelc does), then you can get bugs in your code. This is why ANS-Forth programming is difficult.
What we need is a new standard. Then we could give the programmers rules that made sense. The programmers wouldn't have to break the rules to do useful work. All the difficulty is lifted from the programmer's shoulders because he can just follow the rules and feel confident that the rules make sense --- they weren't just arbitrary barriers put in his path by an idiot --- they are there to prevent bugs and keep everybody on track.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-04 15:05 +0000 |
| Message-ID | <2016Jun4.170538@mips.complang.tuwien.ac.at> |
| In reply to | #47808 |
"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> >
>> >> One problem with this approach is the lifetime of the quotations.
>> >> There's no garbage collection, so we have to put the captured locals
>> >
>> >Who said the parent's locals should be captured? Local variables are
>> >"local" variables. When parent exits, its locals are gone. Simple as that.
>>
>> So you want Pascal-like behaviour. This brings us back to the
>> question of usefulness (and efficiency, see below):
>
>Let's do. In the context of why Forth might find quotations useful
>i.e. one line code fragments that don't deserve a separate definition,
>name, testing or own locals - can you give a simple example of a
>quotation where accessing the parent's locals would have dire
>consequences?
Dire consequences? I can construct cases that don't work on Gforth's
implementation (see this thread), and if I look at how locals are
implemented in VFX, cases that don't work on VFX, and likewise for
other Forth systems. And I expect that some cases that work on one
system don't work on the next, and vice versa.
>As for implementing such quotations, it should be easy - load the
>quotations code before the locals code.
Does the locals code grow frame pointers and static links by loading
it afterwards? No.
>I can accept quotations
>with restrictions - but quotations that couldn't access the parent's
>locals I would regard as useless.
That does not convince anyone that quotations that can access outer
locals are useful, and that their implementation cost is justified.
I thought about this issue a little, and thought about one set of
features and restrictions that might be useful and relatively cheap to
implement: Have locals in the outermost colon definition, no locals in
any higher-level words, and allow accessing, but not defining locals
in quotations.
Implementation: On a system with a separate locals stack like Gforth,
this requires nothing additional (maybe a change in the automatic
scoping implementation, or alternatively, a restriction in connection
with that); on a system with the locals on the return stack, this
would require a frame pointer (but no static links chains or
displays); on a system with locals in registers, this would require
choosing registers that are not used by the higher-order words.
Benefit: Instead of passing additional parameters on the stack in
hard-to-understand ways (I certainly have not developed an intuition
about how to do that in connection with nested invocations of
high-level words yet), one can do that through locals.
Let's look at the one case where I found that access to outer locals
might help (tracking the additional stack parameters was hard), and
see if this restricted form would help. From
<2015Jul13.181357@mips.complang.tuwien.ac.at>:
|: for ( ... u xt -- ... )
| \ xt ( ... u1 -- ... )
| { xt } 1+ 1 ?do i xt execute loop ;
|: sum-series ( ... u xt -- ... r )
| \ xt ( ... u1 -- ... r )
| 0e swap [: swap dup >r execute r> f+ ;] for ;
|: test1 1000 [: 1e dup * s>f f/ ;] sum-series ;
|test1 cr f.
|: test ( u -- )
| 10 [: over + s>f ;] sum-series ;
|10 test cr f.
(on running it again, I see that there are a few DROPs missing)
Let's start with unrestricted locals, to get an idea:
: for ( ... u xt -- ... )
\ xt ( ... u1 -- ... )
{ xt } 1+ 1 ?do i xt execute loop ;
: sum-series ( ... u xt -- ... r )
\ xt ( ... u1 -- ... r )
{ xt } ( ... u ) 0e [: xt execute f+ ;] for ;
: test1 1000 [: 1e dup * s>f f/ ;] sum-series ;
test1 cr f.
: test { u -- }
10 [: u + s>f ;] sum-series ;
10 test cr f.
SUM-SERIES improves quite a bit with outer locals, but unfortunately
would be outlawed by the restriction of not using locals in
higher-level words. TEST would improve a little, but not enough to
convince me of the usefulness of outer locals. There is probably
still a few DROPs missing, but I cannot test this version.
So this example shows a little benefit from the cheap solution I had
in mind, and some more from a more expensive, less restrictive
solution. Both don't convince me that they are worth the cost, yet.
Can you give convincing examples?
BTW, allowing locals in high-level words does not require a full-blown
Pascal-style implementation: There is still only one scope accessible
in any quotation, so one needs access to only one frame; maybe one can
implement this more cheaply than in the full Pascal solution.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-06 01:41 -0700 |
| Message-ID | <f6b16071-e9ab-40c7-bf81-af0891ae2de5@googlegroups.com> |
| In reply to | #47824 |
On Saturday, June 4, 2016 at 10:37:24 AM UTC-7, Anton Ertl wrote:
> "HAA" <someone@microsoft.com> writes:
> >Let's do. In the context of why Forth might find quotations useful
> >i.e. one line code fragments that don't deserve a separate definition,
> >name, testing or own locals - can you give a simple example of a
> >quotation where accessing the parent's locals would have dire
> >consequences?
>
> Dire consequences? I can construct cases that don't work on Gforth's
> implementation (see this thread),
Your gForth is breaking ANS-Forth rules such as (section 13.3.3):
"The position in program source at which the sequence of (LOCAL) messages is sent, referred to here as the point at which locals are declared, shall not lie within the scope of any control structure"
It seems ridiculous that you complain that other people's non-standard Forth is not compatible with your non-standard Forth.
Also, as a practical matter, why would anybody care about gForth anyway? Your gForth generates code that is about half the speed of SwiftForth, and SwiftForth generates code that is about half or one quarter the speed that would be needed for practical use. I think that Elizabeth Rather appointed you to be the chair-person of the Forth-200x committee on the condition that you would make sure that gForth is not competitive with SwiftForth --- the only virtue of gForth is that it saves SwiftForth from the embarrassing position of being the most inefficient ANS-Forth compiler ever written --- but gForth has no practical value; gForth has never been used in any commercial program and it never will; gForth is slowwwwwwwwww...
> and if I look at how locals are
> implemented in VFX, cases that don't work on VFX,
You are totally lying about this. There are no bugs in my VFX code!
Here is my VFX code once again:
: rexit ( -- ) rdrop ;
: (r:) ( -- r ) r@ 5 + ; \ 5 is the size of a JMP instruction in 32-bit x86
: r[ ( -- r ) postpone (r:) postpone ahead ; immediate
: ]r ( -- ) postpone rexit postpone then ; immediate
code rex ( r -- ) \ HumptyDumpty called this RCALL --- REX means "R execute"
push edi \ this is the HOF's LF which won't be used by the quotation
mov edi, 0 [edi] \ this is the parent's LF which will be used by the quotation
call ' execute
pop edi \ restore HOF's LF
next, end-code
Where is the bug that causes it to not work? Show an example case (you said that you could!) in which it doesn't work. You can't!
My code is actually quite simple, and it works fine. The parent function can have locals, the HOF can have locals, the quotation can't have locals but it accesses the parent function's locals.
It is true that if there are nested HOFs then only one of them can have locals. Maybe this is the example case that you were going to pull out. This is a pretty contrived example case --- as a practical matter, this is very unlikely to ever occur --- it is easy to document this limitation and not worry about it.
> >As for implementing such quotations, it should be easy - load the
> >quotations code before the locals code.
>
> Does the locals code grow frame pointers and static links by loading
> it afterwards? No.
I still don't know what HAA meant here, nor do I know what the response meant.
> >I can accept quotations
> >with restrictions - but quotations that couldn't access the parent's
> >locals I would regard as useless.
>
> That does not convince anyone that quotations that can access outer
> locals are useful, and that their implementation cost is justified.
Anton Ertl is playing dumb here. He actually knows that general-purpose data-structures are useful --- he also knows that Elizabeth Rather has spent the last 40 years railing against general-purpose code (her standard refrain is: "The programmer should have full control," which implies that the programmer has all of the source-code) --- he has to play dumb and pretend to agree with her, because otherwise she will appoint a more loyal pocket-boy to be the Forth-200x committee chair-person.
Here is my EACH function from the novice-package:
: each ( i*x head 'toucher -- j*x ) \ toucher: i*x node -- j*x
>r
begin dup while \ -- node \r: -- 'toucher
r@ over .fore @ >r \ -- node 'toucher \r: -- 'toucher next
execute r> repeat drop
rdrop ;
I had to put the internal data of EACH on the return-stack with >R during the execution of the xt so the pseudo-quotation (called a "toucher" in the comments) would have access to the data that the parent function pushed onto the data-stack prior to calling EACH. This is inefficient. It is also cumbersome because the toucher has to use stack-juggling to modify the elements on the stack and then get them back into the same order again.
Here is an EACH (not tested) that works with quotations:
: each ( head qxt -- ) \ quotation: node --
locals| qxt |
begin dup while \ -- node
dup .fore @ swap \ -- next node
qxt rex repeat drop ;
This should be more efficient because it doesn't have to push the next adr to and from the return-stack. It is certainly more readable because of this. Most importantly however, the quotation can access the parent function's local variables. The improves both efficiency and readability compared to accessing the data-stack elements that the parent function pushed prior to calling EACH.
> I thought about this issue a little, and thought about one set of
> features and restrictions that might be useful and relatively cheap to
> implement: Have locals in the outermost colon definition, no locals in
> any higher-level words, and allow accessing, but not defining locals
> in quotations.
>
> Implementation: On a system with a separate locals stack like Gforth,
> this requires nothing additional (maybe a change in the automatic
> scoping implementation, or alternatively, a restriction in connection
> with that); on a system with the locals on the return stack, this
> would require a frame pointer (but no static links chains or
> displays); on a system with locals in registers, this would require
> choosing registers that are not used by the higher-order words.
Any Forth system that holds locals in registers does so optionally if there are some registers available and not too many locals. The simple solution here is to assume that any function that has quotations must be a parent function and so it will not store any locals in registers but will use the local-frame for all of its locals. This leaves the registers available for the HOF to use for its locals --- the HOF has to be fast, because it is doing iteration through the nodes of the data-structure typically.
> BTW, allowing locals in high-level words does not require a full-blown
> Pascal-style implementation: There is still only one scope accessible
> in any quotation, so one needs access to only one frame; maybe one can
> implement this more cheaply than in the full Pascal solution.
Maybe one can just use the code that I wrote and which is provided above.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-06 13:12 +0000 |
| Message-ID | <2016Jun6.151245@mips.complang.tuwien.ac.at> |
| In reply to | #47865 |
hughaguilar96@gmail.com writes:
>On Saturday, June 4, 2016 at 10:37:24 AM UTC-7, Anton Ertl wrote:
>> I can construct cases that don't work on Gforth's
>> implementation (see this thread), and if I look at how locals are
>> implemented in VFX, cases that don't work on VFX,=20
>
>You are totally lying about this. There are no bugs in my VFX code!
>
>Here is my VFX code once again:
>
>: rexit ( -- ) rdrop ;=20
>: (r:) ( -- r ) r@ 5 + ; \ 5 is the size of a JMP instruction in=
> 32-bit x86=20
>: r[ ( -- r ) postpone (r:) postpone ahead ; immediate=20
>: ]r ( -- ) postpone rexit postpone then ; immediate=20
>
>code rex ( r -- ) \ HumptyDumpty called this RCALL --- REX means "R e=
>xecute"=20
> push edi \ this is the HOF's LF which won't be used by the q=
>uotation=20
> mov edi, 0 [edi] \ this is the parent's LF which will be used by the=
> quotation=20
> call ' execute=20
> pop edi \ restore HOF's LF=20
> next, end-code=20
>
>Where is the bug that causes it to not work? Show an example case (you said=
> that you could!) in which it doesn't work. You can't!
: ex { xt } xt execute ;
: foo { x } r[ x . ]r ex ;
cr 5 foo
should print 5, does print 135006813 on VFX Forth for Linux IA32
Version: 4.71 [build 0537] (probably other numbers on other VFX
versions).
>My code is actually quite simple, and it works fine. The parent function ca=
>n have locals, the HOF can have locals, the quotation can't have locals but=
> it accesses the parent function's locals.
The example above satisfies these restrictions.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-06 08:29 -0700 |
| Message-ID | <21d2609a-5c6b-474e-be9e-b83bd6d342ba@googlegroups.com> |
| In reply to | #47870 |
On Monday, June 6, 2016 at 6:25:44 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@gmail.com writes:
> >On Saturday, June 4, 2016 at 10:37:24 AM UTC-7, Anton Ertl wrote:
> >> I can construct cases that don't work on Gforth's
> >> implementation (see this thread), and if I look at how locals are
> >> implemented in VFX, cases that don't work on VFX,=20
> >
> >You are totally lying about this. There are no bugs in my VFX code!
> >
> >Here is my VFX code once again:
> >
> >: rexit ( -- ) rdrop ;=20
> >: (r:) ( -- r ) r@ 5 + ; \ 5 is the size of a JMP instruction in=
> > 32-bit x86=20
> >: r[ ( -- r ) postpone (r:) postpone ahead ; immediate=20
> >: ]r ( -- ) postpone rexit postpone then ; immediate=20
> >
> >code rex ( r -- ) \ HumptyDumpty called this RCALL --- REX means "R e=
> >xecute"=20
> > push edi \ this is the HOF's LF which won't be used by the q=
> >uotation=20
> > mov edi, 0 [edi] \ this is the parent's LF which will be used by the=
> > quotation=20
> > call ' execute=20
> > pop edi \ restore HOF's LF=20
> > next, end-code=20
> >
> >Where is the bug that causes it to not work? Show an example case (you said=
> > that you could!) in which it doesn't work. You can't!
>
> : ex { xt } xt execute ;
> : foo { x } r[ x . ]r ex ;
> cr 5 foo
>
> should print 5, does print 135006813 on VFX Forth for Linux IA32
> Version: 4.71 [build 0537] (probably other numbers on other VFX
> versions).
>
> >My code is actually quite simple, and it works fine. The parent function ca=
> >n have locals, the HOF can have locals, the quotation can't have locals but=
> > it accesses the parent function's locals.
>
> The example above satisfies these restrictions.
You are supposed to use REX for executing quotations --- not EXECUTE --- did you not even look at the code?
: ex { xt } xt rex ; ok
: foo { x } r[ x . ]r ex ; ok
cr 5 foo
5 ok
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-07 06:06 +0000 |
| Message-ID | <2016Jun7.080618@mips.complang.tuwien.ac.at> |
| In reply to | #47877 |
hughaguilar96@gmail.com writes:
>On Monday, June 6, 2016 at 6:25:44 AM UTC-7, Anton Ertl wrote:
>> hughaguilar96@gmail.com writes:
>> >On Saturday, June 4, 2016 at 10:37:24 AM UTC-7, Anton Ertl wrote:
>> >> I can construct cases that don't work on Gforth's
>> >> implementation (see this thread), and if I look at how locals are
>> >> implemented in VFX, cases that don't work on VFX,=20
>> >
>> >You are totally lying about this. There are no bugs in my VFX code!
>> >
>> >Here is my VFX code once again:
>> >
>> >: rexit ( -- ) rdrop ;=20
>> >: (r:) ( -- r ) r@ 5 + ; \ 5 is the size of a JMP instruction in=
>> > 32-bit x86=20
>> >: r[ ( -- r ) postpone (r:) postpone ahead ; immediate=20
>> >: ]r ( -- ) postpone rexit postpone then ; immediate=20
>> >
>> >code rex ( r -- ) \ HumptyDumpty called this RCALL --- REX means "R e=
>> >xecute"=20
>> > push edi \ this is the HOF's LF which won't be used by the q=
>> >uotation=20
>> > mov edi, 0 [edi] \ this is the parent's LF which will be used by the=
>> > quotation=20
>> > call ' execute=20
>> > pop edi \ restore HOF's LF=20
>> > next, end-code=20
>> >
>> >Where is the bug that causes it to not work? Show an example case (you said=
>> > that you could!) in which it doesn't work. You can't!
>>
>> : ex { xt } xt execute ;
>> : foo { x } r[ x . ]r ex ;
>> cr 5 foo
...
>You are supposed to use REX for executing quotations --- not EXECUTE --- did you not even look at the code?
Oops, sorry, my bad. Ok, next try:
: foo { x } r[ x . ]r rex ;
cr 5 foo
should print 5, prints 134512640.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-06-06 10:51 -0700 |
| Message-ID | <66a934e9-e4ab-4901-b515-db5b0f053b30@googlegroups.com> |
| In reply to | #47870 |
On Monday, June 6, 2016 at 3:25:44 PM UTC+2, Anton Ertl wrote:
> : ex { xt } xt execute ;
> : foo { x } r[ x . ]r ex ;
> cr 5 foo
>
> should print 5, does print 135006813 on VFX Forth for Linux IA32
It looks like it can be made to work if the x[ and ]x
words save/restore the locals stackpointer (in case
there is one)?
-marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-07 06:36 +0000 |
| Message-ID | <2016Jun7.083627@mips.complang.tuwien.ac.at> |
| In reply to | #47881 |
mhx@iae.nl writes:
>On Monday, June 6, 2016 at 3:25:44 PM UTC+2, Anton Ertl wrote:
>> : ex { xt } xt execute ;
>> : foo { x } r[ x . ]r ex ;
>> cr 5 foo
>>
>> should print 5, does print 135006813 on VFX Forth for Linux IA32
>
>It looks like it can be made to work if the x[ and ]x
>words save/restore the locals stackpointer (in case
>there is one)?
For a system with a locals stack like Gforth, if you save the locals
stack pointer on the outside of r[...]r, you have the right value, but
how do you pass it to the inside? You would need to pass an extra
cell (the static link), or alternatively use a trampoline (which you
could put on the locals stack). Moreover, you cannot just restore the
locals-stack pointer on the inside of r[...]r: What if a word is
called there that uses locals itself? It would overwrite the locals
of the higher-order word.
VFX uses a frame pointer, so at least the latter problem does not
exist there. But the issue on how to pass the right value to the
inside of the quotation is still there, and the possible solutions are
the same. Hugh Aguilar's REX saves the frame pointer, and follows the
dynamic link chain for one hop; Therefore it works if there is exactly
one locals definition in the higher-order word. If there are 0 or >1,
it accesses the wrong local.
Anyway, with the static link and trampolines, we could implement this
stuff, but is it worth that cost?
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-07 00:44 -0700 |
| Message-ID | <9138dc77-0e84-4121-8a45-496c618f5a84@googlegroups.com> |
| In reply to | #47898 |
On Monday, June 6, 2016 at 11:59:52 PM UTC-7, Anton Ertl wrote:
> mhx@iae.nl writes:
> >On Monday, June 6, 2016 at 3:25:44 PM UTC+2, Anton Ertl wrote:
> >> : ex { xt } xt execute ;
> >> : foo { x } r[ x . ]r ex ;
> >> cr 5 foo
> >>
> >> should print 5, does print 135006813 on VFX Forth for Linux IA32
> >
> >It looks like it can be made to work if the x[ and ]x
> >words save/restore the locals stackpointer (in case
> >there is one)?
>
> For a system with a locals stack like Gforth, if you save the locals
> stack pointer on the outside of r[...]r, you have the right value, but
> how do you pass it to the inside? You would need to pass an extra
> cell (the static link), or alternatively use a trampoline (which you
> could put on the locals stack). Moreover, you cannot just restore the
> locals-stack pointer on the inside of r[...]r: What if a word is
> called there that uses locals itself? It would overwrite the locals
> of the higher-order word.
>
> VFX uses a frame pointer, so at least the latter problem does not
> exist there. But the issue on how to pass the right value to the
> inside of the quotation is still there, and the possible solutions are
> the same. Hugh Aguilar's REX saves the frame pointer, and follows the
> dynamic link chain for one hop; Therefore it works if there is exactly
> one locals definition in the higher-order word. If there are 0 or >1,
> it accesses the wrong local.
>
> Anyway, with the static link and trampolines, we could implement this
> stuff, but is it worth that cost?
I don't think this is a problem. Just document the restriction and call it a feature.
As a practical matter, you aren't going to have nested HOFs --- I can't think of any circumstance that would call for this.
Also, your HOF is going to have local variables. The HOF almost always traverses a data-structure and executes the quotation for every node. It is going to involve iteration and it is going to have internal data on the stack. You don't want the quotation pointer to be on the stack and have to make a duplicate of it for REX because this would be hugely cumbersome. Almost always, your quotation pointer is going to be in a local variable so it can easily be provided to REX without any stack juggling. So, there you go! The restriction is actually what you were going to do anyway, so it is not restricting you at all. Just document it and don't worry.
If this whole thing seems too restrictive, then use a fat-xt like I did in Stundurd.4th --- this is what I'm going to do in Straight Forth --- what I have here with REX and all that is just a way to provide ANS-Forth with pretty much the same capability super-cheap.
What I have here is adequate to support general-purpose data-structures --- that is the whole point, as far as I'm concerned --- this is also why this will never be accepted by the Forth-200x committee (all committee members were appointed by Elizabeth Rather, who has devoted her entire career to blocking general-purpose code which she says is not the "Forth way").
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-06-07 11:35 -0700 |
| Message-ID | <835657f2-4412-4058-ae3e-2282997f6301@googlegroups.com> |
| In reply to | #47898 |
On Tuesday, June 7, 2016 at 8:59:52 AM UTC+2, Anton Ertl wrote: > mhx@iae.nl writes: > >On Monday, June 6, 2016 at 3:25:44 PM UTC+2, Anton Ertl wrote: [..] > Anyway, with the static link and trampolines, we could implement this > stuff, but is it worth that cost? No, of course not. -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-08 07:14 +0000 |
| Message-ID | <2016Jun8.091440@mips.complang.tuwien.ac.at> |
| In reply to | #47927 |
mhx@iae.nl writes:
>On Tuesday, June 7, 2016 at 8:59:52 AM UTC+2, Anton Ertl wrote:
>> Anyway, with the static link and trampolines, we could implement this
>> stuff, but is it worth that cost?
>
>No, of course not.
At least for now. Maybe in a decade we (well, some of us:-) will be
using higher-level words so much that we will reconsider.
Another implementation approach (often advocated by Bernd Paysan) is
to inline the higher-order word, then constant-propagate the
quotation, and inline that, too. So now you have everything in just
one word, and can access locals just fine (provided you can handle the
multiple locals definitions).
However, I don't think that this is an implementation idea that we can
base a language feature on, because we don't want to outlaw stuff like:
defer how ( ... xt -- ... )
... [: ... ;] how ...
And we cannot use the full inlining approach for that. So we would
have to implement the static link approach as fallback, resulting in
the full complexity cost of that approach (plus the complexity of the
inlining approach, plus the complexity of deciding between the two),
although usually not the run-time cost.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-09 00:58 -0700 |
| Message-ID | <5f5f5cd0-819f-424d-90e9-685851c59b0f@googlegroups.com> |
| In reply to | #47945 |
On Wednesday, June 8, 2016 at 12:23:53 AM UTC-7, Anton Ertl wrote:
> mhx@iae.nl writes:
> >On Tuesday, June 7, 2016 at 8:59:52 AM UTC+2, Anton Ertl wrote:
> >> Anyway, with the static link and trampolines, we could implement this
> >> stuff, but is it worth that cost?
> >
> >No, of course not.
>
> At least for now. Maybe in a decade we (well, some of us:-) will be
> using higher-level words so much that we will reconsider.
LOL
> Another implementation approach (often advocated by Bernd Paysan) is
> to inline the higher-order word, then constant-propagate the
> quotation, and inline that, too. So now you have everything in just
> one word, and can access locals just fine (provided you can handle the
> multiple locals definitions).
This is a hokey technique commonly used in C with #DEFINE because C doesn't support quotations. In the novice-package I have:
macro: each[ \ toucher: i*x node -- j*x
begin dup while
dup .fore @ >r ;
macro: ]each
r> repeat drop ;
This can be used instead of this:
: each ( i*x head 'toucher -- j*x ) \ toucher: i*x node -- j*x
>r
begin dup while \ -- node \r: -- 'toucher
r@ over .fore @ >r \ -- node 'toucher \r: -- 'toucher next
execute r> repeat drop
rdrop ;
\ EACH[...]EACH generates faster-executing code than EACH, and can be more readable, but the code is more bloated.
\ EACH[...]EACH uses the return stack. This can create havoc in functions that use locals or use >R and R>.
\ EACH[...]EACH is mostly only used when speed is important, which largely precludes locals anyway.
\ FIND-NODE and FIND-PRIOR can't be written like this because they both involve an early-out.
\ EACH allows the toucher (the code that touches the node) to be tested on its own, and also to be used on its own.
\ EACH also allows the toucher to use local variables.
\ Both of these advantages can be achieved with EACH[...]EACH by factoring the toucher into a function and calling it.
\ EACH can easily be rewritten in assembly language, which might not be true of EACH[...]EACH.
\ Because of these reasons, EACH should generally be used rather than EACH[...]EACH.
This technique, as shown here with EACH[ ... ]EACH only works in simple cases such as this (a singly-linked list is pretty much the simplest data-structure there is). I didn't provide anything like this in ASSOCIATION.4TH where the data-structure is a LLRB tree and hence WALK> <WALK and WALK are recursive (it might be possible to use this technique, but it would be grossly complicated so I didn't even consider it). This technique really only works in super-simple circumstances --- only a fool would believe that it could be used as a general technique for all data-structures --- typically the fool plans on only using the technique in one simple circumstance (singly linked lists) and then going on the internet declaring himself to be the world's expert on Forth (like Tarzan beating his chest and howling, except that instead of killing a lion with a knife the fool kills a mouse with a shotgun).
Anyway, I'm utterly disgusted by you and Bernd and everybody else involved in Forth-200x --- you are the Committee of Can't --- you just aren't any good at programming, so you turn molehills into mountains. Problems such as you are discussing here I solved in one day several years ago, but you wonder if they might be solved "maybe in a decade" (I put a LOL after your comment earlier, but it is actually not funny at all, but it is really pathetic and embarrassing).
The Forth-200x committee's incompetence is an embarrassment to the entire Forth community --- this is because you are obsessed with displaying your incompetence publicly on the internet --- common sense would indicate that if you don't know how to program in Forth then you should learn in private, rather than declare yourselves to be the leading experts of Forth and qualified to determine what Standard Forth is, and then hope to somehow learn Forth in the process.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-06-09 11:37 +0000 |
| Message-ID | <njbkcn$egb$1@dont-email.me> |
| In reply to | #47945 |
Anton Ertl wrote: > Maybe in a decade we (well, some of us:-) will be > using higher-level words so much that we will reconsider. OCaml: let incr_list n = List.map ((+) n) ;; incr_list 50_000 [2;3;5;8] ;; ===> [50002; 50003; 50005; 50008] -- The former leader of the National Front Jean-Marie Le Pen was fined 30,000 euros for exposing the Jews Holocaust gas chamber hoax. infostormer.com/jean-marie-le-pen-fined-30000-euros-for-exposing-jewish-holocaust-gas-chamber-hoax
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-07 12:37 -0700 |
| Message-ID | <877fe0bxjg.fsf@jester.gateway.pace.com> |
| In reply to | #47898 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Anyway, with the static link and trampolines, we could implement this > stuff, but is it worth that cost? This seems way beyond the simplicity of traditional Forth implementation methods and not likely to fly. I'm also not sure whether the quotation should be able to modify the parent locals (I guess Pascal allows that) or should shadow them like in C++. Overall though, I think people who want to program in Lisp probably should do so directly ;-).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-07 19:03 -0700 |
| Message-ID | <ea57925f-24b2-4361-b1e8-1742dd898a52@googlegroups.com> |
| In reply to | #47933 |
On Tuesday, June 7, 2016 at 12:37:24 PM UTC-7, Paul Rubin wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > > Anyway, with the static link and trampolines, we could implement this > > stuff, but is it worth that cost? > > This seems way beyond the simplicity of traditional Forth implementation > methods and not likely to fly. I'm also not sure whether the quotation > should be able to modify the parent locals (I guess Pascal allows that) > or should shadow them like in C++. Overall though, I think people who > want to program in Lisp probably should do so directly ;-). Of course the quotation needs to modify the parent locals --- the whole point here is that the quotation communicates information back to the parent through the locals. The example I gave was that the quotation counts nodes that meet some criteria and passes this count back to the parent (the parent has a local called CNT that it initializes to zero prior to calling the HOF and which has the count in it after the HOF returns). I don't want to program in Lisp. That is ridiculous! Lisp has serious performance problems due to its use of tagged data (dynamic OOP) and garbage collection. Lisp creates its local-frame on the heap and then GCs it when none of the closures that access it nor the parent function are in scope anymore. This is slowwwwwwwwwwwwww...... The world is full of Lisp-derivative languages such as Ruby, Python, Factor and our own Franck's oForth. I'm not interested in any of these because they all have the performance problems described above. My intention with Straight Forth is that it will provide quotations (using a fat-xt) that provide most of the useful features of closures (it will support general-purpose data-structures) but in a somewhat restricted way (the quotation can only be called so long as the parent function remains in scope), and most importantly that it does this efficiently (it puts the local-frame on the return-stack which is fast and there is no tagged data or GC). This VFX code that I wrote is even more restricted (there can only be one HOF and it must have local variables) but this is the best that I can do in VFX because VFX is a pretty restrictive language. My VFX code (with REX etc.) is useful because it does support general-purpose data-structures, which is the point. Right now I'm porting my ASSOCIATION.4TH from ANS-Forth to VFX, which will be a demonstration of how quotations work. My interest in VFX is just something to do until I have Straight Forth going. I can learn more about quotations using this highly restrictive VFX system and this knowledge might be helpful in putting together Straight Forth. It is unlikely that I will ever buy VFX because it is very expensive, it is only 32-bit, and Stephen Pelc is a Forth-200x committee member which implies that he is profoundly corrupt --- the point of ANS-Forth is to prevent people from writing Forth programs --- Stephen Pelc supports ANS-Forth to prevent competition against MPE, but he himself doesn't program in ANS-Forth because doing so would be stupid. Straight Forth has a 64-bit cell. Numbers are fixed-point 64-bit with a unity of 2^32 for the Fixed version or are IEEE-754 for the Float version. All addresses are 32-bit however, so the system is limited to 4GB (the positive addresses are the dictionary and the negative addresses are the heap). The fat-xt method works well here because the 64-bit xt contains a 32-bit cfa and a 32-bit local-frame pointer. Similarly, a 64-bit string datum contains a 32-bit pointer to the string and a 32-bit count. I consider this thread to be a joke. Elizabeth Rather has devoted her entire career to preventing general-purpose code from being written in Forth. She is not going to give you guys permission to put anything in Forth-200x that supports general-purpose data-structures. She appoints the committee members, including Anton Ertl, Bernd Paysan and Stephen Pelc and they have to do what she or Leon Wagner tell them to do --- they are tools. I just wrote that VFX code (with REX etc.) as a joke! LOL! Certainly, all of the ANS-Forth cult members absolutely hated my ASSOCIATION.4TH written in ANS-Forth in the novice package, so they are also going to hate the upgraded version written in VFX that uses quotations. When this thread is finished, the ANS-Forth cult members will just continue to use PAD which the ANS-Forth document describes as: "a transient region that can be used to hold data for intermediate processing" --- Elizabeth Rather will continue to post code snippets copied directly out of "Starting Forth" and will continue to claim that all the Forth programmers in the world rely entirely on her to teach them Forth --- Anton Ertl will continue to claim that general-purpose data-structures are the Lisp Way but not the Forth Way (and you will continue to parrot him, as you did above).
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-06-02 11:12 -0500 |
| Message-ID | <wbGdnR_TJd5Mx83KnZ2dnUU7-d_NnZ2d@supernews.com> |
| In reply to | #47729 |
Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > >> One problem with this approach is the lifetime of the quotations. >> There's no garbage collection, so we have to put the captured locals > > Who said the parent's locals should be captured? Local variables are > "local" variables. When parent exits, its locals are gone. Simple as > that. If you access local variables of an out of scope definition, > well, think twice, maybe it's your fault, maybe you should do your > things differently. >> (or references to them) somewhere. We could keep them on one of the >> stacks, but we'd have a dangling reference problem. See here: dangling reference problem. Sure, it's not difficult to write something which works this way, but now it's so restrictive as to be not worth having: you can't pass the quotation to a different thread, for example, without doing something to make sure the current word doesn't exit. So, we'd be adding complexity and getting a broken result. IMO, YMMV, etc. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-02 09:42 -0700 |
| Message-ID | <87zir3czkc.fsf@jester.gateway.pace.com> |
| In reply to | #47752 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > See here: dangling reference problem. Sure, it's not difficult to > write something which works this way, but now it's so restrictive as > to be not worth having: you can't pass the quotation to a different > thread, for example, without doing something to make sure the current > word doesn't exit. That would be like C++11 lambda functions, a convenience feature that has been reasonably well received afaict. It's not a vital feature since it does stuff that can straightforwardly also be done with named functions. But there are lots of use cases for it where it makes things come out cleaner. C++ might benefit more from it than Forth would, since C++'s heavyweight syntax makes the cognitive burden of another named function worse than it is in Forth. The situations where you actually want full-blown closures can usually also be handled with OOP, which is built into C++ and which has been implemented many times in Forth using standard primitives.
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web