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.