On 10/25/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> 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
>
I would just like to mention that 'class' is confusing because you
don't realy mean class there. The whole conversation is about types
so why not have it be 'type'? On the whole i think ^ makes good sense
and looks pretty good. It also meets the needs of being a single
letter, not already being a sigil, etc. 'class ' is no longer a
twigil and leads to the confusing reasoning you had about where it
needs class and where it doesn't\
sub test (^T $x) {
my ^T $y = $x + 5;
}
Is pretty easy and straight forward. With class i can't figure and
obvious DWIM.
sub test (class T $x) {
my class T $y = $x + 5;
}
That doesn't look right because you have 'my class' so you would think
the type is 'class' except the type isn't class, its T. If you
bareword T then it might overlap (collide) with a real class named T.
In the following case it is not clear wether Dog is defined in the
signature, or a realy seperate class.
sub test (class Dog $x) {
my Dog $y = $x + 5;
}
The same example with ^ becomes much clearer to me.
sub test (^Dog $x) {
my ^Dog $y = $x + 5;
}
The ^ clearly states the meaning while bareword Dog and 'class Dog'
would both cause conflicts in my head.
Just my reasoning about it all.
BTW didn't you contradict your own real world usage of type1^type2 ?
Even if we use ^ as a sigil why would it get confused on that? I
don't think type1 ^type2 could have any realy meaning so it should be
easy for the parser to know the difference.
--
--
__________
Eric Hodges
