On Mon, 15 Mar 2004, Larry Wall wrote:
> On Mon, Mar 15, 2004 at 11:56:26AM -0700, John Williams wrote:
> : I'm probably a bit behind on current thinking, but did %hash{bareword}
> : lose the ability to assume the bareword is a constant string?
>
> It's thinking hard about doing that.  :-)
>
> : And why «»?  Last I heard that was the unicode version of qw(), which
> : returns an array.  Using an array constructor as a hash subscriptor is
> : not a "least surprise" to me.
>
> We'd be trading that surprise for the surprise that %hash{shift} doesn't
> call C<shift>.  Plus we get literal hash slices out of it for free.
> Plus it also works on pair syntax :foo«some literal words».  And probably
> trait and property syntax as well.
>
> And basically because I decided :foo('bar') is too ugly for something
> that will get used as often as switches are on the unix command line.
> The %hash syntax is just a fallout of trying to be consistent with
> the pair notation.  Once people start seeing :foo«bar» all over,
> they won't find %hash«bar» surprising at all, and will appreciate the
> self-documenting literalness of argument.
>
> And unfortunately it's an unavoidable part of my job description to
> decide how people should be surprised.  :-)

And I suppose it's my job to ask silly questions and give muddled
feedback, so you know which bits confuse us users.  :)


According to E7 :foo«bar» is exactly the same as foo=>'bar', and I should
even be able to say

   %hash = ( :id0(3) :id1«foo» :id2{ :sub :ack } );

if I wanted to abuse the syntax that much.  I'm ok with that, but it
doesn't seem like the sort of thing we should actually encourage users to
do.

But the syntax is really  :key«val»  vs  %hash«key»  so the key placement
is an inconsistency.

We also have  :key(expr)  vs  %hash{expr}

:key{expr} (ala E7) is really something completely different, and perhaps
even unexpected when one gets used to the «» similarity.

One could nit-pik more key-vs-value inconsistencies, but I think
:key{expr} will turn out out to be the worst one.


No doubt you have already considered all of this, but it won't hurt for me
to try to "think like Larry" once in a while.

Something "like a unix command line option" implies :key=val might be
desirable. So :key=val could do both-side quoting, and :key=>expr could do
left-side quoting.

However the lack of commas between options rather rules out the above
because it strongly implies that :foo => val is allowed, when it really
isn't because the option ends at the whitespace after :foo .  So the
values really need to go into some sort of subscript-like operator which
is expected to be attached directly to :foo().  And it should also be
quote-like if we want it to autoquote the right-side as well.

Possible quote-like operators are

    :foo'val'   :foo"val"    :foo«val»

«» is the most subscript-like there, so I can see how you got there.


And I suppose that is when «» starting being considered as a subscript
operator in other places.

Getting free slicing and dicing with %hash«cut two 3» instead of
%hash{«cut 2 three»} may be nice, but what about %hash{'one big key'}?
or :key('one big value') for that matter?

Does %hash«key» = @x; put @x in list context or scalar context?
Because it could be a single hash value or a slice with one member.

I can think of a few places where something is definitely a hash-key:

     key => 'value'       # autoquote hash key (if simple identifier)
     :key                 # autoquote hash key (if simple identifier)
     %hash{key}           # perl5 autoquote hash key if simple identifier
     %hash«key»           # perl6 quote hash key if non-whitespace

So, we would be replacing the quoting rule in the 3rd case (which works
the same as the first two[*]) with a different (stronger quoting, but
different) style of quoting the 4th case.
[* well, overlooking that :(expr) isn't allowed]

But it also creates a correlation between the hash-key in %hash«key» and
the hash-value in :key«value», which will probably result in a lot of
explaining why :key{expr} is different from %hash{expr}.

It's your call of course, but I'm not yet convinced of the need to change
the semantics of %hash{key}.  Which usually just means that I lack
enlightenment on the subject. :)

~ John Williams


Reply via email to