- Haskell-Cafe - Haskell.org

Fwd: Re: Binary and Serialize classes
by Alberto G. Corona 04 May '11

04 May '11

---------- Forwarded message ---------- De: "Alberto G. Corona" <agocorona(a)gmail.com> Fecha: 03/05/2011 11:24 Asunto: Re: [Haskell-cafe] Binary and Serialize classes Para: "Antoine Latter" <aslatter(a)gmail.com> E1610With the exception of heavy serialization usage, for example, in very optimized RPC applications (and even there SOAP shows that this is not ever the case), text serialization is better. The unwritten rules of good design says that data representation and compression must be orthogonal. The binary formats were designed for performing both functionalities in the times when memory were measured in Kbytes. 2011/4/28 Antoine Latter <aslatter(a)gmail.com> > > On Thu, Apr 28, 2011 at 10:00 AM, Evan Laforge <...

2 1

runST readSTRef type error
by Ken Takusagawa II 04 May '11

04 May '11

I run into the following type error: foo :: ST s (STRef s Int) -> Int foo p = (runST (p >>= readSTRef)) with ghc 6.12.1 st.hs:8:16: Couldn't match expected type `s1' against inferred type `s' `s1' is a rigid type variable bound by the polymorphic type `forall s1. ST s1 a' at st.hs:8:9 `s' is a rigid type variable bound by the type signature for `foo' at st.hs:7:10 Expected type: ST s1 (STRef s Int) Inferred type: ST s (STRef s Int) In the first argument of `(>>=)', namely `p' In the first argument of `runST', namely `(p >>= readSTRef)' However, if I add {-# LANGUAGE RankNTypes #-} and change the type signature to foo :: (forall s.ST s (STRef s Int)) -> Int it works. I don't fully understand what's going on here. Is this the "right" way to fix the problem? Are there other options? My gut feeling is, for such a simple use case of the ST monad, I shouldn't need such a big hammer as RankNTypes. --ken

3 2

ANN: Leksah 0.10.0
by Hamish Mackenzie 04 May '11

04 May '11

Yesterday we uploaded our official 0.10.0 release (0.10.0.4) to Hackage and we have Windows and OS X installers at http://leksah.org/download.html Anyone using an earlier version should upgrade. This release is mainly small improvements and bug fixes. Some of the improvements include: * Better messages for some common problems. * Improved grep (now searches all source directories in your workspace) * Updated build system for more reliable rebuilding of dependent packages in your workspace We have automated the building of the Leksah installers and this should allow us to do more frequent releases in the future. There is a lot more to do and we would love to hear from anyone who has time to help out. Worth mentioning because they can be hard to find: * <Ctrl> R adds missing imports * <Ctrl> <Enter> evaluates current line or selection in GHCi * Right click menu in the editor has other debug functions * Comment and uncomment are now <Ctrl> D and <Ctrl> <Shift> D To build Leksah yourself: * Install Gtk and GtkSourceView2 (C libraries and headers) * Install The Haskell Platform (or GHC >= 6.12.3) * cabal update * cabal install gtk2hs-buildtools * cabal install leksah * leksah Making a Gtk application look nice on Windows and OS X is not easy so we recommend using one of these prebuilt binaries: Windows users using GHC 7.0.3 http://leksah.org/packages/leksah-0.10.0.4-ghc-7.0.3.exe Windows users using GHC 6.12.3 http://leksah.org/packages/leksah-0.10.0.4-ghc-6.12.3.exe OS X 10.6 users using GHC 7.0.3 http://leksah.org/packages/leksah-0.8.0.6.dmg (These installers do not install Gtk2Hs packages on your system) Please consult http://leksah.org/download.html for more details about installation! Background information can be found in the Leksah manual http://leksah.org/leksah_manual.pdf. Known bugs and problems: * Leksah does not run with GHC 6.12.2 (http://http://hackage.haskell.org/trac/ghc/ticket/4038) Have fun Jürgen & Hamish See you on #leksah IRC

11 19

Filtering / branching enumeratee
by Skirmantas Kligys 04 May '11

04 May '11

Hello, I am using enumerator-0.4.10, and I need to distribute processing of different parts of the incoming stream to different iteratees (I am parsing a huge XML file, and different sub-trees have different processing logic). Only a single iteratee will be active at a time since the sub-trees don't intersect. I wrote a simple example that filters the stream and passes the result to one iteratee; please see below. However, with multiple nested iteratees it seems to me that I can no longer use an enumeratee. Do I need to write my own multi-enumeratee that holds multiple inner iteratees? Any better ideas? Here is my (beginner's) code for a single nested iteratee: module Main ( main ) where import qualified Data.Enumerator as E ( Enumeratee, Step(..), Stream(..), checkDone, checkDoneEx, continue, enumList, joinI, run_, yield ) import Data.Enumerator ( ($$), (>>==) ) import qualified Data.Enumerator.List as EL ( consume ) -- cribbed from EL.concatMap concatMapAccum :: Monad m => (s -> ao -> (s, [ai])) -> s -> E.Enumeratee ao ai m b concatMapAccum f s0 = E.checkDone (E.continue . step s0) where step _ k E.EOF = E.yield (E.Continue k) E.EOF step s k (E.Chunks xs) = loop s k xs loop s k [] = E.continue (step s k) loop s k (x:xs) = case f s x of (s', ais) -> k (E.Chunks $ ais) >>== E.checkDoneEx (E.Chunks xs) (\k' -> loop s' k' xs) passFromTo :: Monad m => ((a -> Bool), (a -> Bool)) -> Bool -> E.Enumeratee a a m b passFromTo (from, to) pass0 = concatMapAccum updatePass pass0 where updatePass pass el = case (pass, from el, to el) of (True, _, to_el) -> (not to_el, [el]) (False, True, _) -> (True, [el]) (False, False, _) -> (False, []) main :: IO() main = do E.run_ (E.enumList 3 [1..20] $$ E.joinI $ passFromTo ((\e -> e == 3 || e == 13), (\e -> e == 7 || e == 17)) False $$ EL.consume) >>= print $ ./dist/build/StatefulEnumeratee/StatefulEnumeratee [3,4,5,6,7,13,14,15,16,17]

1 0

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