[mercury-users] Present state of type classes - especially for parametrized types

[Ralph Becket]

J?rg Roman Rudnick, Tuesday,  3 October 2006:
> 
>    To my present understanding, an aim of typeclasses is to
>    be able to provide type-dependent behaviour.

That's the idea.

>    (1) 'O-tone R.B.':
>    > The empty/0 func causes us some grief, since it doesn't mention T;
>    instead
>    > we need to jump through a hoop like
>    > func empty(T) = S, % T is a dummy arg to make the types work
>    > mode empty(unused) = out is det,
>    > which isn't very satisfying.

Here you've omitted the context, which was a discussion of 
type classes for collections, where there is a collection type and an
item type.  Functional dependencies now handle the empty/0 situation.

>    (2) 'O-tone R.B.' (others discussed similar ideas in the following):
>    > But things get worse: in an instance declaration the parameters must
>    all be of the form
>    > `typename(typevar, ...)', and not just `typevar', which
>    > rules out
>    > :- instance sequence(list(T), T).
>    > Oh deary me! What is needed, as was discussed at the end of last
>    year,
>    > is the ability to handle constructor classes, so we could write
>    > :- typeclass sequence(S(T)) where [
>    >     func empty = S(T),
>    >     func cons(T, S(T)) = S(T),
>    >     func head(S(T)) = T,
>    >     func tail(S(T)) = S(T),
>    >     ...
>    > ].
>    > and
>    > :- instance sequence(list(T)).

Again, functional dependencies can handle many of these cases.
Constructor classes would be even better, but right now adding them is
not a priority.

>    ASSUMED STATE: Difficult to say...
>    While the compiler seems to tolerate parametrized types in typeclasses
>    -
>    + func tail(in) = out works, also pred empty(in) is semidet,
>    + typeclass declarations allow type variables in predicates not listed
>    among the typeclass parameters,
>    + instance declarations allow types which are parametrized (inside),
>    if an additional typeclass constraint upon the type variables is
>    added,
>    there seem to be obstacles:
>    (a) The content type (e.g. intNode, stringNode) cannot be given
>    explicitly in a typeclass declaration, applying functional depencies
>    does not appease the compiler.

That's right: type classes range over type variables; instances range
over types.

>    (b) Without a such lore, the compiler seems not to be able to read it
>    from the instance declaration (which in fact contains it) - moreover
>    it seems to be more serious than just a 'typecast' issue - wrapping a
>    typeclass call in an appropriate function lets the compiler finish
>    successfully, but seems to produce an endless loop at execution:
>    In the attached example code, this loop already happens when
>    uncommenting '% _First = first2(Q2),'.

I don't understand.  If you can produce a short program containing the
problem, that would be good.

>    (c) By directly calling first/1 (just deleting the '2' at line 66 and
>    recompiling), the compiler complains:
>    fringe.m:054: In clause for predicate `fringe.main/2':
>    fringe.m:054: error: ambiguous overloading causes type ambiguity.
>    fringe.m:054: Possible type assignments include:
>    fringe.m:054: _First: (pred int) or T
>    (d) At uncommenting 'insert/2' (equivalent to your 'cons/2') already
>    in the typeclass & instance declarations, the compiler throws the
>    following miraculous error message:
>    fringe.m:027: In clause for type class method implementation:
>    fringe.m:027: in unification of variable `HeadVar__3'
>    fringe.m:027: and term `q_insert(HeadVar__1, HeadVar__2)':
>    fringe.m:027: type error in argument(s) of functor `q_insert/2'.
>    fringe.m:027: Argument 1 (HeadVar__1) has type `(some [T] T)',
>    fringe.m:027: expected type was `(some [T] T)'.
>    Does this mean existential types are regarded as per se not unifiable?

The types (some [T1] f(T1)) and (some [T2] f(T2)) clearly will not be
the same in general.

>    Under the bottom line, I guess what I am trying to achieve is finding
>    a 'crude way' of having rank two polymorphism with )o+>0.13.

Now you've completely lost me!  I still don't understand what
it is you're trying to achieve.  If you can produce a short
pseudo-program illustrating what you want to do, that would help.

-- Ralph
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------