- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] [Newbie] Quest for inheritance
by ChrisRathman.6155983＠bloglines.com 07 Jun '05

07 Jun '05

--- Cédric Paternotte <cpaternotte(a)gmail.com > Does this mean that I was wrong in saying in my initial post that > existential types can be used to get "code inheritance" ? Or is it > just that the Shapes example has never been meant to illustrate that > side of things ? The Haskell shapes example was a recreational activity that started with Jim Weirich's challenge at: http://onestepback.org/articles/poly/ As Jim notes, inheritance was not the point of the exercise. And the Haskell example I did was somewhere in the middle of 56 other languages I had been tinkering with: http://www.angelfire.com/tx4/cus/shapes/index.html In most of the OOP languages, we tried to use code inheritance if it was available, but where it was not obvious or easily achievable (Erlang, Mercury, Clean, Haskell), it was bypassed. I did spend a bit of time trying to figure out how to get subtype polymorphism to work in Haskell, but in terms of my familiarity with the language, I am by no means proficient with the language. Best to ask Ralf about the more involed stuff. :-) > Okay, I think I've finally spotted the difference : Using existential > types you actually managed to put both CircleInstance and > RectangleInstance in the same list. I didn't notice that detail at > first. All the difference lies in that line ;) Subtypes may share some common behavior but from a top level perspective, a Rectangle type is not the same as a Circle type. Existential types allow you to treat the different types via the common behavior defined in the parent type. Without existential types, you can have only monomorphic collections. Chris Rathman

1 0

Re: [Haskell-cafe] [Newbie] Quest for inheritance
by ChrisRathman.6155983＠bloglines.com 07 Jun '05

07 Jun '05

The differences in the two shape examples doesn't have to do with code inheritance - it has to do with subtype polymorphism. Existential types allow you to throw different subtypes into a collection and have the function dispatch on the common superclass type. The example without existential types demonstrates parametric polymorphism, but not subclass polymorphism. Generally speaking, OO programming is based on three properties (a) encapsulation; (b) inheritance; and (c) polymorphism. Well, Haskell has pretty good means of encapsulation (though I'm spoiled by ML at the moment). And existential types can get you subtype polymorphism. As far as inheritance, there's actually two kinds that occur in most OO languages. The first being type inheritance (which really just gets you subtype polymorphism). And then there's code inheritance - which is what you are trying to achieve. A language like Sather actually treats type inheritance and code inheritance as seperate things. Languages that mix the two concepts have their own set of difficulties, as the two forms of inheritance are sometimes at odds with each other. Anyhow, the classic case for code inheritance is from a re-use perspective - i.e. not having to repeat the code in multiple places. The classic problem with code inheritance is that it breaks encapsulation, as classes that reuse code from a superclass become tightly coupled with the implementation. At any rate, I consider inheritance to be a convenience mechanism, and not vitally necessary to the concepts of encapsulation, type inheritance, and polymorphism, though I realize that many do consider it important. From a Java perspective, you usually have to decide whether you want single inheritance via class extension, or multiple inheritance via interface implementation. >From the perspective of Java, the shape example that does not have code inheritance corresponds to the Java world of Interfaces - with Interfaces not allowing code inheritance. Chris Rathman --- Cédric Paternotte <cpaternotte(a)gmail.com wrote: > 1. Through existential types > > As shown in the Shapes example at > http://www.angelfire.com/tx4/cus/shapes/haskell.html. > However, I couldn't spot the advantage over the standard version using > normal classes at > http://www.angelfire.com/tx4/cus/shapes/haskell98.html > > The getX function still needs to be defined in both RectangleInstance > and CircleInstance. This is not what I call inheritance. Inheritance > would make it possible to define getX only once in ShapeInstance. Or > maybe the point was only to demonstrate polymorphism. But then what is > the advantage of using existential types ? It just looks like more > work compared to the standard version that also makes use of > polymorphism. Or am I missing something ?

2 1

RE: [Haskell-cafe] [Newbie] Quest for inheritance
by Ralf Lammel 06 Jun '05

06 Jun '05

Re: your enumeration. Let me add one more bullet. In cases where inheritance is about abstract base classes and concrete subclasses ((add interface polymorphism likewise)) you can use a (for unknown reasons) unappreciated pattern for extensible datatypes in Haskell: http://homepages.cwi.nl/~ralf/OOHaskell/src/interpreter/extensible.hs (Note: conceptually unrelated to OOHaskell) Re: OOHaskell Thanks for calling this a very good and thorough attempt :-) I would really like to understand why you think that a) this could possibly be a "huge hack" b) "awkward syntax" would be involved. Regarding a), could it be that you are overwhelmed by the details of the implementation of OOHaskell' *typeful* object system? Wouldn't you be similarly concerned when looking at details of *any* other object system of *any* other *typed* language? (( We are currently massaging the OOHaskell paper. >From what you say, it might seem appropriate to emphasize the OO programming API more clearly, while moving implementation details of OOHaskell out of the face of a programmer who migrates from C#/Java to Haskell. )) Regarding b), could it be that you would want to see special keywords in your face, rather than thinking in terms of records, monadic functions, open fixpoints, closing fixpoints, ...? If yes, I guess that's an valid desire. If there was a mainstream technique for Haskell syntax extension, we want to use it for OOHaskell. Ralf > -----Original Message----- > From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- > bounces(a)haskell.org] On Behalf Of Cédric Paternotte > Sent: Sunday, June 05, 2005 6:52 AM > To: haskell-cafe(a)haskell.org > Subject: [Haskell-cafe] [Newbie] Quest for inheritance > > Hi. This is my first message here so Hello to everyone. > > I'm just starting to learn Haskell and I really think it's a cool > language. > > Coming from an OO world, I've been looking for ways to achieve > inheritance as you get it in Java and the likes. > > I know OO and inheritance is not really the point of Haskell and that > other mechanisms are provided to somewhat achieve reuse. But it's a > way of programming I've been so used to that I feel lost without it. > You might think I'm heading in the wrong direction. My mistake I have > to agree. Let's take it as a learning exercise then. > > So I've been searching the net for *easy* ways to get it and the least > I can say is that I'm confused. It soon became apparent that, > inheritance not being a core feature of the language, many people have > been hacking Haskell to come up with similar effects (btw I never > thought there could be so many ways to reach the same goal...Haskell > programmers are clever bastards). Of the many implementations that > I've found, few are really simple and most achieve it with various > levels of success and/or dodgy syntax. > > Here are the various techniques I've come across so far : > (I'm far from understanding them all) > > 1. Through existential types > > As shown in the Shapes example at > http://www.angelfire.com/tx4/cus/shapes/haskell.html. > However, I couldn't spot the advantage over the standard version using > normal classes at > http://www.angelfire.com/tx4/cus/shapes/haskell98.html > > The getX function still needs to be defined in both RectangleInstance > and CircleInstance. This is not what I call inheritance. Inheritance > would make it possible to define getX only once in ShapeInstance. Or > maybe the point was only to demonstrate polymorphism. But then what is > the advantage of using existential types ? It just looks like more > work compared to the standard version that also makes use of > polymorphism. Or am I missing something ? > > 2. Through typeful heterogeneous collections > > This technique is described at > http://homepages.cwi.nl/~ralf/OOHaskell/ and is able to bring most OO > principles into Haskell. This seems to be a very good and thorough > attempt. Unfortunately it looks more like a huge hack than a solution. > The problem I have with it is the awkward syntax it requires, which to > my newbie eyes doesn't look like Haskell anymore. > > 3. Through phantom types > > I couldn't find any idiot-proof documentation on this topic but this > technique seems to be used to model inheritance. The few papers I've > come across (http://research.microsoft.com/Users/simonpj/Papers/oo- > haskell/overloading_conf.pdf > , > http://www.informatik.uni-bonn.de/~ralf/publications/Phantom.pdf > ,http://www.informatik.uni-bonn.de/~ralf/publications/With.pdf ) seem > very interesting but all go way over my head. > > 4. Through O'Haskell (http://www.cs.chalmers.se/~nordland/ohaskell/) > > Which is a non standard extension of Haskell that seems to be dead anyway. > > 5. With this : http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01- > 60.pdf > > This is a very interesting paper, at least for a newbie like me who's > used to Java. > The aim of this paper was to develop a same application in both Java > and Haskell and to compare the resulting implementations afterwards. > > What interested me in this was the mechanism they used to model > inheritance (described on page 16 & 19), based on data types instead > of classes. The idea being that all constructors of the Employee > datatype have a same parameter, 'inCommon', of type > 'CommonOfEmployees'. > The data type CommonOfEmployees consists of all the fields shared by > all types of employees. By then defining polymorphic functions that > only use the 'inCommon' property of any employee, they've managed to > instantiate these methods only once. My explanation must be horrible > to you but you'll certainly get it by reading their paper. > The Haskell source code can be found here > :http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/Haskell_Impl/ > > The conclusion I drew from my quick & early findings is that the > latest method is the simplest way to get inheritance in my programs. > > I guess my question now is this : Are there other ways to achieve > inheritance in Haskell ? > Simpler techniques ? Or more accurate / comprehensive ? Would you have > pointers to useful resources ? > > I apology in advance for the errors, false assertions, misconceptions, > confusions made in this document. I'm still learning Haskell. I'd just > like to get the most of it. > > > Cedric Paternotte > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

Looking for lost library
by Gracjan Polak 06 Jun '05

06 Jun '05

Hi, Sorry for stupid question, but... Some time ago I read a beautiful paper about variables that had their dependencies automatically tracked and could trigger recalculation when changed. Prototype was implemented in OCaml, then reimplemented in Haskell (using monads). I would like to read that paper once again, but... I lost it :( I do not remember neither title, nor authors. Google asked about any keywords that come to my mind do not show any interesting results. So I ask here :) Can anybody help me, please? Thanks for any pointers... -- Gracjan

2 2

RE: [Haskell-cafe] Re: CGI module almost useless
by Simon Marlow 06 Jun '05

06 Jun '05

On 03 June 2005 14:17, John Goerzen wrote: > On 2005-06-02, Ferenc Wagner <wferi(a)tba.elte.hu> wrote: >> Yes, I also mailed upstream and got no response. But I'm >> using WASH under GHC 6.4 without any problems. Automatic >> preprocessor invocation is not supported in 6.4, but that >> style of coding didn't really work out for me anyway. > > Can you enlighten us as to how you made that work? > > I built and installed WashNGo 2.3.1 using the patch at > http://article.gmane.org/gmane.comp.lang.haskell.libraries/3160 for > GHC > 6.4. > > When I try to build a particular program that uses it, I get this: > > /usr/local/lib/WASH-CGI-1.4.37/ghc-6-4/import/Fields.hi : > Could not find module `ISO8601': > it is not a module in the current program, or in any known > package. ghc-6.4: panic! (the `impossible' happened, GHC version 6.4): > forkM Declaration for zdfReasonISODate{v} That error message is most likely caused by missing modules in the package specification. That is, there are modules missing from either the 'exposed-modules' or 'hidden-modules' field of the package spec (or .cabal file, if you're using Cabal). Cheers, Simon

1 0

About ($)
by Frank-Andre Riess 05 Jun '05

05 Jun '05

Hello there, name's Frank-Andre Riess. Nice to meet you m(_ _)m So, well, my first question on this list is admittedly somewhat simple, but I managed to delay it long enough and now I think I should ask about it: Does ($) have any relevance at all except for being a somewhat handier version of parentheses? Thanks in advance for taking the time to enlighten me. Regards, FAR

5 4

Processing a file with HaXml without invoking processXmlWith?
by Echo Nolan 02 Jun '05

02 Jun '05

Hi all, I've an application which needs to process some XML, but the only way I can see in the Haddock-generated documentation is using the processXmlWith wrapper, which reads it's input and output arguments from the command line. I'd prefer a pure function which took a Document or a String and returned the same, processed. I hope I've overlooked something. Regards, Echo Nolan

4 4

LC online references
by Matthew Roberts 02 Jun '05

02 Jun '05

Hi, I hope I am not too OT here. I am in the process to coming to terms with various calculi based on the lambda calculus. I end up returning to LC books all the time to put things in context. However, I have taken to living out of my laptop and certainly can't carry around the laptop, the book I am reading plus Barendregt's book (plus my phone, plus ....). Besides, I can't afford to buy any books and the library is going to want it back sometime. Does anyone have any pointers to useful online references for the LC? Matt

2 1

RE: Re[2]: [Haskell-cafe] ghc 6.4 import problem
by Simon Marlow 02 Jun '05

02 Jun '05

On 01 June 2005 07:24, Bulat Ziganshin wrote: > Hello Fergus, > > Tuesday, May 31, 2005, 10:24:41 PM, you wrote: > >>> import Data.Set hiding (map) >>> import qualified Data.Set as Set >>> >>> will do fine. > >> That code only compiles with ghc 6.4, and won't compile with ghc 6.2: >> you'll get an error for the "hiding (map)" part, because in 6.2 >> Data.Set does not contain a "map" function. > > btw, question to Simon Marlow and Simon PJ - how about disabling this > error message? You mean allowing import M hiding (x) even if x is not exported by M? Or making it a warning? That's certainly possible, but it constitutes an extension to Haskell 98, so it would at least require the -fglasgow-exts flag. I think you're better off keeping your code portable. Cheers, Simon

2 1

G machine in FORTH
by Andrew Harris 02 Jun '05

02 Jun '05

Hi - Brace yourself... I work in an environment where FORTH is still used. I've been thinking about writing a G-machine interpreter in FORTH so that one could write Haskell like programs that would compile down and run "graph-reduction" style on the FORTH machine. Many developers think FORTH is nice, but the language is so, shall we say, "terse". I'm curious about what people think about this; having the expressiveness of a Haskell-like language that compiles to this environment might provide the best of both worlds, simple hardware architecture and an advanced programming language. let me know what you think, -andrew

5 4