- Haskell - Haskell.org

Re: package mounting
by Frederik Eaton 24 Jun '05

24 Jun '05

(By the way, sorry about cross-posting again. People have already replied to just 'haskell@' and just 'libraries@' but I'll try to stick to 'libraries@' after this since it seems that some users' mail clients show them two copies otherwise) > This idea has been raised before, but it was a while back, and we called > it "grafting". Here's the start of the thread, which went on for quite > some time: > > http://www.haskell.org/pipermail/libraries/2003-August/001310.html Actually it looks like that is slightly different from my idea, perhaps I should have expounded a bit more in my original post. Correct me if I'm wrong, but in my proposal: - grafting/mounting would be done per compilation unit. In yours it seems it would be done per (user, system). - configuration of graft/mount points would be done at compile time, zero or one times per package import option. In yours it would be at package install time. I think my proposal is better. In it there would be no cross-system compatibility issues: since each program would specify where its imported packages get mounted itself, you could write a Haskell program on one system and be assured that someone else could use it on another system without problems. I think this is a rather important property and we shouldn't allow it to be broken - a warning that, as you say, "This wouldn't be recommended though: any source code you write won't compile on someone else's system that doesn't have the same convention" is quite insufficient in my opinion! Plus, I think the ability to remount packages at non-standard locations is an important one, but for the above reason your proposal makes it too dangerous and therefore unusable in practice. Our proposals agree on this point: > The implementation must obey the following rule: > When compiling a module belonging to a package, that package > is temporarily grafted into the root of the module hierarchy. It was kind of "implicit" in my proposal though. I think the "alternative design" which is mentioned in your proposal is interesting: > Alternative design: modules in the current package could be specified > explicitly, perhaps by prefixing them with '.'. This would avoid the > possibility of overlap between the current package and the global > hierarchy, at the expense of having to add lots of extra '.'s. I think that might be a useful feature. Obviously one could introduce the '.' syntax and still allow the present sytax to be used for backward compatibility. Frederik -- http://ofb.net/~frederik/

1 0

RE: [Haskell] Dynamic binding
by Ralf Lammel 24 Jun '05

24 Jun '05

> If we were on an OOP mailing > list, I could ask for days how to simulate pattern matching and > algebraic types---and get a nonsensical runaround involving the visitor > pattern and huge swaths of unreadable code. In such a case, I would be happy if someone told me that there is work like this: http://www.cs.cornell.edu/Projects/jmatch/ People who wrote those papers clearly have thought harder of the problem than most subscribers to the preconceived OOP mailing list. > Ralf, I think it's incumbent on you, having said several times "that > isn't solving the problem", to more clearly explain what problem you > think exists and cannot be solved gracefully I am sure I said it. Also, Oleg and I should be fairly clear on all this in the OOHaskell paper. http://www.cwi.nl/~ralf/OOHaskell Major revision 13 June 2005 We will be grateful for additional comments and questions, and I am happy to summarize all feedback we get, if not on this mailing list, then in the paper's appendices, and elsewhere. Anyway, as it is incumbent on me to explain, I try to be as concise as I can get at 4.00am: [This should also cover Andreas' question.] 1. The original poster asked: > What would be the normal way for a Haskell programmer > to handle the typical shape example in beginner OO > tutorials? 2. I take for granted that "typical shape example" is very well abstracted in this famous benchmark: http://onestepback.org/articles/poly/ http://www.angelfire.com/tx4/cus/shapes/ The essence of the typical shape example is the following: a there are different kinds of shapes (say rectangle, circle, whatever), b which are organized in a subtyping hierarchy, and c each kind of shape supports a subclass-specific draw method; d the interface of shapes allows for mutation/observation of state, e and eventually we want to process collections of shapes 3. Note that e) looks arbitrary at first sight, but it is crucial because shape apps will involve instances of the Composite pattern. Also note that the original poster indeed said: std::list<shape *> shapes; for(std::list<shape *>::iterator it = shapes.begin();it != shapes.end();++it) { (*it)->draw(...); } Also note that the body of the for loop happens to be a single statement that invokes draw, but obviously we must keep in mind what happens if the body is a compound statement. 4. Where did I say "that isn't solving the problem"? (( For the record, I did *not* say so when Lennart posted his proposal. I only mentioned that this proposal has the extensibility problem and that ("minor issue") it needs extra effort to recover the same degree of type distinction as in the normal OO approach. )) Indeed, I did strongly disagree regarding the faithfulness of Bulat's attempts. He made two proposals. The first one basically suggested: - do not build a list of shapes, - do rather build a list of (lazy) applications of draw methods to shape construction arguments - then do not map over a list of shapes to perform functionality per element - do rather map over a list of expressions to sequence their effects. If you think of it, we can get rid of the generality of Haskell's map this way, which is something that others have thought of: http://lambda-the-ultimate.org/node/view/613 The second proposal by Bulat goes as follows: (again I save band with by not showing the actual code) - define a single *non-parameterized* datatype ShapeInterface - construct all sorts of shapes as terms over this monomorphic type - allow for state by IOref allocation before returning the shape terms - do *not* cover the problem of shapes with different interfaces - that is do really just pretend that all shapes have the same type - do therefore simplify away the issue of different types for different kinds of shapes - based on this simplification, build a homogeneous list of shapes - and do a reasonable loop with type-specific draw method invocations indeed. Again, if you think of it, we can adopt the same simplification strategy to Haskell. That is, in Haskell 20??, superclass constraints will not be allowed. We will recommend to define a single class in the recompilable Prelude to which we add methods as we encounter them. Ralf P.S.: I just realized that there is no OOCobol solution in the shapes repository. I sign for it.

1 0

RE: [Haskell] Dynamic binding
by Ralf Lammel 23 Jun '05

23 Jun '05

Lennart, from a textbook perspective I agree that this solution should be mentioned to make it easy for non-Haskellers to get into the subject. However (as you of course know, but I just don't understand why you don't dare to mention the limitations a) and b) ...) a) Your constructor-based approach is not extensible. (Adding another form of shape requires touching existing code and recompilation.) I reckon that the (normal implied OO) point of the Shapes example, to a considerable extent, is also about the potential addition of new shapes. Saying we can take a snapshot of shape "types" and burn them into constructors of an algebraic type does not give me the impression of Haskell being ahead in type system and programming language arena. b) This "burn subtypes into constructors" leads me to a second weakness. By doing so, we have lost the precision of the original type dichotomy circle vs rectangle vs square since these guys are now all represented as terms of type. Of course, you might say that we could define dedicated types for circle, rectangle and square so that we would use the shape type merely as a *sum* type. (So constructors only serve for embedding.) This way we could at least recover the typing precision of OO. So I am willing to give in on b) but I maintain a) and I really miss extensible datatypes :-) Ralf (doing too much C# these days I guess) > -----Original Message----- > From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Lennart Augustsson > Sent: Thursday, June 23, 2005 7:30 AM > To: Andrew Ward > Cc: haskell(a)haskell.org > Subject: Re: [Haskell] Dynamic binding > > Andrew Ward wrote: > > Hi All, > > In Simon Thompson's The Craft of Functional Programming Second Edition, > > page 226, it is mentioned that Laufer (1996) describes a Haskell > > extension to allow dynamic binding. I was wondering if this has been > > implemented as an extension in any of the haskell compilers, or > variants? > > I am a c++ programmer by trade, only dabbling in Haskell when I was at > > university, so it seems a disadvantage to me to not have dynamic binding > > in Haskell 98. > > What would be the normal way for a Haskell programmer to handle the > > typical shape example in beginner OO tutorials? > > > Unlike previous posters that have shown various ways to simulate > object oriented programming I'm going to try and answer the > question. :) > > Here is what I would do: > > ---------------------- > data Shape > = Circle Point Radius > | Square Point Size > > draw :: Shape -> Pict > draw (Circle p r) = drawCircle p r > draw (Square p s) = drawRectangle p s s > > moveTo :: Shape -> Point -> Shape > moveTo (Circle _ r) p = Circle p r > moveTo (Square _ s) p = Square p s > > shapes :: [Shape] > shapes = [Circle (0,0) 1, Square (1,1) 2] > > shapes' :: [Shape] > shapes' = map (moveTo (2,2)) shapes > ---------------------- > > This is in rather stark contrast to the object oriented way of doing the > same things. For reference, here's how you could do it : > > ---------------------- > class IsShape shape where > draw :: shape -> Pict > moveTo :: Point -> shape -> shape > > data Shape = forall a . (IsShape a) => Shape a > > data Circle = Circle Point Radius > instance IsShape Circle where > draw (Circle p r) = drawCircle p r > moveTo p (Circle _ r) = Circle p r > > data Square = Square Point Size > instance IsShape Square where > draw (Square p s) = drawRectangle p s s > moveTo p (Square _ s) = Square p s > > shapes :: [Shape] > shapes = [Shape (Circle (0,0) 10), Shape (Square (1,1) 2)] > > shapes' :: [Shape] > shapes' = map (moveShapeTo (2,2)) shapes > where moveShapeTo p (Shape s) = Shape (moveTo p s) > ---------------------- > > Both ways of doing it contains the same information, it's just that > it's organized in different ways. > > The "functional way" centers around the type Shape. You can find out > all about what shapes exist by looking at the type definition. For > each operation on shapes (draw & moveTo) you describe what they do for > the different shapes. > > The object oriented way centers more around the objects (surprise, > surprise). For each kind of object you say that it's a shape and how > the shape operations work. > > > So, which is better? I don't think you can say one is better than the > other. They have different strengths. With the object oriented way it > is easy to answer questions like "What is a Circle?", whereas with the > functional way it is easy to answer "How do you draw a Shape"? > Likewise, with the object oriented way it's easier to add a new kind > of shape and with the functional way it's easier to add a new > operation. > > To me it's a matter of taste. I like the functional taste; my brain > has been warped over many years. > > -- Lennart > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

2 1

rfc: package mounting
by Frederik Eaton 23 Jun '05

23 Jun '05

Hi all, It looks like there's been a bit of recent discussion regarding module and package namespaces. There is a certain possible design feature that I don't think has been mentioned yet, that I think would be very helpful, so I thought I should at least bring it up. What I want is to be able to build a module namespace for a program out of packages in much the same way that filesystem namespaces are built, namely with mounting operations, rather than just by "union" or "overlay" operations as in the status quo. In other words I would like to be able to specify along with the "-package" option a "mount point" for that package in the module namespace. One possible option syntax might be e.g. "-package my-graphics-lib -package-base Graphics.UI.MyGraphicsLib". (Also, for backward compatibility and convenience, packages should probably be able to specify a default "mount point", to allow existing compiler command-line syntax to be used.) The idea is that with such a feature, library packages could get rid of the common module path prefixes which currently must be specified in every module in the library (such as "Graphics.UI.MyGraphicsLib" above). These prefixes would instead be specified once by each user of the library package (unless the default was desired), perhaps after the package import option on the compiler command line. Modules would have simple unqualified names within the library, like "Button" or "Window" which, if the package mount point were specified as say "Graphics.UI.MyGraphicsLib" in a certain compiler invocation, would be mapped to "Graphics.UI.MyGraphicsLib.Button" and "Graphics.UI.MyGraphicsLib.Window" respectively for code compiled by that invocation. But they could just as easily be mapped to "MGL.Button" etc. in a different invocation in a different project if a different mount point were preferred or were necessary to eliminate a namespace collision. There would be many benefits to being able to do things this way. First, developers would be able to move shared code across libraries without having to worry about the need to make widespread trivial changes to reflect the new module names. I could copy a 'Debug' or 'Util' module into my library from another library, and not have to go through the code to update the module hierarchy base location - furthermore I could incorporate new upstream changes easily without having to repeat this menial fixing-up procedure each time. While it's true that new version control systems like 'darcs' are meant to handle search-and-replace style changes effectively, I think that as far as this issue goes, a VC-based solution would be less elegant and less usable than what I am proposing. Second, this would decouple some aspects of the design process that in my opinion shouldn't be coupled. I would be able to start writing a library before deciding on a name, for instance - currently I at least have to stick in a dummy name as the module namespace base to avoid potential conflicts with other library imports while testing. But under this proposal I could just concentrate on building interior, bottom-up functionality first - at the end of the process a certain set of the package modules would be marked for external visibility, would comprise the exterior interface, and would suggest to me a fitting package name. Setting this name would only involve touching the cabal file rather than every single source file in my library. This would also make it easier to merge and split packages. Third, it would encourage the use of lightweight modules, by reducing the maintenance overhead of each module. Currently modules are the only way (correct me) to partition parts of the top-level namespace of a program - this is OK except that especially in libraries each module contains a certain amount of administrative paperwork, which is to say that it has to know the name of the library that contains it, because that, or some form of it, has to be part of the module name; and other importers of the module have to specify this information too; and as argued above there is a little work involved in touching up these references when code moves between libraries or when the library name changes. As a result I think people end up sticking more code in the same module at times when multiple modules would have been otherwise more suitable. Fourth, I think there would be psychological benefits. I think it's a bit patronizing to the programmer that he has to pretend to remind himself "you are in the following package" at the top of each file. I think people can easily enough keep track of that amount of state. It's as if the building code required me to put a sign with the current city and country in each room of my house. These are bits of context that I can easily call to mind if necessary, but which I would sometimes like to temporarily forget about. I believe programming is somewhat the same. We've come a long way from languages like C where one has to decide whether to precede each symbol in a library with an otherwise-meaningless identifier like "Py_", or risk namespace collisions with other libraries - but I don't think we're at the end of the road yet. It's true that if a module occurs in a package then that is its package, but often the package name doesn't do anything to suggest what the module functionality is - maybe the module exists only because other package modules depend on it, or maybe the package provides an assortment of otherwise unrelated functionality in its modules. In other words, the package name may describe something that the module functionality is only *applicable* to, or it may just be a catchy name. Being able to leave out this not-quite-relevant piece of information would make package-distributed code more conceptually streamlined, easier to quote out of context in e.g. papers, etc. Haskell is really a beautiful language - it's very dense and I think it is one of its great advantages that it allows the programmer to eliminate from code almost all save that which is absolutely relevant to its functionality - this proposal would take the language further in that direction. There is a strong tradition in science to put things in taxonomies, in static hierarchies, and people have tried to do this with collections of code libraries too, perhaps in imitation of scientists. One thing to note however is that the things from the natural world such as the genes of biological organisms change a lot more slowly than man-made code does. Science is different from engineering. A related reason that language designers may be drawn to requiring users to participate in universal classifications is that doing so projects an artificial aura of stability and organization onto the evolving code situation. But these designers, in shading themselves from progress, also stifle it. They create a central administrative hoop which couples all packages and impacts the scalability of the collective development effort. What I'm proposing would be a big departure from the practice of languages like Perl and Java that demand such a global module hierarchy. I've been told that the Haskell community is trying to make it so that two packages can have modules of the same name, as long as they aren't imported in the same compilation unit. My proposal would go further by (1) removing the latter restriction (2) allowing the package code to be completely ignorant of any "mount point". By the way, if you look at some aspects of operating system interfaces I think you'll see that often the choice I'm suggesting has already been made. For instance, you don't have to specify your current working directory with every command you execute, and furthermore the same command can easily be used in different working directories without modification; you can install binaries at different locations in the filesystem; you can mount filesystems at different mount-points, etc. One further thing, there have been proposals to simplify the importing of collections of modules from a certain point in the namespace, etc. I hope it is realized that they are independent from my proposal. They would not be very useful in implementing my proposal, at least I think any such solution would be far from optimal; and vice-versa. Modules and packages are quite distinct constructs, modules are needed for namespace partitioning and packages are needed to delineate administrative boundaries and sources of change. Both are necessary and both deserve special consideration in the ongoing design of Haskell. I will not be surprised if it seems strange to people that I attach such importance to what is likely seen as an unimportant detail of the language, but I do, and I hope that people will consider my suggestion. Also, I haven't said anything about implementation. I realize that this would probably require some modification to the linker. I hope I'm correct in assuming that the modifications will be relatively easy to make, provided it turns out of course that this feature is really something that people want. Frederik P.S. Thanks to John Meacham for a useful discussion. -- http://ofb.net/~frederik/

2 1

Dynamic binding
by Andrew Ward 23 Jun '05

23 Jun '05

Hi All, In Simon Thompson's The Craft of Functional Programming Second Edition, page 226, it is mentioned that Laufer (1996) describes a Haskell extension to allow dynamic binding. I was wondering if this has been implemented as an extension in any of the haskell compilers, or variants? I am a c++ programmer by trade, only dabbling in Haskell when I was at university, so it seems a disadvantage to me to not have dynamic binding in Haskell 98. What would be the normal way for a Haskell programmer to handle the typical shape example in beginner OO tutorials? Andrew Ward.

3 2

RE: [Haskell] Dynamic binding
by Ralf Lammel 23 Jun '05

23 Jun '05

Andreas Rossberg: Andreas R. wrote: > "dynamic binding" is just the OOO way of saying > "calling a first-class function"). Let me presume that dynamic binding was meant here in the sense of late binding, in the sense of subtyping polymorphism. At least, the given shapes example strongly suggested that. If so, I can't fully parse your reply in this context. Please elaborate. (First-class function seems to refer to currying or what?) (Did you miss a "polymorphic" before function? That would explain it. But then again, note, *first-class polymorphism* comes at the price of extra types just as the ugly ex. polymorphism trick. (This is of course just the same trick, indeed.) As we argue in Section 5.6 of the OOHaskell draft, current version, this does really not scale!) Andreas R. wrote: > In typical functional programming style, > you need the general thing only rarely. My impression is that the reason for not wanting (some do want however) true dynamic binding in Haskell relates more to the fact that we willingly make closed world assumptions about the cases to dispatch one. Where the C++ programmer defines classes, we are often just fine to define *one* datatype with n constructors (corresponding to n classes). In such a case, we have an easy time (except when we want case n+1 without recompilation). Using this "idea", late binding degenerates to pattern matching, which is the value-level variation on VMT dispatch. (And for the rare cases, where we want to become polymorphic with an open world, we seem to be willing to sacrifice type inference and we engage into existential polymorphism / first-class polymorphism.) And then of course with normal Haskell type classes we can nicely simulate *interface* polymorphism (again modulo the lack of type inference for subtyping polymorphism). So pre-OOHaskell doesn't miss a lot ;-) Ralf

2 1

RE: Re[2]: [Haskell] Dynamic binding
by Ralf Lammel 23 Jun '05

23 Jun '05

Andrew, you are circumventing the hard problem! (Even though I am sure you just forgot to mention it.) That is, the question is about drawing a *list* of shapes. As correctly observed by Rathman ages back, one naturally ends up with existential quantification when simulating dynamic binding. Ex. quantification is sufficiently scary for folks moving from C++ to Haskell. But fortunately it's not necessary ... see earlier plug ... Ralf > -----Original Message----- > From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of ajb(a)spamcop.net > Sent: Thursday, June 23, 2005 12:42 AM > To: haskell(a)haskell.org > Subject: Re: Re[2]: [Haskell] Dynamic binding > > G'day all. > > Thursday, June 23, 2005, 5:38:03 AM, you wrote: > > > To handle the problem of drawing all shapes, in c++, I would have a list > > of shape pointers: > > > struct shape{ virtual void draw(...);}; > > struct circle : public shape {...}; > > struct square : public shape {...}; > > std::list<shape *> shapes; > > for(std::list<shape *>::iterator it = shapes.begin();it != > > shapes.end();++it) > > { (*it)->>draw(...); } > > > This general pattern of dynamic binding I use over and over again. Could > > you give me some example code of this type of thing handled in Haskell's > > way? Assuming that the number of classes deriving from shape might get > > quite large. > > class Drawable s where > draw :: s -> IO () > > data Circle = Circle Point Radius > > instance Drawable Circle where > draw (Circle centre radius) = ... > > If you only need interface inheritance, this should do. If you also need > implementation inheritance, then you can model it with an upcast method: > > data Shape = Shape Stuff > > class Shape s where > toShape :: s -> Shape > draw :: s -> IO () > > instance Shape Shape where > toShape s = s > draw s = ... > > data Circle = Circle Shape Point Radius > > instance Shape Circle where > toShape (Circle s _ _) = s > draw (Circle _ centre radius) = ... > > In your original example, draw() wasn't abstract virtual, so I assume > there's a reasonable default draw() method for your "shape" class. If > there isn't, then it's probably better in Haskell to split the typeclass: > > class Shape s where > toShape :: s -> Shape > > class (Shape s) => DrawableShape s where > draw :: s -> IO () > > And only define DrawableShape on types where "draw" makes sense. > > Cheers, > Andrew Bromage > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

RE: Re[2]: [Haskell] Dynamic binding
by Ralf Lammel 23 Jun '05

23 Jun '05

Bulat, Bulat wrote: > just create list of draw functions itself: > > [drawCircle (10,10) 5, drawSquare (20,20) 10] No! the exercise is about lists of shapes not lists of results of drawing shapes. This is clearly a major difference. Bulat wrote: > for more complex tasks - declare interface as a structure: > > data ShapeInterface = Shape { draw :: IO (), > moveTo :: Point -> IO (), > calcArea :: Float > } No! You miss the point that the different shapes differ regarding state types. You don't have a chance when you use one datatype. haskell-cafe? Ralf > -----Original Message----- > From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Bulat Ziganshin > Sent: Thursday, June 23, 2005 12:18 AM > To: Andrew Ward > Cc: Pal-Kristian Engstad; haskell(a)haskell.org > Subject: Re[2]: [Haskell] Dynamic binding > > Hello Andrew, > > Thursday, June 23, 2005, 5:38:03 AM, you wrote: > > AW> To handle the problem of drawing all shapes, in c++, I would have a > list > AW> of shape pointers: > > AW> struct shape{ virtual void draw(...);}; > AW> struct circle : public shape {...}; > AW> struct square : public shape {...}; > AW> std::list<shape *> shapes; > AW> for(std::list<shape *>::iterator it = shapes.begin();it != > AW> shapes.end();++it) > { (*it)->>draw(...); } > > AW> This general pattern of dynamic binding I use over and over again. > Could > AW> you give me some example code of this type of thing handled in > Haskell's > AW> way? Assuming that the number of classes deriving from shape might get > AW> quite large. > > just create list of draw functions itself: > > [drawCircle (10,10) 5, drawSquare (20,20) 10] > > you are not expected that this problem can be solved with one line of > code? :) > > > for more complex tasks - declare interface as a structure: > > data ShapeInterface = Shape { draw :: IO (), > moveTo :: Point -> IO (), > calcArea :: Float > } > > > and return this structures from "constructor" functions: > > circle x y r = Shape { draw = drawCircle center r, > moveTo newCenter = ...., > calcArea = pi*r*r > } > where center = Point x y > > square x y size = Shape { draw = ...., > moveTo newCenter = ...., > calcArea = size*szie > } > > figures = [circle 1 2 3, square 4 5 6, circle 7 8 9] > > > > of course, you cannot use inherited field names when using this > technique :) > > -- > Best regards, > Bulat mailto:bulatz@HotPOP.com > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

RE: [Haskell] Dynamic binding
by Ralf Lammel 23 Jun '05

23 Jun '05

At the risk of being excluded from this list (because of an unmoral number of plugs about OOHaskell), here we go: http://homepages.cwi.nl/~ralf/OOHaskell/ You might start with the appendices of the paper and also read Section 2 which finally implements the Shapes example with ease. The C++ encoding is a bit verbose in so far that C++ doesn't quite have type inference, Haskell does and so OOHaskell does too :-) Apologies, Ralf > -----Original Message----- > From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Andrew Ward > Sent: Wednesday, June 22, 2005 6:38 PM > To: Pal-Kristian Engstad > Cc: haskell(a)haskell.org > Subject: Re: [Haskell] Dynamic binding > > Pal-Kristian Engstad wrote: > > >On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote: > > > > > >>What would be the normal way for a Haskell programmer to handle the > >>typical shape example in beginner OO tutorials? > >> > >> > > > >By not doing OO. You have to ask yourself, what is the purpose and/or > benefit > >of using OO? In C++, OO is _useful_ because you restrict the problems of > >mutable data (by enclosing it in C++ classes). > > > >ML type languages have other methods of doing things, and guess what, OO > is > >not that needed for these languages. Sum-types, pattern-matching and data > >constructors make half of the need for OO go away. Higher order functions > and > >make it even less needed. For the rest, there's always work-arounds. > > > >PKE. > > > > > To handle the problem of drawing all shapes, in c++, I would have a list > of shape pointers: > > struct shape{ virtual void draw(...);}; > struct circle : public shape {...}; > struct square : public shape {...}; > std::list<shape *> shapes; > for(std::list<shape *>::iterator it = shapes.begin();it != > shapes.end();++it) > { (*it)->draw(...); } > > This general pattern of dynamic binding I use over and over again. Could > you give me some example code of this type of thing handled in Haskell's > way? Assuming that the number of classes deriving from shape might get > quite large. > > Andrew Ward. > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: [Haskell] Dynamic binding
by Andrew Ward 23 Jun '05

23 Jun '05

Pal-Kristian Engstad wrote: >On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote: > > >>What would be the normal way for a Haskell programmer to handle the >>typical shape example in beginner OO tutorials? >> >> > >By not doing OO. You have to ask yourself, what is the purpose and/or benefit >of using OO? In C++, OO is _useful_ because you restrict the problems of >mutable data (by enclosing it in C++ classes). > >ML type languages have other methods of doing things, and guess what, OO is >not that needed for these languages. Sum-types, pattern-matching and data >constructors make half of the need for OO go away. Higher order functions and >make it even less needed. For the rest, there's always work-arounds. > >PKE. > > To handle the problem of drawing all shapes, in c++, I would have a list of shape pointers: struct shape{ virtual void draw(...);}; struct circle : public shape {...}; struct square : public shape {...}; std::list<shape *> shapes; for(std::list<shape *>::iterator it = shapes.begin();it != shapes.end();++it) { (*it)->draw(...); } This general pattern of dynamic binding I use over and over again. Could you give me some example code of this type of thing handled in Haskell's way? Assuming that the number of classes deriving from shape might get quite large. Andrew Ward.

5 4