On Tue, 2006-09-12 at 14:55 +1000, skaller wrote:
> On Mon, 2006-09-11 at 23:35 -0400, Peter Tanski wrote:
> []
A 'hacked' solution is: open the typeclass fully polymorphically.
Now, when we come to instantiate or bind the function,
we go 'Woops, this function is pure virtual, it can't be
instantiated by beta-reduction (of the types)!
Instead, we must run off and look for an explicit instantiation".
This will work now without any changes to the front end.
It is identical in the lookup phase to just opening
a polymorphic module.
It's easy enough I think to patch the backend to run off
and find a concrete instance provided by the user:
a bit harder to cope with clashes (distinct instances
of a typeclass, with the same substitutions are possible).
Not finding an instance is easy (just chuck an exception).
The problem is that this is probably wrong because each binding
to the type class methods is resolved independently, they can
resolve to methods of distinct instances of the typeclass.
For example:
typeclass X[u,v] { add: u * v -> u; }
fun f[with X] { .. add(1,2.0) .. add(2.0,1) .. }
If we just put
add[u,v]: u * v -> u
into scope, BOTH add calls in f resolve to the add
routine with bindings:
X[int,long] and X[long,int]
respectively. This is why have to do
fun f[with X[int,long]] ..
which puts
add: int * long -> int
into scope .. causing the second lookup of add to fail.
The point is precisely that this 'add' must be put
into scope, it's a specialisation of the typeclass
NOT an instantiation.
The instantiation involves sending the ground
types through the specialisation chains. In the original
example we hade
fun f[r,s with X[r,s]] ..
so we must put the specialisation:
add: r * s -> r
into scope. No ground types in sight: this has nothing
to do with typeclass instances. The instances can only
be identified by the instantiator, which applies the
composed specialisation substitutions, to find the
instance, and at THAT point we replace the binding to
the typeclass method to one that binds instead to the
instance method.
What has to be done is quite simple. The problem is
that there' is no way to put
add: t * s -> r
into scope because Felix used an indirect binding:
"add" -> 1234 -> table[1234] =
forall u,v. add[u,v]: u * v -> u;
In other words, the problem is that the quantifiers
are part of the function signature, and the entry
is stored in a hashtable. There's no way to bind
to a partial specialisation, other than to physically
copy the definition above, specialise it, and add it
to the table as entry 5678. Then the binding is to '5678'.
Having found that, we can not the binding was made
with a particular substitution of the typeclass,
and rebind directly to the typeclass, with that
substitution.
Later, we compose the substitutions of a call chain
to find bindings to ground types, and look for instances
of the type class with those ground types, and use that
as the instantiation: the instantiator 'unrolls' everything
down to ground types (as does the C++ code generator).
What is required is to add:
1234 with u->r, t->s = add: r * s -> r
to the environment, and get back
1234 with u->r, t->s
but there is no way to do this. We have to put
5678: add: r * s -> r
into the symbol table instead, so that the name map (alpha converter)
says:
"add" -> 5678
Doing that for all the methods in the typeclass ensures
all the binding are to a single partial specialisation,
namely the one actually specified in the 'when' clause.
The PROBLEM is that the 'symbol table entry' is just using
string names. The only way to 'alpha-convert' it changes
it to a completely distinct kind of entry using a completely
distinct set of terms on which we cannot do lookup.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
