[mercury-users] Typeclasses & parameters

[Jörg Roman Rudnick]

Dear Doug,


please let me first mention my second mail two hours after the first, 
where my first approach, unfortunately too much in a haste, is corrected to

:-typeclass tree(T, V, E) <= ( iVertex(V), iEdge(E) ) where [...].

> I followed this thread and did a bit of exploratory programming down
> this path.  Although I got it working, I'm not sure this will be to
> Tomas' liking: the existential types allow for a heterogeneous tree,
> and, although Tomas requested a pred that gave edge labels for any
> type of tree, I think he was looking for a homogeneous tree (one 
> cartesian type per each tree, instead of N cartesian types per
> each tree).  Although heterogeneity allows homogeneity (which
> gives Tomas an answer in his domain, "solving" his problem), if 
> homogeneity is required, then the existential "solution" will compile
> systems that fail this domain requirement (creating new problems).
>
>   
Here again, please look at my correction:

----------------
Now you can create a convenient parametrised type upon `xVertex' & 
`xEdge', e.g. a `btree(V, E)'. Thanks to existential types, it may be 
used in an instance by

:-type xBtree == btree(xVertex, xEdge).

:-instance tree(xBtree, xVertex, xEdge) where [...].
-----------------

> I also tried the functional dependency approach, but ran right back
> into the issue raised in a separate thread about functional dependencies
> and typeclass constraints.
>
> This issue and other similar ones raised in threads (the restriction
> against typeclassing polymorphic types, "functional insts", etc) seem to
> be addressed by dependently-typed languages ... perhaps a review of the
> things Mercury does so well (modes, insts, types, typeclasses, determinism)
> vis-a-vis dependent types could yield a language that is more expressive
> with a stronger type correctness?
>
> Just a thought.
>
> On the other hand, the standard library already has the polymorphic tree
> type defined, which allows the user to extract edge and "vertex" ("node"
> in the standard library) information.  Aren't the things that Tomas is attempting
> already defined in the library?
>   
As you see, in the second example, it well meaningful to employ a 
polymorphic tree type of the library -- it might still make sense to 
associate certain behaviour to it at a single place. Often, one wishes 
to use existential types for V & E for convenience -- not only for 
certain node or edge behaviour, but especially for convenience when 
using varying combinations of types, e.g. nodes und edges.

If you need to distinguish between types, it is possible to declare 
different existential types for each 'role'.

I did not check it for Tomas' tree, but I can say the approach works. Of 
course, a question remains about possible performance drawbacks...

To my impression, typeclass are most attractive to people having been 
bred up with OO coding (like myself), but in somewhat less extent to 
people which already know equivalent techniques of functional / logic 
programming.

Still I do believe architecture -- especially in the large -- is one of 
the really strong points of OO and therefore worth some consideration 
for Mercury. My motivation was to check out inhowfar the typeclass 
system really fits to the Java OO, especially interface, system -- and 
if the performance is ok, I would regard Mercury typeclasses already at 
present as superior to Java interfaces: definitely a hidden strength...

(Perhaps some additional documention about elegant ways mode casting 
would be fine...)

Still sitting over the Tk interface, typeclasses of course are a strong 
issue...


All the best,

          Nick








--------------------------------------------------------------------------
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
--------------------------------------------------------------------------