> 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 simp
>
>$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 thr
> : 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
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
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
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
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 "".
S
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
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 t
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 th
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
"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 ther
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 '_'. B
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 yo
> > 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
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
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 everyt
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.[$
> >> 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 w
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?
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 b
21 matches
Mail list logo
