On Tue, Oct 25, 2005 at 10:25:48PM -0600, Luke Palmer wrote:
: 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.
Well, I think it's silly too. I'm just trying to see if we need to
reserve the syntax in case someone figures out a way to make it
unsilly in some dialect.
: 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.
And that's basically what we decided in Portland when we went to
set types rather than junctional types. And that's why I'm kind of
pushing for a natural bundling via juxtaposition that can be viewed
as ANDing the constraints:
:(Any Dog Cat Fish ¢T $dc)
That says much the same thing as
:($ where {
.does(Any) and
.does(Dog) and
.does(Cat) and
.does(Fish) and
.does(Class) and ¢T := $dc.class and
.does(Scalar) and $dc := $_;
}
)
And basically, if | can be used to construct type sets, it ends up
meaning exactly the same thing:
:(Any|Dog|Cat|Fish ¢T $dc)
But maybe that just means we don't need it.
Larry
