On Wed, Oct 26, 2005 at 01:17:10AM +0200, Juerd wrote:
: Larry Wall skribis 2005-10-25 15:51 (-0700):
: > ^T would still have to be a placeholder variable.
:
: Which it is, in a way.
Though we don't currently allow placeholders in ordinary sigs, or even
in conjunction with ordinary sigs.
: Still, I don't think ^ as a sigil needs to mean the same thing as ^ as a
: twigil. Visually similar pairs are also not related:
:
: ?foo $?foo
: *foo $*foo
: +foo $+foo
: =foo $=foo
: <foo ...> $<foo
True, though it would be the first time we used the same character as
both a sigil and a twigil. ^^T would certainly be a placeholder
in that case, but that might be confusing.
: I think that it would help, and in different ways, even, to see ¢ as a
: prefix operator with special syntax, instead of as a sigil. It doesn't
: fit well in the list of sub, hash, array, scalar.
But then you can't have ¢*T, ¢+T, ¢^T, ¢?T, ¢.T, etc.
By the way, the meaning of the + twigil just changed. Last week it
meant "The $? of the currently compiling unit". That's been taken
over by the COMPILING::<$?foo> notation, partly because I wanted to
steal $+ for generalized "environment" variables, that is, dynamically
visible lexicals, such as $_. See
http://svn.perl.org/perl6/doc/trunk/design/syn/S02.pod
I've also checked in various changes to
http://svn.perl.org/perl6/doc/trunk/design/syn/S06.pod
[Everyone please remember to start new threads for unrelated topics.]
: Making it a prefix op would allow whitespace after it, which would make
: the "class" keyword not seem so desperato. (I think it's a bad keyword
: for this, and picking ^ instead would render it unnecessary, but more
: about why I think "class" is bad for this in a later post.)
Let's delete "sub" too while we're at it. :-)
I'm not stuck on "class" as the ASCII workaround. It's not quite the
same as "sub" since we don't allow "sub X" everywhere we allow "&X".
: > And it might conflict with infix ^ if we ever allow xor'ed types,
: > since declarations contain lots of things that look like juxtaposed
: > terms.
:
: Is this the same "conflict" that occurs in %foo % %bar?
Nope. Normal expressions always know whether they're expecting a term
or operator. I'm talking about in signatures where (it seems to me)
terms are juxtaposed to mean "and", and the available operators
can only be ones that can't be confused with a term prefix or zone
marker. We actually had that problem back when we had junctional
types:
T1&T2
Is that a sub T2 returning a T1?
T1 &T2
Or is a type constraint that must match both types?
T1 & T2
Currently we've said that such junctions should be down in a "where"
clause, but it would be nice to leave the door open for
Int|Str
type constraints. But it's somewhat problematic to have a junctional
return type, so maybe that will never happen, and the most complicated
thing we'll see (in the absence of where clauses and subsignatures),
is
sub foo (Mammal ¢T $fido)
In that case ^ or | could be forced to work. But I'd still rather use
something that doesn't shout "operator", especially if the notation can
sneak into rvalue code. And I'd prefer to leave the ASCII characters
available for real operators and metaoperators later.
: (I cannot imagine needing a one() junction for types, by the way. If
: someone can come up with a good real-life example, please do so.)
Oh, that's easy, for some definition of "real". In real life, cats and
dogs don't overlap, so if you say Cat|Dog, you really mean Cat^Dog.
But these junctional types are only good for constraints. A given
object may only have a set of types, not a junction of types.
Larry
