- Haskell-Cafe - Haskell.org

ANN bytestring-trie 0.1.2 (bugfix)
by wren ng thornton 06 Jan '09

06 Jan '09

-------------------------------------------- -- bytestring-trie 0.1.2 (bugfix) -------------------------------------------- Another bugfix release for efficient finite maps from (byte)strings to values. Release early, release often. -------------------------------------------- -- Changes -------------------------------------------- * Fixed a bug in alterBy pointed out by Mark Wotton. Same bug as the previous one pointed out by Maxime Henrion (a missing case). * Added an Eq instance, in case anyone cares. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-trie Darcs: http://code.haskell.org/~wren/bytestring-trie/ Haddock (Darcs version): http://code.haskell.org/~wren/bytestring-trie/dist/doc/html/bytestring-trie/ -- Live well, ~wren

1 0

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