Re: "=>" brother

2004-07-14 Thread Jonadab the Unsightly One
Luke Palmer <[EMAIL PROTECTED]> writes:

>> strange, but :shift«value» looks a little more noisy to me than
>> shift => 'value',
>
> For some reason, it looks that way to me, too.  

Me three.

> Perhaps:
>
> :shift« value »
>
> I *think* that's better...

To me, that's even worse.  My brain sees spaces within the value, even
though I technically know that the <<>> operator throws them out.

To me, :shift <> looks somewhat better (if it means the same
thing...), but I still like the old => syntax even more, perhaps
because I'm accustomed to it; assuming it still DWIM it's what I'll
probably continue to use, personally.

>>  %hash = ( :key«value»
>>:key2«value»
>>:key3
>>key4 => 'value',
>>'key5','value',
>>«key6 value key7 value» )
>> 
>> Did I make mistakes here?
>
> I don't think so.

In terms of maintainability, I'd rather see any given chunk of code
pick a syntax and stick with it for at least long enough to complete
one entire assignment, for crying out loud.  (No, I don't think the
language should enforce that; I just think it would be better practice
in almost all cases.)

Though that probably isn't what the OP was asking.

> :foo«   bar   »
> :ziph«  zam   »
> :split« spork »
>
> Although I'll admit that looks a little strange.  

A little.  It's better than not lining up, IMO.

>> ah.. sorry about messing up all question in one post, but I have
>> one more:)  if key could be of any type, not only strings, than
>> what will be with numeric keys? would they be converted to strings
>> automatically?
>
> It's Perl: what's the difference?

There are probably subtle differences hiding in the pathological
corner cases, but they are probably not important, IMO.  The more
important reason not to flatten hashkeys into strings is so that
references and objects can be used as hash keys without loss of
information.  

Say you have an object that numerifies to 42 but stringifies to
"The answer to the ultimate question of life, the universe, and everything."
Now it suddenly matters whether hash keys get autostringified or not.

FWIW, if they did I could have lived with that just fine.  (You can
always keep a copy of the reference in the value, along with whatever
else you're storing there, in an anonymous hash or array; this is not
one of the limitations of Perl5 that bugs me.)  But it will be
important to know one way or the other.

If the => stringifies where another syntax does not, that will IMO not
be a bad thing.  MTOWTDI.  But I'm not going to get excited about it
one way or the other, assuming it's well-documented, which I'm sure it
will be.

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"[EMAIL PROTECTED]/ --";$\=$ ;-> ();print$/



Re: "=>" brother

2004-07-12 Thread Matt Diephouse
Alexey Trofimenko wrote:
I wonder about mixed synax:
 %hash = ( :keyÂvalueÂ
   :key2ÂvalueÂ
   :key3
   key4 => 'value',
   'key5','value',
   Âkey6 value key7 value )
Did I make mistakes here?
That depends. I asked Damian about this a few weeks ago. He said 
whetever they could get away with would be valid. Meaning that as long 
as it is doable with the parser you can do it.

matt


Re: "=>" brother

2004-07-09 Thread Luke Palmer
Alexey Trofimenko writes:
> >Arguably, the :shiftÂvalue syntax makes it easier to quote both
> >sides of a pair, so perhaps there's a little less need for an
> >autoquoting =>.  But I think that generating non-quoted keys for
> >subscripting happens a lot more often than non-quoted keys for pairs,
> >so I'm inclined to leave the autoquoting of => in for now.
> >
> >Larry
> 
> strange, but :shiftÂvalue looks a little more noisy to me than shift =>  
> 'value',

For some reason, it looks that way to me, too.  Perhaps:

:shift value Â

I *think* that's better...

> 
> oh.. I have a question.
> in
> 
>  %hash := { :keyÂvalue :key2Âvalue :key3}
> 
> there's no need to put comma between, right?

Right.

> I wonder about mixed synax:
> 
>  %hash = ( :keyÂvalueÂ
>:key2ÂvalueÂ
>:key3
>key4 => 'value',
>'key5','value',
>Âkey6 value key7 value )
> 
> Did I make mistakes here?

I don't think so.

> if all was right, than I can figure that :key Âvalue (with whitespace
> between) is outlawed..  Bad Thing for people who like to write pairs
> in columns.

Well, not necessarily:

:foo   bar   Â
:ziph  zam   Â
:split spork Â

Although I'll admit that looks a little strange.  Anyway, I suspect I'll
still be writing hashes perl5-style, while I'll use the new style for
named arguments.

> ah.. sorry about messing up all question in one post, but I have one more:)
> if key could be of any type, not only strings, than what will be with  
> numeric keys? would they be converted to strings automatically?

It's Perl: what's the difference?

Luke


Re: "=>" brother

2004-07-09 Thread Alexey Trofimenko
On Fri, 9 Jul 2004 18:00:44 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
On Sun, Jun 20, 2004 at 03:41:41AM +0400, Alexey Trofimenko wrote:
: There was some talks about hash keys autoquoting and barewords.. later  
are
: gone and former is disambigued by forcing to write %hash{'key'} or
: %hashÂkey ( as opposite to %hash{key} which is now %hash{key()} )..
: right?..
: that's almost ok to me, if there's any hope that  will have a  
_standard_
: way to type accross all the editors:) (btw, I also hope I would never
: happen to mantain a perl6 program written by Chineese programmer, who
: thinks that chineese identifiers are cool)..
:
: but now I'm curious what you gonna do with => autoquoting behavior:
:
:   shift => 'value'  is the same as
:   shift() => 'value'or
:   'shift' => 'value'in perl6?
:
: or in this particular case consistancy doesn't matter? ,)

Well, consistency with *what* is the question.  The default Perl 6
design rule is that, unless we've said otherwise, Perl 6 is consistent
with Perl 5.  So for the moment, => still autoquotes its left side.
only if it does look like an outlawed bareword?.. ah.. 100% perl5 syntax.  
I like that:)


Arguably, the :shiftÂvalue syntax makes it easier to quote both
sides of a pair, so perhaps there's a little less need for an
autoquoting =>.  But I think that generating non-quoted keys for
subscripting happens a lot more often than non-quoted keys for pairs,
so I'm inclined to leave the autoquoting of => in for now.
Larry
strange, but :shiftÂvalue looks a little more noisy to me than shift =>  
'value',

oh.. I have a question.
in
 %hash := { :keyÂvalue :key2Âvalue :key3}
there's no need to put comma between, right?
I wonder about mixed synax:
 %hash = ( :keyÂvalueÂ
   :key2ÂvalueÂ
   :key3
   key4 => 'value',
   'key5','value',
   Âkey6 value key7 value )
Did I make mistakes here?
if all was right, than I can figure that :key Âvalue (with whitespace  
between) is outlawed..
Bad Thing for people who like to write pairs in columns.

ah.. sorry about messing up all question in one post, but I have one more:)
if key could be of any type, not only strings, than what will be with  
numeric keys? would they be converted to strings automatically?


Re: "=>" brother

2004-07-09 Thread Larry Wall
On Sun, Jun 20, 2004 at 03:41:41AM +0400, Alexey Trofimenko wrote:
: There was some talks about hash keys autoquoting and barewords.. later are  
: gone and former is disambigued by forcing to write %hash{'key'} or  
: %hash«key» ( as opposite to %hash{key} which is now %hash{key()} )..  
: right?..
: that's almost ok to me, if there's any hope that « will have a _standard_  
: way to type accross all the editors:) (btw, I also hope I would never  
: happen to mantain a perl6 program written by Chineese programmer, who  
: thinks that chineese identifiers are cool)..
: 
: but now I'm curious what you gonna do with => autoquoting behavior:
: 
:   shift => 'value'  is the same as
:   shift() => 'value'or
:   'shift' => 'value'in perl6?
: 
: or in this particular case consistancy doesn't matter? ,)

Well, consistency with *what* is the question.  The default Perl 6
design rule is that, unless we've said otherwise, Perl 6 is consistent
with Perl 5.  So for the moment, => still autoquotes its left side.

Arguably, the :shift«value» syntax makes it easier to quote both
sides of a pair, so perhaps there's a little less need for an
autoquoting =>.  But I think that generating non-quoted keys for
subscripting happens a lot more often than non-quoted keys for pairs,
so I'm inclined to leave the autoquoting of => in for now.

Larry


"=>" brother

2004-06-20 Thread Alexey Trofimenko
There was some talks about hash keys autoquoting and barewords.. later are  
gone and former is disambigued by forcing to write %hash{'key'} or  
%hashÂkey ( as opposite to %hash{key} which is now %hash{key()} )..  
right?..
that's almost ok to me, if there's any hope that  will have a _standard_  
way to type accross all the editors:) (btw, I also hope I would never  
happen to mantain a perl6 program written by Chineese programmer, who  
thinks that chineese identifiers are cool)..

but now I'm curious what you gonna do with => autoquoting behavior:
  shift => 'value'  is the same as
  shift() => 'value'or
  'shift' => 'value'in perl6?
or in this particular case consistancy doesn't matter? ,)