Front page | perl.perl6.language |
Postings from December 2004
On Fri, Dec 03, 2004 at 12:56:18AM -0800, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall <larry@wall.org> wrote:
: > Speaking of "at the moment", I just now updated the Synopses at
: > dev.perl.org.
:
: The new S2 says:
: # Heredocs are no longer written with <<, but with an adverb on any other
: # quote construct:
: #
: # print qq:to/END/
: # Give $amount to the man behind curtain number $curtain.
: # END
:
: Does "any other quote construct" include rx//? I've wanted that for a
: while in Perl 5 (although with anonymous rules, I suppose it's no
: longer that important...).
The rx// construct is not an official quote construct because it
doesn't produce a string via run-time interpolation. But that doesn't
mean you shouldn't get access to :to somehow or other. Either we
hack it into the rx adverbs, or maybe we allow a backdoor into q//
via some kind of :rx adverb. Especially with the extended syntax
being the default, putting your rule over several heredocish lines
seems like a real win.
But we should probably look at the respective adverbs for q and rx to
see if we're setting up any awful cognitive dissonances. I confess I
haven't thought about that yet.
: # In order to interpolate an entire hash, it's necessary to subscript with
: # empty braces or angles:
: #
: # print "The associations are:\n%bar{}"
: # print "The associations are:\n%bar<>"
:
: Am I to assume you can use empty French/Texas quotes, too? (i.e.
: %bar«» or %bar<<>>).
Yes.
: This paragraph also made me realize: am I the only one who foresees
: somebody doing this?
:
: $OUT.printf("We produced <b>%d</b> somoflanges this month!\n", $content);
:
: (Granted, the fix is trivial--just replace the double-quotes with
: single-quotes, or add some of that optional spacing HTML lets you
: splatter around--but it seems like an easy mistake to make.)
Probably also a fairly easy mistake to catch if we discourage slash as the
first character inside a <...>. So maybe they'd get a warning unless they
wrote < /b > instead. Or maybe even an outright compilation error.
But there's no doubt that there will be occasional interference between *ML
and <> subscripts.
: Finally, I noticed that the "Files" section only talks about iterating
: over all lines. Do you have a decision on single-line reads yet?
Nope, though C<pull> is cute. But we still have this fundamental
underlying question of how much we want to unify array and iterator
notation that hasn't really been resolved. It seems a shame to set
up arrays with all these queue-like operations and then not use that
to describe, for instance, gather/take queues, or other inter-thread
message queues. So what if .[] isn't implemented, or is slow?
If you only ever shift/pull an array, does it matter? And really,
the essence of arrays is ordering: the indexability is only a side
effect of that.
But then are we willing to rename shift/unshift to pull/put? If we're
gonna go that far, we might as well switch all the bracket characters
around. Oh, wait...
I suppose it might be argued that if we present a queue as an array,
someone will index it instead of shifting it, and end up storing the
whole history of the queue in memory. Seems like a weak argument,
though. We already have that problem with arrays bound to infinite
generators.
I guess the only real argument against unifying is that neither of
for *@foo {...}
or
for @foo {...}
indicate destructive readout. Which probably says that *
is the wrong operator to use for that, which undoes our pretty
for * {...}
But "for pull" doesn't read very well. Unfortunately we don't have any
destructive "all" quantifiers in English that I can think of offhand.
I suppose "every" comes about as close as anything.
Well, hey, if we have +<< meaning numeric left shift, how about
for @foo *<< 1 {...}
meaning list left shift? :-) * .999
: [And a note to the editors of dev.perl.org: can we get tables of
: contents on these documents? While it's nice to exercise Firefox's
: slick find-in-page interface so much on, say, Apocalypse 12, it'd be
: more convenient to just have a TOC.]
I miss 'em too, but they're admittedly ugly. Maybe they could be put
at the end, with a TOC link at the front?
Larry