OO and FP (Re: Is Haskell Object-Oriented? (was: Re: Is GC needed?)) 
Author Message
 OO and FP (Re: Is Haskell Object-Oriented? (was: Re: Is GC needed?))


   Haskell does not include the single most important property of
   object-oriented systems, dynamic binding of function calls to
   functions based on the dynamic types of the arguments, and so should
   not be called a true object-oriented language.  Type classes support
   static overloading, not dynamic overloading.
   [...]
   I think it would be interesting to develop a functional language that
   supported dynamic binding directly.  Since method lookup depends on
   the dynamic types of the arguments rather than their static type, I'm
   not sure such a language could be lazy.

There is a simple equivalence between putting closures into data
structures and dynamic method binding. Consider the following simple
example:

   datatype fruit = FRUIT of {
        identify : unit -> string
   };

   fun make_general_fruit() = FRUIT{identify = fn () => "general_fruit"};

   fun make_banana() = FRUIT{identify = fn () => "banana"};

   val l = [make_general_fruit(),make_banana()];

   app (fn FRUIT x => let val name = #identify(x)() in print(name^" ") end) l;

In the general case, the closures contained in FRUIT would make
reference to arguments of make_general_fruit and local variables.
Note that if you express dynamic method dispatch in this way, it is
clear that the question of eager or lazy evaluation is completely
orthogonal.

Inheritance in such a scheme is slightly more cumbersome, since it
requires explicit type projection operators:

   datatype extended_banana = EBANANA of {
        identify : unit -> string,
        length : unit -> int
   };

   fun make_extended_banana() =  EBANANA{
        identify = fn () => "banana",
        length = fn () => 3
   };

   fun project_extended_banana_to_fruit(EBANANA{identify,...}) =
        FRUIT{identify=identify};

If you have closures, both dynamic method dispatch and inheritance are
nothing other than syntactic sugar for closures-in-data-structures and
for type projection operators. You can think of a statically typed OO
language like C++ simply of having a limited form of closures and
inserting the appropriate projection operators in the right places.
Note, in particular, that I do not believe that inheritance makes a
static type system (like that of ML) any more powerful.

In fact, in my programs, I have found that I very rarely need either
dynamic method dispatch or inheritance. Passing around closures
explicitly is usually the "right" thing to do--cleaner, simpler, more
natural, and just as powerful. From that point of view, I think adding
an object system to a language that already has closures is redundant.

While I don't see much use for explicit support for dynamic method
dispatch and inheritance (in the form of an "object system"), I have
found occasional, limited use for ("static") overloading to make
arithmetic expressions for user-defined numerical types look a little
more natural.

                                        Thomas.

PS: There are some discussions of this in the literature; see, for
example, SCIP. For a specific application, you can find a discussion
of these issues in anonymous FTP: maya.idiap.ch:pub/tmb/spie-fp-*.dvi.Z



Wed, 28 Dec 1994 05:02:17 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. I am not deaf, but am I mute?

2. Haskell: am I missing something?

3. I am looking for haskell/glasgow binaries

4. Why I am not enthusiatic about OO COBOL

5. i am a lamer and i need your help :-)

6. I NEED HELP WITH AN ERROR I GET IN THIS ASSIGNMENT I AM CLOSE TO FINISHING

7. i am new need help

8. i am new and need info

9. I am a student and need some help...

10. i am in desperate need of help

11. I am new to LabVIEW and I am having the classic problem of...

12. I am using LABview 5.0 and I am having difficulty with...

 

 
Powered by phpBB® Forum Software