Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
Hello Bob and Mike, Reading a little within the suggested book I came across the following statement. We should first examine the merits and limitations of the traditional approach: using functions as a basis for the architecture of software systems. This will not only lead us to appreciate why we need something else — object technology — but also help us avoid, when we do move into the object world, certain methodological pitfalls such as premature operation ordering, which have been known to fool even experienced O-O developers. Because you both have more experience with this piece of literature, how would you interpret it? With a grain of salt or would function really mean procedure from the viewpoint of the author? Thank you very much in advance. Best regards, Rico Moorman On Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison hutch-li...@recursive.cawrote: On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva dhelta.d...@gmail.com wrote: Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life. So my questions for you all are: * Is it really worthwhile for me to learn OO-programming? Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big. As for languages I'd suggest Smalltalk or Eiffel, perhaps both. The big advantage to Eiffel is that you have Object Oriented Software Construction (second edition (not first)) to work from. Every OO language has to answer to the issues brought up in OOSC2 (and they don't/can't). Eiffel's inheritance mechanism is also one of the few that let you use inheritance to do useful things (OOSC2 names 16 or 18 different uses for inheritance… it's not just for 'is-a' relationships). Eiffel also has a contract system that's powerful enough to be useful. Smalltalk's advantage is that it will also introduce you to the idea of a programming 'system', for lack of better words. Smalltalk works in a live system, as you are writing code you are modifying live and already executing code. Once you realize that the 'best' editor in Smalltalk is the debugger (and what 'a good debugger' actually means) you'll understand test-driven-development's origins. This is very different from Haskell. Actually, you should probably learn both languages. I don't think C++ will help you learn OO, or much of anything else either. Vigorously avoid is my advice. C you're probably going to have to learn sooner or later but wait until you have to. And it's not OO at all. Though, if you learn KR C (pre-ansi C) you'll get a better understanding of why people liked OO so much :-) Ruby might be an easy route to OO too. I like the language quite a lot, but I'm not sure I'd recommend it for your purposes. * If so, where should I start? There are plenty of functional programming for OO programmers but I have never seen OO programming for functional programmers. * Is it true that learning other programming languages leads to a better use of your favorite programming language? That's been my experience. And it'll be harder to name your favourite language too. * Will I learn new programming strategies that I can use back in the Haskell world? Probably. Cheers, Bob Thanks in advance for your kind responses, Daniel Díaz. ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A weird bug of regex-pcre
I had similar issues a while ago. It had to do with UTF-8 encoding as far as I can recall. I wanted to wrap a multiline string (code listings) within some pandoc generated HTML of a hakyll page with a container div. The text to wrap would be determined using a PCRE regex. Here the (probably inefficient) implementation: module Transformations where import Hakyll import qualified Text.Regex.PCRE as RE import qualified Data.ByteString.UTF8 as BSU import qualified Data.ByteString as BS -- Wraps numbered code listings within the page body with a div -- in order to be able to apply some more specific styling. wrapNumberedCodelistings (Page meta body) = Page meta newBody where newBody = regexReplace' regex wrap body regex = table\\s+class=\sourceCode[^]+.*?/table- wrap x = div class=\sourceCodeWrap\ ++ x ++ /div -- Replace the whole string matched by the given -- regex using the given replacement function (hopefully UTF8-aware) regexReplace' :: String - (String - String) - String - String regexReplace' pattern replace text = BSU.toString $ go textUTF8 where patternUTF8 = BSU.fromString pattern textUTF8 = BSU.fromString text replaceUTF8 x = BSU.fromString $ replace $ BSU.toString x regex = RE.makeRegexOpts compOpts RE.defaultExecOpt $ BSU.fromString pattern compOpts = RE.compMultiline + RE.compDotAll + RE.compUTF8 + RE.compNoUTF8Check go part = case RE.matchM regex part of Just (before, match, after) - BS.concat [before, replaceUTF8 match, go after] _ - part The discussion back then was http://www.haskell.org/pipermail/beginners/2012-June/010064.html Hope this helps. Best regards, Rico Moorman P.S. Sorry for the double email Magicloud ... didn't hit reply all at first On Tue, Dec 18, 2012 at 10:43 AM, José Romildo Malaquias j.romi...@gmail.com wrote: On Tue, Dec 18, 2012 at 02:28:26PM +0800, Magicloud Magiclouds wrote: Attachment is the test text file. And I tested my regexp as this: Prelude :m + Text.Regex.PCRE Prelude Text.Regex.PCRE z - readFile test.html Prelude Text.Regex.PCRE let (b, m ,a, ss) = z =~ a href=\(.*?)\.*?img class=\article-image\ :: (String, String, String, [String]) Prelude Text.Regex.PCRE b ... n of the Triumvirate/td\r\ntd class=\small\David Rapoza/td\r\n td class=\small\\r\n iReturn to Ravnica/i\r\n /td\r\n td class=\small\10/31/2012/td\r\n /trtr\r\n td class=\small\ Prelude Text.Regex.PCRE m a href=\/magic/magazine/article.aspx?x=mtg/daily/activity/1088\img class=\article-image\ From the value of b and m, it was weird that the matching was moved forward by 1 char ( the ss (sub matching) was even worse, 2 chars ). Rematch to a and so on gave correct results. It was only the first matching that was broken. Tested with regex-posix (with modified regexp), everything is OK. I have a similar issue with non-ascii strings. It seems that the internal representation used by Haskell and pcre are different and one of them is counting bytes and the other is counting code points. So they diverge when a multi-byte representation (like utf8) is used. It has been reported previously. See these threads: http://www.haskell.org/pipermail/haskell-cafe/2012-August/thread.html#102959 http://www.haskell.org/pipermail/haskell-cafe/2012-August/thread.html#103029 I am still waiting for a new release of regex-pcre that fixes this issue. Romildo ___ 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] A weird bug of regex-pcre
regex = table\\s+class=\sourceCode[^]+.*?/table- And mind the sneaky single - ... it doe not belong there ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] naming and packaging things
Hi everyone, As anyone following this mailinglist surely noticed, there are a few issues regarding haskell packaging. Lot of discussion is going on about how cabal contributes to the problems and how things could be fixed by making our tools smarter (which is a great thing to do IMHO). I think though, that there might be other ways to deal with or at least reduce the problems. One of those ways would be expressing the influence of changes in a package's public API, using the name of a package instead of just version numbers. I mean, in case a major backwards incompatible/breaking change happens, one would change the name of the package/namespaces a.s.o. And with breaking I really mean that kind of oh my ... now I have to rewrite this part of my application because of this. Simple additions to the API do not count as breaking because existing functionality is left alone. This way, incompatible versions of the same library can coexist without any problems right within the same program if one chose to do so even allowing for improved transition processes for larger application I presume. It would easily be possible to safely install newer versions of the same package without breaking things. There are more open source libraries/projects as it seems, which use this approach (version number in the package name) such as the kdelibs, gtk, beautifulsoup, apache and bind. One example: take an application which needs two libraries A and B which both depend on library C. Now lets assume that A uses a slightly older version of C and B uses a version with a major incompatibility. In the current versioning scheme, there could be major problems causing development delays or custom forks to emerge a.s.o. But following the other naming method, in case library C chooses to introduce a major breaking change in the public API, a new package C2 is born, which can be used alongside C (and effectively is a different library anyway I think). The choice for the new version of C (C2) is explicit within the name and all related things. I am aware of the fact that this would take more forethought on library design, but I do not think that this alone would be a bad idea anyway. Also it would be difficult to enforce this, but well, a good maintainer would be aware of this anyway, taking care of not introducing breaking changes to the public API I guess. Furthermore we would end up with more packages with different names (but probably the same idea behind it) which would be on hackage. Likely it would be nice to add some grouping or tagging features which would bind them together for everyone browsing the packages. But I think this is probably not a real problem but more a cosmetic one. I really would like to see this discussed here. What would be the good and the bad of promoting this kind of versioning. I am looking forward to hear what you think. Best regards, Rico Moorman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] naming and packaging things
Hi everyone, As anyone following this mailinglist surely noticed, there are a few issues regarding haskell packaging. Lot of discussion is going on about how cabal contributes to the problems and how things could be fixed by making our tools smarter (which is a great thing to do IMHO). I think though, that there might be other ways to deal with or at least reduce the problems. One of those ways would be expressing the influence of changes in a package's public API, using the name of a package instead of just version numbers. I mean, in case a major backwards incompatible/breaking change happens, one would change the name of the package/namespaces a.s.o. And with breaking I really mean that kind of oh my ... now I have to rewrite this part of my application because of this. Simple additions to the API do not count as breaking because existing functionality is left alone. This way, incompatible versions of the same library can coexist without any problems right within the same program if one chose to do so even allowing for improved transition processes for larger application I presume. It would easily be possible to safely install newer versions of the same package without breaking things. There are more open source libraries/projects as it seems, which use this approach (version number in the package name) such as the kdelibs, gtk, beautifulsoup, apache and bind. One example: take an application which needs two libraries A and B which both depend on library C. Now lets assume that A uses a slightly older version of C and B uses a version with a major incompatibility. In the current versioning scheme, there could be major problems causing development delays or custom forks to emerge a.s.o. But following the other naming method, in case library C chooses to introduce a major breaking change in the public API, a new package C2 is born, which can be used alongside C (and effectively is a different library anyway I think). The choice for the new version of C (C2) is explicit within the name and all related things. I am aware of the fact that this would take more forethought on library design, but I do not think that this alone would be a bad idea anyway. Also it would be difficult to enforce this, but well, a good maintainer would be aware of this anyway, taking care of not introducing breaking changes to the public API I guess. Furthermore we would end up with more packages with different names (but probably the same idea behind it) which would be on hackage. Likely it would be nice to add some grouping or tagging features which would bind them together for everyone browsing the packages. But I think this is probably not a real problem but more a cosmetic one. I really would like to see this discussed here. What would be the good and the bad of promoting this kind of versioning? I am looking forward to hear what you think. Best regards, Rico Moorman P.S. sorry if you got this twice but I seem to have mail problems at the moment ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how to check thunk
Dear Austin, Wouldn't it be a good idea to link the Vacuum version-number to the related ghc version number directly as it's functionality is directly tied to the ghc version anyway. vacuum 7.4 for ghc 7.4; vacuum 7.2 for ghc 7.2 aso. Best regards, Rico Moorman On Mon, Jul 2, 2012 at 12:04 PM, Austin Seipp mad@gmail.com wrote: Hi, Just a word of note: a while back, I decided to take up maintainership of Vacuum and some associated stuff. In the process of doing this, I realized that the ClosureType code in vacuum may not accurately model reality depending on the GHC version. In particular, the definition of ClosureType in vacuum as currently released on Hackage is woefully out of date with respect to Modern GHC. Matt Morrow it seems originally just copied the definition wholesale when he developed it, but as GHC has evolved, so too has the ClosureType definition. Vacuum has not kept up. I have a github repository[1] containing several cleanups of Vacuum which I'm calling Vacuum 2.0, one of these cleanups being that the ClosureType definition is automatically generated from the GHC definition, and compiled-in accordingly. I have also dropped support for older GHCs (although it could be re-added.) In this case, based on the changes I made I believe it is fairly unlikely that isThunk would turn up being wrong here. The THUNK* definitions seem to have been relatively untouched over GHC's evolution. But for more advanced functionality, it could possibly result in Vacuum as it stands constructing an invalid heap representation based on object misinterpretations. I have been busy with a new job but I am not totally absent, and I think I will take this opportunity to release v2.0 in short order, which is mostly intended as a polish and maintenance release for modern GHCs. In the future I would like to see vacuum deprecated and move all its functionality into GHC - much of the code is deeply intertwined with GHC's runtime representations and in some cases I have seen code in the package that was literally copied verbatim from the GHC sources itself, obviously dating several years. It's hard to assess the validity of much of this code. All of this feels brittle and makes me uneasy, and given the complexity of the package as it stands, will make it extremely difficult to maintain as GHC moves forward. Sorry for the ramble, but I figured it might be relevant if people are going to rely on this functionality. [1] https://github.com/thoughtpolice/vacuum On Mon, Jul 2, 2012 at 2:54 AM, Erik Hesselink hessel...@gmail.com wrote: There is also the 'isevaluated' package (which depends on vacuum, but seems to do something more involved than your code). Erik On Mon, Jul 2, 2012 at 7:40 AM, Chaddaï Fouché chaddai.fou...@gmail.com wrote: On Mon, Jul 2, 2012 at 5:29 AM, Kazu Yamamoto k...@iij.ad.jp wrote: Hello, Are there any ways to see if a value is a thunk or memorized? I would like to have a function like: isThunk :: a - IO Bool vacuum allow that and much more though I don't know if it still works correctly on GHC 7.4. Anyway your isThunk is isThunk a = fmap GHC.Vacuum.ClosureType.isThunk GHC.Vacuum.closureType (Feel free to arrange your imports to make that a bit more readable ;) http://hackage.haskell.org/package/vacuum -- Jedaï ___ 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 -- Regards, Austin ___ 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] Installing pandoc / json with ghc 6.12.1
Hello, I recently tried to install the latest version of pandoc on my debian stable box (with ghc 6.12.1) using virthualenv as sandboxing mechanism. But instead of a normal installation, compilation of the json package (more specifically the Text.JSON.Parsec module) hangs and causes ghc to consume around 2GB of RAM (out of 3GB) and the system to swap and hang. For reference ... I just created a plain virthualenv (for sandboxing) and after that ran (tmp) foo@bar:/tmp$ cabal install json I also tried if this has something to do with version 0.5 (the latest version) only, to no avail. Are there other users of pandoc/json or related packages who encountered/solved this issue? Am I doing something wrong here? Best regards, Rico ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
