Re: map { $_ => $_ } @foo

2005-04-24 Thread Juerd
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

turning off warnings for a function's params?

2005-04-24 Thread David Storrs
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

Re: map { $_ => $_ } @foo

2005-04-24 Thread Larry Wall
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: : >: : >:

Re: map { $_ => $_ } @foo

2005-04-24 Thread Darren Duncan
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,

Re: map { $_ => $_ } @foo

2005-04-24 Thread Larry Wall
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

2005-04-24 Thread Autrijus Tang
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

Re: Thunking semantics of :=

2005-04-24 Thread Aaron Sherman
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

Re: -X's auto-(un)quoting?

2005-04-24 Thread John Macdonald
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

Re: Lazy Lists + Mutable Arrays + Garbage Collection

2005-04-24 Thread Brad Bowman
> 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: Accepted abbreviations

2005-04-24 Thread Juerd
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

Lazy Lists + Mutable Arrays + Garbage Collection

2005-04-24 Thread Brad Bowman
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

Re: Thunking semantics of :=

2005-04-24 Thread Nigel Sandever
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