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 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-06-03 02:53 -0500 |
| Message-ID | <ktWdncyfpJbiqszKnZ2dnUU7-UHNnZ2d@supernews.com> |
| In reply to | #47754 |
Paul Rubin <no.email@nospam.invalid> wrote: > 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. I haven't used C++ lambdas, but this isn't my impression of how it works: I thought that you only had dangling references to locals if you actually asked for them by using & . To which the simple response is "Don't do that, then." IM(V)HO Java takes a much more sensible approach: locals are captured by value, not reference. But, with C++, in the absence of GC there is still the problem of when to recycle the memory. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-03 23:00 -0700 |
| Message-ID | <87d1nxcx3s.fsf@jester.gateway.pace.com> |
| In reply to | #47785 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > I haven't used C++ lambdas, but this isn't my impression of how it > works: I thought that you only had dangling references to locals if > you actually asked for them by using & . I'm going by this, which of course is unofficial: http://en.cppreference.com/w/cpp/language/lambda It looks to me like the lambda allocates a closure object on the stack, so when the parent returns, the closure is out of scope and calling it is UB.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-06-04 04:37 -0500 |
| Message-ID | <RfidnZOFsujPPM_KnZ2dnUU7-QOdnZ2d@supernews.com> |
| In reply to | #47813 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> I haven't used C++ lambdas, but this isn't my impression of how it >> works: I thought that you only had dangling references to locals if >> you actually asked for them by using & . > > I'm going by this, which of course is unofficial: > > http://en.cppreference.com/w/cpp/language/lambda > > It looks to me like the lambda allocates a closure object on the stack, > so when the parent returns, the closure is out of scope and calling it > is UB. It says "If an entity is captured by reference, implicitly or explicitly, and the function call operator of the closure object is invoked after the entity's lifetime has ended, undefined behavior occurs. The C++ closures do not extend the lifetimes of the captured references." Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-05 19:12 -0700 |
| Message-ID | <87wpm3awv0.fsf@jester.gateway.pace.com> |
| In reply to | #47820 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > It says "If an entity is captured by reference, implicitly or > explicitly, and the function call operator of the closure object is > invoked after the entity's lifetime has ended, undefined behavior > occurs. The C++ closures do not extend the lifetimes of the captured > references." Hmm, so maybe it's ok to call the closure after the parent has returned, if there are no captured reference args. I wonder what happens to parent variables captured by value. I'd have guessed they have to be copied into the closure on every call, but I haven't tried modifying one inside the closure to see what happens across calls.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-05 21:20 -0700 |
| Message-ID | <87shwraqxg.fsf@jester.gateway.pace.com> |
| In reply to | #47854 |
Paul Rubin <no.email@nospam.invalid> writes:
> Hmm, so maybe it's ok to call the closure after the parent has returned,
> if there are no captured reference args.
I just tried modifying a captured-by-value variable inside a C++ lambda
and got a compile time error saying I'd tried to change a read-only
variable. Also, it looks like the value is copied to the closure at the
time the closure is made (changes between calls aren't reflected in the
later calls). So I guess that explains. The code I tested:
#include <iostream>
main() {
int n = 7;
auto clo = [n]() {
std::cout << "n: " << n << "\n";
return 1;
};
clo();
n++;
clo();
}
It prints "n: 7" twice.
I think this is more complicated behaviour than one would expect to find
in Forth.
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2016-06-09 02:55 -0700 |
| Message-ID | <fbf7fb62-85d2-4557-b3da-c4cca01c24d7@googlegroups.com> |
| In reply to | #47855 |
Le lundi 6 juin 2016 06:21:01 UTC+2, Paul Rubin a écrit :
> Paul Rubin <no.email@nospam.invalid> writes:
> > Hmm, so maybe it's ok to call the closure after the parent has returned,
> > if there are no captured reference args.
>
> I just tried modifying a captured-by-value variable inside a C++ lambda
> and got a compile time error saying I'd tried to change a read-only
> variable. Also, it looks like the value is copied to the closure at the
> time the closure is made (changes between calls aren't reflected in the
> later calls). So I guess that explains. The code I tested:
>
> #include <iostream>
>
> main() {
> int n = 7;
> auto clo = [n]() {
> std::cout << "n: " << n << "\n";
> return 1;
> };
> clo();
> n++;
> clo();
> }
>
> It prints "n: 7" twice.
>
> I think this is more complicated behaviour than one would expect to find
> in Forth.
That is how Oforth blocks work (at least for the capture part).
The values are copied at the time the closure is made.
: test1( n -- )
#[ "n:" . n . ] dup perform
n 1+ -> n
perform ;
ok
7 test1
n: 7 n: 7 ok
Some will call this a feature, some will call this a restriction.
In Oforth, as closures are often used to send parameters to another
task running in parallel, this allows to reinforce isolation between
tasks in a multi-threading context : a task can't directly update
another task state.
For instance :
import: parallel
: runTask(n) #[ "n:" . n . ] & ;
: test2 | i | loop: i [ i runTask ] ;
100 test2
ok
>n: 1 n: 2 n: n: n: n: 3 4 6 5 n: n: n: n: 7 8 9 10 n: n: n: n: 11 12 13
14 n: n: n: n:17 16 n: 15 n: 18 20 n: 1921 n: n: 22 23 n: 27 n: n: n: n:25
n: 2926 n: 30 24 28 n: n: 32 n: 31 n: 35 33 n: 38 n: n: n: n: 37 34 36 39
n: n: n: n:42 41 n: n:45 43 n:47 44 n: n: 46 40n: 50 n: 48 n: 4951 n: 53
n: n:55n: n: n: 56 57 54n: n: 58 n: 52 59n: 60 n: 61 n: 62 n: 63 n: 65 n:
66 n:67 64 n:n: 68 n: n: 69n: 71 n: 73 72 n: 75 n: 76 70 n: n: 74 n: 77
n: 78 n: 79 n:n: 83 82 n: 84 n: n: 81 80n: 87 n: 86 n:n:90 85 89 n: 93
n: 88 n: 91 n: 95 n: 92 n: n: n: n: 94 96 97 98 n: n:99 100
ok
Franck
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-09 19:20 -0700 |
| Message-ID | <8c74bf63-a94c-4d3a-bfb4-85306919e495@googlegroups.com> |
| In reply to | #47976 |
On Thursday, June 9, 2016 at 2:56:00 AM UTC-7, franck....@gmail.com wrote:
> Le lundi 6 juin 2016 06:21:01 UTC+2, Paul Rubin a écrit :
> > Paul Rubin <no.email@nospam.invalid> writes:
> > > Hmm, so maybe it's ok to call the closure after the parent has returned,
> > > if there are no captured reference args.
> >
> > I just tried modifying a captured-by-value variable inside a C++ lambda
> > and got a compile time error saying I'd tried to change a read-only
> > variable. Also, it looks like the value is copied to the closure at the
> > time the closure is made (changes between calls aren't reflected in the
> > later calls). So I guess that explains. The code I tested:
> >
> > #include <iostream>
> >
> > main() {
> > int n = 7;
> > auto clo = [n]() {
> > std::cout << "n: " << n << "\n";
> > return 1;
> > };
> > clo();
> > n++;
> > clo();
> > }
> >
> > It prints "n: 7" twice.
> >
> > I think this is more complicated behaviour than one would expect to find
> > in Forth.
>
> That is how Oforth blocks work (at least for the capture part).
> The values are copied at the time the closure is made.
>
> : test1( n -- )
> #[ "n:" . n . ] dup perform
> n 1+ -> n
> perform ;
> ok
> 7 test1
> n: 7 n: 7 ok
>
> Some will call this a feature, some will call this a restriction.
>
> In Oforth, as closures are often used to send parameters to another
> task running in parallel, this allows to reinforce isolation between
> tasks in a multi-threading context : a task can't directly update
> another task state.
Well, your closures have a completely different purpose than supporting general-purpose data-structures. I think that Straight Forth should support multi-threading, but I don't really know much about the subject of multi-threading and I don't yet know how multi-threading will be supported (I'm learning Go from Google to learn about the subject). Quotations won't be used to communicate between tasks --- some other mechanism will be needed.
How does Oforth support general-purpose data-structures? The goal is "information hiding." The application programmer can use a data-structure without knowing how the data-structure is implemented internally. The application program is also simpler because it doesn't have all the code for the data-structure mixed together with the application code.
Here is a quote from Elizabeth Rather:
--------------------------------------
...in Forth it's so easy to build data structures that are exactly right for the particular application at hand that worrying about what pre-built structures you have and how to use them is just not worth the bother.
--------------------------------------
Here is another:
--------------------------------------
Virtually every Forth application needs some kind of array structures. The reason that some general-purpose one might be "little used" is because it's so easy to make a version that does *exactly* what the application needs rather than some generic definition. ... The objective is to master the toolset and be able to think clearly about exactly what kind of arrays will be useful in your application and then build exactly that kind.
--------------------------------------
So, if the application programmer needs a self-balancing tree (an LLRB tree, for example), he needs to "build exactly that kind" in the middle of his application program. Quite a lot of bother! If he later writes another program that also needs a self-balancing tree, he needs to build another one in the middle of that application program (most likely, he will cut-and-paste the code from the first program into the middle of the second program). This makes application programs much more complicated than necessary (LLRB trees are dang complicated and very few people other than Robert Sedgewick can tell you how they work off the top of their head; even with Sedgewick's documents in front of you, the explanation can be something of a minder-binder). All of this complicated code is also a likely source of bugs because it is cut-and-paste between various programs, but it is slightly different in each program (different structs in each program), so it is difficult to verify that it works correctly (it has to be tested and debugged from scratch each time).
How does Oforth avoid the swamp of cut-and-paste programming?
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2016-06-10 07:00 -0700 |
| Message-ID | <4f12ca50-9f6e-4aec-b7dc-dbe3dfb4c311@googlegroups.com> |
| In reply to | #47993 |
Le vendredi 10 juin 2016 04:20:45 UTC+2, hughag...@gmail.com a écrit : > Well, your closures have a completely different purpose than supporting general-purpose data-structures. > How does Oforth support general-purpose data-structures? The goal is "information hiding." I don't understand what is "a closure supporting general purpose data structures". Of course, closures can be sent as parameter to HOF, like any other word (if this is your question). They are not only dedicated to send parameters to tasks in a multi-threading context (did I say that ?). At startup, Oforth has thoses collections already defined : List (or arrays), Interval, Buffer, Stack and String The internal implementation is hidded into those classes. Oforth has many HOF implemented. The most basic HOF is "apply" that applies a word (or a closure) on each element of the collection. For instance : 0 #+ [ 1, 2, 3, 4, 5 ] apply . 15 ok 0 #[ sq + ] [ 1, 2, 3, 4, 5 ] apply . 55 ok : sumSerie( serie n -- f ) 0 #[ serie perform + ] n seq apply ; #[ sq inv ] 1000 sumSerie . 1.64393456668156 ok ( this calculates sum(1/(p^2)) for p = 1 to n) And it is not required for a quotation to be able to update locals of the parent. In fact, it is a choice (and, for oforth, it was an easy choice : no). If you want to count the numbers of elements (or nodes, ...) that meet some criteria, you can write (this HOF already exists) : : count ( t coll -- n ) 0 #[ t perform ifTrue: [ 1+ ] ] coll apply ; #[ between(10, 20) ] [ 1, 2, 12, 50, 13, 3, -5, 17 ] count . 3 ok Franck
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-10 10:00 -0700 |
| Message-ID | <8ea54806-88c9-484a-a2ed-fad7e3feb52a@googlegroups.com> |
| In reply to | #47996 |
On Friday, June 10, 2016 at 7:00:36 AM UTC-7, franck....@gmail.com wrote:
> If you want to count the numbers of elements (or nodes, ...)
> that meet some criteria, you can write (this HOF already exists) :
>
> : count ( t coll -- n )
> 0 #[ t perform ifTrue: [ 1+ ] ] coll apply ;
>
> #[ between(10, 20) ] [ 1, 2, 12, 50, 13, 3, -5, 17 ] count .
> 3 ok
That is pretty much the same as what I have in the novice-package right now. This is why every HOF I have, such as EACH <WALK WALK> WALK etc., pushes its internal data onto the return-stack prior to executing the "toucher" (pseudo-quotation) so the parent function's data on the data-stack will be exposed to the toucher.
Here is WALK> from ASSOCIATION.4TH:
: walk> ( i*x node 'toucher -- j*x ) \ traverses in left-to-right order (alphabetical)
>r
?dup if >r \ -- \r: -- 'toucher node
r@ .left @ rr@ recurse
r@ rr@ execute
r> .rite @ r> recurse
exit then
rdrop ;
Here is CRAWL> which is like WALK> except uses local variables:
: crawl> { node 'toucher depth -- }
\ traverses in left-to-right order (depth should initially be 1)
node if
node .left @ 'toucher depth 1+ recurse
depth node 'toucher execute
node .rite @ 'toucher depth 1+ recurse
then ;
This is also how the Paysan-faked quotations work. AFAIK, the only HOF that Bernd has ever written has been TRAVERSE-WORDLIST --- he trots that one out every time that the issue of quotations is brought up --- I haven't seen the source-code for it, but presumably he pushes all the internal data to the return-stack or stores it in local variables, similar to my HOFs.
This isn't a good technique. For one thing, it makes the HOF slow, and the HOF is iterating through a big data-structure so it should be fast. Also, and more importantly, it makes the quotation complicated especially in cases in which there is more than one data on the data-stack that have to be modified, as all that data has to be put back in place again afterward.
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2016-06-10 10:56 -0700 |
| Message-ID | <a63b7aae-b791-4c16-8d64-af6ceff6d2d3@googlegroups.com> |
| In reply to | #48003 |
Le vendredi 10 juin 2016 19:00:48 UTC+2, hughag...@gmail.com a écrit : >This is why every HOF I have, such as EACH <WALK WALK> WALK etc., pushes its internal data onto the return-stack prior to executing the "toucher" (pseudo-quotation) so the parent function's data on the data-stack will be exposed to the toucher. > imo, this should be a general rule (no matter locals are used or not, no matter parent locals can be updated or not and whatever the price is) : a HOF should not leave something on the stack prior to execute its parameter(s). But, if the quotation can't use locals, things are getting more complicated. > This isn't a good technique. For one thing, it makes the HOF slow, and the HOF is iterating through a big data-structure so it should be fast. Also, and more importantly, it makes the quotation complicated especially in cases in which there is more than one data on the data-stack that have to be modified, as all that data has to be put back in place again afterward. Can you give an example of this ?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-10 17:56 -0700 |
| Message-ID | <40c321b7-9be0-40cb-93df-d6d47026cd5b@googlegroups.com> |
| In reply to | #48005 |
On Friday, June 10, 2016 at 10:56:51 AM UTC-7, franck....@gmail.com wrote: > Le vendredi 10 juin 2016 19:00:48 UTC+2, hughag...@gmail.com a écrit : > > >This is why every HOF I have, such as EACH <WALK WALK> WALK etc., pushes its internal data onto the return-stack prior to executing the "toucher" (pseudo-quotation) so the parent function's data on the data-stack will be exposed to the toucher. > > > > imo, this should be a general rule (no matter locals are used or not, > no matter parent locals can be updated or not and whatever the price is) : > a HOF should not leave something on the stack prior to execute its > parameter(s). > > But, if the quotation can't use locals, things are getting more complicated. In the novice-package the "touchers" are just colon words, and in the Paysan-faked quotations they are :NONAME words --- both of which have their own locals. In both SwiftForth and VFX however, the use of locals kills the speed --- it is better to use >R for speed, although can make for complicated code. > > This isn't a good technique. For one thing, it makes the HOF slow, and the HOF is iterating through a big data-structure so it should be fast. Also, and more importantly, it makes the quotation complicated especially in cases in which there is more than one data on the data-stack that have to be modified, as all that data has to be put back in place again afterward. > > Can you give an example of this ? Well, this doesn't lend itself well to example code that is small enought to be posted on c.l.f. --- my example earlier with counting wasn't very good because there was only one datum (the count) and your 1+ updated it nicely on the stack. I expect that in a real program in which you have a database with a large record containing many fields, allowing the quotation to communicate information back to the parent function via the parent function's locals will simplify the code a lot. About two years ago I started to write a cross-compiler. It used ASSOCIATION.4TH to hold all the code generated as an intermediate step. I never got as far as writing the optimizer, but the idea was to have the optimizer work on this intermediate code. I will port ASSOCIATION.4TH from ANS-Forth to VFX (using REX etc.). I will also port the cross-compiler from ANS-Forth to VFX, which is needed so I can do various other things that have been outlawed in ANS-Forth (for example, smudge dictionary headers). At this time, allowing the quotations to access the parent function's locals will help to simplify the optimizer a lot --- this is my expectation. I think that ANS-Forth is cripple-ware. I have been wasting my time for about a decade in programming in ANS-Forth. If Stephen Pelc doesn't program in ANS-Forth but only programs in VFX-specific Forth, why shouldn't I do the same? I think that ANS-Forth is a trap designed to waste people's time --- as far as Stephen Pelc is concerned, the purpose of ANS-Forth was to prevent Forth programmers from competing against MPE --- ANS-Forth is designed to be useless, and Pelc supports the ANS-Forth cult to keep the Forth community trapped in this pit of useless idiocy and unable to compete against him. Pelc is well aware that ANS-Forth lacks important features, which is why he provides these features in VFX, but he makes no effort to introduce these features into Forth-200x --- he is on the Forth-200x committee, but he just jumped onto the bandwagon for the purpose of dragging his feet --- he wants Forth-200x to be as idiotic as ANS-Forth was, to keep the Forth community trapped in this pit of idiocy that Elizabeth Rather dug for us in 1994. The irony here is that Elizabeth Rather doesn't know that ANS-Forth is cripple-ware. She put all that ambiguity in ANS-Forth because her mind was muddled and she was confused throughout most of the ANS-Forth development process. She wasn't actually trying to corrupt the Standard with ambiguity, but this mess of ambiguity was really her best effort at not being ambiguous. She standardized PAD because she understood how it worked and it seemed useful to her (this was one instance when she wasn't confused and felt that she really understood the subject matter). She doesn't know that Stephen Pelc is playing her for a fool --- he supports her ANS-Forth cult for the purpose of trapping his competition in the pit of idiocy, which he tells them is the Standard for Forth --- he doesn't program in ANS-Forth himself though, because he's not an idiot himself.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-06-14 05:18 -0700 |
| Message-ID | <c3122e60-e672-4695-a73d-4bf8491b3a87@googlegroups.com> |
| In reply to | #48007 |
On Saturday, 11 June 2016 01:56:13 UTC+1, hughag...@gmail.com wrote: > Pelc is well aware that ANS-Forth lacks important features, which is why he provides these features in VFX, but he makes no effort to introduce these features into Forth-200x You'd need another couple of decades to introduce really useful stuff like serial comms and bluetooth and TCP/IP. Best to let them go obsolete *first* then we can argue about not standardising them and go off and do our own implementations.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-26 16:12 -0700 |
| Message-ID | <9568077e-0c8d-4a8a-bdd3-6614f74d36b5@googlegroups.com> |
| In reply to | #48138 |
On Tuesday, June 14, 2016 at 5:18:21 AM UTC-7, Mark Wills wrote: > On Saturday, 11 June 2016 01:56:13 UTC+1, hughag...@gmail.com wrote: > > Pelc is well aware that ANS-Forth lacks important features, which is why he provides these features in VFX, but he makes no effort to introduce these features into Forth-200x > > You'd need another couple of decades to introduce really useful stuff like > serial comms and bluetooth and TCP/IP. Best to let them go obsolete *first* > then we can argue about not standardising them and go off and do our own > implementations. I'm not suggesting that such high-level features as TCP/IP and BlueTooth should be part of the Standard --- these would obviously be extension code-libraries --- in Straight Forth I'm focusing on making the language small (about half the size of ANS-Forth), but in making it a solid base for writing these code-libraries (programming in ANS-Forth is like founding a house upon sand and for mortar you use slime).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-02 12:41 -0700 |
| Message-ID | <076e5487-0f97-4d7a-9109-d99c2c748f13@googlegroups.com> |
| In reply to | #47729 |
On Thursday, June 2, 2016 at 5:08:40 AM UTC-7, Raimond Dragomir 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. > > The trend is to name these "local variables" differently. Lua name them > somehow but I don't remember how. The idea is "local variables" are > exactly that, and "local" variables that may be captured by a quotation > are a completely different thing. > > > them. Neither of these strikes me as a good idea. Also, we'd need a > > mechanism which allows access to captured locals as well as locals > > declared in a quotation. All of this turns a simple and useful > > proposal into a sprawling mess, IMO. > > The mechanism is so simple and easy to implement... Did you hear about frame pointers? Raimond and I independently invented the "local-fall-through" idea --- LFTforth. Now HumptyDumpty has also independently invented it (or maybe he read my post on c.l.f. previously in which I described it) --- or maybe the idea is just so obvious that any reasonably intelligent programmer who thinks about the issue for 5 minutes will independently invent it.
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-06-02 13:03 -0700 |
| Message-ID | <07033820-07d1-45e9-8e88-43669bff9f16@googlegroups.com> |
| In reply to | #47758 |
On Thursday, June 2, 2016 at 10:41:16 PM UTC+3, hughag...@gmail.com wrote: > On Thursday, June 2, 2016 at 5:08:40 AM UTC-7, Raimond Dragomir 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. > > > > The trend is to name these "local variables" differently. Lua name them > > somehow but I don't remember how. The idea is "local variables" are > > exactly that, and "local" variables that may be captured by a quotation > > are a completely different thing. > > > > > them. Neither of these strikes me as a good idea. Also, we'd need a > > > mechanism which allows access to captured locals as well as locals > > > declared in a quotation. All of this turns a simple and useful > > > proposal into a sprawling mess, IMO. > > > > The mechanism is so simple and easy to implement... Did you hear about frame pointers? > > Raimond and I independently invented the "local-fall-through" idea --- LFTforth. Now HumptyDumpty has also independently invented it (or maybe he read my post on c.l.f. previously in which I described it) --- or maybe the idea is just so obvious that any reasonably intelligent programmer who thinks about the issue for 5 minutes will independently invent it. Hi! It was an extension of thinking about continuations. I posted here in c.l.f examples of loop using continuations, like: : continuation R@ ; : forever ( just for fun now :) continuation >R ( loop body ) R@ ; and go 'forever' :) Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-02 13:37 +0000 |
| Message-ID | <2016Jun2.153709@mips.complang.tuwien.ac.at> |
| In reply to | #47725 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>HAA <someone@microsoft.com> wrote:
>> Anton Ertl wrote:
>>> ...
>>> That's why the discussion about locals in quotations has settled on
>>> standardizing only accessing locals from a quotation that were defined
>>> in that quotation;
>>
>> Usefulness and efficiency - not ease of implementation - should be
>> the goal.
Conservative Forth circles have questioned both the usefulness of
locals and the usefulness of quotations. A version of quotations that
is hard to implement because of locals is going to be a hard sell in
these circles.
But there is a way to get more than just opinions on this: Advocates
of access to outer locals present useful and efficient examples of
using outer locals, and advocates of inner-locals-only can then
demonstrate what it takes to achieve the same without outer locals.
>And there is no point when we already have a perfectly good mechanism
>for capturing data already: the stack.
We have looked at some examples, and if you combine several
higher-order words, each having additional stack arguments, it was
pretty surprising to me which stack item becomes which parameter of
which higher-order word. Maybe easier to grok with more exercise, but
not really something I would recommend.
>Locals seemed to be a good
>idea at the time, but like many language features a multiplying effect
>causes burgeoning complexity when combined with other language
>features such as quotations.
If you limit locals to be really local (to the quotation or
definition, but no contained quotations), there is little additional
complexity, but also little additional benefit.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-06-08 04:33 -0500 |
| Message-ID | <ku2dnVzK9I_Ce8rKnZ2dnUU7-eNj4p2d@supernews.com> |
| In reply to | #47734 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>Locals seemed to be a good idea at the time, but like many language >>features a multiplying effect causes burgeoning complexity when >>combined with other language features such as quotations. > > If you limit locals to be really local (to the quotation or > definition, but no contained quotations), there is little additional > complexity, but also little additional benefit. Sorry to come back to this, but I realize that I didn't understand it at the time. Additional to what? Could you expand a little? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-08 09:39 +0000 |
| Message-ID | <2016Jun8.113945@mips.complang.tuwien.ac.at> |
| In reply to | #47947 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>
>>>Locals seemed to be a good idea at the time, but like many language
>>>features a multiplying effect causes burgeoning complexity when
>>>combined with other language features such as quotations.
>>
>> If you limit locals to be really local (to the quotation or
>> definition, but no contained quotations), there is little additional
>> complexity, but also little additional benefit.
>
>Sorry to come back to this, but I realize that I didn't understand it
>at the time. Additional to what?
Compared to imnplementing quotations in a locals-unaware way plus
implementing locals in a quotation-unaware way. You probably could
get away with 0 additional complexity, and if the user goes there and
hurts himself, tell them not to do that, but in the current Gforth
implementations of locals we added a little complexity to make outer
locals invisible inside quotations.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-06-08 05:53 -0500 |
| Message-ID | <GqednZP9q7W5ZMrKnZ2dnUU7-R_NnZ2d@supernews.com> |
| In reply to | #47948 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> >>>>Locals seemed to be a good idea at the time, but like many language >>>>features a multiplying effect causes burgeoning complexity when >>>>combined with other language features such as quotations. >>> >>> If you limit locals to be really local (to the quotation or >>> definition, but no contained quotations), there is little additional >>> complexity, but also little additional benefit. >> >>Sorry to come back to this, but I realize that I didn't understand it >>at the time. Additional to what? > > Compared to imnplementing quotations in a locals-unaware way plus > implementing locals in a quotation-unaware way. You probably could > get away with 0 additional complexity, and if the user goes there > and hurts himself, tell them not to do that, but in the current > Gforth implementations of locals we added a little complexity to > make outer locals invisible inside quotations. I see. Even implementing quotations in a locals-unaware way is going to be tricky in something like SwiftForth because you (at a bare minimum) have to tell the compiler to create and destroy a new locals context. I wasn't aware that there might be a way to implement quotations without doing that. Or by "locals unaware" did you mean that quotations don't have their own locals? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-08 11:30 +0000 |
| Message-ID | <2016Jun8.133054@mips.complang.tuwien.ac.at> |
| In reply to | #47950 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>I see. Even implementing quotations in a locals-unaware way is going
>to be tricky in something like SwiftForth because you (at a bare
>minimum) have to tell the compiler to create and destroy a new locals
>context. I wasn't aware that there might be a way to implement
>quotations without doing that.
>
>Or by "locals unaware" did you mean that quotations don't have their
>own locals?
Well, it's not what I really meant, but I did think about it when I
wrote the posting. Purely local locals in quotations buy little, so
if there are systems where leaving them away would make implementation
simpler, leaving them away is certainly something we should consider.
- 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]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web