When I announced that I fixed a version of Perl6::Variables to do <<>>,
crickets chirped. I dislike having to place a lot of matching quotes,
brackets, parenthesis, and braces in my code. You must stop and
visually inspect code to make sure it balances out and even then is a
common source of bug causing typos.
I've been working in Pike's predecessor, LPC, lately. Arrays and hashes
are both subscripted with []
foo["bar"][10][baz]
Variables are autoconverted to the correct type. This has two drawbacks.
Visually inspecting the dreference sequence, you can't tell whether this
is an hash of arrays of hashes or a hash of arrays of arrays. If { }
were used to deference hashes, you'd be able to tell.
Second, autovivication is impossible for the same reason. We can't tell
from parsing this lone expression whether baz should be converted to numbers
or strings automatically.
Enough science, time for anecdotes!
If you can't remember what a data structure looks like, it doesn't matter if
the code spells out the sequences of hash-array-hash each time - you're
going to spell it out wrong. People new to Perl and new to data structures
have this problem all the time - they can't keep straight what the data structure
*is*.
I adjusted to the lack of autovivication very quickly and easily. I'd sacrifice
autovivication *much* sooner than I'd sacrifice a concise subscript syntax.
Data structures are really only ever initialized in a few places in code
except in pathologically badly written code. This adjustment was akin to the
"use warnings"'s handling of undef reguarding "Use of unitialized value".
Hardcoding things around is normally considered bad, and in LPC at least once
in the past month, I've switched an array to being a hash. I was able to do
so without rewritting all of the code that accesses the data structure -
it automatically began accept strings as well as numbers for keys in the
subscript. Hence, using { } vs [ ] might be providing too much redundancy.
And since when have we forced people to be explicit in Perl?
In LPC and apparently Pike, it is all or nothing. Perl can have it's cake and
eat it too. If you want autovivication and information about your datastructures
hardcoded around, use {}, [], and <<>>. If you want concise code, use `. I'd
actually go one further and coopt the . operator and emulate JavaScript more
closely, but I admit the visual distinction between method calls and subscripts
might warrent the noise.
Re: the re-adjustment, after 5 years of heavy Perl programming, LPC's relatively
simple syntax is extremely soothing. The only thing I'm really missing is
list flattening, implicit or explicit, frequently doing things like
bar(xyz["foo"][0], xyz["foo"][1], xyz["foo"][2]).
Let me summarize. The gripes about "you can't do that with `!" miss the point.
Two ways to subscript is not too many. The simplicity available from it is far
from the terse line noise associated with Perl but is something worthy of
languages billed as clean and readable (Pike, not JavaScript). There are
distinct advantages besides concise to this syntax that make it desireable.
So, I strongly support ` or something equivilent.
-scott
On 0, Juerd <[EMAIL PROTECTED]> wrote:
>
> chromatic skribis 2004-04-14 12:32 (-0700):
> > That's exactly my objection to this idea. I think it goes too far to
> > make simple things simpler while making complex things impossible.
>
> Absolutely false.
>
> This is an addition to the already existing {}, which should stay.
> %foo{ something } will still be necessary if:
>
> * the key is the result of an expression
> * you want a slice
> * the key is not a string
> * the key is a string that isn't simple enough (i.e. contains \W in a
> way that isn't supported)
>
> > I really don't want to explain why there are two hash key access
> > mechanisms, one that only works for single keys that match a very
> > simplified regular expression and one that works for one or many hash
> > keys with no restrictions.
>
> There are already two. One that works with expressions and one that
> works for one or many hash keys as long as they are literals.
>
> %foo<<$bar>> doesn't quite do the same as %foo{$bar}.
>
> > Simplicity is good, yes. Huffman coding is also good. But you have to
> > balance them with consistency of expression, usage, and semantics.
>
> I agree.
>
> > I don't think this proposal does the latter.
>
> I disagree.
>
> > On the other hand, if you prod Luke Palmer, he can probably write a
> > macro to make this syntax work for you in under ten minutes and three
> > messages. In that case, it may not be a core feature, but you can have
> > it for very nearly free.
>
> Or I could use something that modifies the grammar Perl uses. Almost any
> syntax feature can be added outside the core. I'm not exploring the
> possibility of this operator, but suggesting that it be in the core.
>
> This operator is possible, improves readability, eases typing and does
> not clash with something that already exists.
>
> Yes, it does mean learning the meaning of one more character. I think
> every programmer is able to cope with that. Even beginners.
>
>
> Juerd
