[Haskell-cafe] Re: [Haskell] Dynamic binding
Ralf Lammel wrote: Can you just tell how *you* would favor encoding the shapes example that was posed by poster? (It might just be that your code would be very close to Lennart's proposal?) There is no universal answer. The shape example obviously is just a toy example. As long as I have no idea what *concrete* problem the original poster is trying to solve, I cannot really tell which approach is preferable for his endeavour. It seems more appropriate to describe the options and their trade-offs. First of all, note that very often, you do not need a heterogeneous collection at all. Then plain polymorphism with type classes is more than enough, and more than OO provides in that situation. In many cases where you need some kind of heterogenicity (is that a word?), the standard datatype approach shown by Lennart is perfectly suitable - in fact, often much more suitable than the OO solution. You know about the expression problem, and the two dual notions of extensibility? OO supports one dimension, datatypes the other. It depends on the problem which one is more important. When you really need OO-style intensional kind of behaviour selection then first-class functions can bring you quite a long way, and often with much less amount of boilerplate than typical OO solutions. When the behaviour you have to encapsulate in heterogeneous collection becomes more complex - say, more then just one or two functions - first-class functions can be tedious. Existential types represent a more coarse-grained and structured variant of the first-class function approach. They combine the power of first-class functions with the convenience of type classes, very similar to class-based objects. In these cases, they are the most appropriate solution. Note again that with the latter two solutions, as with the OO approach, you do not have extensibility on the operations dimension. Cheers, - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Dynamic binding
Hello Andrew, Friday, June 24, 2005, 12:35:16 AM, you wrote: AW Assuming I have a list of shapes somewhere in my program. The list would AW be heterogeneous, or at least contain data constructed using various AW different type constructors. The list would also be changing all the AW time, for example in a drawing program. So, using the suggestion of a AW list of drawing functions, would this not mean I would have to alter the AW list of drawing functions each time I alter the list of shapes? of course, we suggest this solution only for cases when all you need from shapes - to draw them. as i write in previous letter, one time i changed a list of regular expressions to list of functions that check matches with these regular expressions because it was the only operation i need if you require several operations, you can pack them in tuple or structure (really, tuple is a structure without field names) if you need fields/interfaces inheritance, then this method will not work. but in 90% of cases it's enough. in C++, creating classes is the most useful method of structuring program, so it is used for any problem - from very simple to most complex. when you translate such thing to Haskell, it's better to see which concrete problem are solved with help of classes, and not to emulate the classes itself (because in this case you will write many unneeded code) AW It does AW not seem an extensible solution. When it comes to adding new types or AW new functionality for existing types would it not be easy to miss AW updating a part of the program source that needed updating? adding new class needs adding one constructor function. it's hard to skip that part :) adding new function to interface need to change interface structure definition or adding new element to tuple. then type-checker of Haskell compiler will force you to add new function to all places where this structure/tuple are created. you just never worked with such strong type-checking as in Haskell AW The example I have found the simplest is the one given by Lennart, AW however this to me seems equivalent to the way people use switch AW statements in C to mimic dynamic binding. only because it's C-like :) you just can't believe that Haskell program can be 3-10 times smaller while keeping the same functionality :))) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] Dynamic binding
Bulat wrote: if you require several operations, you can pack them in tuple or structure (really, tuple is a structure without field names) How are we going to anticipate all possible bodies of a for-loop? By comparison, when we build a normal Haskell list, does the construction precisely mirror what we are going to *do* with each element? Fold the map then!!! if you need fields/interfaces inheritance, then this method will not work. but in 90% of cases it's enough. What to do for the other 10%? in C++, creating classes is the most useful method of structuring program, so it is used for any problem - from very simple to most complex. when you translate such thing to Haskell, it's better to see which concrete problem are solved with help of classes, and not to emulate the classes itself (because in this case you will write many unneeded code) Yes, but we ought to solve the shapes problem. The shapes example is in Bulat's 10% region. only because it's C-like :) you just can't believe that Haskell program can be 3-10 times smaller while keeping the same functionality :))) But note that same functionality is one thing, having separate compilation and program extensibility too is another one. Ralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Dynamic binding
Ralf Lammel wrote: only because it's C-like :) you just can't believe that Haskell program can be 3-10 times smaller while keeping the same functionality :))) But note that same functionality is one thing, having separate compilation and program extensibility too is another one. As I said, and as is well-known, extensibility is a red herring in this context - you merely trade one dimension of extensibility for another one. Cheers, - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] Dynamic binding
But note that same functionality is one thing, having separate compilation and program extensibility too is another one. As I said, and as is well-known, extensibility is a red herring in this context - you merely trade one dimension of extensibility for another one. I am not going to fight for extensibility. It's just that I believe that there is a value in a direct correspondence as opposed to a transcription. I cite from the OOHaskell abstract: The [...] code [...] demonstrates that OO code translates into OOHaskell in an intuition-preserving way: essentially expression-by-expression, without requiring global transformations. I would like to add a peer-reviewed clear reference to the OOHaskell paper about the red herring that you mention. I don't have such a reference. May I kindly ask you to offer a few for selection? Thanks, Ralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Dynamic binding
Ralf Lammel wrote: I would like to add a peer-reviewed clear reference to the OOHaskell paper about the red herring that you mention. I don't have such a reference. May I kindly ask you to offer a few for selection? Off-hand, I recall a paper by Martin Odersky and the Scala people discussing their approach to the Expression Problem, and a related paper by Jacques Garrigue, where he proposes to solve it using OCaml's polymorphic variants. Both should be easy to dig up with Google, and probably contain further pointers. Hope this helps, - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] Dynamic binding
Off-hand, I recall a paper by Martin Odersky and the Scala people discussing their approach to the Expression Problem, So ... http://icwww.epfl.ch/publications/documents/IC_TECH_REPORT_200433.pdf ... I guess The key innovative idea there is composition of mixins while replacing formal superclasses of mixins by the actual base class for mixin composition. I quote: In a mixin composition A with B with C, class A acts as actual superclass of mixins B and C, replacing the declared superclasses of B and C. To maintain type soundness, A must be a subclass of the declared superclasses of B and C. A super reference in either B or C will refer to a member of class A. As is the case for trait composition, Scala's mixin composition is commutative in the mixins - A with B with C is equivalent to A with C with B. In OOHaskell, you would parameterize in the superclass and that's it. DISCLAIMER: we haven't tried this. Thanks for the inspiration. and a related paper by Jacques Garrigue, where he proposes to solve it using OCaml's polymorphic variants. I am not sure. Is this referring to Objective Label? Which paper exactly? Hope this helps, It's interesting but I don't see how we make progress with the original (by now perhaps trivial) question regarding the transportation of an OO design into Haskell. The shapes problem doesn't call for Odersky's new contribution: I quote: We add to this list the following criterion: * Independent extensibility: It should be possible to combine independently developed extensions so that they can be used jointly [21]. The shapes problem rather calls for silly subtyping polymorphism. So we are beating a dead horse (or a red herring) by detouring to Scala unless I don't get you were hinting at. BTW, I just notice that Oderksy's list of partial solutions isn't complete: - Visitor combinators (Joost Visser) complementing Palsberg et al. - Many forms of generic functional programming (Hinze etc.) - Haskell type classes allow for extension in both type and processor extension. It's getting late here. Ralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Dynamic binding
Ralf Lammel [EMAIL PROTECTED] writes: and a related paper by Jacques Garrigue, where he proposes to solve it using OCaml's polymorphic variants. I am not sure. Is this referring to Objective Label? Which paper exactly? I think it refers to http://wwwfun.kurims.kyoto-u.ac.jp/%7Egarrigue/papers/variant-reuse.ps.gz and the expression problem seems to be the one described in: http://www.daimi.au.dk/~madst/tool/papers/expression.txt Benedikt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Dynamic binding
Andreas Rossberg said: [Followups to Haskell Cafe] as far as I read it, dynamic or late binding is orthogonal to subtyping, or typing in general. It is just that most typed OO languages lump these concepts together. Absolutely agreed. Often a simple first-class function, or a record thereof, is enough (in fact, dynamic binding is just the OOO way of saying calling a first-class function). In typical functional programming style, you need the general thing only rarely. Can you just tell how *you* would favor encoding the shapes example that was posed by poster? (It might just be that your code would be very close to Lennart's proposal?) Thanks, Ralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
