O'Haskell OOP Polymorphic Functions

[Ashley Yakeley]

At 2001-01-16 00:03, Johan Nordlander wrote:

>Ashley Yakeley wrote:
>> 
>> How do you do OOP-style polymorphic functions in O'Haskell? My first
>> attempt looked something like this:
>> 
>> struct Base
>> 
>> struct Derived < Base =
>>      value :: Int
>> 
>> theValue :: Base -> Maybe Int
>> theValue x = Just (x.value) -- problem line
>> theValue _ = Nothing
>> 
>> In the problem line, x is considered to be of type Base, so x.value 
>> gives an error. 
>
>I'm not sure what OOP-style you're referring to.  This is like trying
>to access the "color" field of an ordinary, uncolored "point".

Right, but returning 'Nothing' for uncolored points and (Just) the color 
for colored points.

> How would you program your function in Java?

Library code:

public class Base
     {
     }

public class Derived
extends Base
     {
     public int value;

     public Derived(int v)
          {
          value = v;
          }
     }


Application code:

     public static MaybeInt theValue(Base x)
          {
          if (x instanceof Derived)
           return new MaybeInt(((Derived) x).value);
          else return MaybeInt.NOTHING;
          }

>> I tried replacing it with
>> 
>> theValue (x :: Derived) = Just (x.value)
>> 
>> ...but that doesn't work either.
>
>But that's just because O'Haskell doesn't support type annotated
>variables in patterns (yet).  Change the type signature of your function
>to 
>
>   theValue :: Derived -> Maybe Int
>
>instead, and it should typecheck (it still wouldn't make much sense, though).

I want a function of type 'Base -> Maybe Int' that returns the value of a 
Derived and Nothing for any other Base.

Is it possible to construct such a function?

>However, as a general remark, I'd like to point out that record terms in
>O'Haskell don't carry their type with them at run-time.  Like in C++,
>the type of a record term is a purely static notion that only exists at
>compile time.  Hence it's not possible to define a function that returns
>a value that depends on the dynamic type of its argument (a big win when
>one wants to enforce information hiding).
>
>The solution is instead to use an ordinary datatype for values that one
>would like to scrutinize at run-time by pattern-matching (the FP way),

This requires knowing the entire type structure before defining any such 
functions.

>or to internalize the function in question into the record type itself
>(the OOP way).

This requires knowing all such functions before defining the type 
structure. It also makes multiple dispatch difficult. I'm not sure this 
can even be done by adding a dynamic-type field, since you still need to 
cast to the Derived type to get the value.

-- 
Ashley Yakeley, Seattle WA