- Haskell-Cafe - Haskell.org

deconstruction of the list/backtracking applicative functor?
by Conal Elliott 24 Mar '08

24 Mar '08

Is there a known deconstruction of the list/backtracking applicative functor (AF)? If I decompose the list type into pieces (Maybe, product, composition), I think I can see where the ZipList AF comes from, but not the list/backtracking AF. Is there some construction simpler than lists (non-recursive) that introduces cross products? Thanks, - Conal

2 3

ghc warn-unused-imports
by Evan Laforge 24 Mar '08

24 Mar '08

So it appears that GHC will warn about "unused" imports when you import qualified if you could have gotten the symbol from somewhere else. For instance, if you write: import qualified Control.Monad.Trans as Trans import qualified Control.Monad.Writer as Writer and use "Trans.lift", it will complain because you could have used "Writer.lift". Then if you go import State, it will want you to use State.liftIO instead of Trans.liftIO (Writer doesn't have liftIO). Now, one question is why these modules are exporting random stuff from Trans, but in general the practice of warning when you use qualified imports seems not only misleading (since if you comment out the import your code breaks, and it's not obvious where it wanted you to get the symbol), but brittle since a messy export list on some module you import can suddenly trigger a flood of warnings. So I'd suggest that if you say "import qualified M" and then use "M.something", then "M is unused" msgs shouldn't appear. warn-unused-imports is genuinely useful most of the time, so I don't like to put on -fno-warn-unused-imports. Is there a better way to suppress the "false positives" here?

2 1

BUG: genObjectNames dies on Win32
by Jefferson Heard 24 Mar '08

24 Mar '08

Could this get forwarded on to another more appropriate maling list? Confirmed on GHC and GHCi 6.6 and 6.8, Graphics.Rendering.OpenGL.GL.genObjectNames n is dying if I ask it to return an IO :: [DisplayList] For an example, just open GHCI and change context to Graphics.Rendering.OpenGL.GL and do genObjectNames 4 :: IO [DisplayList] GHCi will merely die. Compiled with GHC, I'm simply running out of memory. It eats RAM indefinitely. -- Jeff

1 0

HXT and types in Control.Arrow.ArrowTree
by Robert Vollmert 24 Mar '08

24 Mar '08

Hello, I'm having some trouble with HXT, the types of some functions in particular. This may well be caused by a lack of understanding for arrow programming -- I'd appreciate any hints. In short, I'm constantly running into what appear to be artificial type restrictions in Control.Arrow.ArrowTree. For example, the signature of "deep" is deep :: (Tree t, ArrowTree a) => a (t b) (t b) -> a (t b) (t b) instead of the more general deep :: (Tree t, ArrowTree a) => a (t b) c -> a (t b) c Say I have an arrow getLink :: (ArrowXml a) => a XmlTree Link that converts an HTML link (<a href="url">text</a>) into some appropriate data type (code below). To collect all links in a document, I'd like to use deep getLink instead of deep (hasName "a") >>> getLink Is this the wrong approach to converting XML into Haskell data types? Cheers Robert module Links where import Text.XML.HXT.Arrow data Link = Link { url, text :: String } deriving Show getLink :: (ArrowXml a) => a XmlTree Link getLink = isElem >>> hasName "a" >>> (getAttrValue0 "href" &&& getAllText) >>> arr (uncurry Link) getAllText :: (ArrowXml a) => a XmlTree String getAllText = listA (deep isText >>> getText) >>> arr concat

2 2

more on FFI build error
by Galchin Vasili 24 Mar '08

24 Mar '08

line #102 ... allocaBytes (#const sizeof(struct mq_attr)) $ \ p_attrs -> do definition of struct mq_attr on Linux ... struct mq_attr { long int mq_flags; /* Message queue flags. */ long int mq_maxmsg; /* Maximum number of messages. */ long int mq_msgsize; /* Maximum message size. */ long int mq_curmsgs; /* Number of messages currently queued. */ long int __pad[4]; }; build errors received .... vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs build Preprocessing library unix-2.2.0.0... MQueue.hsc: In function 'main': MQueue.hsc:102:0: error: invalid application of 'sizeof' to incomplete type 'struct mq_attr' MQueue.hsc:102:0: error: invalid application of 'sizeof' to incomplete type 'struct mq_attr' MQueue.hsc:102:0: error: invalid application of 'sizeof' to incomplete type 'struct mq_attr' compiling dist/build/System/Posix/MQueue_hsc_make.c failed comma ??? Kind regards, vasili

4 3

RE: How to implement Read instance for user defined type
by Verma Anurag-VNF673 24 Mar '08

24 Mar '08

That works, but is probably not what you want. You can use the lex function to parse identifiers not enclosed in quotes: > instance Read Mark where > readsPrec _ str = [(Mark x, t') | ("mark",t) <- lex str, > (x,t') <- reads t I played a bit around with lex function and it seems that under certain circumstances it doesn't read the string of token properly For e.g. -- IP address *Mark> lex "192.168.0.1" [("192.168",".0.1")] -- digit + char Also lex "8021p" output is *Mark> lex "8021p" [("8021","p")] Is there any other lex variant available? Or should I switch to using Parsec library, in that case, will I still be able to use it with Read instances? If so, how? Anurag

1 0

HFuse: ls fails in HelloFS
by Georg Neis 24 Mar '08

24 Mar '08

Hello, I've installed the HFuse package from hackage and am playing with the HelloFS example in the System/Posix/HFuse directory. The problem that I encounter is that listing the directory doesn't work: % ghc --make HelloFS.hs [1 of 1] Compiling Main ( HelloFS.hs, HelloFS.o ) Linking HelloFS ... % mkdir bla % ./HelloFS bla % cd bla % cat hello Hello World, HFuse! % ls ls: cannot open directory .: Function not implemented Here's the relevant output from strace: open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = -1 ENOSYS (Function not implemented) write(2, "ls: ", 4ls: ) = 4 write(2, "cannot open directory .", 23cannot open directory .) = 23 write(2, ": Function not implemented", 26: Function not implemented) = 26 Some system information: - Debian unstable - Linux 2.6.24 - Fuse 2.7.3 - GHC 6.8.2 - HFuse 0.1 Any ideas? Thanks, Georg

7 10

Any ideas for "->" (function type) in a simply-typed lambda calculus version of Brett Victor's Alligator Eggs game?
by Benjamin L. Russell 24 Mar '08

24 Mar '08

Brett Victor has invented an Alligator Eggs game (very loosely resembling Conway's Game of Life), using formal rules to determine feeding and breeding patterns for alligators and their eggs, but the game represents the *untyped* lambda calculus: Alligator Eggs! http://worrydream.com/AlligatorEggs/ I am interested in adapting this to the *simply typed* lambda calculus with Curry-style typing, to aid students of Haskell. Brett Victor's game currently aids students of LISP, and I think that it would be helpful to have a Haskell counterpart (see http://wadler.blogspot.com/2007/05/oh-no-alligators.html for a comment on how the Alligator Eggs game has been used by EE students at Caltech in learning LISP): Simply typed lambda calculus - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Simply_typed_lambda_calculus Thereafter, I would like to create a new entry for this Haskell version of Alligator Eggs on HaskellWiki, and create a link to it under a new subsection, "Board Games," under the current "Learning Haskell" category: http://www.haskell.org/haskellwiki/Learning_Haskell In Brett Victor's version, the following representations hold: * a hungry alligator: lambda abstraction * an old alligator: a pair of parentheses * an egg: a variable * the Eating Rule: beta-reduction * the Color Rule: (over-cautious) alpha-conversion * the Old Age Rule: the rule that a pair of parentheses containing a single term may be removed However, in thinking about how to adapt the game, I am not quite sure how to incorporate the representation of "->" (function type): * ???: "->" (function type) What ideas, if any, would anybody have on how "->" (function type) could be represented in a simply-typed lambda calculus version of Brett Victor's Alligator Eggs? Benjamin L. Russell

2 2

hoisting as well as lifting and returning
by Matthew Pocock 23 Mar '08

23 Mar '08

Hi, Happy Easter! I've been using monad transformers for the first time in anger this week. They certainly do the job. However, there's an operation that I keep defining over and over again. It is sort of like lift and return in that it's glue to get operations and values into the monad from outside it. Here are two examples. hoistList :: (Monad m) => [a] -> ListT m a hoistList = foldr (mplus . return) mzero hoistMaybe :: (Monad m) => Maybe a -> MaybeT m a hoistMaybe = maybe mzero return The general idea is that you have some legacy, non-transform operation in some monad MonadFoo, and you are writing an operation in MonadFooT. You want to get the monadFoo value into MonadFooT. So, you say something like: do vInMFT <- hoist vInMF Is this a common enough operation on a monad transformer and it's 'raw' monad to warrant a class of its own? I have 'hoist' methods for several monad transformers, including RamdomMonadT, although I've probably defined them in ways that are overly eager or eat stack/heap, so I'd prefer knowledgable people to write them :) There must be other operations that link the base monad with its transformed version, other than 'hoist' - the runFooT method for example. Perhaps 'hoist' already exists and I'm re-inventing the wheel? Matthew

2 2

Type checking of partial programs
by ac 23 Mar '08

23 Mar '08

Is anybody interested in working on this? This is a project I've been interested in for some time, but recognize I probably need some guidance before I go off and start hacking on it. As dcoutts pointed out on #haskell-soc, this may be of particular interest to people working on yi and HaRe. Other interesting and related projects include parsing partial programs to insert "placeholders" in appropriate places. An example of a partial program could be: foo :: [Foo] -> <placeholder 1> foo xs = map <placeholder 2> xs What are the possible type signatures for placeholder 1 and the possible expressions for placeholder 2? I would like to stir up a discussion about this, and eventually write some useful code. -Abram

10 13