Re: for all(@foo) {...}
No, S03 is probably just wrong there. Junctions are scalar values, and
don't flatten in list context. Maybe we need something like:
for =all(@foo) {...}
to iterate the junction.
for all(1,2,3).values { say $_; }
reads nicely and works in pugs.
Also, flattening may get messy with nested junctions.
for any(1,2,3) {...}
then it would have done the next, because 1 2.
Confused myself there. Thanks.
=none(1,2,3) should return a list of all the things that aren't 1, 2,
or 3 in random order. Maybe a lazy implementation will be beneficial
at that point. :-)
none() outside of boolean context is lazily evaluated by my brain.
My eyes glaze over and I think about something else.
Brad
--
When one is not capable of true intelligence, it is good to consult with
someone of good sense. -- Hagakure http://bereft.net/hagakure/
Re: Accepted abbreviations
arefarray reference boolboolean const constant elemelement err error fh filehandle funcfunction hrefhash reference int integer interp interpreter i iterator? kv key/value num number obj object op operator, operation r read(able) ref reference regex regular expression expr expression rw read/write ro read-only str string sub subroutine w write(able) in input out output io input/output mem memory os operating system anon anonymous interestingly, among references there are aref and href, but scalar and subroutine references are not presented. Vadim
Re: Thunking semantics of :=
On Sat, 23 Apr 2005 21:00:11 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: On Sun, Apr 24, 2005 at 03:37:23AM +, Nigel Sandever wrote: : On Sun, 24 Apr 2005 03:47:42 +0800, [EMAIL PROTECTED] (Autrijus Tang) wrote: : : Oh well. At least the same code can be salvaged to make iThreads : : Please. No iThreads behaviour in Perl 6. : : Nobody uses them and whilst stable, the implementation is broken in so many way. : : But worse, the underlying semantics are completely and utterly wrong. Are you confusing iThreads with pThreads? Or are you recommending we go back to the pThreads fiasco? I certainly am not advocating a shared-by-default, or everything-shared model. From what I've read, the trend in most modern implementations of concurrency is away from shared state by default, essentially because shared memory simply doesn't scale up well enough in hardware, and coordinating shared state is not terribly efficient without shared memory. If you are claiming that modern computer scientists are completely and utterly wrong in moving that direction, well, that's your privilege. But you should be prepared for a little pushback on that subject, especially as you are merely badmouthing something without goodmouthing something else in it's place. When I said iThreads, I was referring to the only defenition I can find for iThreads, the Perl 5.8.x implementation. The broken underlying semantics are 1) The fork-like, duplicate-everything-in-the-process-at-the-point-of-spawn. This makes spawning a thread heavier than starting a process in many cases. It makes using (the p5 implementation of) iThreads an exercise in frustration trying to avoid the semantics it imposes. 2) The shared-memory is really multiple-copies-with-ties. This removes 90% of the benefits of shared-memory, whilst doing nothing to make it easier to use. The user is still responsible for locking and synchronisation, but looses the ability to use either ties or object-semantics to encapsulate it. That forces every programmer to re-invent the techniques in every program as it is nearly impossible to write clean, effcient apis and put them into modules. The duplication and tied-updates makes using shared memory so slow and clumsy, that it can be quicker to freeze/transmit-via-socket/thaw shared data between processes, than to share a piece of memory within a process. 3) Using the low-level pthreads api as the basis for the user view of threading. This precludes the use of native thread features on any platform that has extended or better api, and forces the programmer to deal with the ultra-low- level at which that API is defined without any of the control that he would have if using it directly. Larry njs.
Lazy Lists + Mutable Arrays + Garbage Collection
Hi,
I've been wondering how to lazy lists will work.
The answer Correctly, don't worry about it, is entirely acceptable...
The intent of this example in S06 seems clear, make @oddsquares
a lazily filled array of squares of odd @nums:
S06/Pipe operators
It [==] binds the (potentially lazy) list from the blunt end
to the slurpy parameter(s) of the subroutine on the sharp end.
[...]
If the operand on the sharp end of a pipe is not a call to a
variadic operation, it must be a variable, in which case the
list value is assigned to the variable. This special case
allows for pure processing chains:
@oddsquares == map { $_**2 } == sort == grep { $_ % 2 } == @nums;
So @oddsquares is like a stream of values derived from @nums. (is it?)
Then presumably I can make a @primesquares stream:
my (@ints, @primesquares);
@ints == 2...;
@primesquares == map { $_**2 } == grep { is_prime($_) } == @ints;
say @primesquares[3];
Can I then treat @primesquares like an array, say by swapping
two elements? How about @ints?
If these arrays can be be mutated then how can they be garbage
collected? All the non-prime @ints could be still hanging around
while either array is in scope.
With cons based lists, past stream values are no longer referred to
so can be reclaimed, but we have random access arrays.
That's about where my wondering stopped.
Brad
I always get nervous when this sig appears randomly...
--
There are times when a person gets carried away and talks on without
thinking too much. But this can be seen by observers when one's mind is
flippant and lacking truth. -- Hagakure http://bereft.net/hagakure/
Re: Accepted abbreviations
konovalo skribis 2005-04-24 10:24 (+0400): interp interpreter I don't recall having seen that used. i iterator? Used as such, but I think discouraging i in favour of iter is a better idea, because i is also often used as index. anon anonymous Is this used? interestingly, among references there are aref and href, but scalar and subroutine references are not presented. Because I have never seen them used as singleletterref yet. Probably because sref would be highly ambiguous. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Lazy Lists + Mutable Arrays + Garbage Collection
With cons based lists, past stream values are no longer referred to so can be reclaimed, but we have random access arrays. That's about where my wondering stopped. It started again. @primesquares.shift would do it Brad
Re: -X's auto-(un)quoting?
On Saturday 23 April 2005 14:19, Juerd wrote: Mark A. Biggar skribis 2005-04-23 10:55 (-0700): After some further thought (and a phone talk with Larry), I now think that all of these counted-level solutions (even my proposal of _2.foo(), etc.) are a bad idea. In that case, why even have OUTER::? Referring to something by relative position is great when refactoring will not change the relationship. If you refactor the enclosing context, whatever context is wrapped around me is changed by refactoring in the right way; while that specific thing that is 2 levels out (at the time I wrote this code) is changed in the wrong way, because the specific context you want to refer to may now be 1 or 3 or 50 levels out.
Re: Thunking semantics of :=
On Sun, 2005-04-24 at 07:51 +, Nigel Sandever wrote: On Sat, 23 Apr 2005 21:00:11 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: From what I've read, the trend in most modern implementations of concurrency is away from shared state by default, essentially because shared memory simply doesn't scale up well enough in hardware, and coordinating shared state is not terribly efficient without shared memory. Keep in mind that, these considerations aside, Parrot is implementing an interpreter-per-thread model, so much of the debate for P6-on-Parrot is moot. http://groups-beta.google.com/group/perl.perl6.internals/msg/18b86bff49cac5a0?dmode=source We'd decided that each thread has its own interpreter. Parrot doesn't get any lighter-weight than an interpreter, since trying to have multiple threads of control share an interpreter seems to be a good way to die a horrible death. -Dan Sugalski / 14 Apr 2005 When I said iThreads, I was referring to the only defenition I can find for iThreads, the Perl 5.8.x implementation. The broken underlying semantics are 1) The fork-like, duplicate-everything-in-the-process-at-the-point-of-spawn. This makes spawning a thread heavier than starting a process in many cases. It makes using (the p5 implementation of) iThreads an exercise in frustration trying to avoid the semantics it imposes. Keep in mind that for Parrot, this won't be as big a deal. It will mean that thread-creation will probably stomp all over the gains in performance that the JIT gives you, but that irons itself out over time (so again, long-lived threads are more efficient than short-lived ones). 2) The shared-memory is really multiple-copies-with-ties. This removes 90% of the benefits of shared-memory, whilst doing nothing to make it easier to use. Again, given Parrot this is not as big a deal. tying is just a matter of adding vtable entries, and one layer of PMC indirection is not a huge hit. It does mean that shared access to low-level types (int, str, etc) will preclude their being implemented as truly low-level types (i.e. they will be PMCs, not int, str, etc. in Parrot). However, I can't really imagine a sane shared-access scheme that would not take this hit. That forces every programmer to re-invent the techniques in every program as it is nearly impossible to write clean, effcient apis and put them into modules. Again, I think letting Parrot (or whatever underlies your given P6 implementation) do a lot of this work for you allows you, once again, to do the right thing. The duplication and tied-updates makes using shared memory so slow and clumsy, that it can be quicker to freeze/transmit-via-socket/thaw shared data between processes, than to share a piece of memory within a process. Again, I doubt you'll see the same behavior on top of Parrot. Then again, this is arm-waving, and I don't know what state threading is in in the Parrot world. 3) Using the low-level pthreads api as the basis for the user view of threading. This precludes the use of native thread features on any platform that has extended or better api, and forces the programmer to deal with the ultra-low- level at which that API is defined without any of the control that he would have if using it directly. Hopefully we can abstract that away a bit, and presumably you could always write a Parrot module to provide some native semantics for threading, but that would require some deep Parrot spelunking.
map { $_ = $_ } @foo
A while ago I posted a conflict between a block containing a pair
constructor, vs. a hash constructor:
map { $_ = $_ } @foo;
Larry suggested that to keep it from being collapsed, we somehow
augment toplevel AST:
map { $_ = $_; } @foo;
map { +($_ = $_) } @foo;
But here is a new idea: Since the parser knows that the bare block is
followed by no trailing comma, how about we using it as a disambiguating
device, and define that it never collapses?
map { $_ = $_ } @foo; # closure
map { $_ = $_ }, @foo; # hash
And maybe it can be extended over adverbial blocks, too:
@foo.map:{ $_ = $_ }; # closure
Also as control structure body, just for consistency's sake:
for @foo { $^x = $^y };
Is it a sane approach? I have just tentatively implemented it as r2305
if people would like to experiment with this proposal.
Thanks,
/Autrijus/
pgpGr0w8m9W9k.pgp
Description: PGP signature
Re: map { $_ = $_ } @foo
On Mon, Apr 25, 2005 at 02:13:26AM +0800, Autrijus Tang wrote:
: A while ago I posted a conflict between a block containing a pair
: constructor, vs. a hash constructor:
:
: map { $_ = $_ } @foo;
:
: Larry suggested that to keep it from being collapsed, we somehow
: augment toplevel AST:
:
: map { $_ = $_; } @foo;
: map { +($_ = $_) } @foo;
Uh, I'm not sure what + would return for a Pair, but I'm pretty sure it's
not a pair. A little P5ism sneaking in there? :-)
: But here is a new idea: Since the parser knows that the bare block is
: followed by no trailing comma, how about we using it as a disambiguating
: device, and define that it never collapses?
:
: map { $_ = $_ } @foo; # closure
: map { $_ = $_ }, @foo; # hash
A block can be arbitrarily long. I worry about disambiguating it by
something could come lines later. It's the /x problem all over again.
Plus, I think many folks would rather think of the closure comma as
optional rather than mandatorily missing. Besides, if they can't
keep the {...} straight, they're not gonna keep the comma straight either.
: And maybe it can be extended over adverbial blocks, too:
:
: @foo.map:{ $_ = $_ }; # closure
:
: Also as control structure body, just for consistency's sake:
:
: for @foo { $^x = $^y };
:
: Is it a sane approach? I have just tentatively implemented it as r2305
: if people would like to experiment with this proposal.
I really think for clarity it has to be disambiguated by either
something syntactic on the front or something semantic at the top level.
It's probably pretty easy to catch the error of saying
map { $_ = $_ } @foo;
when you mean
map { hash $_ = $_ } @foo;
or
map { list $_ = $_ } @foo;
because map wants a closure as its first argument, not a hash. I still
kinda like the rule that it's a hash if the top-level looks like some
kind of list of pairs. It optimizes for the common case. Closures
returning pairs are a rarity.
Larry
Re: map { $_ = $_ } @foo
At 4:39 PM -0700 4/24/05, Larry Wall wrote:
On Mon, Apr 25, 2005 at 02:13:26AM +0800, Autrijus Tang wrote:
: A while ago I posted a conflict between a block containing a pair
: constructor, vs. a hash constructor:
:
: map { $_ = $_ } @foo;
: And maybe it can be extended over adverbial blocks, too:
:
: @foo.map:{ $_ = $_ }; # closure
Why not just always use the ':' when you are giving a block. The
block is essentially an adverb for a map|grep|sort anyway. Whereas,
no ':' means its a hash-ref. (Presumably each of map|grep|sort will
have a reasonable default adverb if no ':{}' is given.)
I really think for clarity it has to be disambiguated by either
something syntactic on the front or something semantic at the top level.
I agree. See my previous paragraph for an example.
I still
kinda like the rule that it's a hash if the top-level looks like some
kind of list of pairs. It optimizes for the common case.
I agree.
Closures
returning pairs are a rarity.
Larry
This is beside the point but ...
Perhaps one of the new Perl 6 features makes this unnecessary, but I
often found myself doing just that when I wanted an effective method
to test multiple times if an element is in an array, like this:
my %foo = map:{ ( $_ = 1 ) } @bar;
if( %foo{'abc'} ) ...
if( %foo{'def'} ) ...
if( %foo{'zrs'} ) ...
That closure is returning a pair for each array element.
-- Darren Duncan
Re: map { $_ = $_ } @foo
On Sun, Apr 24, 2005 at 06:14:35PM -0700, Darren Duncan wrote:
: At 4:39 PM -0700 4/24/05, Larry Wall wrote:
: On Mon, Apr 25, 2005 at 02:13:26AM +0800, Autrijus Tang wrote:
: : A while ago I posted a conflict between a block containing a pair
: : constructor, vs. a hash constructor:
: :
: : map { $_ = $_ } @foo;
:
: : And maybe it can be extended over adverbial blocks, too:
: :
: : @foo.map:{ $_ = $_ }; # closure
:
: Why not just always use the ':' when you are giving a block. The
: block is essentially an adverb for a map|grep|sort anyway. Whereas,
: no ':' means its a hash-ref. (Presumably each of map|grep|sort will
: have a reasonable default adverb if no ':{}' is given.)
There are lots of blocks that shouldn't take colons.
: I really think for clarity it has to be disambiguated by either
: something syntactic on the front or something semantic at the top level.
:
: I agree. See my previous paragraph for an example.
:
: I still
: kinda like the rule that it's a hash if the top-level looks like some
: kind of list of pairs. It optimizes for the common case.
:
: I agree.
:
: Closures
: returning pairs are a rarity.
: Larry
:
: This is beside the point but ...
:
: Perhaps one of the new Perl 6 features makes this unnecessary, but I
: often found myself doing just that when I wanted an effective method
: to test multiple times if an element is in an array, like this:
:
: my %foo = map:{ ( $_ = 1 ) } @bar;
: if( %foo{'abc'} ) ...
: if( %foo{'def'} ) ...
: if( %foo{'zrs'} ) ...
:
: That closure is returning a pair for each array element.
How 'bout:
[EMAIL PROTECTED] »=« 1;
That seems a lot clearer to me. If you don't like hyper, how about
[EMAIL PROTECTED] = (1..2:by(0));
:-)
Larry
