May 2011 - Haskell-Cafe

Robert Harper on monads and laziness
by Ketil Malde 03 May '11

03 May '11

I'm following Harper's blog, Existential Type¹, which I find to be an enjoyable and entertainingly written tirade about the advantages of teaching functional programming - specifically ML - to students. Of course, he tends to be critical of Haskell, but it's nice to get some thought provoking opinion from somebody who knows a bit about the business. Recently, he had a piece on monads, and how to do them in ML, and one statement puzzled me: "There is a particular reason why monads had to arise in Haskell, though, which is to defeat the scourge of laziness." My own view is/was that monads were so successful in Haskell since it allowed writing flexible programs with imperative features, without sacrificing referential transparency. Although people are quick (and rightly so) to point out that this flexibility goes way beyond IO, I think IO was in many ways the killer application for monads. Before IO, we had very limited functionality (like 'interact' taking a 'String -> String' function and converting it into an exectuable program) to build real programs from. Laziness does require referential transparency (or at least, it is easier to get away with the lack of RT in a strict language), so I can see that he is indirectly correct, but RT is a goal in itself. Thus, I wonder if there are any other rationale for a statement like that? -k ¹ http://existentialtype.wordpress.com/ -- If I haven't seen further, it is by standing in the footprints of giants

9 11

Please add instance Semigroup Text
by Yitzchak Gale 03 May '11

03 May '11

Hi Edward, Could you please add a Semigroup instance for Text? Once you're doing that, I suppose you'd also want to add it for lazy Text and both kinds of ByteStrings. But what I currently need is strict Text. The reason, of course, is that in complex calculations <> is *so* much more readable than `mappend`. Obviously WrappedMonoid is useless there. Hmm, and now for Semigroup and Monoid we start down the same path as for Functor and Monad... Or should we give <> back to Monoid and use something different for Semigroup? That doesn't seem very nice either... Well, in the meantime, you really will make my life easier if you could add some more Semigroup instances for popular Monoids. Thanks, Yitz

5 6

Re: [Haskell-cafe] Re: Functional dependencies and Peano numbers (and hoogle-bug?)
by Oscar Finnsson 03 May '11

03 May '11

Thanks for the great feedback. The bijective example was especially interesting. While reading "Fun with Type Functions" I notices GNum as an interesting alternative to the Num type class but I couldn't find any such package on hackagedb. Do anyone know if there is anything like GNum on hackagedb? On an unrelated note: I hoogled "to" (i.e. http://haskell.org/hoogle/?hoogle=to) and just got a blank page. Nothing. Nil (not even <html>...</html>). Is this a bug or a "feature"? :) The reason I hoogled it was because I'm searching for something like explicit casting found in many other languages, something similar to > class To f t where > to :: f -> t > > instance To a a where > to x = x > > instance (Real a, Fractional b) => To a b where > to = realToFrac > > instance (Read a) => To String (Maybe a) where > to = maybeRead -- not from cgi :) so I can write something like > ("23.2" `to`) :: Maybe Double or > ((42 :: Integer) `to`) :: Float Anyone made a module/package that solves this problem already? I cannot be the first that needs generic type safe conversion... . -- Oscar

3 2

Is Harper right that Haskell cannot model the natural numbers?
by Richard O'Keefe 03 May '11

03 May '11

In one of his blog posts, Robert Harper claims that the natural numbers are not definable in Haskell. SML datatype nat = ZERO | SUCC of nat Haskell data Nat = Zero | Succ Nat differ in that the SML version has strict constructors, and so only finite instances of nat can be constructed, whereas Haskell has lazy constructors, so inf = Succ inf is constructible, but that's not a natural number, and it isn't bottom either, so this is not a model of the natural numbers. Fair enough, but what about data Nat = Zero | Succ !Nat where the constructors *are* strict? It's perfectly good Haskell 98 as far as I can see. Now "Nat" itself isn't _quite_ a model of the naturals because it includes bottom, but then an SML function returning nat can also fail, so arguably SML's nat could or should be thought of as including bottom too. What am I missing?

5 4

"Computational Semantics w/ Functional Programming", Jan van Eijck and Christina Unger, 2010. It's in #Haskell. :)
by caseyh＠istar.ca 03 May '11

03 May '11

This may have already been mentioned but it is worth mentioning n times: "Computational Semantics w/ Functional Programming", Jan van Eijck and Christina Unger, 2010. It's in #Haskell. :)

2 1

Idea for Haddock: Specifying a syntax field when using template splicing
by Mathew de Detrich 03 May '11

03 May '11

I just had an idea while I was working on a webserver in Haskell, where I not only enter Haskell code (obviously) but I also enter Javascript and CSS code in functions that use QuasiQuoting (i.e. TemplateHaskell). The idea is basically that with standard Haddock comments you can specify a 'tag' for function argument that has a QuasiQuoter as a type, the 'tag' specifying the syntax of the code inside of what is being spliced (for that specific function). The generated haddock documentation would then display the syntax tag for that specific function. The purpose for this would be that IDE's and Editors would pick up that the code going through the QuasiQuoter has a certain syntax, and the IDE/Editors can then apply syntax coloring (and indenting rules and whatnot) to that piece of code I guess this tag concept can be applied generally to any type of function (and any type of tag, not just tags for syntax) but there should be some standardization, (tag types especially should be static, tag values don't have to) Thoughts?

1 0

Binary and Serialize classes
by Evan Laforge 02 May '11

02 May '11

It's been remarked to me that relying on the Binary and Serialize classes is dangerous, because there's no guarantee they won't maintain a consistent format. So if my app uses the Serialize instances that come with cereal, it could suddenly fail to read old saves after an upgrade to cereal. However, neither binary nor cereal expose the underlying serialization algorithms for various types except through the instances, so I would have to copy and paste the code over if I want control over it. If I don't trust 'instance Serialize String' to not change behind my back, maybe I could at least trust 'Data.Serialize.stringToUtf8' to not change since if it did the name would now be wrong. Are these fears justified? I imagine if the Int instance for Serialize changed there would be an uproar and it would probably have to be changed back. I sent a bug to the maintainers of data-binary a long time ago about the Double instance not serializing -0, and they ignored it, probably because it would be bad to change the instance. So can I use the included instances without fear of them changing between releases? Of course I still run the risk of an instance from some other package changing, but I'm less likely to be using those. Speaking of that Double instance... both data-binary and cereal use decodeFloat and encodeFloat which mean they suffer from the same problems as realToFrac, namely that -0 becomes 0 and NaN becomes -Infinity (I'm not sure why the latter happens since the decoded values differ... must be a problem with encodeFloat). It's tempting to just get the ieee754 bitmap out and serialize that. I know I've seen this question around before, but is it possible to somehow cast a D# directly to bytes? I know I can write a C function and FFI that in, but it would be tidier to do it all in haskell. I guess I can probably use castPtr and memCpy, but I don't see the required addressOf. I.e. how would I write 'memcpy(buf, &d, sizeof(double));'?

6 7

Re: [Haskell-cafe] Interfacing C++ iterators does not work as expected
by Huynh Huu Long 02 May '11

02 May '11

Big thanks, that works for me as well. Doesn't GHC check whether a type is allowed (like CInt,...) or not (like Bool,...)? 2011/5/2 Gábor Lehel <illissius(a)gmail.com>: > It works if I replace the 'bool' return type of 'finished' with int > and CInt on the C++ and Haskell side, respectively, and test for (/= > 0).

2 1

Reformatter for Show
by Alexey Khudyakov 02 May '11

02 May '11

Hello everyone! Haskell have nice automatically derivable Show type class. It's quite useful for debugging with one exception. String representation of even moderately large value is completely unreadable (example below). My question is there any tool for reformatting result of show so it could be read by human beings? Real life example of world salad produced by show > Module (SrcLoc {srcFilename = "rec.hs", srcLine = 1, srcColumn = 1}) > (ModuleName "Main") [OptionsPragma (SrcLoc {srcFilename = "rec.hs", > srcLine = 1, srcColumn = 1}) (Just GHC) "-F -pgmF ./preprocessor "] > Nothing (Just [EVar (UnQual (Ident "main"))]) [] [DataDecl (SrcLoc > {srcFilename = "rec.hs", srcLine = 3, srcColumn = 1}) DataType [] > (Ident "Foo") [] [QualConDecl (SrcLoc {srcFilename = "rec.hs", > srcLine = 3, srcColumn = 12}) [] [] (RecDecl (Ident "Foo") [([Ident > "asd"],UnBangedTy (TyCon (UnQual (Ident "Int")))),([Ident > "fgh"],UnBangedTy (TyCon (UnQual (Ident "String"))))])] [(UnQual > ...

5 5

versioning of Haskell packages
by Daniil Elovkov 02 May '11

02 May '11

Hello list I have an idea on versioning of Haskell packages and a small question about release model of Haskell Platform. Since the latter is shorter let's start with it. So, what is the release model of Haskell Platform? Is it released every N months and frozen at that point? Or some intermediate package/compiler updates can make the new version to appear out of schedule? Now, about package versioning. Haskell packages are flourishing and evolving at a high speed. Packages depend on other package and they evolve asynchronously. In result it is easy to end up in need of multiple versions of the same package in one program or maybe stumble upon other conflicts/problems. I'm expressing myself a little vaguely because I don't have a good example in my head right now. However, the idea is to maintain not just multi-digit version names that don't carry any semantics except that 1.1.3 is later than 1.1.2, but also somehow describe compatibility between versions. This way, even if the package A has jumped from 1.0 to 1.5 and the dependent package B has been stagnant all this time (and B depends on A 1.0), if we have information that 1.5 is compatible with 1.0, then we can safely use A 1.5 while building B. Or we could use whatever version of A is found in the system as long as its compatible with A 1.0 that B depends on. The compatibility relation can be made more fine grained and be applied not at the level of packages but that of modules, for example. This way, if we only use modules that are compatible with the version we depend on, it's fine to go with the newer version. Even if the package as a whole is not compatible. Also, when doing this at the level of modules, package authors could deliberately maintain compatibility by leaving the API of old modules intact and making them sort of wrappers to the new API which itself is not compatible with the older version. Of course, if the case when a newer version is backwards compatible is rare for most Haskell packages, then the idea doesn't make a lot of sense. But if it's common, then this could simplify building packages/programs and maintaining installed packages. What do you think? -- Daniil Elovkov

4 4