Re: Dereferencing Syntax (Was: Outer product considered useful)
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 create intermediate variables that make it any easier. For
example, you can say "my $ref = $x{$y}{$z};@$ref" or you can say "local
*ary=$x{$y}{$z};@ary" but the latter isn't that obvious to most, and can
run afoul of strict. In Perl 6:
my @ary := %x{$y}{$z};
should make it much more likely that we'll all use those intermediates.
I also seem to recall something about a ".@" operator that would work
like so:
for %x{$y}{$z}.@ -> $i {...}
No? If everything else is chained on the right for dereferencing, I
certainly see the utility in this. Am I imagining that it was stated
earlier?
What's more that could be:
for *%x{$y}{$z} -> $i {...}
and I can't imagine it makes any sense to bind that * anywhere but:
for *(%x{$y}{$z}) -> $i {...}
I like the division between @ and *, since the two meanings had somewhat
too much overlap in most code.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: Dereferencing Syntax (Was: Outer product considered useful)
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 real
> : array)?
>
> @{EXPR} still works.
Okay, now that that's all cleared up, time to propose something.
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.
I propose that the precedence of the of the dereferencing sigils be
loosened so I don't have to write those pesky squigglies all the time.
What used to be:
for my $i (@{$foo->{bar}[$ind]}) { }
Can now be:
for @$foo{bar}[$ind] -> $i {...}
It doesn't feel quite right, but that's probably because I've written it
the other way so much.
The only reason to keep it around is if you wanted to use the archaic:
@$foo[2];
Or if you wanted to call methods on the array:
@$foo.sort;
But since you can call methods on a reference and get them delegated
anyway, that's not a problem. And as for the first one, well, who needs
that when they can just leave off the @ altogether?
Luke
Re: Dereferencing Syntax (Was: Outer product considered useful)
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
: $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 real
: array)?
@{EXPR} still works.
Larry
Re: Dereferencing Syntax (Was: Outer product considered useful)
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 have a pseudo-filehandle or perhaps a tied one and
> just use C to print?
>
> ln.print @bar.elems;
> print ln : @bar.elems;
>
> Though I'm not sure why a feature like this would be needed at all, so I
> think this is something users should define something like this
> themselves if they want it:
>
> my &say = &print.assuming :ors "\n";
>
> (Wildly guessing syntax here. I cincerely hope parens won't be needed.)
Well I'm sincerely certain that they are.
my &say := &print.assuming(:ors("\n"));
> I think I prefer things the way they happen to already be.
>
> print @bar.elems, "\n";
Ugh. You do!? I think that's the biggest PITA in Perl. I never
thought of "say", but I've been known to write:
sub p { print @_, "\n" }
In some of my more verbose scripts.
It's a sign that something's wrong when on every one-liner I write, and
in even some longer scripts, I specify -l on the command line. C
is indeed shorter than C, and I like that, because I use it more
often.
Will there also be:
sub complain([EMAIL PROTECTED]) {
print $ERR: @_, "\n";
}
:-)
> Also, I think C is a bad choice. Many people use a function called
> C for chat bots and text-to-speech.
Uh huh, but the ones I have experience with use it as a method, so it
doesn't interfere.
$bot.say("Welcome, $user")
Plus, a lot of people use C to create an index, C to find
the length of an array, C to delete files, C to do their
homework, and C to commit suicide (or was that C?). That's
why variables have sigils, and lexicals have scopes...
You even said yourself:
my &say := ...
That works even if C is built-in.
> It will of course be possible to override the builtin, but for a good
> reason most people choose to not do that.
>
> 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 times (contrast with Synposis 3 :-).
Luke
Re: Dereferencing Syntax (Was: Outer product considered useful)
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 similarly should look similarly? I dislike having another method/function/whatever to do exactly the same thing, yet a little different. That is PHP's niche. Can't we instead just have a pseudo-filehandle or perhaps a tied one and just use C to print? ln.print @bar.elems; print ln : @bar.elems; Though I'm not sure why a feature like this would be needed at all, so I think this is something users should define something like this themselves if they want it: my &say = &print.assuming :ors "\n"; (Wildly guessing syntax here. I cincerely hope parens won't be needed.) I think I prefer things the way they happen to already be. print @bar.elems, "\n"; Also, I think C is a bad choice. Many people use a function called C for chat bots and text-to-speech. It will of course be possible to override the builtin, but for a good reason most people choose to not do that. Has this C already been decided? Juerd
Re: Dereferencing Syntax (Was: Outer product considered useful)
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 when you think
> it's clearer. The primary use of * is still to defeat the signature,
> and @$foo doesn't do that.
Okay, good. So this is correct:
my $baz = @foo;
@bar = map { ... } @$baz;
(to be equivalent of mapping over @foo)?
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 real
array)?
Luke
Re: Dereferencing Syntax (Was: Outer product considered useful)
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 auto-newline-appending version of print (without
having to make *all* my prints behave that way via -l), and my Perl
scripts of late often begin with a
sub puts(@) { for (@_) { print "$_\n" } }.
Of course, then I start forgetting my semicolons . . .
-Mark
Re: Dereferencing Syntax (Was: Outer product considered useful)
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 : >context it also happens to defer the signature checking to use the : >interpolated values, that's just an extra bonus. : No! Please, God, no! I like perl, in no small part, because references : are less confusing then pointers. Pointers, in no small part, are : confusing because "*" means both "this is a pointer" (as in "int*"), and : "give me the thingy at" (as in "chr=*str"). : : It seems like this is creating the same confusion. No, the confusion in C is because you never know whether * indicates a single item or the start of a list. In Perl it will only indicate that something should be considered listier than it otherwise would. : >$foo = 0...; # take ref to an infinite range : >@bar = $foo; # puts in the iterator as a reference : > say @bar.elems;# prints 1 : >@bar = *$foo;# puts in 0... : > say @bar.elems;# prints Inf : >@bar = **$foo; # throws exception: "Please install a lot more : >memory" : I hope that Perl will be intelegent enough to notice that the range is : infinite, and say "attempt to flatten infinite list" rather then : "ENOMEM" here. Er, that was a joke... : 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 when you think it's clearer. The primary use of * is still to defeat the signature, and @$foo doesn't do that. : By the way, I like say, but wonder if we're going to become a horrible : mix of APL and PHP. At least we don't have a Unicode alias for say : (yet, why do I suspect we're about to get a unary » operator for it? I will let other people define their own Unicode alias for "say". And I hope it takes them more than three keystrokes to type. :-) And "say" isn't in there because of APL or PHP. It's actually inspired by something worse in Ruby. : Perhaps I'm just pessimistic this morning.) Don't slit your wrists just yet... Larry
Re: Dereferencing Syntax (Was: Outer product considered useful)
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 values, that's just an extra bonus. No! Please, God, no! I like perl, in no small part, because references are less confusing then pointers. Pointers, in no small part, are confusing because "*" means both "this is a pointer" (as in "int*"), and "give me the thingy at" (as in "chr=*str"). It seems like this is creating the same confusion. $foo = 0...;# take ref to an infinite range @bar = $foo;# puts in the iterator as a reference say @bar.elems; # prints 1 @bar = *$foo; # puts in 0... say @bar.elems; # prints Inf @bar = **$foo; # throws exception: "Please install a lot more memory" I hope that Perl will be intelegent enough to notice that the range is infinite, and say "attempt to flatten infinite list" rather then "ENOMEM" here. 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 *.) By the way, I like say, but wonder if we're going to become a horrible mix of APL and PHP. At least we don't have a Unicode alias for say (yet, why do I suspect we're about to get a unary » operator for it? Perhaps I'm just pessimistic this morning.) -=- James Mastros
Re: Dereferencing Syntax (Was: Outer product considered useful)
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. Larry
Re: Dereferencing Syntax (Was: Outer product considered useful)
Larry Wall wrote: say @bar.elems; # prints 1 C? Not C? -- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Dereferencing Syntax (Was: Outer product considered useful)
On Thu, Mar 25, 2004 at 08:42:53AM -0700, Luke Palmer wrote: : Aaron Sherman writes: : > More to the point is there ever a reason to want any array ref in list : > context to NOT explode other than []? I can't think of any. : > : > push @a, $b : > : > Is it too non-obvious that if $b is an array ref, then this is going to : > extend @a by $b.length elements? : : Quite a bit too subtle, yes. While array references are now doing many : of the same things in similar contexts as arrays, flattening in list : context is not one of them. Array references are still different beasts : from arrays. Your push example is one of the reasons why. Yes, things that look like scalars have to stay scalars in list context. : Some time back, Larry said that you had to do: : : push @a, @$b; : : Just like in Perl 5. But this was before * was a unary operator instead : of a context forcing operator. That is, as of A6: : : sub foo(@a, @b, @c, @d, @e); : foo(@a, @b, [EMAIL PROTECTED], @d); # Flatten @c and @d into the parameter list : : But now, it's: : : foo(@a, @b, [EMAIL PROTECTED], @d); # Flatten @c into the parameter list : : So that might mean that push looks like: : : push @a, *$b; 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 values, that's just an extra bonus. However, we'll have to be a little careful about calling it a "flattening" operator, because it isn't exactly... Normal list context only flattens notionally in Perl 6, and the actual flattening is done lazily by default. If you really, truly want it flattened Right Now, you have to use unary ** instead (by analogy to the ** prefix in the declaration, or is it the other way around now?). But usually you want the * semantics such that, if a lazy list is interpolated into the list, it's just another generator in that list. To wit: $foo = 0...;# take ref to an infinite range @bar = $foo;# puts in the iterator as a reference say @bar.elems; # prints 1 @bar = *$foo; # puts in 0... say @bar.elems; # prints Inf @bar = **$foo; # throws exception: "Please install a lot more memory" It seems to be a useful mnemonic that, loosely speaking, ** is always an "exponential" operator, one way or another... :-) Larry
Re: Dereferencing Syntax (Was: Outer product considered useful)
Aaron Sherman writes: > I would expect [] to force itself into scalar context anyway. Is there > ever a reason to want otherwise? Clearly the entire point of [] is to > create a scalar array ref from a list of arguments. > > More to the point is there ever a reason to want any array ref in list > context to NOT explode other than []? I can't think of any. > > push @a, $b > > Is it too non-obvious that if $b is an array ref, then this is going to > extend @a by $b.length elements? Quite a bit too subtle, yes. While array references are now doing many of the same things in similar contexts as arrays, flattening in list context is not one of them. Array references are still different beasts from arrays. Your push example is one of the reasons why. Some time back, Larry said that you had to do: push @a, @$b; Just like in Perl 5. But this was before * was a unary operator instead of a context forcing operator. That is, as of A6: sub foo(@a, @b, @c, @d, @e); foo(@a, @b, [EMAIL PROTECTED], @d); # Flatten @c and @d into the parameter list But now, it's: foo(@a, @b, [EMAIL PROTECTED], @d); # Flatten @c into the parameter list So that might mean that push looks like: push @a, *$b; Luke
Re: Dereferencing Syntax (Was: Outer product considered useful)
On Tue, 2004-03-23 at 13:11, Goplat wrote: > @(...) is the "list context" operator in S3. I hope array references won't > explode in list context, that would be very annoying when making > multi-dimentional arrays: > > @foo = ([1, 2], [3, 4]) # oops, would be (1, 2, 3, 4) > @foo = ($([1, 2]), $([3, 4])) # ugh :( I would expect [] to force itself into scalar context anyway. Is there ever a reason to want otherwise? Clearly the entire point of [] is to create a scalar array ref from a list of arguments. More to the point is there ever a reason to want any array ref in list context to NOT explode other than []? I can't think of any. push @a, $b Is it too non-obvious that if $b is an array ref, then this is going to extend @a by $b.length elements? Pardon my ignorance, but I thought this was the plan. Feel free to correct me if I am wrong. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback signature.asc Description: This is a digitally signed message part
Re: Dereferencing Syntax (Was: Outer product considered useful)
--- Smylers <[EMAIL PROTECTED]> wrote:
> Luke Palmer writes:
>
> > for @(@ranges[1]) -> $i {
>
> Oooh, where did that dereferencing syntax come from, using parens rather
> than braces?
@(...) is the "list context" operator in S3. I hope array references won't
explode in list context, that would be very annoying when making
multi-dimentional arrays:
@foo = ([1, 2], [3, 4]) # oops, would be (1, 2, 3, 4)
@foo = ($([1, 2]), $([3, 4])) # ugh :(
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
Re: Dereferencing Syntax (Was: Outer product considered useful)
Smylers wrote:
Luke Palmer writes:
for @(@ranges[1]) -> $i {
Oooh, where did that dereferencing syntax come from, using parens rather
than braces?
It isn't a dereferencing syntax--it's a context-forcing syntax (one I'm
intimately familiar with), which forces @ranges[1] into list context.
Which shouldn't affect anything. So I think it's probably a mistake.
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
