On 10/25/05, Eric <[EMAIL PROTECTED]> wrote:
> 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'?
If you read the introduction to theory.pod[1], you'll find that we are
actually talking about classes. First, let me define what I mean:
class: A concrete, instantiable type. Each value has exactly one of these.
type: A behavioral interface. Each value probably has more than
one of these.
One of the big ideas behind theories is that you can never write the
name of a class in your program... ever. The only way you can talk
about classes is through variables with constraints. So, when I say:
sub foo(Int $bar) { $bar + 1 }
I actually mean:
sub foo(¢T $bar where ¢T (in) Int) { $bar + 1 }
(Which is pseudosyntax)
That is, foo accepts any *class* which obeys the Int *type*. That's
the most specific you can get.
> 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.
Yeah, I didn't really follow his argument on that one. I, too, think
that the one() junction in general is silly, especially for types.
When you say Dog^Cat, you're saying "I want something that either
conforms to the Dog interface or the Cat interface, but *definitely
not both*!" Why the heck would you care about that? Does there
really arise a situation in which your code will be erroneous when the
variable conforms to both interfaces?
And in fact, its very existence defies another implicit principle of
mine, that is, the "principle of partial definition": Defining a new
type or instance can only break a previously typechecking program by
making it ambiguous. The idea behind that is that at some time you
may realize that oen of your types already obeys another type, and
declare that it conforms to that interface. But you don't go the
other way around, undeclaring that an interface holds, without your
program having been erroneous in the first place. Declaring that a
new interface holds (so long as it actually does) shouldn't break
anything that was already correct.
The principle also has strong implications with library code:
including a new library but doing nothing with it shouldn't start
randomly breaking stuff. (Unless, of course, it breaks the rules and
does crazy stuff, in which case anything goes)
Luke
[1] I'm still thinking in terms of this proposal. If it turns out to
be wrong, disregard my comments.
