- Haskell-Cafe - Haskell.org

Interesting problem from Bird (4.2.13)
by R J 07 Mar '09

07 Mar '09

Could someone provide an elegant solution to Bird problem 4.2.13? Here are the problem and my inelegant solution: Problem ------- Since concatenation seems such a basic operation on lists, we can try to construct a data type that captures concatenation as a primitive. For example, data (CatList a) = CatNil | Wrap a | Cat (CatList a) (CatList a) The intention is that CatNil represents [], Wrap x represents [x], and Cat x y represents x ++ y. However, since "++" is associative, the expressions "Cat xs (Cat ys zs)" and "Cat (Cat xs ys) zs" should be regarded as equal. Define appropriate instances of "Eq" and "Ord" for "CatList". Inelegant Solution ------------------ The following solution works: instance (Eq a) => Eq (CatList a) where CatNil == CatNil = True CatNil == Wrap z = False CatNil == Cat z w = ( z == CatNil && w == CatNil ) Wrap x == CatNil = False Wrap x == Wrap z = x == z Wrap x == Cat z w = ( Wrap x == z && w == CatNil ) || ( Wrap x == w && z == CatNil ) Cat x y == CatNil = x == CatNil && y == CatNil Cat x y == Wrap z = ( x == Wrap z && y == CatNil ) || ( x == CatNil && y == Wrap z ) Cat x y == Cat z w = unwrap (Cat x y) == unwrap (Cat z w) unwrap :: CatList a -> [a] unwrap CatNil = [] unwrap (Wrap x) = [x] unwrap (Cat x y) = unwrap x ++ unwrap y instance (Eq a, Ord a) => Ord (CatList a) where x < y = unwrap x < unwrap y This solution correctly recognizes the equality of the following, including nested lists(represented, for example, by Wrap (Wrap 1), which corresponds to [[1]]): Wrap 1 == Cat (Wrap 1) CatNil Cat (Wrap 1) (Cat (Wrap 2) (Wrap 3)) == Cat (Wrap 1) (Cat (Wrap 2) (Wrap 3)) Wrap (Wrap 1) == Wrap (Cat (Wrap 1) CatNil) Although this solution works, it's a hack, because unwrap converts CatLists to lists. The question clearly seeks a pure solution that does not rely on Haskell's built-in lists. What's the pure solution that uses cases and recursion on CatList, not Haskell's built-in lists, to capture the equality of nested CatLists? _________________________________________________________________ Windows Live™ Contacts: Organize your contact list. http://windowslive.com/connect/post/marcusatmicrosoft.spaces.live.com-Blog-…

6 7

Type question re: map
by R J 07 Mar '09

07 Mar '09

Given the following (usual) definition of "map": map :: (a -> b) -> [a] -> [b] map f [] = [] map f (x : xs) = f x : map f xs What's the type of "map map"? GHCi's :t command reveals: *Main> :t map map map map :: [a -> b] -> [[a] -> [b]] I'd be grateful if anyone could provide a systematic type calculation so that I can reason through more complicated examples myself. Thanks. _________________________________________________________________ Windows Live™: Life without walls. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009

3 2

Test if a file is empty or stat in haskell
by Anish Muttreja 07 Mar '09

07 Mar '09

I am looking for a way to test if a file is empty. Something like isFileEmpty along the lines of System.Directory.doesFileExist? A function that wraps stat would also serve the purpose. I get the feeling that someone must have felt the need for this before me, but Google search not yield anything, hence the question. Thanks! Anish

5 6

Re: [Haskell-cafe] Data.Binary stack overflow with Data.Sequence String
by Gwern Branwen 07 Mar '09

07 Mar '09

On Tue, Mar 3, 2009 at 11:50 PM, Spencer Janssen <spencerjanssen(a)gmail.com> wrote: > On Tue, Mar 3, 2009 at 10:30 PM, Gwern Branwen <gwern0(a)gmail.com> wrote: >> So recently I've been having issues with Data.Binary & Data.Sequence; >> I serialize a 'Seq String' >> >> You can see the file here: http://code.haskell.org/yi/Yi/IReader.hs >> >> The relevant function seems to be: >> >> -- | Read in database from 'dbLocation' and then parse it into an 'ArticleDB'. >> readDB :: YiM ArticleDB >> readDB = io $ (dbLocation >>= r) `catch` (\_ -> return empty) >> where r x = fmap (decode . BL.fromChunks . return) $ B.readFile x >> -- We read in with strict bytestrings to guarantee the >> file is closed, >> -- and then we convert it to the lazy bytestring >> data.binary expects. >> -- This is inefficient, but alas... >> >> My current serialized file is about 9.4M. I originally thought that >> the issue might be the recent upgrade in Yi to binary 0.5, but I >> unpulled patches back to past that, and the problem still manifested. >> >> Whenever yi tries to read the articles.db file, it stack overflows. It >> actually stack-overflowed on even smaller files, but I managed to bump >> the size upwards, it seems, by the strict-Bytestring trick. >> Unfortunately, my personal file has since passed whatever that limit >> was. >> >> I've read carefully the previous threads on Data.Binary and Data.Map >> stack-overflows, but none of them seem to help; hacking some $!s or >> seqs into readDB seems to make no difference, and Seq is supposed to >> be a strict datastructure already! Doing things in GHCi has been >> tedious, and hasn't enlightened me much: sometimes things overflow and >> sometimes they don't. It's all very frustrating and I'm seriously >> considering going back to using the original read/show code unless >> anyone knows how to fix this - that approach may be many times slower, >> but I know it will work. >> >> -- >> gwern > > Have you tried the darcs version of binary? It has a new instance > which looks more efficient than the old. > > > Cheers, > Spencer Janssen I have. It still stack-overflows on my 9.8 meg file. (The magic number seems to be somewhere between 9 and 10 megabytes.) -- gwern

3 5

MPI
by FFT 07 Mar '09

07 Mar '09

Are MPI bindings still the best way of using Haskell on Beowulf clusters? It's my feeling that the bindings stagnated, or are they just very mature?

4 6

Re: [Haskell-cafe] Hint and Ambiguous Type issue
by Daniel Gorín 06 Mar '09

06 Mar '09

I think you can achieve what you want but you need to use the correct types for it. Remember that when you write: getFilterMainStuff :: Deliverable a => FilePath -> Interpreter (Path, Filter a) the proper way to read the signature is "the caller of getFilterMainStuff is entitled to pick the type of a, as long as it picks an instance of Deliverable". Contrast this with a method declaration in Java where: public Set getKeys() is to be read: "The invoked object may pick the type of the result, as long as it is a subclass of (or implements) Set". When you say that you want "to apply fMain to a (Config, Email) and get back a Deliverable a", I think you mean that fMain picks the type for a (and has to be an instance of Deliverable). There two ways to do this in Haskell: 1) You don't. If you know that your possible Deliverables are just FlatEmail and MaildirEmail, then the idiomatic way of doing this would be to turn Deliverable into an ADT: data Deliverable = FlatEmail .... | MaildirEmail .... deriving (Typeable) getFilterMainStuff :: FilePath -> Interpreter (Path, Filter Deliverable) 2) Existential types. If, for some reason, you need your "dynamic code" to be able to define new "deliverables", then you need to use the extension called "existential types". -- using GADT syntax data SomeDeliverable where Wrap :: Deliverable a => a -> SomeDeliverable getFilterMainStuff :: FilePath -> Interpreter (Path, Filter SomeDeliverable) This basically resembles the contract of the Java world: if you run fMain you will get a value of type SomeDeliverable; you can pattern- match it and will get something whose actual type you don't know, but that it is an instance of class Deliverable. See http://www.haskell.org/haskellwiki/Existential_type Good luck! Daniel On Mar 6, 2009, at 2:33 AM, Joseph Fredette wrote: > Okay, I think I understand... I got so hung up thinking the error > had to be in the Interpreter code, I didn't bother to look in the > caller... > > But every answer breeds another question... The practical reason for > inferring fMain as being of type "Deliverable a => Filter a", is to > apply it (via runReader) to a (Config, Email) and get back a > Deliverable a, then to use the deliverIO method on the result -- my > question is, it appears I have to "know" the specific type of a in > order to get the thing to typecheck, but in order to use it, I need > to not know it... > > Perhaps, in fact, I'm doing this wrong. Thanks for the help Daniel, > everyone... > > /Joe > > Daniel Gorín wrote: >> Ok, so I've pulled the latest version and the error I get now is: >> >> Hackmain.hs:70:43: >> Ambiguous type variable `a' in the constraint: >> `Deliverable a' >> arising from a use of `getFilterMainStuff' at Hackmain.hs: >> 70:43-60 >> Probable fix: add a type signature that fixes these type >> variable(s) >> >> Function getFilterMainStuff compiles just fine . The offending line >> is in buildConf and reads: >> >> > (inboxL, fMain) <- runUnsafeInterpreter . getFilterMainStuff $ >> filterMainL >> >> The problem is that GHC can't figure out the type of fMain. It >> infers (Filter a), but doesn't know what is a and therefore how to >> build a proper dictionary to pass to getFilterMainStuff. >> >> Observe that you would get a similar error message if you just >> defined: >> >> > f = show . read >> >> I can get it to compile by providing a type annotation for fMain: >> >> > (inboxL, fMain) <- runUnsafeInterpreter . getFilterMainStuff $ >> filterMainL >> > let _ = fMain :: Filter MaildirEmail >> >> So once you use fMain somewhere and GHC can infer it's type, >> everything should work fine. >> >> Daniel >> >> On Mar 5, 2009, at 11:26 PM, Joseph Fredette wrote: >> >>> Oh, crap- I must have never pushed the latest patches, I did put >>> the typeable instances in all the appropriate places. And provided >>> a (maybe incorrect? Though I'm fairly sure that shouldn't affect >>> the bug I'm having now) Typeable implementation for Reader, but I >>> still get this ambiguous type. I'll push the current version asap. >>> >>> Thanks. >>> >>> /Joe >>> >>> Daniel Gorín wrote: >>>> Hi >>>> >>>> I've downloaded Hackmain from patch-tag, but I'm getting a >>>> different error. The error I get is: >>>> >>>> Hackmain.hs:63:10: >>>> No instance for (Data.Typeable.Typeable2 >>>> Control.Monad.Reader.Reader) >>>> arising from a use of `interpret' at Hackmain.hs:63:10-67 >>>> >>>> Hint requires the interpreted values to be an instance of >>>> Typeable in order to check, in runtime, that the interpreted >>>> value matches the type declared at compile. Therefore, you need >>>> to make sure that (Filter a) is indeed an instance of Typeable. >>>> >>>> Since you have Filter a = Reader (Config, Email) a, you probably >>>> need to >>>> >>>> - Derive Config and Email instances for Filter, >>>> >>>> - Manually provide Typeable instances for Reader a b, something >>>> along the lines of: >>>> >>>> instance (Typeable a, Typeable b) => Typeable (Reader a b) where... >>>> >>>> (I don't know why this isn't done in the mtl....) >>>> >>>> - Change the signature to: >>>> >>>> getFilterMain :: (Typeable a, Deliverable a) => FilePath -> >>>> Interpreter (Filter a) >>>> >>>> Also, you can try using "infer" instead of "as :: ...." >>>> >>>> Hope that helps >>>> >>>> Daniel >>>> >>>> On Mar 5, 2009, at 8:47 PM, Joseph Fredette wrote: >>>> >>>>> So, I tried both of those things, both each alone and together. >>>>> No dice. Same error, so I reverted back to the >>>>> original. :( >>>>> However, I was, after some random type signature insertions, >>>>> able to convert the problem into a different one, via: >>>>> >>>>> getFilterMain :: Deliverable a => FilePath -> Interpreter >>>>> (Filter a) getFilterMain MainLoc = do >>>>> loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/ >>>>> ='.') fMainLoc)] fMain <- >>>>> (interpret "(filterMain)" infer) >>>>> return (fMain :: Deliverable a => Filter a) >>>>> >>>>> Inferred type is less polymorphic than expected >>>>> Quantified type variable `a' is mentioned in the environment: >>>>> fMain :: Filter a (bound at Hackmain.hs:77:1) >>>>> In the first argument of `return', namely >>>>> `(fMain :: (Deliverable a) => Filter a)' >>>>> In the expression: return (fMain :: (Deliverable a) => Filter a) >>>>> In the expression: >>>>> do loadModules [fMainLoc] >>>>> setTopLevelModules [(takeWhile (/= '.') fMainLoc)] >>>>> fMain <- (interpret "(filterMain)" infer) >>>>> return (fMain :: (Deliverable a) => Filter a) >>>>> I'm >>>>> thinking that this might be more easily solved -- I do think I >>>>> understand the issue. somehow, I need to tell the compiler >>>>> that the 'a' used in the return statement (return >>>>> (fMain :: ...)) is the same as the 'a' in the type sig for the >>>>> whole function. >>>>> >>>>> While I ponder this, and hopefully receive some more help -- >>>>> thanks again Dan, Ryan -- Are there any other options besides >>>>> Hint that might -- at least in the short term -- make this >>>>> easier? I'd really like to finish this up. I'm _so_ close to >>>>> getting it done. >>>>> >>>>> Thanks, >>>>> >>>>> /Joe >>>>> >>>>> Ryan Ingram wrote: >>>>>> So, by using the Haskell interpreter, you're using the >>>>>> not-very-well-supported dynamically-typed subset of Haskell. >>>>>> You can >>>>>> tell this from the type signature of "interpret": >>>>>> >>>>>> >>>>>>> interpret :: Typeable a => String -> a -> Interpreter a >>>>>>> >>>>>> >>>>>> >>>>>>> as :: Typeable a => a >>>>>>> as = undefined >>>>>>> >>>>>> >>>>>> (from http://hackage.haskell.org/packages/archive/hint/0.2.1/doc/html/src/Languag…) >>>>>> >>>>>> In particular, the "as" argument to interpret is specifying >>>>>> what type >>>>>> you want the interpreted result to be typechecked against; the >>>>>> interpretation fails if it doesn't match that type. But you >>>>>> need the >>>>>> result type to be an instance of Typeable; (forall a. >>>>>> Deliverable a => >>>>>> Filter a) most certainly is not. >>>>>> >>>>>> >>>>>> Off the top of my head, you have a couple of directions you can >>>>>> take this. >>>>>> >>>>>> (1) Make Typeable a superclass of Deliverable, saying that all >>>>>> deliverable things must be dynamically typeable. Then derive >>>>>> Typeable >>>>>> on Filter, and have the result be of type "Filter a" using >>>>>> ScopedTypeVariables as suggested before. (You can also pass >>>>>> "infer" to >>>>>> the interpreter and let the compiler try to figure out the >>>>>> result type >>>>>> instead of passing (as :: SomeType).) >>>>>> >>>>>> (2) Make a newtype wrapper around Filter and give it an >>>>>> instance of >>>>>> Typeable, and add a constraint to filterMain that the result >>>>>> type in >>>>>> the filter is also typeable. Then unwrap the newtype after the >>>>>> interpreter completes. >>>>>> >>>>>> Good luck; I've never tried to use the Haskell interpreter >>>>>> before, so >>>>>> I'm curious how well it works and what problems you have with it! >>>>>> >>>>>> >>>>>> -- ryan >>>>>> >>>>>> 2009/3/5 Joseph Fredette <jfredett(a)gmail.com>: >>>>>> >>>>>>> I've been working on a little project, and one of the things I >>>>>>> need to do is >>>>>>> dynamically compile and import a Haskell Source file >>>>>>> containing filtering >>>>>>> definitions. I've written a small monad called Filter which is >>>>>>> simply: >>>>>>> >>>>>>> type Filter a = Reader (Config, Email) a >>>>>>> >>>>>>> To encompass all the email filtering. The method I need to >>>>>>> import, >>>>>>> filterMain, has type: >>>>>>> >>>>>>> filterMain :: Deliverable a => Filter a >>>>>>> >>>>>>> where Deliverable is a type class which abstracts over >>>>>>> delivery to a path in >>>>>>> the file system. The notion is that I can write a type like: >>>>>>> >>>>>>> data DEmail = {email :: Email, path :: FilePath} >>>>>>> newtype Maildir = MD DEmail >>>>>>> >>>>>>> instance Deliverable Maildir where >>>>>>> {- ... omitted -} >>>>>>> >>>>>>> However, Filter a should not be restricted to Deliverable >>>>>>> types- it also >>>>>>> encompasses the results of regular expression matching, etc, >>>>>>> which are not >>>>>>> -- in general -- Deliverable instances. >>>>>>> >>>>>>> My question is this, when importing the file containing the >>>>>>> definitions of >>>>>>> filterMain, I have the following code to grab filterMain and >>>>>>> return it as a >>>>>>> function. >>>>>>> >>>>>>> getFilterMain :: Deliverable a => FilePath -> Interpreter >>>>>>> (Filter a) >>>>>>> getFilterMain fMainLoc = do >>>>>>> loadModules >>>>>>> [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] >>>>>>> fMain <- (interpret "(filterMain)" (as :: >>>>>>> Deliverable a >>>>>>> => Filter a)) return (fMain) >>>>>>> >>>>>>> However, when I try to >>>>>>> compile >>>>>>> this, I get the type error: >>>>>>> >>>>>>> Hackmain.hs:70:43: >>>>>>> Ambiguous type variable `a' in the constraint: >>>>>>> `Deliverable a' >>>>>>> arising from a use of `getFilterMainStuff' at >>>>>>> Hackmain.hs:70:43-60 >>>>>>> Probable fix: add a type signature that fixes these type >>>>>>> variable(s) >>>>>>> >>>>>>> My understanding is that a type like "Foo a => Bar a" (where >>>>>>> Foo is a class >>>>>>> and Bar is a datatype) would simply restrict >>>>>>> the values of a to only those implementing Foo. But evidently >>>>>>> I'm wrong. Is >>>>>>> there a good (read, easy... :) ) fix to this? >>>>>>> >>>>>>> Any help would be greatly appreciated. >>>>>>> >>>>>>> /Joe >>>>>>> >>>>>>> PS. All the actual code is on patch-tag, here >>>>>>> http://patch-tag.com/repo/Hackmail/home -- if anyone prefers >>>>>>> to look at that >>>>>>> directly, the relevant files are in Src, namely, Hackmain.hs, >>>>>>> Filter.hs, and >>>>>>> Deliverable.hs >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Haskell-Cafe mailing list >>>>>>> Haskell-Cafe(a)haskell.org >>>>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> <jfredett.vcf>_______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe(a)haskell.org >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>> <jfredett.vcf> >> >> > <jfredett.vcf>

2 1

Re: Migration to QuickCheck 2.0
by John Goerzen 06 Mar '09

06 Mar '09

John Goerzen wrote: > Hi, > > My google skills must be faulty, because I can't find much stuff on > migrating from QuickCheck 1.0 to 2.0. > > I've got a number of questions: > > What's the deal with Result and reason being in two different places > in QuickCheck with two different definitions? > > All the QC.Config -- configMaxTest, defaultConfig, arguments, etc. are > missing. Are there direct replacements? OK, ignore the second one. That was an HUnit question; sorry. > > Thanks, > > -- John

1 0

Re: [Haskell] Lazy IO breaks purity
by Simon Marlow 06 Mar '09

06 Mar '09

Lennart Augustsson wrote: > I don't see any breaking of referential transparence in your code. > Every time you do an IO operation the result is basically > non-deterministic since you are talking to the outside world. > You're assuming the IO has some kind of semantics that Haskell makes > no promises about. > > I'm not saying that this isn't a problem, because it is. > But it doesn't break referential transparency, it just makes the > semantics of IO even more complicated. > > (I don't have a formal proof that unsafeInterleaveIO cannot break RT, > but I've not seen an example where it does yet.) So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) Cheers, Simon > -- Lennart > > On Thu, Mar 5, 2009 at 2:12 AM, <oleg(a)okmij.org> wrote: >> >> We demonstrate how lazy IO breaks referential transparency. A pure >> function of the type Int->Int->Int gives different integers depending >> on the order of evaluation of its arguments. Our Haskell98 code uses >> nothing but the standard input. We conclude that extolling the purity >> of Haskell and advertising lazy IO is inconsistent. >> >> Henning Thielemann wrote on Haskell-Cafe: >>> Say I have a chain of functions: read a file, ... write that to a file, >>> all of these functions are written in a lazy way, which is currently >>> considered good style >> Lazy IO should not be considered good style. One of the common >> definitions of purity is that pure expressions should evaluate to the >> same results regardless of evaluation order, or that equals can be >> substituted for equals. If an expression of the type Int evaluates to >> 1, we should be able to replace every occurrence of the expression with >> 1 without changing the results and other observables. >> >> The expression (read s) where s is the result of the (hGetContents h1) >> action has the pure type, e.g., Int. Yet its evaluation does more than >> just producing an integer: it may also close a file associated with >> the handle h1. Closing the file has an observable effect: the file >> descriptor, which is a scarce resource, is freed. Some OS lock the >> open file, or prevent operations such as renaming and deletion on the >> open file. A file system whose file is open cannot be >> unmounted. Suppose I use an Haskell application such as an editor to >> process data from a removable drive. I mount the drive, tell the >> application the file name. The (still running) application finished >> with the file and displayed the result. And yet I can't unplug the >> removable drive, because it turns out that the final result was >> produced without needing to read all the data from the file, and the >> file remains unclosed. >> >> Some people say: the programmer should have used seq. That is the >> admission of guilt! An expression (read s)::Int that evaluates to 1 is >> equal to 1. So, one should be able substitute (read s) with 1. If the >> result of evaluating 1 turns out not needed for the final outcome, >> then not evaluating (read s) should not affect the outcome. And yet it >> does. One uses seq to force evaluation of an expression even if the >> result may be unused. Thus the expression of a pure type >> has *side-effect*. >> >> The advice about using seq reminds me of advice given to C programmers >> that they should not free a malloc'ed pointer twice, dereference a >> zero pointer and write past the boundary of an array. If lazy IO is >> considered good style given the proper use of seq, then C should be >> considered safe given the proper use of pointers and arrays. >> >> Side affects like closing a file are observable in the external >> world. A program may observe these effects, in an IO monad. One can >> argue there are no guarantees at all about what happens in the IO >> monad. Can side-effects of lazy IO be observable in _pure_ Haskell >> code, in functions with pure type? Yes, they can. The examples are >> depressingly easy to write, once one realizes that reading does have >> side effects, POSIX provides for file descriptor aliasing, and sharing >> becomes observable with side effects. Here is a simple Haskell98 code. >> >> >>> {- Haskell98! -} >>> >>> module Main where >>> >>> import System.IO >>> import System.Posix.IO (fdToHandle, stdInput) >>> >>> -- f1 and f2 are both pure functions, with the pure type. >>> -- Both compute the result of the subtraction e1 - e2. >>> -- The only difference between them is the sequence of >>> -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1 >>> -- For really pure functions, that difference should not be observable >>> >>> f1, f2:: Int -> Int -> Int >>> >>> f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2 >>> f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2 >>> >>> read_int s = read . head . words $ s >>> >>> main = do >>> let h1 = stdin >>> h2 <- fdToHandle stdInput >>> s1 <- hGetContents h1 >>> s2 <- hGetContents h2 >>> print $ f1 (read_int s1) (read_int s2) >>> -- print $ f2 (read_int s1) (read_int s2) >> >> One can compile it with GHC (I used 6.8.2, with and without -O2) and >> run like this >> ~> /tmp/a.out >> 1 >> 2 >> -1 >> That is, we run the program and type 1 and 2 as the inputs. The >> program prints out the result, -1. If we comment out the line >> "print $ f1 (read_int s1) (read_int s2)" and uncomment out the last >> line the transcript looks like this >> ~> /tmp/a.out >> 1 >> 2 >> 1 >> >> Running the code with Hugs exhibits the same behavior. Thus a pure >> function (-) of the pure type gives different results depending on the >> order of evaluating its arguments. >> >> Is 1 = -1? >> >> >> >> >> >> >> _______________________________________________ >> Haskell mailing list >> Haskell(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell >> > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

6 5

Difficulties in accessing inner elements of data types
by David Miani 06 Mar '09

06 Mar '09

Hi, I'm working on a Haskell library for interacting with emacs org files. For those that do not know, an org file is a structured outline style file that has nested headings, text, tables and other elements. For example: * Heading 1 Some text, more text. This is a subelement of Heading 1 1. You can also have list 1. and nested lists 2. more... ** Nested Heading (subelement of Heading 1) text... (subelement of Nested Heading) ** Another level 2 heading (subelement of Heading 1) | Desc | Value | |-----------+--------------------------------------| | Table | You can also have tables in the file | | another | row | | seperator | you can have seps as well, eg | |-----------+--------------------------------------| * Another top level heading There are many more features, see orgmode.org My library enables read and write access to a subset of this format (eg lists aren't parsed atm). The data structures used for writing are: data OrgFile = OrgFile [OrgFileElement] data OrgFileElement = Table OrgTable | Paragraph String | Heading OrgHeading -- heading level, title, subelements data OrgHeading = OrgHeading Int String [OrgFileElement] data OrgTable = OrgTable [OrgTableRow] data OrgTableRow = OrgTableRow [String] | OrgTableRowSep To write a file you contruct a OrgFile out of those elements, and pass it to a writeOrgFile func. Eg: writeOrg $ OrgFile [Heading (OrgHeading 1 "h1" [Paragraph "str"])] would produce: * h1 str I was going to use the same data structures for reading an org file, but it quickly became apparent that this would not be suitable, as you needed the position of the file of an element to be able to report errors. Eg if you needed to report an error that a number was expected, the message "'cat' is not a number" is not very useful, but "Line 2031: 'cat' is not a number" is. So the data structures I used were: data FilePosition = FilePosition Line Column data WithPos a = WithPos { filePos :: FilePosition, innerValue :: a } data OrgTableP = OrgTableP [WithPos OrgTableRow] data OrgFileElementP = TableP OrgTableP | ParagraphP String | HeadingP OrgHeadingP data OrgHeadingP = OrgHeadingP Int String [WithPos OrgFileElementP] data OrgFileP = OrgFileP [WithPos OrgFileElementP] Finally there is a function readOrg, which takes a string, and returns an OrgTableP. Now, this all works as expected (files are correctly being parsed and written), however I am having a lot of trouble trying to come up with a decent API to work with this. While writing an OrgFile is fairly easy, reading (and accessing inner parts) of an org file is very tedious, and modifying them is horrendous. For example, to read the description line for the project named "Project14" in the file: * 2007 Projects ** Project 1 Description: 1 Tags: None ** Project 2 Tags: asdf,fdsa Description: hello * 2008 Projects * 2009 Projects ** Project14 Tags: RightProject Description: we want this requires the code: type ErrorS = String listToEither str [] = Left str listToEither _ (x:_) = Right x get14 :: OrgFileP -> Either ErrorS String get14 (OrgFileP elements) = getDesc =<< (getRightProject . concatProjects) elements where concatProjects :: [WithPos OrgFileElementP] -> [OrgHeadingP] concatProjects [] = [] concatProjects ((WithPos _ (HeadingP h)) : rest) = h : concatProjects rest concatProjects (_ : rest) = concatProjects rest getRightProject :: [OrgHeadingP] -> Either ErrorS OrgHeadingP getRightProject = listToEither "Couldn't find project14" . filter (\(OrgHeadingP _ name _) -> name == "Project14") getDesc :: OrgHeadingP -> Either ErrorS String getDesc (OrgHeadingP _ _ children) = case filter paragraphWithDesc (map innerValue children) of [] -> Left $ show (filePos $ head children) ++ ": Couldn't find desc in project" ((ParagraphP str):_) -> Right str _ -> error "should not be possible" paragraphWithDesc :: OrgFileElementP -> Bool paragraphWithDesc (ParagraphP str) = str =~ "Description" paragraphWithDesc _ = False If you think that is bad, try writing a function that adds the Tag "Hard" to Project2 :( What I really need is a DSL that would allow sql like queries on an OrgFileP. For example: select (anyHeading `next` headingWithName "Project14" `withFailMsg` "couldn't find p14" `next` paragraphMatchingRegex "Description" `withFailMsg` "no desc") org `output` paragraphText would return a String OR select (anyHeading `next` headingWithName "Project2" `next` paragraphMatchingRegex "Tag:") org `modify` paragraphText (++ ",Hard") would return an OrgFile, with the new Hard tag added. However, I don't know if this is even possible, how to do it, or if there is a better alternative to this. I would really apreciate any hints with regards to this. It would be useful to know if there are other libraries that also face this problem, and how they solved it. Finally, I would be grateful for any other advice regarding my code. One thing that has bugged me is my solution for having file position info - my solution never seemed very elegant. Thanks, David

5 5

Hint and Ambiguous Type issue
by Joseph Fredette 06 Mar '09

06 Mar '09

I've been working on a little project, and one of the things I need to do is dynamically compile and import a Haskell Source file containing filtering definitions. I've written a small monad called Filter which is simply: type Filter a = Reader (Config, Email) a To encompass all the email filtering. The method I need to import, filterMain, has type: filterMain :: Deliverable a => Filter a where Deliverable is a type class which abstracts over delivery to a path in the file system. The notion is that I can write a type like: data DEmail = {email :: Email, path :: FilePath} newtype Maildir = MD DEmail instance Deliverable Maildir where {- ... omitted -} However, Filter a should not be restricted to Deliverable types- it also encompasses the results of regular expression matching, etc, which are not -- in general -- Deliverable instances. My question is this, when importing the file containing the definitions of filterMain, I have the following code to grab filterMain and return it as a function. getFilterMain :: Deliverable a => FilePath -> Interpreter (Filter a) getFilterMain fMainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] fMain <- (interpret "(filterMain)" (as :: Deliverable a => Filter a)) return (fMain) However, when I try to compile this, I get the type error: Hackmain.hs:70:43: Ambiguous type variable `a' in the constraint: `Deliverable a' arising from a use of `getFilterMainStuff' at Hackmain.hs:70:43-60 Probable fix: add a type signature that fixes these type variable(s) My understanding is that a type like "Foo a => Bar a" (where Foo is a class and Bar is a datatype) would simply restrict the values of a to only those implementing Foo. But evidently I'm wrong. Is there a good (read, easy... :) ) fix to this? Any help would be greatly appreciated. /Joe PS. All the actual code is on patch-tag, here http://patch-tag.com/repo/Hackmail/home -- if anyone prefers to look at that directly, the relevant files are in Src, namely, Hackmain.hs, Filter.hs, and Deliverable.hs

4 7