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
arefarray reference
boolboolean
const constant
elemelement
err error
fh filehandle
funcfunction
hrefhash reference
int integer
interp interpreter
i iterator?
kv key/value
num
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
:
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)
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
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
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
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
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
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:
:
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,
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:
: :
: :
12 matches
Mail list logo
