Larry Wall skribis 2005-04-24 18:50 (-0700):
> [EMAIL PROTECTED] = (1..2:by(0));
[EMAIL PROTECTED] = 1 xx Inf;
[EMAIL PROTECTED] = 1 xx @bar;
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
I image we've all written logging code that looks something like this
(Perl5 syntax):
sub foo {
my ($x,$y) = @_;
note("Entering frobnitz(). params: '$x', '$y'");
...
}
This, of course, throws an 'uninitialized value in concatenation or
string' warning when your test suite
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:
: >:
: >:
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 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:
:
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 id
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 simp
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 ev
> 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
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 r
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
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 iThread
12 matches
Mail list logo