November 2012 - Haskell-Cafe

isLetter vs. isAlpha
by Artyom Kazak 23 Nov '12

23 Nov '12

Hello! I saw a question on StackOverflow about the difference between isAlpha and isLetter today. One of the answers stated that the two functions are interchangeable, even though they are implemented differently. I decided to find out whether the difference in implementation influences performance, and look what I found: > import Criterion.Main > import Data.Char >fTest name f list = bgroup name $ map (\(n,c) -> bench n $ whnf f c) list >tests = [("latin", 'e'), ("digit", '8'), ("symbol", '…'), ("greek", 'λ')] >main = defaultMain [fTest "isAlpha" isAlpha tests, > fTest "isLetter" isLetter tests] produces this table (times are in nanoseconds): latin digit symbol greek ----- ----- ------ ----- isAlpha | 156 212 368 310 isLetter | 349 344 383 310 isAlpha is twice as fast on latin inputs! Does it mean that isAlpha should be preferred? Why isn’t isLetter defined in terms of isAlpha in Data.Char?

2 1

ANNOUNCE: rethinkdb 0.1.0
by Etienne Laurin 23 Nov '12

23 Nov '12

Greetings, I am pleased to announce a Haskell client library for RethinkDB[1]. RethinkDB[2] is a newly released, open source, distributed database. Its simple yet powerful API seemed well suited to be accessed from a language like Haskell. This haskell library is modelled upon the existing Javascript and Python API and adds static type checking. Here is an example from the RethinkDB javascript tutorial[3] ported to Haskell: run h $ orderBy ["reduction"] . groupedMapReduce (! "Stname") mapF (0 :: NumberExpr) (R.+) . filter' filterF . pluck ["Stname", "POPESTIMATE2011", "Dem", "GOP"] . zip' $ eqJoin (table "county_stats") "Stname" (table "polls") where mapF doc = ((doc ! "POPESTIMATE2011") R.* ((doc ! "GOP") R.- (doc ! "Dem"))) R./ (100 :: Int) filterF doc = let dem = doc ! "Dem" :: NumberExpr; gop = doc ! "GOP" in (dem R.< gop) `and'` ((gop R.- dem) R.< (15::Int)) What is the advantage of RethinkDB? [4] "What's really special about all RethinkDB queries is that the program you wrote gets sent to the server, broken up into chunks, sent to relevant shards, executed completely in parallel (to the degree that the query makes possible -- complex queries often have multiple parallelization and recombination stages), but as a user you don't have to care about that at all. You just get the results. [...] Of course the visceral experience you get from using RethinkDB isn't just about the query language, or parallelization, or pleasant client libraries. It's about hundreds upon hundreds of examples like it, some large, some small, that add up to a completely different product. The team is fastidious about every command, every pixel, every algorithm, sometimes even every assembly instruction, so that people can use the product and at every step say `Wow, I can't believe how easy this was, how do they do that?!!' " I hope this library can help other Haskell programmers use this new database. Etienne Laurin [1] http://hackage.haskell.org/package/rethinkdb [2] http://www.rethinkdb.com [3] http://www.rethinkdb.com/docs/tutorials/elections/ [4] http://www.quora.com/RethinkDB/What-is-the-advantage-of-RethinkDB-over-Mong…

2 2

Portability of Safe Haskell packages
by Roman Cheplyaka 23 Nov '12

23 Nov '12

It has been pointed out before that in order for Safe Haskell to be useful, libraries (especially core libraries) should be annotated properly with Safe Haskell LANGUAGE pragmas. However, that would make these libraries unusable with alternative Haskell implementations, even if otherwise they these libraries are Haskell2010. To quote the standard: If a Haskell implementation does not recognize or support a particular language feature that a source file requests (or cannot support the combination of language features requested), any attempt to compile or otherwise use that file with that Haskell implementation must fail with an error. Should it be advised to surround safe annotations with CPP #ifs? Or does anyone see a better way out of this contradiction? Roman

2 1

Re: [Haskell-cafe] Compilers: Why do we need a core language?
by citb＠lavabit.com 23 Nov '12

23 Nov '12

> What would be the point in doing so? Well, I don't know. Would it save some time? Why bother with a core language?

6 8

Re: [Haskell-cafe] Compilers: Why do we need a core language?
by Richard O'Keefe 23 Nov '12

23 Nov '12

On 23/11/2012, at 1:56 AM, Jacques Carette wrote: > On 20/11/2012 6:08 PM, Richard O'Keefe wrote: >> On 21/11/2012, at 4:49 AM, <citb(a)lavabit.com> wrote: >> >>> Well, I don't know. Would it save some time? Why bother with a core language? >> For a high level language (and for this purpose, even Fortran 66 counts as >> "high level") you really don't _want_ a direct translation from source code >> to object code. You want to eliminate unused code and you want to do all >> sorts of analyses and improvements. It is *much* easier to do all that to >> a small core language than to the full source language. > > Actually, here I disagree. It might be much 'easier' for the programmers to do it for a small core language, but it may turn out to be much, much less effective. I 'discovered' this when (co-)writing a partial evaluator for Maple: we actually made our internal language *larger*, so that we could encode more invariants syntactically. This ended up making our jobs considerably easier, because we did not have to work so hard on doing fancy analyses to recover information that would otherwise have been completely obvious. Yes, there were a lot more cases, but each case was relatively easy; the alternative was a small number of extremely difficult cases. I don't think we do disagree. We are talking about the same thing: ``not hav[ing] to work so hard on doing fancy analyses''. The key point is that an (abstract) syntax *designed for the compiler* and a syntax *designed for programmers* have to satisfy different design goals and constraints; there's no reason they should be the same. As a very very crude example of this, with its user-defined operators, Prolog lets you write rules using lots of (unquoted) operators to express yourself in an quasi-English sort of way, e.g., if Block must move and top of Block is not clear then clear top of Block. Readable. But lousy for processing. You'd want to change it to something like action(clear_top(Block), [ must_move(Block), \+ top_is_clear(Block)]).

3 2

To "cabal install cabal-install" on Windows ...
by KC 22 Nov '12

22 Nov '12

- completely remove the earlier Haskell Platform - reboot - defragment the partition/hard drive - reboot - install the newer Haskell Platform - reboot - defragment the partition/hard drive (recommended) - reboot - cabal update - cabal install cabal-install It seems like what is slowing down the install process (or hanging it) is the thrashing of your hard drive to find all the little file fragments it needs during the install Casey -- -- Regards, KC

1 0

Call for Seattle Area Haskell Users Group
by Eli Frey 22 Nov '12

22 Nov '12

Greetings, (x-posted from /r/haskell) I am calling for any interested parties to come together and help me get a SEA HUG going. My boss has offered to provide facilities and foods. I don't think he's expecting much, maybe we can make him second guess the offer :P. I have put together a meetup <http://www.meetup.com/SEAHUG> group. I don't know what all Seattle area Haskellers are wanting from this kind of thing, so I thought our first meeting would be low key. Some time to shoot the bull and introduce ourselves. Some time to help each other on our stumbling blocks. Then talking about what we would want from further meetups. We'll need a central place for discussion and coordination, so aside from voicing your support, it would be great if you could take further commentary over to the meetup page. If that doesn't work for some, let me know. Hope to hear from y'all soon. - Eli

1 0

QuickCheck Generators
by graham＠fatlazycat.com 22 Nov '12

22 Nov '12

I have data Tweet = Tweet { user :: String, text :: String, retweets :: Double } deriving (Show) data TweetSet = NoTweets | SomeTweets Tweet TweetSet TweetSet and trying to create some generators for testing, with instance Arbitrary Tweet where arbitrary = liftM3 Tweet arbitrary arbitrary arbitrary instance Arbitrary TweetSet where arbitrary = sized set' where set' 0 = return NoTweets set' n | n>0 = oneof[return NoTweets, liftM3 SomeTweets arbitrary subTweets subTweets] where subTweets = set' (n `div` 2) but wondering how I would go about generating a random TweetSet that contains a known random Tweet I later have reference to and I would also assume the known Tweet to be placed randomly. Then I could test a contains function. Thanks

2 1

fixed-length bit-vectors
by Greg Fitzgerald 22 Nov '12

22 Nov '12

Hi all, My goal, eliminate the failure case in 'byte': https://gist.github.com/4128503 I don't want my 'byte' function to fail at runtime or return $ Left "vector not 8 bits". I want it to return a Word8 for an 8-bit bit-vector or not compile. Is there an existing library that offers fixed-length vectors as a thin veneer over the 'vector' package? I see 'vector-static', but it is unmaintained and hasn't been touched in years. Alternatively, there's 'VecN', but having already learned 'vector', I'd like to know if there is an existing solution that uses it. Thanks, Greg

2 1

naming and packaging things
by Rico Moorman 21 Nov '12

21 Nov '12

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

1 1