Front page | perl.perl6.language |
Postings from November 2004
Larry Wall wrote:
> * We get the cute, clean and rather more typeable
>
> $var<key1><key2>[3]<key3>
>
>
No more or less typeable for me, or anyone else who can remap their
keyboard. I'm presuming there's something costly about {} on non-US
keyboards, but how much does it cost? and do those non-US perl hacks use
remapping already?
> * People can probably get used to reading things like:
>
> $var<key1><key2>[3]<key3> < $var<key1><key2>[4]<key3>
>
>
It's just as readable as XML.
> * Though they will certainly carp.
>
>
Carp.
Carp.
Carp.
> * The ordinary angles do a better job of turning the
> literal keys into visual pills than «...» do.
>
>
What're the objectives here again?
Sorry, but <> don't turn ANYTHING into "visual pills". They never have.
(HT|X)ML looks like gobbledygook interspersed with low-slung X's. The
line above reads like a IOCCC loser.
> * 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.
>
>
while ($.fetch)
??
> * 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.
>
>
Sorry, why wouldn't `` work?
How about just having C< system() > return a clever object with .output
and .err methods?
> * That means that, roughly, we have this proportion:
>
> '...' : "..." :: <...> : «...»
>
>
Have we discussed which quote-like operator is going to stand for "eval"?
There's a number of different post-processing things you can do with
string literals, with interpolation at one end of the spectrum and
execution at the other.
Why not just write this down as "these are all just special cases of XXX
behavior", and then build some handles onto XXX, a la NEXT, LAST, etc.
Then provide "standard bindings" for '', ``, "", and //.
> * 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.
>
>
my $foo = `*.c` :post(literal); # *.c
my $bar = /$foo/ :post(glob); # a.c b.c ...
my $cmd = 'echo $foo' :post(interpolate); # echo *.c
my $output = q{$cmd} :post(exec); # *.c
my $files = "$cmd" :post(shell); # a.c b.c ...
> $var«key1»«key2»[3]«key3» < $var«key1»«key2»[4]«key3»
>
>
I'm looking for the goodness, and I'm just preferring the more vertical
{} as parallels with [].
> * The Texas quotes <<...>> are only needed when you *have* to interpolate.
>
>
Not even a little bit sure what this means. If non-interpolation is an
option, put a modifier on it.
> * Multimethed references could be distinghuised either way:
>
> &bark«Tree»
> &bark<Dog>
>
>
At some point, nestled « was considered a short-circuit of the
paren/hash. Is that supposed to stand, or are those quotes?
> * Match vars become $<foo> instead of $«foo».
>
>
Seems independent of the others. Is this just a consistency issue?
> * A rule like <ident> now captures, while «ws» or <<ws>> doesn't.
>
>
So <...>, which is analogous to '...' above, doesn't interpolate but
does capture? While «...», which is analogous to "...", does interpolate
but doesn't capture?
>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".
>
>
I think that last sentence sums it up: using «ws» is less visually
obvious. For scenarios where we don't want visual obviousness, like
string delimiters, that's probably a win. I really don't want stealth
paint on my data infrastructure, though.
>Larry
>
>
=Austin