develooper Front page | perl.perl6.language | Postings from November 2004

Re: Angle quotes and pointy brackets

From:
Larry Wall
Date:
November 30, 2004 13:35
Subject:
Re: Angle quotes and pointy brackets
Message ID:
20041130213536.GC30391@wall.org
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



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About