Damian Conway [EMAIL PROTECTED] writes:
Incidentally, the table of C=~ comparisons (Table 1) at:
http://dev.perl.org/perl6/apocalypse/4
suggests that hash/hash matching is equivalent to:
match if grep exists $a{$_}, $b.keys
I hope to convince Larry that it would be better if
At 2:33 PM +0100 4/7/02, Piers Cawley wrote:
Jonathan E. Paton [EMAIL PROTECTED] writes:
but wait, there's more... what does:
@multi_dim[$a][$b][$c]
give?
Who cares? So long as the intermediate results in
@multi_dim.[$a].[$b].[$c] respond to [].
Hrm. Will they need to? That could
but wait, there's more... what does:
multi_dim[$a][$b][$c]
give?
Who cares? So long as the intermediate results in
multi_dim.[$a].[$b].[$c] respond to [].
Hrm. Will they need to? That could arguably pass a three
element key ($a,$b,$c) to multi_dim which, conveniently
being
Dan Sugalski [EMAIL PROTECTED] writes:
At 2:33 PM +0100 4/7/02, Piers Cawley wrote:
Jonathan E. Paton [EMAIL PROTECTED] writes:
but wait, there's more... what does:
@multi_dim[$a][$b][$c]
give?
Who cares? So long as the intermediate results in
@multi_dim.[$a].[$b].[$c] respond to [].
On Mon, 2002-04-08 at 13:01, Jonathan E. Paton wrote:
I'm I beating this point to death, or do I have to write
the RPC:
Keep the {} and [] notation for hashes and arrays
or
Save our array!
Let's boil this RFC down to one short phrase:
If {} goes away in Perl6, then everything you've
Aaron Sherman [EMAIL PROTECTED] writes:
On Mon, 2002-04-08 at 13:01, Jonathan E. Paton wrote:
I'm I beating this point to death, or do I have to write
the RPC:
Keep the {} and [] notation for hashes and arrays
or
Save our array!
Let's boil this RFC down to one short phrase:
If
I'm I beating this point to death, or do I have to write
the RPC:
Keep the {} and [] notation for hashes and arrays
or
Save our array!
Let's boil this RFC down to one short phrase:
If {} goes away in Perl6, then everything you've heard
about Perl6 being not really all
On Mon, Apr 08, 2002 at 02:50:55PM -0400, Aaron Sherman wrote:
Also, just wondering:
$_[_][EMAIL PROTECTED] _=_0_-_
does that work the way I expect it to?
Well, my internal Perl 6 parser hadn't been used all that much, but if
you expect this to be a syntax error, then I think you're
On Mon, Apr 08, 2002 at 07:56:11PM +0100, Piers Cawley wrote:
Also, just wondering:
$_[_][EMAIL PROTECTED] _=_0_-_
does that work the way I expect it to?
Dunno, what do you expect it to do?. To my way of thinking there's
going to be a syntax error at the third '_'. But I'm not
Mark J. Reed [EMAIL PROTECTED] writes:
On Mon, Apr 08, 2002 at 07:56:11PM +0100, Piers Cawley wrote:
Also, just wondering:
$_[_][EMAIL PROTECTED] _=_0_-_
does that work the way I expect it to?
Dunno, what do you expect it to do?. To my way of thinking there's
going to be a
On Mon, 2002-04-08 at 14:56, Piers Cawley wrote:
Aaron Sherman [EMAIL PROTECTED] writes:
Also, just wondering:
$_[_][EMAIL PROTECTED] _=_0_-_
does that work the way I expect it to?
Dunno, what do you expect it to do?. To my way of thinking there's
going to be a syntax error at
On Mon, 2002-04-08 at 15:09, Mark J. Reed wrote:
On Mon, Apr 08, 2002 at 07:56:11PM +0100, Piers Cawley wrote:
Also, just wondering:
$_[_][EMAIL PROTECTED] _=_0_-_
does that work the way I expect it to?
Dunno, what do you expect it to do?. To my way of thinking there's
On Mon, 2002-04-08 at 15:12, Piers Cawley wrote:
Mark J. Reed [EMAIL PROTECTED] writes:
On Mon, Apr 08, 2002 at 07:56:11PM +0100, Piers Cawley wrote:
$_[_][EMAIL PROTECTED] _=_0_-_
$_.[_()] _ @_._() _= _0_() - _()
[...]
This is where my interpretation fails because the result of
On Mon, Apr 08, 2002 at 06:01:57PM +0100, Jonathan E. Paton wrote:
To make the symbols {} and [] aggregate you'd have to
default [] to using hashes - and force it back to
arrays using explicit syntax. You can't automagically
decide that it's never going to be used like a hash.
I'm I
Damian Conway writes:
:use invocant 'self';
Hmm. My first inclination is to say it should be something like:
macro self { '%MY.frame.arg[0]' }
But suppose you want all .foo to refer to self and not to the current
topic. It would be problematic to have a macro whose name is .
So
Larry wrote:
:use invocant 'self';
Hmm. My first inclination is to say it should be something like:
macro self { '%MY.frame.arg[0]' }
But suppose you want all .foo to refer to self and not to the current
topic. It would be problematic to have a macro whose name is .
So
Aaron Sherman writes:
: On Mon, 2002-04-08 at 13:01, Jonathan E. Paton wrote:
:
: I'm I beating this point to death, or do I have to write
: the RPC:
:
: Keep the {} and [] notation for hashes and arrays
:
: or
:
: Save our array!
:
: Let's boil this RFC down to one short phrase:
:
Damian Conway writes:
: Fortunately, Igority is transitive...
:
: I thought that was maxim was: Igorance is blithth.
That's not a maxim, that's a minim.
Larry
: I thought that was maxim was: Igorance is blithth.
That's not a maxim, that's a minim.
No need to get all crotchet-y.
Damian
$a is a hash key
$b is an array index
$c is another hash key
So, if I try:
multi_dim[$b][$a][$c]
then it's obviously going to break. But how can I, the
programmer, easily spot that? It's not as clear as:
multi_dim{$a}[$b]{$c}
where I can see what I'm getting as I work through the
data
As to the inspring issue about using [] for hashes, I say go for it if
(and only if) it is a signifigant improvement for the parser.
I would imagine it's not. The braces are one of the things that make Perl
feel like Perl. My original post that inspired this gigantic discussion
was simply
21 matches
Mail list logo
