On Tue, Dec 04, 2007 at 08:28:48AM -0800, brian d foy wrote:
: In article <[EMAIL PROTECTED]>, Larry Wall
: <[EMAIL PROTECTED]> wrote:
:
: > : Later in the "Literals" section of S02, there's a chart of the
: > : corresponding forms for fat arrow, pair, and paren notation. It has
: > :
: > : a => 'foo' :a<foo> :a(<foo>)
: > :
: > : That looks like it might mean that these are corresponding forms:
: > :
: > : 8 => 377 :8<377> :8(377)
: >
: > The first is just a pair of 8 and 377, and has no special numeric
: > significance. The adverbial syntax is special in that, for ordinary
: > pairs, what follows the colon must be an identifier, so :8<377>
: > would ordinarily be illegal.
:
: Did I miss this in the spec somewhere? I've basically assked the same
: question in regards to file tests. I wouldn't be asking the question if
: the spec didn't keep talking about pairs and adverbs being the same
: thing. If the Pair and adverbs aren't different syntax for the same
: thing, how should that affect that chart in S02?
You're confusing various levels here when you say "same thing".
They're the same in some ways and different in others.
Syntactically, only the :foo forms can be considered literals. =>
is just a Pair composer operator and takes two scalar expressions of
arbitrary complexity. => always creates a Pair object in the abstract
(which may be interpreted as a named argument when used in an argument
list). The => syntax may only ever be used where a term is expected.
The :foo forms, when used where a term is expected, behave like =>
but are restricted to an identifier for the key. (The value can be any
subscriptlike expression.) But unlike =>, the :foo forms can also be
used as adverbs where an *operator* is expected, as in
1..20 :by(3)
The => form cannot be used in this syntactic slot because it would end
up looking like two terms in a row to the parser:
1..20 'by' => 3
or alternately would look like an attempt to use infix:<by>:
1..20 by => 3
Basically, => shouldn't be used for adverbials. It's only for real Pair
programming. (Or in a pinch, named args, but maybe we should just force
people to use :foo for that.)
: > The :8(377) above is a bit wrong, by the way, and works only because
: > decimal 377 happens to stringify to something that looks like an
: > octal number. You couldn't, for instance, say :16(deadbeef) unless
: > deadbeef() was a 0-ary (or listop with no args) function returning
: > a hex string.
:
: Could you have :16('deadbeef')?
Certainly, why not? It's a hex string passed as a normal arg. But usually
you'd reserve that parenthesized form for when you don't know the arg:
:16($randomvar)
and instead write the above as
:16<deadbeef>
since in that case you want a complete literal. :16($x) is really
kind of a pseudoliteral, like "this is a $randomvar string" is a
pseudoliteral that really is one or more operators in disguise.
:[EMAIL PROTECTED] would also be a pseudo-literal, but :16[1,2,3,4] could
be construed as a real literal only via constant folding of a
real expression, just as :16('deadbeef') could be constant folded.
But we don't yet spec what must be constant folded and what isn't.
This could be construed as a weakness in the spec, since it could
result in non-portabilities. On the other hand, maybe we should
just claim that every operation known to be pure at compile time
is constant folded. That would be simpler to learn and to teach,
except for the part about teaching what "pure" means. :)
: Should the :8(377) still work (so, does
: 'wrong' mean it won't do what I'm thinking it will do, or that it does
: mean that Perl 6 won't compile it, or some other sort of wrong)?
Er, "should"? In one sense of "should", it shouldn't. But as I
said, it does work, but not the way it appears to work, because 377
is parsed as a decimal number, not an octal string. It's just a
mathematical accident that octal can be encoded in decimal that way,
and it misleads people to think that the () are functioning as quotes
rather than real expression delimiters. Then they'll cargocult it
to write :16(deadbeef) as well and it Simply Won't Work.
Larry
