On Tue, Nov 30, 2004 at 09:09:39AM +0300, Alexey Trofimenko wrote:
: When I look at this
:    $var<key1><key2>[3]<key3>
: 
: then I think that it's a *very* cute, nice, and clean syntax... I really  
: like it!
: (and I would sacrifice something for that to happen, if I would be Larry  
: :) )
: but there's a problem for people and parser too. < is a comparison  
: *operator* and hash subscript is *operator* too, and there's no way to  
: distinguish them at all. "Term rule" won't help here.

I rather like it too.  I'm glad someone else is thinking along the
same lines.  The basic problem with «...» is that most of its uses
were turning out to be more useful that the corresponding <...>.
In fact, I was thinking about all this on the way home from Seattle
yesterday (a 15-hour drive), and I think I'm ready to propose a Great
Angle Bracket Renaming.

Here's the proposal.

First the bad news:
    * We accept that the C<< < >> operator requires whitespace
    around it, and be prepared to be burned in effigy occasionally.

    * We steal angles away from iterators.

Now the ugly news:
    * Hyper operators stay the same, »op«.

Now with those out of the way, the good news: 
    * All other uses of «...» and <...> swap, pretty much.

Now, that has certain interesting outcomes.

    * We get <...> as the qw// shorthand where a term is expected.

    * Most uses of qw// involve strings and lists, so there's little
        visual interference with numeric comparison operators.

    * We get the cute, clean and rather more typeable

        $var<key1><key2>[3]<key3>

    * People can probably get used to reading things like:

        $var<key1><key2>[3]<key3> < $var<key1><key2>[4]<key3>

    * Though they will certainly carp.

    * The ordinary angles do a better job of turning the
        literal keys into visual pills than «...» do.

    * Since we already stole angles from iterators, «$fh» is not
        how you make iterators iterate.  Instead we use $fh.fetch (or
        whatever) in scalar context, and $fh.fetch or @$fh or $fh[]
        or *$fh in list context.

    * That frees up «...» for Something Else.

    * That something else is the requested variant of qw// that allows
        interpolation and quoting of arguments in a shell-like manner.

    * That means that, roughly, we have this proportion:

        '...' : "..." :: <...> : «...»

    * Therefore, just as you can use "..." in place of '...' where you
        you think it's more readable, you may still use «...» in place
        of <...> where that helps readability.

        $var«key1»«key2»[3]«key3» < $var«key1»«key2»[4]«key3»

    * Both the «...» and <...> forms work as slices when used as hash
        subscripts.

    * The Texas quotes <<...>> are only needed when you *have* to interpolate.

    * The :w splitting happens after interpolation.  So

            « foo $bar @baz »

        can end up with lots of words, while

            « foo "$bar" "@baz" »

        is guaranteed to end up with three "words".

    * Multimethed references could be distinghuised either way:

        &bark«Tree»
        &bark<Dog>

    * Match vars become $<foo> instead of $«foo».

    * A rule like <ident> now captures, while «ws» or <<ws>> doesn't.

I think I really like that last outcome.  Capturing should be the default.
And the low profile of «ws» makes it look like an "oh by the way".

Anyway, feel free to shoot this full of holes.

Larry

Reply via email to