Re: Dereferencing Syntax (Was: Outer product considered useful)

2004-03-26 Thread James Mastros
Larry Wall wrote: Yes, * was originally a no-op in list context, but I think now we can use it to deref a list that would otherwise not interpolate itself. It maps better onto how a C programmer thinks, and if in scalar context it also happens to defer the signature checking to use the interpolated

Re: Dereferencing Syntax (Was: Outer product considered useful)

2004-03-26 Thread Larry Wall
On Fri, Mar 26, 2004 at 08:59:36AM +0100, James Mastros wrote: : Larry Wall wrote: : >Yes, * was originally a no-op in list context, but I think now we can : >use it to deref a list that would otherwise not interpolate itself. : >It maps better onto how a C programmer thinks, and if in scalar : >co

Re: Dereferencing Syntax (Was: Outer product considered useful)

2004-03-26 Thread Mark J. Reed
On 2004-03-26 at 08:16:07, Larry Wall wrote: > And "say" isn't in there because of APL or PHP. It's actually inspired > by something worse in Ruby. Presumably by "something worse" you mean "puts"? Not a great name, to be sure, but it does have a venerable tradition behind it. :) I do like ha

Re: Dereferencing Syntax (Was: Outer product considered useful)

2004-03-26 Thread Luke Palmer
Larry Wall writes: > : Also, how does the use of *$foo differ from @$foo here? Is the later > : going away? (I'd think that horrible, for the same reason as above: C > : is confusing because it's not always clear what you get when you *.) > > No, @$foo is not going away. You can write it that

Re: Dereferencing Syntax (Was: Outer product considered useful)

2004-03-26 Thread Juerd
Larry Wall skribis 2004-03-25 12:33 (-0800): > On Thu, Mar 25, 2004 at 11:35:46AM -0800, Brent 'Dax' Royal-Gordon wrote: > : Larry Wall wrote: > : > say @bar.elems; # prints 1 > : C? Not C? > It's just a "println" spelled Huffmanly. What happened to the principle that things that work

Re: Dereferencing Syntax (Was: Outer product considered useful)

2004-03-26 Thread Luke Palmer
Juerd writes: > Larry Wall skribis 2004-03-25 12:33 (-0800): > > On Thu, Mar 25, 2004 at 11:35:46AM -0800, Brent 'Dax' Royal-Gordon wrote: > > : Larry Wall wrote: > > : > say @bar.elems;# prints 1 > > : C? Not C? > > It's just a "println" spelled Huffmanly. > > Can't we instead just hav

Re: Dereferencing Syntax (Was: Outer product considered useful)

2004-03-26 Thread Larry Wall
On Fri, Mar 26, 2004 at 09:41:23AM -0700, Luke Palmer wrote: : Okay, good. So this is correct: : : my $baz = @foo; : @bar = map { ... } @$baz; : : (to be equivalent of mapping over @foo)? Yes, that's correct. : Is @{$foo} going away? More specifically, how do I write that map if : $ba

Re: Dereferencing Syntax (Was: Outer product considered useful)

2004-03-26 Thread Luke Palmer
Larry Wall writes: > On Fri, Mar 26, 2004 at 09:41:23AM -0700, Luke Palmer wrote: > : Is @{$foo} going away? More specifically, how do I write that map if > : $baz is some more complex expression, and I don't want to use * (say I > : want to adhere if map decides to change its signature to take a

Re: Dereferencing Syntax (Was: Outer product considered useful)

2004-03-26 Thread Aaron Sherman
On Fri, 2004-03-26 at 15:20, Luke Palmer wrote: > When writing Perl 5, I always find myself writing @{ more often than @$. > Maybe it's just a bad habit that I don't tend to use a lot of > intermediate variables. Well, one of the big problems with Perl 5's dereferencing is that it's painful to cr

New functions in the core (Was Re: Dereferencing Syntax)

2004-03-26 Thread Joe Gottman
- Original Message - From: "Luke Palmer" <[EMAIL PROTECTED]> > Juerd writes: > > Has this C already been decided? > > Doesn't matter, because most of these decisions are up for discussion. > I think everything that was "decided" when Apocalypse 3 was written has > changed at least three

Re: New functions in the core (Was Re: Dereferencing Syntax)

2004-03-26 Thread Simon Cozens
[EMAIL PROTECTED] (Joe Gottman) writes: > This function would be very useful in inner loops, so if it is possible to > implement it more efficiently in the core than as a sub in a module I think > we should do so. And, if it's possible to implement it more efficiently in the core than as a sub in