OO and FP (was subtyping in FP) 
Author Message
 OO and FP (was subtyping in FP)

It's nice to see the functional programming community waking up to the
fact that OO is out there, and might have something to offer :-)

Here's an attempt to clarify some of the terminology and highlight what
I think are the key issues.

First, I suggest when talking about Haskell type classes, one should
always refer to "type classes", i.e. classes (or sets) of types, not
"classes". OO classes are more like types, i.e. sets of objects. "So
are classes the same as types?", I hear you ask. This is a highly
controversional question. My answer to it would be something like:
"Each class has a corresponding type, but there are other types, for
instance function types."

I'm distressed to discover that there are two different meanings in
circulation for static/dynamic typing, i.e. whether types are checked
statically or not, and whether or not it's possible to create new
types at runtime. I always thought it meant the former, but maybe
it's better to avoid the term "static typing" and use "static type
checking" instead. BTW, my understanding is that in type theory, the
term "type" means a static property *by definition*. Any type theorists
out there want to confirm or deny this?

As someone has already pointed out (sorry I haven't kept track of
who has said what in this discussion), static type checking and
dynamic binding (DB) are orthogonal, and many languages, e.g. C++
(well, sort of), Eiffel, Sather, UFO, have both. Static type checking
ensures that there *is* a method with the appropriate type signature
to call. DB means that *which* method may not be known until runtime.
Some people call this merely "late binding" and reserve "dynamic binding"
for an even more dynamic variant (what the CLOS does, basically, I think)
but I think my terminology is fairly standard. BTW C++ *does* have DB  
(and all the other stuff needed to qualify as OO in most peoples' books -
It just has a lot of other stuff too). However, it doesn't happen by
default as it does in most OO languages - you have to use virtual member
functions.

You can simulate dynamic binding in any language which allows function
values (e.g. I do it in C for my UFO implementation), so you can
certainly do it in Haskell, although it probably won't be pretty and
you may find that the type system gets in the way.

A key reason for having dynamic binding is that it provides a
mechanism for selecting between alternatives which is arguably more robust
than explicit selection by conditionals or pattern matching. When a
new subclass is added, or an existing subclass changes, the necessary
modifications are localised: you don't have incomplete conditionals and
broken patterns scattered all over the program. For the OO view on what
I think is a very interesting issue, see [1] p232. Further discussion
can be found in [3].

Before you rush out and try to add dynamic binding to your favourite
functional language, note that it conflicts with lazyness: in order
to dynamically bind on an object (the first argument to a method) you
have to know what class of object it is: to do this you need, in
general, to evaluate it.

The other important aspect of inheritance in most OO languages is
inheritance of implementation code. Type classes don't really do this:
all the real implementation is at the leaves of the hierarchy, the types.
OO people these days make a point of separating code inheritance from
subtyping( = inheritance of interfaces), and to incrementally add
functionality down the hierachy is often considered bad form - "a
concrete class should not inherit from another concrete class". At
least one language, Sather, explicitly enforces this. Again this is
controversial: the important thing to remember is that subtyping and
code inheritance are different, although they are often implemented as
a single feature called "inheritance".

However, adding classes, inheritance, dynamic binding (assuming you
could get round the lazyness problem) etc. to a pure functional
language (to use another well-undertood term :-) would not make it
OO. A fundamental part of the OO mindset is that programming is about
modelling real-world objects:

NONTRIVIAL REAL-WORLD OBJECTS HAVE IDENTITY AND STATE; THEY RETAIN
THEIR IDENTITY WHEN THEIR STATE CHANGES

When one changes a flap setting on a 747, one does not get a new 747.

To people brought up with this mindset, functional programming looks
Just Plain Silly. Now we know this isn't the case, but IMHO unless the
FP community recognises the problem and makes the counter-arguments,
it will continue to be marginalised. One counter-argument is as follows:
much (most?) of programming is *not* about modelling real-world objects:
it is about manipulating abstract entities which are immutable, or
can adequately be modelled as such. Nevertheless, I believe that the
above observation means that there is a large class of applications
for which pure FP is not the most appropriate tool. Parallelism issues
reinforce this view, but that's another matter.

For good introductions to the OO mindset, I recommend the early chapters
of [1] and [2]. If you want to know more about my United Functions and
Objects approach, try [3] or [4]. ([3] is a bit out of date, and [4]
is better on the above issues, but you can get [3] without leaving
your desk).

[1] Bertrand Meyer: Object-oriented software construction, Prentice
Hall 1988.

[2] Grady Booch: Object-oriented analysis and design, 2nd ed.,
Benjamin/Cumnmings 1994.

[3] J. Sargeant: United Functions and Objects: An Overview
Technical report UMCS-93-1-4, Department of Computer
Science, University of Manchester, 1993. Available by ftp from
m1.cs.ac.man.uk, /pub/TR/UMCS-93-1-4.ps.Z

[4] J. Sargeant: Uniting Functional and Object-Oriented
Programming, International Sympoisum on Object Technologies for
Advanced Software, Kanazawa, Japan, November 1993
LNCS 742, pp 1-26.



Tue, 03 Dec 1996 23:27:32 GMT  
 OO and FP (was subtyping in FP)

Quote:

>It's nice to see the functional programming community waking up to the
>fact that OO is out there, and might have something to offer :-)

        Hey, don't rush us; we're still arguing about the definition of
"functional programming".  :-)

Quote:
>Here's an attempt to clarify some of the terminology and highlight what
>I think are the key issues.

>    [discussion of Haskell "class"-es deleted.

        I think we're dancing around a more fundamental problem:  the
terms "type", "class", "dynamic typing", "subtying" and what-not don't
really have agreed-upon meanings.  (At least, not here.  :-))

Quote:
>First, I suggest when talking about Haskell type classes, one should
>always refer to "type classes", i.e. classes (or sets) of types, not
>"classes". OO classes are more like types, i.e. sets of objects.

        I would disagree with your claim that "OO classes are more like
types, i.e. sets of objects."  OOP classes are really object *generators*,
schema from creating objects dynamically at run time, and are terms of the
OOP *language*.  Types, on the other hand, are usually thought of as some
sort of categorization scheme on language terms, and are usually based
on the valid uses of some language term.  In this respect, classes can't be
considered isomorphic to types:  two distinct classes may generate objects
of the same type: responding to the same set of messages, but with different
(internal) behaviors.

        Furthermore, classes themselves may have a type; this is especially
true if your language allows you to use classes in a first-class (!) way:
passing them around and extending them at run time (a la Smalltalk).  Then
you would want to type class expressions based on the messages they implement,
say.

Quote:
>I'm distressed to discover that there are two different meanings in
>circulation for static/dynamic typing, i.e. whether types are checked
>statically or not, and whether or not it's possible to create new
>types at runtime. I always thought it meant the former, but maybe
>it's better to avoid the term "static typing" and use "static type
>checking" instead. BTW, my understanding is that in type theory, the
>term "type" means a static property *by definition*. Any type theorists
>out there want to confirm or deny this?

        Well, that depends on who you talk to, of course.  Higher-order
type theories allow you to pass types around at run time, but this idea
hasn't made it into any "practical" programming languages that I'm aware
of yet.

Quote:
>The other important aspect of inheritance in most OO languages is
>inheritance of implementation code. Type classes don't really do this:
>all the real implementation is at the leaves of the hierarchy, the types.
>OO people these days make a point of separating code inheritance from
>subtyping( = inheritance of interfaces).

        I think it's important to separate the notions of "inheritance" and
"subtyping".  Inheritance is basically "code reuse".  When class A inherits
from class B, the objects generated from class B may be of

        (1) A subtype of those generated by class A (for example, B merely
            implements an additional message name.
        (2) The same type as those generated by A (for example, B merely
            overrides a method implemented in A).
        (3) A type unrelated to that of the objects generated by A.

The third case arises when methods return values and take parameters that
are of the "self" type; i.e., the type of the object that receives the
message.  Loosely speaking, these methods change their type as they pass down
the inheritance heirarchy.

Quote:
>However, adding classes, inheritance, dynamic binding (assuming you
>could get round the lazyness problem) etc. to a pure functional
>language (to use another well-undertood term :-) would not make it
>OO. A fundamental part of the OO mindset is that programming is about
>modelling real-world objects:

>NONTRIVIAL REAL-WORLD OBJECTS HAVE IDENTITY AND STATE; THEY RETAIN
>THEIR IDENTITY WHEN THEIR STATE CHANGES

>When one changes a flap setting on a 747, one does not get a new 747.

        Now, this is also my personal view, but to be fair, there is an
alternative view of OOP that makes excellent sense in a FP paradigm:
delegation.  Much of the impetus towards OOP has to do with the desire
to partition up a global state into more manageable pieces, but this
doesn't mean that this is the *only* view of object-oriented programming.
The delegation-style approach revolves around the incremental refinement
and code-reuse ideas of OOP.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



Wed, 04 Dec 1996 08:22:32 GMT  
 OO and FP (was subtyping in FP)
Sorry folks, not only did I scramble the address, but our ftp site seems to

  John


Fri, 06 Dec 1996 18:59:09 GMT  
 OO and FP (was subtyping in FP)

writes:

Quote:
>It's nice to see the functional programming community waking up to the
>fact that OO is out there, and might have something to offer :-)

[ excellent analysis of OO and FP deleted ]

Quote:
>[3] J. Sargeant: United Functions and Objects: An Overview
>Technical report UMCS-93-1-4, Department of Computer
>Science, University of Manchester, 1993. Available by ftp from
>m1.cs.ac.man.uk, /pub/TR/UMCS-93-1-4.ps.Z

I think this should be m1.cs.man.ac.uk.

However, this site doesn't appear to be set up for anon. ftp access
(username 'anonymous' is unknown) :-(. Lynx can't access it either.

David Hopwood



Sat, 07 Dec 1996 04:02:19 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Subclassing vs Subtyping (partly OOP vs FP)

2. More than two FP-TB-3 with FP-TC-120

3. FP Component Libraries? (FP vs OOP)

4. FP to FP Binary/Hex

5. FP as enhancement of OO

6. FP's and OO and generic programming

7. OO and FP - mutually exclusive?

8. FP/OO

9. OO and FP - mutually exclusive?

10. OO and FP [Fwd: comparison OOP and FP (and how to put them together) was: Re: need help with haskell]

11. Using FP registers as additional GP registers

12. FP in a larger scale (Re: Comparison of functional languages)

 

 
Powered by phpBB® Forum Software