[Haskell-cafe] Re: OOP'er with (hopefully) trivial questions.....
Nicholls, Mark wrote: data Shape = Circle Int | Rectangle Int Int | Square Int Isn't this now closed...i.e. the statement is effectively defining that shape is this and only ever thisi.e. can I in another module add new types of Shape? Yes, but in most cases, this is actually a good thing. For instance, you can now define equality of two shapes: equal :: Shape - Shape - Bool equal (Circle x)(Circle y)= x == y equal (Rectangle x1 x2) (Rectangle y1 y2) = x1 == x2 y1 == y2 equal (Square x)(Square y)= x == y In general, the open approach is limited to functions of the form Shape - ... - Shape / Int / something else with no Shape occurring in the other ... arguments. I'm trying to teach myself HaskellI've spent a few hours going through a few tutorialsand I sort of get the basics... [...] After many years of OOP though my brain is wired up to construct software in that 'pattern'a problem for me at the moment is I cannot see how to construct programs in an OO style in HaskellI know this is probably not the way to approach it...but I feel I need to master the syntax before the paradigm. This approach is probably harder than it could be, you'll have a much easier time learning it from a paper-textbook like http://www.cs.nott.ac.uk/~gmh/book.html http://web.comlab.ox.ac.uk/oucl/publications/books/functional/ http://haskell.org/soe/ After all, it's like learning programming anew. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: OOP'er with (hopefully) trivial questions.....
Not really with this... The open case (as in OO) seems to be more like the Haskell class construct, i.e. if new types declare themselves to be members of a class then they must satisfy certain constaintsI can then specify equals with the class and leave the onus on the implementor to implement itthe data construct seems more analogous to a OO class definition...which is closed in the same way. The approach is deliberate...but I accept may be harder than it needs to be...I'm interested in Haskell because of the alleged power/formality of it's type system against the relatively weakness of OO ones...the irony at the moment is that they do not really seem to correspond directlyand OO type system seems to (loosely) correlate to Haskell type class system, and an OO class system (loosely) to Haskels type system, though in OOP's they are unpleasantly tangled. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of apfelmus Sent: 17 December 2007 12:34 To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Re: OOP'er with (hopefully) trivial questions. Nicholls, Mark wrote: data Shape = Circle Int | Rectangle Int Int | Square Int Isn't this now closed...i.e. the statement is effectively defining that shape is this and only ever thisi.e. can I in another module add new types of Shape? Yes, but in most cases, this is actually a good thing. For instance, you can now define equality of two shapes: equal :: Shape - Shape - Bool equal (Circle x)(Circle y)= x == y equal (Rectangle x1 x2) (Rectangle y1 y2) = x1 == x2 y1 == y2 equal (Square x)(Square y)= x == y In general, the open approach is limited to functions of the form Shape - ... - Shape / Int / something else with no Shape occurring in the other ... arguments. I'm trying to teach myself HaskellI've spent a few hours going through a few tutorialsand I sort of get the basics... [...] After many years of OOP though my brain is wired up to construct software in that 'pattern'a problem for me at the moment is I cannot see how to construct programs in an OO style in HaskellI know this is probably not the way to approach it...but I feel I need to master the syntax before the paradigm. This approach is probably harder than it could be, you'll have a much easier time learning it from a paper-textbook like http://www.cs.nott.ac.uk/~gmh/book.html http://web.comlab.ox.ac.uk/oucl/publications/books/functional/ http://haskell.org/soe/ After all, it's like learning programming anew. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: OOP'er with (hopefully) trivial questions.....
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicholls, Mark The open case (as in OO) seems to be more like the Haskell class construct, i.e. if new types declare themselves to be members of a class then they must satisfy certain constaintsI can then specify equals with the class and leave the onus on the implementor to implement itthe data construct seems more analogous to a OO class definition...which is closed in the same way. This may or may not help, but anyway... As Henning has pointed out, this is a FAQ. However, his recommended page (OOP_vs_type_classes) is quite involved. As a counterpoint, I really liked Lennart's example and summary from a couple of years ago: http://www.haskell.org/pipermail/haskell/2005-June/016058.html (I've added it to section 5 of this page: http://www.haskell.org/haskellwiki/Existential_type) The key point (IMO): 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. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OOP'er with (hopefully) trivial questions.....
On Dec 17, 2007 1:18 PM, Nicholls, Mark [EMAIL PROTECTED] wrote: Not really with this... The open case (as in OO) seems to be more like the Haskell class construct, i.e. if new types declare themselves to be members of a class then they must satisfy certain constaintsI can then specify equals with the class and leave the onus on the implementor to implement itthe data construct seems more analogous to a OO class definition...which is closed in the same way. Yes that's pretty much true. In lots of cases you do have tons of different representations of a specific type that is known at to be closed. E.g. singly linked list has two cases it's either a Link or it's the end of the list: data List a = Link a (List a) | Nil You could do this in C++ with two different classes inheriting from a common base class, and then use RTTI to discover what variant of List something is, or add a virtual function called isLink or something, or maybe just have a single variant but add a boolean or an enum field describing wether or not the Link pointer is valid. As you see it gets messy (and in this trivial case you would use the built in two-way case of pointers, where you can specify Nil as simply a link with a null tail - but that's not always the possible, and even in this case I find it much nicer to explicitly use two completely different representations for the two variants). In general you don't tend to use this sort of tagged union to build stuff in OOP so there's no direct correspondence to typical OOP patterns. So one side effect of learning Haskell is (or at least was to me) a greater familiarity with that approach to describing data, which is simple and powerful enough that you sometimes emulate it even when it gets a bit messy in other languages. It really gets nice when you start defining functions on the data type using pattern matching, as everything is just extremely clear and nice since you only deal with one case at a time.. Here's a few examples using the list (uncompiled): isEmpty Nil = True isEmpty _ = False length Nil = 0 length (Link _ xs) = 1 + length xs concat Nil xs = xs concat (Link x xs) ys = Link x (concat xs ys) -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OOP'er with (hopefully) trivial questions.....
On Dec 17, 2007 8:18 AM, Nicholls, Mark [EMAIL PROTECTED] wrote: The approach is deliberate...but I accept may be harder than it needs to be...I'm interested in Haskell because of the alleged power/formality of it's type system against the relatively weakness of OO ones...the irony at the moment is that they do not really seem to correspond directlyand OO type system seems to (loosely) correlate to Haskell type class system, and an OO class system (loosely) to Haskels type system, though in OOP's they are unpleasantly tangled. When I was learning Haskell, I found it helpful to think this way: In an OO system, classes describe objects. In Haskell, classes decribe types. It may also be helpful to note that Haskell's class system can be emulated in the language itself[1] by a technique known as dictionary passing. For example, the Eq class is equivalent to a function of type a - a - Bool, for some a. type EqD a = a - a - Bool So any time I have a function that uses Eq, foo :: Eq a = a - a - a - a foo a b c = if a == b then c else b I could define an equivalent function without it fooBy :: EqD a - a - a - a - a fooBy eq a b c = if eq a b then c else b The difference between foo and fooBy is that fooBy requires me to explicitly provide the Eq dictionary, whereas the compiler takes care of providing it to foo. A lot of functions in Data.List exist in foo and fooBy forms. [1] This isn't entirely true if we're talking about Haskell 98. Some classes dictionaries can't be defined without an extension, but that extension is widely supported and will almost certainly be in the next language standard. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: OOP'er with (hopefully) trivial questions.....
Thomas Davie wrote: Take a look at the Typable class. Although, pretty much any code that you can compile can be loaded into ghci without modification, and that's by far the easier way of finding the types of things. Is there a way to make ghci to know also the symbols which are not exported? My problem is that :t unexportedSymbolName reports undefined. Is there a way to make :t working without first exporting unexportedSymbolName and then reloading the module in ghci and asking with :t again? Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OOP'er with (hopefully) trivial questions.....
There was a thread about this recently. In any case, if you load the code interpreted (which happens if there is no .o or .hi file of the module lying around), then you can look inside all you want. But if it loads compiled, then you only have access to the exported symbols. The reason is because of inlining optimizations; you know about the encapsulation of the module when you compile it, and you can optimize the memory and code usage based on compiling functions that are not exported differently. That's my weak understanding, at least. Luke On Dec 17, 2007 5:52 PM, Peter Hercek [EMAIL PROTECTED] wrote: Thomas Davie wrote: Take a look at the Typable class. Although, pretty much any code that you can compile can be loaded into ghci without modification, and that's by far the easier way of finding the types of things. Is there a way to make ghci to know also the symbols which are not exported? My problem is that :t unexportedSymbolName reports undefined. Is there a way to make :t working without first exporting unexportedSymbolName and then reloading the module in ghci and asking with :t again? Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: OOP'er with (hopefully) trivial questions.....
Luke Palmer wrote: There was a thread about this recently. In any case, if you load the code interpreted (which happens if there is no .o or .hi file of the module lying around), then you can look inside all you want. But if it loads compiled, then you only have access to the exported symbols. The reason is because of inlining optimizations; you know about the encapsulation of the module when you compile it, and you can optimize the memory and code usage based on compiling functions that are not exported differently. That's my weak understanding, at least. Luke Great. Cleaning before loading into ghci works. Thanks, Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
