- Haskell-Cafe - Haskell.org

Infix operators naming conflicts (was: class Ref)
by Dimitry Golubovsky 07 Jun '05

07 Jun '05

Gracjan Polak wrote: > val = readIORef > a=:b = writeIORef a b Pretty shame := is already reserver :(. There is something alike Graphics.Rendering.OpenGL.GL.StateVar. The use $= for assignment. Generalizing "variables" (in respect to some monad) seems to be often reinvented idea :) Indeed, has anyone tried to summarize possible conflicts between infix operators as they are defined in many places to serve different purpose? e. g. (!) :: Ix i => Array i e -> i -> e The value at the given index in an array. (Data.Array) (!) :: a -> [HtmlAttr] -> a (Text.Html) so if a module imports both modules mentioned above simultaneously, will the compiler complain about (!) and ask to use a qualified name? I had the following experience: when trying to create a convenient syntax to access fields of foreign C structures using appropriate Ptr and field label, I tried to define a combinator for that, and to name it (.) (dot, same as dot-composition defined in Prelude, to look similarly to Java notation) Type signature for my (.) was totally different than Prelude's (.), and semantically it is not composition of functions. However the compiler (GHC) asked to use qualified name. Finally I ended up with the name (-->) which looks like C notation. But who knows, whether someone wishes to use (-->) for other purposes? -- Dimitry Golubovsky Anywhere on the Web

2 1

Usage of | in classes
by Frank-Andre Riess 07 Jun '05

07 Jun '05

Hi, Gracjan's question led me to another question: > class Monad m => Ref m r | m -> r where > newRef :: a -> m (r a) > readRef :: r a -> m a > writeRef :: r a -> a -> m () What's the meaning of the bar and the function type in this declaration. I've seen something like that before (with state monads, I think), but couldn't find an explanation in the Haskell grammar (or anywhere else on haskell.org) Thanks in advance, Frank-Andre

2 1

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

07 Jun '05

Hi Gracjan, > > http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/ > > (again *not* using OOHaskell) > > From the quick skim of code: > .?. -- apply function to upcast object > .!. -- apply modification function to upcast object and substitute > returned value (new object), basically update Absolutely. > Is there any description avaliable what is PoorMens2 all about? Let me try. It's just a variation on Chris' encoding of the shape example, while trying to improve code reuse, while trying to highlight the commonalities in the data parts of the objects in the inheritance hierarchy. The approach ends up being similar to yours in so far that getters (and setters) can be made work for derived types once they are defined on the base type. I just notice that there is a short (because non-monadic) version: http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens/ Ralf

2 1

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

07 Jun '05

> Cédric Paternotte wrote: > ... > > > 5. With this : > http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf > > > > Gracjan Polak wrote: > > I've been thinking about slight generalization of this lately. Here are > my semi-backed thoughts as of now. I should have mentioned http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/ (again *not* using OOHaskell) The actual example encodes Chris Rathman's shape benchmark. The underlying story is somewhat similar to Gracjan's email. Compared to the code that Gracjan posted, - this code pinpoints another issue of this poormens' approach: get_super is quite obviously not enough if you end up wanting mutable objects. You need a setter as well. (My feeling here is that the encapsulation could be better. It would need coding effort to avoid that all data is public.) - this code also shows how the "fake inheritance through data composition" approach blends with virtual methods: one uses an extra class per abstract/virtual method. (Clearly, one can potentially try to bundle some methods in a class.) An issue here is that client code might get bloated with constraints: for datatype subtyping *and* all used virtual methods. Alternatively, one can place the OO methods (their functional counterparts) in the data capsules themselves! Then you get into the trouble of self references. A more general and preliminary observation: the entire approach is potentially more about object *composition* (and perhaps delegation) rather than inheritance. Many OO evangelists consider inheritance as a concept that was used too much in early OO times, while object composition is often more appropriate and flexible. So one *might* say that this approach does not encode a Java-inheritance solution but it does an inheritance-to-object-composition migration on the fly. So what Gracjan calls "Inherits" (and I call subtyping or substitution) is perhaps more a "delegates". Ralf

3 2

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

07 Jun '05

There are tons of good research questions readily waiting. Such as: - What would we want to explore in OOish Haskell so that we, once more, can provide interesting input for mainstream language development? More specifically: what sorts of type inference would make a difference in Java 1.5+, C# 2.0+? - How would Haskell's type-class type system need to evolve in order to provide completely satisfying programmer experience for the uses of type classes in the various existing styles of OOish Haskell programmning? - We have Template Haskell but we are *still* rather lame when doing (OOish) language extensions. Macro systems with syntax extensions perhaps really open up a wormhole but nevertheless: *how* can we get a more experimental Haskell environment where language experiments make a good impression at the level of syntactic sugar, debugging, error messages, and all that? - How is it possible that Haskell lacks true extensible functions (modulo the kind of encoding I sent around earlier)? This is one of the big immediate benefits of OO mainstream programming. Seeing Haskell not providing them, makes me feel sad. It is also amazing that Haskell scores with complicated modes of extensibility (cf. monad transformers), but has no watertight answer when it comes to silly extensible datatypes (or classes) and functions (or methods) defined upon those. - ... Let's go to Sydney :-) (Or at the very least, let's meet at the Haskell Workshop!) Ralf > -----Original Message----- > From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- > bounces(a)haskell.org] On Behalf Of Matthew Roberts > Sent: Tuesday, June 07, 2005 12:15 AM > To: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] [Newbie] Quest for inheritance > > I don't think this is publishable research, there is too much other > stuff already out there. > > matt > > On 06/06/2005, at 5:58 PM, Gracjan Polak wrote: > > > Matthew Roberts wrote: > >> I have a project (for an early research student) waiting for an > >> interested student to take on. It is called "Programming patterns > >> for OO-like programming in Haskell". The basic idea is to identify > >> how to achieve OO-like organisation of your code in vanilla haskell. > >> Hopefully the student can come to a deep understanding of OO and > >> haskell programming in the process.

1 0

Re: [Haskell-cafe] [Newbie] Quest for inheritance
by Matthew Roberts 07 Jun '05

07 Jun '05

I don't think this is publishable research, there is too much other stuff already out there. matt On 06/06/2005, at 5:58 PM, Gracjan Polak wrote: > Matthew Roberts wrote: >> I have a project (for an early research student) waiting for an >> interested student to take on. It is called "Programming patterns >> for OO-like programming in Haskell". The basic idea is to identify >> how to achieve OO-like organisation of your code in vanilla haskell. >> Hopefully the student can come to a deep understanding of OO and >> haskell programming in the process. > > If this could count as graduate student project and could spawn > publication then I would be interested. :) > >> Sounds like exactly what you need. Shame no-one has taken it up yet. >> Perhaps next semester :) Anyone out there want to come to Sydney >> and take it on? > > As I see you did not cc the list, so currently I'm the only one that > received this message. :) > >> Matt >> On 06/06/2005, at 3:55 AM, Gracjan Polak wrote: >>> Cédric Paternotte wrote: >>> > 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. >>> >>> Me too :) >>> >>> > 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. >>> >>> Me too :) >>> >>> > 5. With this : >>> http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf >>> > >>> >>> I've been thinking about slight generalization of this lately. Here >>> are my semi-backed thoughts as of now. >>> >>> First of all, in Haskell there will be strict separation between >>> interfaces and data, so almost every method will be declared twice. >>> This is not so strange to anybody programing in Java, but for C++ >>> programmers can be. Inheritance relation is specified after data. >>> There is also separation between two concepts: what interfaces each >>> piece of data implements and which intefaces given interface >>> inherits. So: >>> >>> {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} >>> >>> module Main where >>> >>> -- general inheritance relation >>> class Inherits b x where >>> get_super :: x -> b >>> >>> -- declare interface with one method >>> class IA a where >>> get_a :: a -> Int >>> >>> -- define data with one field >>> data DA = DA { da_field :: Int } >>> >>> -- say how data DA conforms to interface IA >>> instance IA DA where >>> get_a x = da_field x >>> >>> -- declare some other interface IB >>> -- note: IB is unrelated to IA >>> class IB a where >>> get_b :: a -> String >>> >>> -- data that inherits fields of DA and adds one another field >>> data DB = DB { db_super :: DA, db_field :: String } >>> >>> -- DB inherits fields and methods of DA >>> instance Inherits DA DB where >>> get_super x = db_super x >>> >>> -- data DB implements interface IB >>> instance IB DB where >>> get_b x = db_field x >>> >>> -- some other random data >>> data DC = DC { dc_super :: DA } >>> >>> -- DC implements interface IB >>> instance IB DC where >>> get_b x = show (get_a x) >>> >>> -- and inherits DA >>> instance Inherits DA DC where >>> get_super x = dc_super x >>> >>> -- now the tricky part: state that every data x inheriting DA >>> -- implements all interfaces of DA (repeat for each interface) >>> instance (Inherits DA x) => IA x where >>> get_a w = da_field (get_super w) >>> >>> main = do >>> let db = DB (DA 123) "zzz" >>> let dc = DC (DA 123) >>> putStrLn $ show (get_a db) >>> putStrLn $ show (get_a dc) >>> putStrLn $ show (get_b db) >>> putStrLn $ show (get_b dc) >>> >>> As you see there is much more writting as in Java. But this gives >>> better control over inheritance and subsumption because everything >>> must be stated explicitly. Multiple inheritance is allowed :) Also >>> it is "private inheritance" (as in C++) by default. >>> >>> There are some problems left: how to update a field? or how to make >>> inheritance transitive. I don't know it yet :) >>> >>> > >>> > I guess my question now is this : Are there other ways to achieve >>> > inheritance in Haskell ? >>> >>> Me too:) >>> >>> My proposal (above) is about the level of 'OO' things done in >>> procedural languages (example: C with GTK+ library). There must be a >>> better way. Any comments? >>> >>> -- >>> Gracjan >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> > >

1 0

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

07 Jun '05

Hi Cedric, Thanks for your investigation. Regarding your guess, the code does *not* use "state monads (for mutable data)". The whole example would make sense without IO. (So this approach is *all* different from OOHaskell :-)) The IO monad is used in Poormens2 because some of the methods might want to do side effects. For instance, in the Shape example, we want to see the progress of drawing at the Console. Also, we added an extra feature to "observe" the invocation of setters. The operators (.?.) and (.!.) can be thought of as generic getters and setters. In fact, close inspection reveals that they rather model reading and writing (or call it object observation and object mutation). Mutability is achieved in Poormens2 merely by having setters. (Optionally, if you like, you *could* use the IO monad to carry around objects. Remember, in OOHaskell, the IO monad provides IORefs for mutable objects; something not used in Poormens2.) (( Some asides: If you remove the IO monad, then the Poormens2 style is really a variation on the style hinted at in Gracjan's email. One interesting difference worth noting is that Gracjan places the actual getters in classes while Poormens2 just uses overloaded functions defined in terms of the generic operators (.!.) and (.?.). But I assert that this is a detail or a minor variation point. There could be monadic and non-monadic versions in the Subtype class; I was just too lazy at that time -- assuming that one needs monads in almost all cases anyhow. (After all, we are trying to understand the migration of imperative OO code to Haskell.) You might say that the fact whether the methods (and getters and setters, say properties) are monadic or not should not disturb the general framework, whereas it does seem to affect the design of the Subtype class used in Poormens2. In particular, you might say that the result type of a getter could be just *any* type: why then expose the monadic status in the framework's types? This is needed for the generic operator (.!.). This operator captures an *in-place* update. That is, it applies the mutator to the supertype component of the datum at hand. Since the aspect of selecting that component *and* putting back the updated component is captured generically, the operator takes a type-preserving function on the supertype and lifts it to a type-preserving function on the subtype. So type preservation is in the type of the generic mutator, and we need the monadic variation on type preservation (i.e., a -> IO a) -- if we anticipate that any mutator will have side effects (in addition to those related to the mutation of the object at hand, which is just explicit in the type!!) It is then just a consistent style to provide a similarly monadic type for generic observers. )) We call this a poor mens' approach because the coding style does not allow for a direct translation of C++/C#/Java OO code -- something we aim to provide by OOHaskell (within limits of course). Ralf > -----Original Message----- > From: Cédric Paternotte [mailto:cpaternotte@gmail.com] > Sent: Monday, June 06, 2005 3:36 PM > To: Ralf Lammel > Cc: haskell-cafe(a)haskell.org; Gracjan Polak > Subject: Re: [Haskell-cafe] [Newbie] Quest for inheritance > > Hi Ralf, > > > I should have mentioned > > http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/ > > (again *not* using OOHaskell) > > > > It's been an interesting evening. I've been having a go at your > poormen's source code and, although it's different from OOHaskell, I > still find it very similar in the sense that it's using the same > concepts, namely infix operators (for syntactic sugar I assume) and > state monads (for mutable data). But I had a look at it anyway ;) > > From what I gathered today infix operators are just like ordinary > functions, that differ only in the way you pass them parameters. I > understand the .?. and .!. operators in your code are shortcuts that > apply a function to the parent type, respectively for get and set > operations. > > The only thing I couldn't figure is the reason of using monads. I > noticed they (returnIO) were extensively used in the setters and in > the .!. operator. Do monads provide features without which this whole > thing wouldn't be possible ? What is it exactly they provide in this > context ? > > > A more general and preliminary observation: > > the entire approach is potentially more about > > object *composition* (and perhaps delegation) > > rather than inheritance. > > That's also the way I see it. > > Cédric

1 0

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

06 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 06 Jun '05

06 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