- Haskell-Cafe - Haskell.org

cabal isn't updating local doc index after local package upgrade
by Richard Cobbe 24 Nov '12

24 Nov '12

Haskell Platform 2012 v2.0.0, MacOS 64-bit. (MacOS 10.8.2.) I just used cabal to upgrade the installation of a local package I'm writing, and I'm still seeing the old version of the documentation in ~/Library/Haskell/doc/index.html. How can I fix this? In more detail: this machine had greek-1.0.1 installed, but I was working on another package that needed greek-1.1.0. So I went into the directory where I keep the source for the greek package, made sure it was up-to-date, and ran cabal clean && cabal configure && cabal build && cabal install as my normal user, not as root. As far as I can tell, the rebuild was successful; cabal's output finished with Installing library in /Users/cobbe/Library/Haskell/ghc-7.4.1/lib/greek-1.1.0/lib Registering greek-1.1.0... Updating documentation index /Users/cobbe/Library/Haskell/doc/index.html However, when I open ~/Library/Haskell/doc/index.html in my browser, I still see the documentation for greek-1.0. The docs for the new version are present, in ~/Library/Haskell/ghc-7.4.1/lib/greek-1.1.0/doc, but they don't appear in the main index. Am I missing a step in the process, or is this a bug in cabal? Is there a workaround? I do have a couple of older versions of the greek package insatlled, because there doesn't seem to be an easy way to remove obsolete packages. Could they be causing problems? If so, what's the best way to delete them? (I don't particularly mind having the older versions hanging around, as long as they're actually harmless.) Thanks much, Richard

2 2

Survey: What are the more common Haskell IDEs in use ?
by Dan 24 Nov '12

24 Nov '12

Because I see there are many preferences on what IDE to use for Haskell I've created a quick survey on this topic. Please click here and select your choices from the lists. http://kwiksurveys.com/s.asp?sid=oqr42h4jc8h0nbc53652 Any comments/suggestions are welcome. (if any is missing, etc) Apologies for the add they show after you select the preferences - it is a free survey tool - i guess they have to live somehow too :)

6 7

class Bytestringable or ToBytestring
by Vincent Hanquez 24 Nov '12

24 Nov '12

Hi cafe, I've been adding lots of types recently that looks more or less like: newtype A = A ByteString data B = B ByteString This is great for extra type safety and letting the compiler do its job, however getting the bytestring back requires boiler plate. At the moment either you give access to the constructor, which is not always wanted, or you use the record syntax to create a function to extract just the bytestring. The latter is fine for 1 or 2 types, but the scheme fall apart when having many of those types and do pollute namespace. I'm basically after something that looks like this: class ToByteString a where toByteString :: a -> ByteString Before anyone suggest the Serialize interface from cereal or the Binary interface from binary which both looks quite similar (from far away): - serialize work in the put monad, and you have to define a get instance: which is something that is not required or possible sometime. - binary works with lazy bytestrings and got the same problem as cereal. - a serialize instance that just do a single putByteString is really slow: 12 ns to 329 ns (26x time slower) on the same exact data on one isolated bench) - neither of those packages are in the platform. If that doesn't exists, could it be a worthy addition to bytestring ? is this a good idea in general ? is there any other way ? Thanks, -- Vincent

3 5

ANN: hledger-web 0.19.3
by Simon Michael 24 Nov '12

24 Nov '12

hledger-web now supports GHC 7.6 properly (no more "Prelude.read: no parse" error). Release notes: * fix "Prelude.read: no parse" errors with GHC >= 7.6 * web & lib refactoring, easier scripting/developing Thanks! -Simon hledger is a command-line tool and haskell library for tracking financial transactions, which are stored in a human-readable plain text format. In addition to reporting, it can also help you record new transactions, or convert CSV data from your bank. Add-on packages include hledger-web, a web interface. hledger is inspired by and compatible with John Wiegley's Ledger. For more, see http://hledger.org . Install it: cabal update; cabal install hledger-web For more installation help, see http://hledger.org/MANUAL.html#installing . Or, sponsor a ready-to-run binary for your platform: http://hledger.org/DOWNLOAD.html .

1 0

Re: [Haskell-cafe] Cabal failures...
by Gregory Guthrie 24 Nov '12

24 Nov '12

No; the first sentence says that someone else had reported that testing on Windows was hard to do because of (a perceived) lack of access to Windows by Haskell developers... The implication is that Haskell developers (only/mainly) use *nix. I commented that if true this lack of Windows testing could limit the availability of Haskell to the largest market share of users. ------------------------------------------- > Subject: Re: [Haskell-cafe] Cabal failures... > To: haskell-cafe(a)haskell.org > On 12-11-20 08:48 AM, Gregory Guthrie wrote: > > It was also interesting to note a comment that most developers don't > > have access to a Windows machine for testing. With Windows at >90% of > > the computing market (Linux = 1.6%), this seems like a problem which > > might limit growth of Haskell usage. Just an observation. :-) > > There is a paradox in that sentence. > > The first sentence says, most developers don't have access to Windows machines for > testing. But they have access to Linux machines. Then Windows machines must be a scarcity > compared to Linux machines, no? So scarce, you even have difficulty borrowing or renting. > > Then the next sentence says, the scarcity is the other way round, Linux machines are scarce, > Windows machines are abundant. OK, so why is it so hard to access something abundant, and > so easy to access something scarce? > ------------------------------

11 15

isLetter vs. isAlpha
by Artyom Kazak 24 Nov '12

24 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 24 Nov '12

24 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