On 10/24/05, TSa <[EMAIL PROTECTED]> wrote:
> Does this capturing of the type into ¢T also involve runtime
> code template expansion? That is, if sametype(Int,Int) didn't
> exist it would be compiled on the fly for a call sametype(3,2)?
I think that's up to the implementation. From the language
perspective, no, it behaves as though it was compiled once. But an
implementation is free to instantiate the routine for various types
for optimization.
> Which brings up the question if ¢T will be allowed in multi defs?
Good question. I believe the ordering multi algorithm can be extended
to handle it, but I'll have to think about what it means.
> > So it's a type position thing if it can be. Good. (I wonder if,
> > since it's allowed in term position, we will come up with ambiguities)
> >
> > How about this:
> >
> > sub foo(c|T $x) {
> > my sub util (c|T $in) {...}
> > util($x)
> > }
> >
> > Is that c|T in util() a new, free type variable, or am I asserting
> > that the type of util()'s argument must be the same type as $x?
>
> I would guess there are two distinct ¢foo::T and ¢foo::util::T free
> type variables.
Hmm, yeah, that makes sense, but it can also be annoying. For
instance, in Haskell, I wrote this:
closure :: (Ord a) => (a -> [a]) -> [a] -> [a]
clsoure f init = closure' Set.empty init
where
closure' :: (Ord a) => Set a -> [a] -> [a]
closure' set [] = []
closure' set (x:xs) = ...
This gives me a type error on closure', because the inner "a" is
different from the outer "a". Incidentally, there is no signautre
that closure' can possibly have. So I was forced to leave off the
signature and let the type inferencer do the work. In this case it
would have been nice to have the variable carry over to inner clauses.
But letting that happen also has problems. You can't freely move code
around, because you depend on the type variables that were bound in
outer scopes. However, if the number of "type topicalizers" (as it
were) is small, then maybe that's okay.
> In the call of util($x) the type reference is handed
> or rebound down the call chain just like value refs. BTW, will there
> be a topic type ¢_, grammar type ¢/ and the exception type ¢! as well?
The topic type ¢_ is discussed in theory.pod. I don't see much use
for the others (there is no @/ or @!, for instance).
> What operations are available for type variables? E.g. ¢foo <= ¢bar could
> be the subtype relation. But what would ¢foo + ¢bar mean?
Nothing.
Perhaps ¢foo (+) ¢bar is a union type, but I don't think it should be.
Again, see theory.pod for formalisms of the difference between things
that are in type variables and the types you declare in the program.
Essentially the things that are in type variables are only
instantiable, concrete types, whereas the types you declare in the
program are more like interfaces. There is no concept of a subtype
in the concrete world; only in the interface world. But theory.pod
isn't gospel (yet ;-).
> Is ¢foo - ¢bar the dispatch distance?
Especially not since that concept doesn't exist anymore.
> Is the compiler obliged to separate type variables from value variables? Or
> does
>
> $foo = \¢bar;
>
> produce a type reference? How would that be dereferenced then? Is the type
> inferencer in the compiler automatically calculating a supertype bound
> for every expression? If yes, how is that accessable?
Hmm, don't know about that. Exactly how "first-class" are type variables?
Luke
