October 2009 - Haskell-Cafe

systemtimmetypeable: Workaround for lack of deriveable data instance in either System.Time or Data.Time.
by Thomas Hartman 21 Oct '09

21 Oct '09

At http://osdir.com/ml/haskell-cafe@haskell.org/2009-10/msg00197.html I griped that the lack of Data-Derivable time values was causing me headache in happstack. In the proposed cabal package http://patch-tag.com/r/tphyahoo/systemtimetypeable/snapshot/current/content… I submit a workaround that, while probably not the ideal thing, has proved helpful to me. Basically, I use the type MyTime, which is data-deriveable, when working with Macid in happstack; and convert from System.Time and/or Data.Time with the accompanying utility functions when necessary. Perhaps the utility functions are useful on their own as well. I found it surprisingly hard to get from Data.Time values to System.Time values. Anyways, I am interested in what others think and, of course, patches and suggestions welcome. thomas.

2 2

Re: [Haskell-beginners] map question
by Gregory Propf 21 Oct '09

21 Oct '09

Remember that there is asymmetry between (+) and (-). The former has the commutative property and the latter does not so: (+) 3 4 = 7 and (+) 4 3 = 7 but (-) 3 4 = -1 and (-) 4 3 = 1 --- On Thu, 9/17/09, Tom Doris <tomdoris(a)gmail.com> wrote: From: Tom Doris <tomdoris(a)gmail.com> Subject: Re: [Haskell-beginners] map question To: "Joost Kremers" <joostkremers(a)fastmail.fm> Cc: beginners(a)haskell.org Date: Thursday, September 17, 2009, 6:06 AM This works: map (+ (-1)) [1,2,3,4] 2009/9/17 Joost Kremers <joostkremers(a)fastmail.fm> Hi all, I've just started learning Haskell and while experimenting with map a bit, I ran into something I don't understand. The following commands do what I'd expect: Prelude> map (+ 1) [1,2,3,4] [2,3,4,5] Prelude> map (* 2) [1,2,3,4] [2,4,6,8] Prelude> map (/ 2) [1,2,3,4] [0.5,1.0,1.5,2.0] Prelude> map (2 /) [1,2,3,4] [2.0,1.0,0.6666666666666666,0.5] But I can't seem to find a way to get map to substract 1 from all members of the list. The following form is the only one that works, but it doesn't give the result I'd expect: Prelude> map ((-) 1) [1,2,3,4] [0,-1,-2,-3] I know I can use an anonymous function, but I'm just trying to understand the result here... I'd appreciate any hints to help me graps this. TIA Joost -- Joost Kremers, PhD University of Frankfurt Institute for Cognitive Linguistics Grüneburgplatz 1 60629 Frankfurt am Main, Germany _______________________________________________ Beginners mailing list Beginners(a)haskell.org http://www.haskell.org/mailman/listinfo/beginners -----Inline Attachment Follows----- _______________________________________________ Beginners mailing list Beginners(a)haskell.org http://www.haskell.org/mailman/listinfo/beginners

13 21

Re: [Haskell-cafe] Error handling package
by Michael Snoyman 20 Oct '09

20 Oct '09

(Sorry, accidently took off cafe.) On Mon, Oct 19, 2009 at 12:44 AM, Henning Thielemann < lemming(a)henning-thielemann.de> wrote: > > On Mon, 19 Oct 2009, Michael Snoyman wrote: > > Does the explicit-exception package provide what you need? >> >> http://hackage.haskell.org/package/explicit-exception >> >> >> I don't think so, but correct me if I'm wrong. I want to make it easy to >> chain together >> computations which could fail in different ways. For example, something >> like this: >> >> attemptReadInt :: String -> Attempt Int >> attemptLookup :: String -> [(String, String)] -> Attempt String >> attemptLookupInt :: String -> [(String, String)] -> Attempt Int >> attemptLookupInt k m = attemptLookup k m >>= attemptReadInt >> >> Now, in the explicit-exception package, I could- in this simple example- >> define >> something like: >> >> data MyErrors = KeyNotFound | InvalidInt >> > > > type Attempt = Exceptional MyErrors > True; that's what I meant by I could do this in my simple example. > > > But this solution would not scale. >> > > You want to add other exceptions? The idea of my package is to make > exceptions explicit in the type. Otherwise you would use > extensible-exceptions. Or you could define MyErrors using an existential > type. Which is my point. I'm trying to provide a package for non-explicit exceptions. To compare to other programming languages, I think your package is providing the equivalent of Java checked exceptions, while mine is providing (safe) unchecked exceptions. I say safe because you still need to explicitly decide to turn an Attempt into a possible runtime exception which will bring down your program. Defining MyErrors using an existential type would essentially recreate the entire attempt package; I don't see that purpose in everyone wanted unchecked exceptions needing to reinvent the wheel in non-compatible ways. If multiple libraries use attempt, they can easily have their possible-error-returning functions chain together safely. > > > Additionally, there's two immediate features I think I would miss from my >> package: >> >> 1) fail works properly, so an Attempt would be a valid monad response from >> people who >> use that function. >> > > As far as I understand, 'fail' is used/abused for reporting failed pattern > matches in do notation. If a failed pattern match indicates a programming > error, it should be a really error, and not something that must be handled > at run-time. > That's a lot of very debateable statements you just made. It might be that it's strongly encouraged to only use fail for failed pattern matching, but in practice you could use it for any monadic failure. Also, there's nothing stopping a user from re-throwing pattern match exceptions received in an Attempt. Michael

2 2

Error handling package
by Michael Snoyman 20 Oct '09

20 Oct '09

While working on the next release of data-object, I wanted to represent some operations that might fail. The typical candidates were: 1) Maybe 2) Either 3) Monad Monad is always iffy because of the often times poorly defined fail. Maybe doesn't provide any means of reporting what the problem was. Either is not defined as a Monad in the base library. Also, the usual candidate of Either String only provides for an error message. It would be nice to have more in-depth information available. So I've put together a package I call "attempt". It defines a data type called (surprise) Attempt with a Success and Failure constructor. The trick here is that it using the new extensible exceptions under the surface, so you can report any kind of exception you want. It also provides a "FromAttempt" type class for possible conversion targets from an Attempt, provides an attempt function with some helpers for performing the equivalent of Control.Exception.catches, and provides two samples of functions I would want to implement with this library: attemptJoin and attemptLookup. My questions for the list are: 1) Is the overall approach sound, or do people have better ideas? 2) Are there any other FromAttempt instances I should provide out of the box? 3) I was considering adding specialized versions of the fromAttempt function, ie ioFromAttempt, maybeFromAttempt. Thoughts? 4) Should I follow the naming scheme attemptJoin, attemptLookup, etc, or just call the functions join, lookup and force people to import the module qualified? 5) Any other suggestions for attempt functions? I've considered head/tail/etc. 6) Include ToAttempt? The code is available on github at http://github.com/snoyberg/attempt/blob/master/Data/Attempt.hs . I appreciate the review. Also, I have not yet documented the code, but I will do so before uploading to Hackage; I just didn't want to document a changing target. Thank you, Michael

3 6

debugtracehelpers Re: traceM and traceShowM
by Thomas Hartman 20 Oct '09

20 Oct '09

I have this and a couple other handy functions in DebugTraceHelpers: http://patch-tag.com/r/tphyahoo/DebugTraceHelpers/snapshot/current/content/… hackage: http://hackage.haskell.org/packages/archive/DebugTraceHelpers/0.12/doc/html… 2009/10/16 Martijn van Steenbergen <martijn(a)van.steenbergen.nl>: > Hello, > > I propose the addition of the following two functions to module Debug.Trace: > >> traceM :: Monad m => String -> m () >> traceM msg = trace msg (return ()) >> >> traceShowM :: (Show a, Monad m) => a -> m () >> traceShowM = traceM . show > > These functions allow tracing in any do-block. I often define them myself; I > think they are useful in general. > > Deadline: 23 October 2009. > > Martijn. > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

3 2

Make two windows work together
by xu zhang 20 Oct '09

20 Oct '09

Hi there, I am trying to make a sub-window of one window and make them work together. I mean, if I zoom or transform some content in one of the window, the other one works in the same way. What I have done so far is just open a new window which have the same drawing view as the original one, but when I try to change some content in one window, the other one does not work at the same time. They are separate. Can anyone give me some hint on how to make them work at the same time not separate anymore? Thank you so much!

2 1

GHC devs
by Andrew Coppin 20 Oct '09

20 Oct '09

Random question of the day: How many developers are working on GHC? I had always *assumed* that there was something like a hundred core developers, with a much larger number of people casually testing and occasionally submitting the odd patch or two. However, I watched a video of a talk the other day (no, I don't remember which one) and it made me reconsider this view. Somebody muttered something like "GHC is really too big now for just 3 developers to manage", which makes it sound as if there are only 3 active developers... Surely that can't be correct. (There would never be any releases, for one thing...) Does anybody know anything concrete about this?

9 14

Re: [Haskell-cafe] Parsec bug, or...?
by S.Doaitse Swierstra 20 Oct '09

20 Oct '09

After some private exchange of info between Uwe and me it became clear that it may not have been immediately clear that the error messages in my original posting where actually part of a more involved process. By removing the optional part in the pCommand (i.e. making the part starting with `opt` invisible, we can show the full power of the built- in error correction. import Text.ParserCombinators.UU.Parsing pCommand [] = pure [] pCommand (x:xs) = ((:) <$> pSym x <*> pCommand xs) -- `opt` (x:xs) pCommands = amb . foldr (<|>) pFail . map pCommand $ ["banana", "chocolate", "frito", "fromage"] t :: String -> ([String], [Error Char Char Int]) t input = parse ( (,) <$> pCommands <*> pEnd) (listToStr input) Now one also gets error messages like: *Main> t "frxi" (["frito"],[ Deleted 'x' at position 2 expecting one of ['i', 'o'], Inserted 't' at position 4 expecting 't', Inserted 'o' at position 4 expecting 'o']) for free. However, since the decision what element to take is based on a limited look-ahead, one also gets: *Main> t "xfxrxix" (["fromage"],[ Deleted 'x' at position 0 expecting one of ['b', 'c', 'f', 'f'], Deleted 'x' at position 2 expecting 'r', Deleted 'x' at position 4 expecting 'o', Deleted 'i' at position 5 expecting 'o', Deleted 'x' at position 6 expecting 'o', Inserted 'o' at position 7 expecting 'o', Inserted 'm' at position 7 expecting 'm', Inserted 'a' at position 7 expecting 'a', Inserted 'g' at position 7 expecting 'g', Inserted 'e' at position 7 expecting 'e']) *Main> which is something not completely expected; the current look-ahead is however three symbols ahead, and once a decision is taken this is not reconsidered (for cost reasons). This is currently a consequence of the rather simplistic inner organisation of the intermediate library. In the next version we hope to have gotten rid of this artefact. Best, Doaitse > > Yes, for my particular problem the complexity is very limited. I > wouldn't even have used parsec for this, in spite of the comment I had > made earlier about this, if I were not already using it in a different > part of the project to parse individual records ("buy security <foo> > for this price on this date", etc), so it was natural to add a bit > more parsec code to also deal with the commands saying what I want to > see from the data. It's all still pretty trivial, but starting already > to be useful to me... it's really quite gratifying what a small amount > of haskell code suffices to make a useful and flexible program. > > best regards, > Uwe > > On 10/15/09, S. Doaitse Swierstra <doaitse(a)swierstra.net> wrote: >> >> On 15 okt 2009, at 16:58, Uwe Hollerbach wrote: >> >>> Hi, all, thanks for the further inputs, all good stuff to think >>> about... although it's going to be a little while before I can >>> appreciate the inner beauty of Doaitse's version! :-) >> >> The nice thing is that you do not have to understand the inner >> workings ;-} I basically builds a greedy parser for each word to be >> recognised which can stop and assume the rest is there if it can no >> longer proceed (the `opt` is greedy in its left alternative) . Hence >> it recognises the longest possible prefix. >> Since my parsers pursue all alternatives in parallel you >> automatically >> get what you want, without having to indicate prefix lengths, calls >> to >> try, etc. >> >> The "amb" combinator has type >> >> amb :: Parser a -> Parser [a] >> >> and collects the result from all alternatives its argument parser is >> constructed from; you might say it convert an ambiguous parser to a >> parser with a list as result, hence preventing the rest of the input >> being parsed over and over again. I am currently working on bringing >> back more abstract interpretation in the implementation (i.e. what we >> have had for almost 10 years in the uulib library), but I do not >> expect you to see a lot of that from the outside. >> >> If you want to work with left-recursive parsers (which does not seem >> to be the case), you may revert to more complicated solutions such as >> found in the "christmastree" (Changing Haskell's Read Implementation >> Such That by Manipulationg Abstract Syntax Trees Read Evaluates >> Efficiently) package if you need to generate parsers online, or to >> happy-based solutions in case your grammar is fixed. >> >> >> If you have any questions do not hesitate to ask, >> Doaitse >> >> >>> I had considered >>> the approach of doing a post-parsec verification, but decided I >>> wanted >>> to keep it all inside the parser, hence the desire to match prefixes >>> there (and lack of desire to write 'string "p" <|> string "pr" <|> >>> string "pre" ...'. >>> >>> By way of background, the actual stuff I'm wanting to match is not >>> food names, but some commands for a small ledger program I'm working >>> on. I needed something like that and was tired of losing data to >>> quicken every so often. I realize of course that there are other >>> excellent ledger-type programs out there, but hey, I also needed >>> another hacking project. I'll put this onto hackage in a while, once >>> it does most of the basics of what I need. No doubt the main >>> differentiator between mine and those other excellent ledger >>> programs >>> out there will be that mine has fewer features and more bugs... >>> >>> thanks again, all! >>> >>> Uwe >> >>

1 0

ANN: strptime bindings
by Eugene Kirpichov 20 Oct '09

20 Oct '09

Hi all. I had to parse dates from bytestrings efficiently and tried to use the parsedate library, but I had to port it to parsec3 to make it usable with bytestrings, and I could not get decent performance out of the resulting version due to ghc having difficulties with parsec3's generality, so I wrote bindings to strptime. Here they are: http://hackage.haskell.org/package/strptime They work for Strings and strict and lazy bytestrings. They are several orders of magnitude faster than parsedate and than Data.Time.readTime,parseTime (a program that ran in 40s with parsec3'd parsedate runs in less than 1s). -- Eugene Kirpichov Web IR developer, market.yandex.ru

1 0

Re: [Haskell-beginners] map question
by oleg＠okmij.org 20 Oct '09

20 Oct '09

> Something I wonder from time to time if it would be a good thing or > not is to allow > a `f g` b > to mean > f g a b You don't have to wonder: http://www.haskell.org/haskellwiki/Infix_expressions Granted, you have to use different characters rather than the backquote. On the other hand, you can play with infix expressions right now, on any Haskell98 system.

1 0