Re: OO in Haskell (was Re: What *I* thinks Haskell Needs.)
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: http://www.cs.mu.oz.au/~fjh | 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.)
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.)
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)
OO in Haskell (was Re: What *I* thinks Haskell Needs.)
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/
Re: OO in Haskell (was Re: What *I* thinks Haskell Needs.)
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/
