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

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 :

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 having an

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 way

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 : Csay? Not Cprint? 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 : Csay? Not Cprint? It's just a println spelled Huffmanly. Can't we instead just have a

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 :

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

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 Csay 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 times

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 a