January 2009 - Haskell-Cafe

GHC 6.10.1 for Solaris i86
by Donald Halomoan 05 Jan '09

05 Jan '09

I am waiting for GHC 6.10. 1 binary for Solaris i86. Thanks.

3 2

Portability of MonadError
by Peter Robinson 05 Jan '09

05 Jan '09

Hello, One thing that's been bothering me about MonadError monads is the non-portability of code that uses a custom Error type. Meaning, if I have libraries A and B that use different error types, I won't be able to write a function func: func = (funcA >> funcB) `catchError` (\e -> ...) funcA :: ErrorT MyErrorA m () funcB :: ErrorT MyErrorB m () So I'm wondering whether there's a reason not to introduce a type class hierarchy instead of custom error types to make the code more portable. Something like this: -------------------- import Control.Exception(IOException) import Control.Monad.Error class (Eq e,Show e,Error e) => MyExc e where myExc1 :: e myExc1 = strMsg "myExc1" -- Now we can simply extend MyExc and catch all errors defined in MyExc and -- MyExc2 in the same error-handler (see handler2 below): class MyExc e => MyExc2 e where myExc2 :: e myExc2 = strMsg "myExc2" -- Uses the error class MyExc test1:: (MonadError e m, Monad m, MonadIO m, MyExc e) => m () test1 = do liftIO $ putStrLn "############ Throwing myExc1: " throwError myExc1 `catchError` handler1 -- Uses the error class MyExc2 that extends MyExc test2 :: (MonadError e m,MonadIO m, MyExc2 e) => m () test2 = do liftIO $ putStrLn "\n############ Throwing myExc2: " throwError myExc2 `catchError` handler2 -- Uses the error type class MyExc2 but throws an error -- already defined in MyExc test3 :: (MonadError e m,MonadIO m,MyExc2 e) => m () test3 = do liftIO $ putStrLn "\n############ Throwing myExc1 within context MyExc2: " throwError myExc1 `catchError` handler2 -- Error handler for class MyExc handler1 :: (MonadError e m, MonadIO m,Monad m,MyExc e) => e -> m () handler1 e = do when (e == myExc1) $ liftIO $ putStrLn $ "Caught a MyExc1 " ++ show e -- Error handler for class MyExc2 (catches errors in MyExc1) handler2 :: (MonadError e m, MonadIO m,Monad m,MyExc2 e) => e -> m () handler2 e = do when (e == myExc1) $ do liftIO $ putStrLn $ "Caught a MyExc1 " ++ show e throwError e when (e == myExc2) $ liftIO $ putStrLn $ "Caught a MyExc2 " ++ show e -- To run the code in the IO monad we need: instance MyExc IOException where myExc1 = userError "myExc1 has occurred" instance MyExc2 IOException where myExc2 = userError "myExc2 has occurred" -- Run test1 and test2 in the IO monad mymain :: IO () mymain = (test1 >> test2 >> test3) `catchError` (\e -> putStrLn $ "Something went wrong...\n" ++ show e) -- Now let's try a custom monad: newtype MyMonad e a = MyMonad { runMM :: ErrorT e IO a } deriving(Monad,MonadError e,MonadIO) runMyMonad :: Error e => MyMonad e a -> IO (Either e a) runMyMonad = runErrorT . runMM mymainT :: IO () mymainT = do res <- runMyMonad (test1 >> test2 >> test3 :: MyMonad IOException ()) case res of Left e -> putStrLn $ "Something went wrong...\n" ++ show e _ -> return () ---------------------- Maybe I'm missing something but is there any advantage of using custom data types rather than the typeclass approach? Cheers, Peter PS: Please be frank if I'm reinventing the wheel here... :-)

3 5

Infinite grid
by Martijn van Steenbergen 05 Jan '09

05 Jan '09

Hello, I would like to construct an infinite two-dimensional grid of nodes, where a node looks like this: > data Node = Node > { north :: Node > , east :: Node > , south :: Node > , west :: Node > } in such a way that for every node n in the grid it doesn't matter how I travel to n, I always end up in the same memory location for that node. I suspect another way of saying that is that > let f = f . north . east . south . west in f origin should run in constant space. I hope this makes the problem clear. :-) How do I do this? Thanks in advance, Martijn.

6 8

Trouble with interact in ghci
by Adrian Neumann 05 Jan '09

05 Jan '09

Hi, I have a strange problem with "interact" on OS X (ghc 6.10.1). It seems to garble stdin. I have some code here http://hpaste.org/13135#a2 , for testing purpose: *Main> main 1 > 1.0 2 > 1.5 3 > 2.0 *Main> setNonBlockingFD: invalid argument (Bad file descriptor) 11:40:45 ~/Desktop> (I hit ctrl-D) *Main> main 1 > 1.0 2 > 1.5 3 > 2.0 ^CInterrupted. *Main> main *** Exception: <stdin>: hGetContents: illegal operation (handle is closed) *Main> Someone on #haskell suspected my editline to be the culprit. Does anyone of you know what I can do about this problem? Greetings, Adrian

2 1

nested function application question
by Galchin, Vasili 05 Jan '09

05 Jan '09

Hello, I have the following: B.intercalate $ B.intercalate ByteString [ByteString] [ByteString] I get a type error with this. If I comment out the 2nd B.intercalate and the third parameter I get no type errors. Regards, Vasili

5 10

Is Arrow based FRP a subset of Classic FRP, at least conceptually/semantically?
by Peter Verswyvelen 05 Jan '09

05 Jan '09

Classic FRP ("CFRP", like Fran, FAL, Reactive, Grapefruit?...) exposes signals as first class values. Arrow based FRP ("AFRP", like Fruit, Yampa...) hides signals as first class values; instead the signal transformers are the first class values. Can I conclude that it would theoretically be possible to translate an AFRP function into a CFRP function? I.e. is AFRP a subset of CFRP? Thanks, Peter

2 1

Inferno and Haskell?
by Mauricio 05 Jan '09

05 Jan '09

Hi, Do you guys know the Inferno platform? en.wikipedia.org/wiki/Inferno_(operating_system) Wouldn't it be a nice place to run GHC? All written in a type safe language (what kind of safety I'm not smart enough to say), seems to have a much simpler design than regular unix, virtual machine runs everywhere and, from my non-expert point of view, probably good for embedded software. This is, however, one of those I-have-no-idea-on- how-much-effort-is-needed-and-have-no-knowledge-to- help questions... Sorry for that. Best, Maurício

1 0

Use of abbreviations in Haskell
by Felix Martini 05 Jan '09

05 Jan '09

Hi all, There is currently a discussion on reddit/programming about Haskell. One complaint is that Haskell functions often use abbreviated names. I tend to agree with that. In my personal experience it generally takes more time to learn a third party Haskell library than libraries written in other languages. I am not sure why but it could be because of function names. It seems to me that Haskell's current record syntax enhances this. Take for example the new xml library, data Element = Element { elName :: QName elAttribs :: [Attr] elContent :: [Content] elLine :: Maybe Line } data Attr = Attr { attrKey :: QName attrVal :: String } data QName = QName { qName :: String qURI :: Maybe String qPrefix :: Maybe String } Personally i would prefer it to be something like data Element = Element { name :: QualifiedName attributes :: [Attribute] content :: [Content] line :: Maybe Line } data Attribute = Attribute { key :: QualifiedName value :: String } data QualifiedName = QualifiedName { name :: String uri :: Maybe String prefix :: Maybe String } but the global scope of the record field names doesn't allow that and therefore all kinds of abbreviations are inserted in front of the record field names which are hard to remember. So a better record syntax would be welcome. Perhaps the constructor could be used to limit the scope of the record field name e.g. QualifiedName.prefix? Regards, Felix

11 22

Re: [Haskell-cafe] Type Family Relations
by Matt Morrow 05 Jan '09

05 Jan '09

Hi, > I think that > >>> class HeaderOf addr hdr | addr -> hdr > does not enforce that there must be a corresponding instance > AddressOf hdr addr. Hence, the type checker cannot use that information > either. Do you have a way to remedy that? I've often wanted something similar, and experimenting with this the following two options seem to be equivalent and work as desired: ----------------------------------------------------------------------------- -- both options share this code: -- | The crucial assertion ipv4 :: AddrHdrPair IPv4 IPv4Header ipv4 = AddrHdrPair data IPv4Header = C1 data IPv4 = C2 data AppAddress = C3 data AppHeader = C4 ----------------------------------------------------------------------------- -- OPTION(1): -- type families + GADT with equality constraints type family HeaderOf addr type family AddressOf hdr data AddrHdrPair hdr addr where AddrHdrPair :: (hdr ~ HeaderOf addr ,addr ~ AddressOf hdr) => AddrHdrPair addr hdr type instance HeaderOf IPv4 = IPv4Header type instance AddressOf IPv4Header = IPv4 ----------------------------------------------------------------------------- -- OPTION(2): -- classes + GADT with instance constraints class HeaderOf addr hdr | addr -> hdr class AddressOf hdr addr | addr -> hdr data AddrHdrPair hdr addr where AddrHdrPair :: (HeaderOf addr hdr ,AddressOf hdr addr) => AddrHdrPair addr hdr instance AddressOf IPv4Header IPv4 instance HeaderOf IPv4 IPv4Header ----------------------------------------------------------------------------- -- And commenting out the above instances in turn -- to verify that everything indeed works, and to -- compare error message content: {- -- type instance HeaderOf IPv4 = IPv4Header Cafe0.hs:9:0: Couldn't match expected type `HeaderOf IPv4' against inferred type `IPv4Header' When generalising the type(s) for `ipv4' Failed, modules loaded: none. -- type instance AddressOf IPv4Header = IPv4 Cafe0.hs:9:0: Couldn't match expected type `AddressOf IPv4Header' against inferred type `IPv4' When generalising the type(s) for `ipv4' Failed, modules loaded: none. -} {- -- instance AddressOf IPv4Header IPv4 Cafe0.hs:9:7: No instance for (AddressOf IPv4Header IPv4) arising from a use of `AddrHdrPair' at Cafe0.hs:9:7-17 Possible fix: add an instance declaration for (AddressOf IPv4Header IPv4) In the expression: AddrHdrPair In the definition of `ipv4': ipv4 = AddrHdrPair Failed, modules loaded: none. -- instance HeaderOf IPv4 IPv4Header Cafe0.hs:9:7: No instance for (HeaderOf IPv4 IPv4Header) arising from a use of `AddrHdrPair' at Cafe0.hs:9:7-17 Possible fix: add an instance declaration for (HeaderOf IPv4 IPv4Header) In the expression: AddrHdrPair In the definition of `ipv4': ipv4 = AddrHdrPair Failed, modules loaded: none. -} -- endcode ----------------------------------------------------------------------------- I'm not sure if there are any circumstances under which these two don't behave equivalently. All the best, Matt

1 1

#haskell IRC channel reaches 600 users
by Don Stewart 05 Jan '09

05 Jan '09

A small announcement :) 7 years after its inception, under the guiding hand of Shae Erisson (aka shapr), the #haskell IRC channel[1] on freenode has reached 600 concurrent users! It's now in the top 3 language channels by size. To chart the growth, we can note that the channel was founded in late 2001, and had slow growth till 2006, reaching 200 users in January of that year. Since then growth in the user base has been far more rapid, reaching 300 users in Dec 2006, 400 users in August 2007, 500 users by July 2008, and 600 on January 2, 2009. This puts the channel at the 7th largest community of the 7000 freenode channels, and in the top 3 language communities. For comparision, a sample of the state of the other language communities, with comments comapred to their status a year ago: #php 612 #python 604 > #haskell 602 -- up 4 ##c++ 558 ##c 506 -- down 1 #perl 502 -- down 3 #ruby-lang 288 -- down #lisp 264 ##javascript 241 #erlang 146 -- unchanged #perl6 129 -- unchanged #scheme 123 -- down #lua 102 -- unchanged #clojure 78 #ocaml 70 -- unchanged You can see the growth of the channel over here: http://haskell.org/haskellwiki/IRC_channel If you've not dropped by the channel yet, feel free to come and chat, and toss around some lambdas! :) Cheers, Don

6 7