[m-dev.] Existentially quantified types.

[Ralph Becket]

Yesterday there was a discussion here about how C# classes might be
made accessible to Haskell under the .NET framework.  Several suggestions
were made, most requiring serious extentions to the Haskell type
system.

It seems to me that typeclasses and existentially quantified types
are sufficient to the task.  When trying to explain my point I spotted
either an oddity of the Mercury e-q-type syntax or a flaw in my
understanding
thereof.

Consider the following example:

----------- C# ----------
class c {
	c f(int, c) {...}
}
-------- Mercury --------
:- typeclass c(T) where [
    some [T3]
        (func f(T, int, T2) = T3 => c(T3)) <= c(T2)
            %   ^---- This is the `self' argument.
].
-------------------------
So here I'm treating C# classes as special cases of C# interfaces
(i.e. limited to single inheritance and, behind the scenes, we expect
implementation inheritance).

So far so good.  Next consider

----------- C# ----------
class d : c {
	d g(int)
}
-------- Mercury --------
:- typeclass d(T) <= c(T) where [
    some [T2]
        func g(int) = T2 => d(T2)
].
-------------------------
In this case the particular T2 I get back from calling g may depend
on the int argument.  That would suggest that the type of g is
better expressed by

    func g(int) = (some [T2] T2 => d(T2))

If I'm right, then there's some substance to the argument that the
current syntax is a little misleading (although more convenient where
T2 appears in multiple places...)

--
Ralph Becket      |      MSR Cambridge      |      rbeck at microsoft.com 
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------