Re: OO in Haskell (was Re: What *I* thinks Haskell Needs.)

1999-09-29 Thread Fergus Henderson

On 28-Sep-1999, Andreas C. Doering <[EMAIL PROTECTED]> wrote:
> > The trickier part is putting different types into a heterogenous
> > collection, and then manipulating according to their _individual_ types.
> 
> If we are already at this point, a naive question:
> 
> Assume we add the type of all types. Hence we can declare a 
> function, say from type to string, we can manipulate types and 
> so forth. 
> This would us allow to deal with this situation. 
> What is the danger, what would it break?

The Hugs/ghc library already includes that.
See the "Type" type and the "Typeable" typeclass,
sections 5.1 and 5.2 in the Hugs/ghc extensions library documentation.

It's sufficient for doing dynamic type casts, but it's
not sufficient for doing dynamic type class casts.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.






Re: OO in Haskell (was Re: What *I* thinks Haskell Needs.)

1999-09-28 Thread Andreas C. Doering

> The trickier part is putting different types into a heterogenous
> collection, and then manipulating according to their _individual_ types.

If we are already at this point, a naive question:

Assume we add the type of all types. Hence we can declare a 
function, say from type to string, we can manipulate types and 
so forth. 
This would us allow to deal with this situation. 
What is the danger, what would it break?

Ex.: 

tuple_arity:: Type -> Maybe Int
tuple_arity () = Just 0
tuple_arity (a,b) = Just 1
...
tuple_arity [a] = Nothing

Of course we would have to add a huge amount 
of predefined functions to work with types, but I guess most of them are
already defined in the compiler/interpreter sources. 

Andreas
---
Andreas C. Doering
Medizinische Universitaet zu Luebeck
Institut fuer Technische Informatik
Ratzeburger Allee, Luebeck, Germany
Email: [EMAIL PROTECTED]
Home: http://www.iti.mu-luebeck.de/~doering 
"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)







Re: OO in Haskell (was Re: What *I* thinks Haskell Needs.)

1999-09-28 Thread Alex Ferguson

> From [EMAIL PROTECTED]  Mon Sep 27 18:50:33 1999
> X-Authentication-Warning: sun00pg2.wam.umd.edu: kevina owned process doing -bs
> Date: Mon, 27 Sep 1999 13:50:59 -0400 (EDT)

Kevin Atkinson:
> You have a collection of Shapes.  Some of these shapes are circles,   
> however, others are rectangle.  Occasionally you will need to extract
> these specific shapes form the collection of generic shapes as there is no   
> way to find the length and width of a generic shape, only its area and
> circumference.  So I need to cast the objects in shapes that are *really*
> rectangles back up to rectangles.
> 
> 1) test for the true type of the object
> 2) cast it back up to its true type

There's no need for a 'cast' here, as Shape can be represented as a
class.  The trickier part is putting different types into a heterogenous
collection, and then manipulating according to their _individual_ types.
Unless you want to restrict yourself to a particular set of possible
types (in which case it's straightforward, anyway), this seems to me
like it _is_ a case of dynamic programming.


> > I'm aware that Haskell doesn't precisely ape that sorts of 'OOP
> > style' that the likes of C++ admits  What I've yet to see is any
> > argument that this is anything other than the wisest possible decision...

> And by this you mean...

That C++ has a very poor type system.

Slán,
Alex.






Re: OO in Haskell (was Re: What *I* thinks Haskell Needs.)

1999-09-27 Thread Kevin Atkinson

Alex Ferguson wrote:
> 
> Kevin Atkinson:
> > You have a collection of Shapes.  Some of these shapes are circles,
> > however, others are rectangle.  Occasionally you will need to extract
> > these specific shapes form the collection of generic shapes as there is no
> > way to find the length and width of a generic shape, only its area and
> > circumference.  So I need to cast the objects in shapes that are *really*
> > rectangles back up to rectangles.
> >
> > 1) test for the true type of the object
> > 2) cast it back up to its true type
> 
> There's no need for a 'cast' here, as Shape can be represented as a
> class.  The trickier part is putting different types into a heterogenous
> collection, and then manipulating according to their _individual_ types.
> Unless you want to restrict yourself to a particular set of possible
> types (in which case it's straightforward, anyway), this seems to me
> like it _is_ a case of dynamic programming.

Yes but it is ALSO a case of typical things one does with OO.  Except
with OO it is very natural as you just stick them all into a container
of Shapes.  When you need to access the identical type of an object you
use simply case up once you are sure what the REAL type of the object
is.  Also in OO you can
have a class heritage like this.

Shape
  Circler
Oval
Circle
  Polygon

Now than suppose the Circler has a method to find the maxim and minimum
radius of its shape.  Now you have a collection of Shapes.  For all
those that are Circler you would like to find this information.  In
these situation it is NOT necessary to recover the complete type of the
object, but merely to cast it up one level to Circler so that you can
find the this information.  Can dynamic programming handle this?  And
how?

> > > I'm aware that Haskell doesn't precisely ape that sorts of 'OOP
> > > style' that the likes of C++ admits  What I've yet to see is any
> > > argument that this is anything other than the wisest possible decision...
> 
> > And by this you mean...
> 
> That C++ has a very poor type system.

You are going to have to justify it as I thing C++ and Java has a VERY
good type system minus the implicit typing system. In fact I *like*  the
C++ typeing system better than I do Haskell's in many cases.

Do you not like OO at all?
-- 
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/






OO in Haskell (was Re: What *I* thinks Haskell Needs.)

1999-09-27 Thread Kevin Atkinson

On Mon, 27 Sep 1999, Alex Ferguson wrote:

> Kevin Atkinson, replying to me:
> 
> > > If I understand you correctly, then the best way of doing this would be
> > > with existentially (boundedly) quantified data types, currently a
> > > non-standard extention present in hbc (and I think, ghc, these days, not
> > > sure if it's with the same generality.)
> > 
> > existentially (boundedly) quantified data types can not cast up.
> 
> 'Cast up' to what?  If you can't write a class context that descibes
> the relatedness of everything you want to put in a heterogenous collection,
> then I'm inclined to doubt if it isn't more heterogenous than is
> sensible.

You have a collection of Shapes.  Some of these shapes are circles,   
however, others are rectangle.  Occasionally you will need to extract
these specific shapes form the collection of generic shapes as there is no   
way to find the length and width of a generic shape, only its area and
circumference.  So I need to cast the objects in shapes that are *really*
rectangles back up to rectangles.

1) test for the true type of the object
2) cast it back up to its true type

> > In order to do that you would ALSO need to use the dramatic typing
> > extensions found in the GHC/Hugs library.
> 
> I don't see how this relates to anything other than heterogenous collections;
> perhaps an example?

A collection of objects with existential types very often is a
heterogeneous collections.

> > The point that class hierarchy isn't precisely _type_ hierarchy is
> > exactly the point I am trying to get gate Haskell needs to also be able to
> > support a class hierarchy if it is to really support OO style programming.
> 
> I'm aware that Haskell doesn't precisely ape that sorts of 'OOP
> style' that the likes of C++ admits  What I've yet to see is any
> argument that this is anything other than the wisest possible decision...

And by this you mean...

---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/