- Haskell-Cafe - Haskell.org

uniplate and haskell-src-exts (was: Re: code review?)
by Evan Laforge 25 May '11

25 May '11

> +1 on that, I use uniplate for pretty much all my haskell-src-exts tasks > these days, works like a charm! > I'd love to include some standard traversal functionality in > haskell-src-exts that depends on uniplate, but hesitate to do so because of > HP aspirations for haskell-src-exts. Neil, what do you reckon the chances of > getting uniplate in the HP are? :-) Or, you could just put a note in the documentation suggesting that uniplate is a good way to traverse parsed output, along with an example or two. And maybe mention a separate package haskell-src-exts-uniplate with utility functions, if there are any. Keeping deps under control by splitting packages this way has some precedent, and makes some logical sense too, since it's not like the parsed data types are trying to be abstract by hiding constructors.

1 0

Status of Haskell + Mac + GUIs & graphics
by Conal Elliott 25 May '11

25 May '11

I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI & graphics work on hold while waiting & hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! - Conal

22 42

Re: [Haskell-cafe] Policy for taking over a package on Hackage
by Ivan Lazar Miljenovic 25 May '11

25 May '11

On 25 May 2011 23:23, Otakar Smrz <otakar.smrz(a)cmu.edu> wrote: > > I took over the maintenance of wl-pprint since Stefan suggested it > himself. I needed to include OverlappingInstances, because that was > required to make better use of the library (there is a difference having > this flag there, which is consistent with the GHC documentation on > OverlappingInstances). > > I was not aware that I have to announce this. I thought people would > know from checking Hackage that there is this maintainer change and a > new version of the package. Sorry. The whole email wasn't aimed at you specifically: it's just that with Hackage's current infrastructure it's quite easy for someone to "take over" a package and possibly do something malicious with it (so the next time they do a "cabal update" they could inadvertently get a package with said malicious code). Especially if there's no announcement of the change, it's difficult to know that someone has indeed taken over maintaining a library, and thus they could keep addressing queries (or throwing blame) at someone "known" to be the maintainer of a package even if they didn't upload the latest version. > Since I do not have any plans to develop wl-pprint further, I have no > problem giving the maintainer's role to you or anyone interested. OK; if no-one has any objections I'll do so and make it class-based as I've discussed in the threads on -cafe (after considering name clashes with Applicative, etc.). > PS: For the point 4 of your suggested rules, I think uploading a new > version of a package if only the maintainer changes, rather than when > there is some actual change to the library, is inappropriate. You could > easily get package versions increasing without any code/documentation > being actually improved or extended. By "point release" I meant incrementing the fourth digit, which is usually used to refer to bug-fixes. My aim with this was that the new maintainer could immediately "make their mark" so that people looking for a project's maintainer on the hackage page knew who to contact (rather than waiting for them to finish of their new & improved version). -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

Cabal upload failure
by Emil Axelsson 25 May '11

25 May '11

Hello! I'm trying to upload a new version of syntactic, but Hackage gives the error: 500 Internal Server Error <stdin>: hWaitForInput: invalid argument (Invalid or incomplete multibyte or wide character) In fact, I get the same error if I use the "Check" functionality on the earlier version that is already on Hackage. Any idea what causes this? / Emil

4 5

ANNOUNCE: haskell-src-exts 1.11.1
by Niklas Broberg 25 May '11

25 May '11

Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.11.1! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts This major release fixes some long-standing bugs in the fixity handling. Many thanks for Lennart Augustsson for the patches! Changelog: 1.10.2 --> 1.11.1 =============== * API change: the fixities field in ParseMode is now of type Maybe [Fixity]. If the field is Nothing the parsing will not try to do any fixity resolution whatsoever, otherwise it behaves as before. * API change, bug fix: The Fixity type contains a QName rather than an Op to name the operator. The operator must match the given QName exactly (i.e., unqualified names only match unqualified names, and qualified names only match qualified names) for applyFixities to perform fixups. * Bug fix: End-of-file inside an OPTIONS pragma no longer loops. Cheers, /Niklas

1 0

Second CFP: Continuation Workshop 2011
by oleg＠okmij.org 25 May '11

25 May '11

Submission deadline: June 25, 2011 Invited speakers: Mats Rooth (Cornell), Noam Zeilberger (Universite' Paris 7) There will be a tutorial session in the evening before the workshop. ACM SIGPLAN Continuation Workshop 2011 http://logic.cs.tsukuba.ac.jp/cw2011/ co-located with ICFP 2011, Tokyo, Japan Saturday, September 24, 2011 Call for Contributions Continuations have been discovered many times, which highlights their many applications in programming language semantics and program analysis, linguistics, logic, parallel processing, compilation and web programming. Recently, there has been a surge of interest specifically in delimited continuations: new implementations (in Scala, Ruby, OCaml, Haskell), new applications (to probabilistic programming, event-driven distributed processing), substructural and constructive logics, natural language semantics. The goal of the Continuation Workshop is to make continuations more accessible and useful -- to practitioners and to researchers in various areas of computer science and outside computer science. We wish to promote communication among the implementors and users in many fields. We would like to publicize the applications of continuations in academic (logic, linguistics) and practical fields and various programming languages (OCaml, Haskell, Scala, Ruby, Scheme, etc). Continuation Workshop 2011 will be informal. We aim at accessible presentations of exciting if not fully polished research, and of interesting academic, industrial and open-source applications that are new or unfamiliar. The workshop will have no published proceedings; submissions of short abstracts are preferred. Invited speakers ---------------- Mats Rooth, Director of Computational Linguistics Lab, Cornell University, USA http://conf.ling.cornell.edu/mr249/ Noam Zeilberger, Universite' Paris 7 http://www.pps.jussieu.fr/~noam/ Tutorials --------- In the evening before the workshop, there will be a tutorial session on delimited continuations and their main applications. Tutorial date and time: Friday, September 23, 2011, 19:00-21:00 Tutorial place: IIJ (next to NII, the place of the ICFP conference) Tutorial speakers: Kenichi Asai and Oleg Kiselyov Important dates --------------- Submission: June 25, 2011 Notification: August 8, 2011 Tutorials: September 23, 2011 Workshop: September 24, 2011 Format ------ The workshop will consist of presentations by the participants, selected from submitted abstracts. Participants are invited to submit working drafts, source code, and/or extended abstracts for distribution on the workshop homepage and to the attendees, but as the workshop will have no formal proceedings, any contributions may be submitted for publication to other venues. (See the SIGPLAN republication policy for more details.) Scope ----- We seek several types of presentations on topics related to continuations. We especially encourage presentations that describe work in progress, outline a future research agenda, or encourage lively discussion. Research presentations on: - implementations of continuations - semantics - type systems and logics - meta-theory and its mechanization - code generation with continuations or effects - distributed programming - systems programming and security - pearls Research presentations must be broadly accessible and should describe new ideas, experimental results, significant advances in the theory or application of continuations, or informed positions regarding new control operators. Application presentations, or status reports These broadly accessible presentations should describe interesting applications of continuations in research, industry or open source. We encourage presentations of applications from areas outside of programming language research -- such as linguistics, logics, AI, computer graphics, operating systems, etc. These presentations need not present original research, but should deliver information that is new or that is unfamiliar to the general ICFP audience. (A broadly accessible version of research presented elsewhere, with the most recent results and more discussion of future work may be acceptable as a CW 2011 status report.) The abstract submission should justify, to a general reader, why an application is interesting. Demos and work-in-progress reports Live demonstrations or presentations of preliminary results are intended to show new developments, interesting prototypes, or work in progress. In the abstract submission (which need only be about half a page), describe the demo and its technical content, and be sure to include the demo's title, authors, collaborators, references, and acknowledgments. A demonstration should take 10-15 minutes, and a work-in-progress report should take about 5 minutes. The exact time per demo will be decided based on the number of accepted submissions. (Presenters will have to bring all the software and hardware for their demonstration; the workshop organizers are only able to provide a projector.) Submission Guidelines and Instructions -------------------------------------- Unlike the previous Continuation Workshops, we do not require the submission of complete research papers. We will select presentations based on submitted abstracts, up to 2 (A4 or US letter) pages long in the PDF format (with the optional supplementary material, up to 8 PDF pages). Persons for whom this poses a hardship should contact the program chair. Submissions longer than a half a page should include a paragraph synopsis suitable for inclusion in the workshop program. Email submissions to cw2011-submit(a)logic.cs.tsukuba.ac.jp Organizers ---------- Yukiyoshi Kameyama, University of Tsukuba Chung-chieh Shan, Rutgers University Oleg Kiselyov Program Committee ----------------- Kenichi Asai, Ochanomizu University, Japan Malgorzata Biernacka, University of Wroclaw, Poland Hugo Herbelin, PPS - pi.r2, INRIA, France Oleg Kiselyov Julia Lawall, University of Copenhagen, Denmark Tiark Rompf, EPFL, Switzerland Chung-chieh Shan, Rutgers University (Chair) Hayo Thielecke, University of Birmingham, UK

1 0

Re: [Haskell-cafe] [Haskell] ANNOUNCE: time-recurrence-0.1
by Yitzchak Gale 25 May '11

25 May '11

Moving the discussion from haskell to haskell-cafe. Chris Heller wrote: >> http://github.com/hellertime/time-recurrence >> A library for generating and inspecting recurring times. Very nice. Please put it up on hackage so we can see the haddocks, try it out easily, etc. >> hoping to solicit some feedback on its design. Very well done. I have been think about recurrence rules, too. Version 2 Olson timezone files contain POSIX rules to specify clock change rules for times later than the last one listed in the timezone series. Currently, the timezone-series package ignores those. I like your introduction of symbolic months and weekdays. The numeric-only interface of Data.Time for those things leads to messiness like multiple functions depending on how you number the weekdays. That logic should be moved out to a separate interface. You are correct that it is worth creating a separate module for that. Please do so! Include neater versions of the corresponding functions from Data.Time. Another comment - I would have used fromGregorianValid instead of fromGregorian. It's not a good idea for a basic time library to introduce possible crashes. At least you should provide an alternative safe interface. Similarly for toEnum. >> The general direction is to have something that works much >> like the RRULE portion of the iCalendar (RFC 5545) >> specification. I have decided avoid strict RFC compliance >> at this time. Ashley Yakeley wrote: > At one point I investigated a really generalised version of this, including > an abstract syntax type and perhaps a way of parsing some useful > subset of English expressions into it. However I got stuck on such > things as > > "any day after the sixth Sunday of a month" > > In order to prove that today was not such a day, it would have know that > "sixth Sunday of a month" never happens. Simply searching into the past for > one would never terminate. Either I would have to restrict the language, or > assert the beginning of time (not necessarily a bad solution). I don't see why you would need to make any such restrictions. There would only be a finite number of primitive comparison types, and since your language would be total, any expression could be reduced to the primitive ones in a finite number of steps. Then it would just be a matter of arithmetic on sets of ranges; see, for example, http://hackage.haskell.org/package/Ranged-sets That allows for half-infinite and infinite ranges as well. Regards, Yitz

2 2

Re: [Haskell-cafe] Code critique - Was [Maybe Int] sans Nothings
by michael rice 25 May '11

25 May '11

Thanks, Alexander. Not as much red ink as I was expecting. My monitor is acting up, so I may be be dropping off the radar unexpectedly while acquiring a replacement. Each prefix is guaranteed to have at least one following word in its suffix list (possibly more) because the map is built from the actual Psalms text. The only prefix for which this does not occur is the final two words of the text, thus the TRUE case in buildMap puts the sole non_word in the suffix list. The generate function then _always_ builds a prefix from the first two words of the text, "Blessed is," looks up its suffix list, chooses the next word randomly, and creates a new prefix by pairing the second word of the old prefix and the new word. Repeat. I've attached the AWK and C++ sources for the same Markov exercise if you wish to examine them. Both just write a single word on each line so I cobbled a Haskell program (lines.hs) to turn them into lines. Michael --- On Tue, 5/24/11, Alexander Solla <alex.solla(a)gmail.com> wrote: From: Alexander Solla <alex.solla(a)gmail.com> Subject: Re: [Haskell-cafe] Code critique - Was [Maybe Int] sans Nothings To: "michael rice" <nowgate(a)yahoo.com> Cc: "Haskell Cafe" <haskell-cafe(a)haskell.org> Date: Tuesday, May 24, 2011, 10:42 PM My comments are in-line, marked off with >>> On Tue, May 24, 2011 at 4:09 PM, michael rice <nowgate(a)yahoo.com> wrote: The input file: http://dl.dropbox.com/u/27842656/psalms The Markov chain exercise from "The Practice of Programming", Kermighan/Pike. Sample runs at the end. Michael ============================ import System.Environment(getArgs)import System.Randomimport Control.Applicativeimport Control.Monad.Reader import Control.Monad.Stateimport Data.Maybeimport Data.Map type Prefix = (String,String)type GeneratorState1 = State ((Map Prefix [String]),Prefix,[String]) type GeneratorState2 = StateT (Prefix,StdGen) (Reader (Map Prefix [String])) non_word = "\n" f key new old = new ++ old >>> I don't see what f is for, since it doesn't do anything with the key. buildMap :: GeneratorState1 (Map Prefix [String])buildMap = do (mp,(pfx1,pfx2),words) <- get if (Prelude.null words) then {- No more words. Return final map (adding non_word for final prefix). -} return (insertWithKey' f (pfx1,pfx2) [non_word] mp) else do {- Add word to map at prefix & continue. -} put (insertWithKey' f (pfx1,pfx2) [head words] mp, (pfx2,(head words)), tail words) buildMap >>> I'm not a fan of explicit if-then-else's, but my preferred alternative won't win much either. (see http://osdir.com/ml/haskell-cafe@haskell.org/2011-05/msg00612.html for an example of what I'm talking about) generate :: GeneratorState2 (Maybe String)generate = do ((pfx1,pfx2),gen) <- get mp <- ask let suffixList = mp ! (pfx1,pfx2) >>> I'm not sure how you're guaranteed that mp ! (pfx1, pfx2) exists, at first glance. "lookup" uses Maybe semantics, in the case there is no result. let (index,newGen) = randomR (0, (length suffixList)-1) gen >>> I might use a function like:>>> listRange :: [a] -> (Int, Int)>>> listRange list = (0, (length $ l) - 1) >>> This is a common enough pattern to abstract away. let word = suffixList !! index if (word == non_word) then return Nothing else do put ((pfx2,word),newGen) return (Just word) rInt :: String -> IntrInt = read >>> rInt is fair enough, but you can also have the same effect with an explicit type signature ((read n) :: Int) I tend to prefer the latter, personally. main = do (seed:nwords:_) <- (Prelude.map rInt) <$> getArgs contents <- getContents putStrLn $ unwords $ catMaybes $ runReader (evalStateT (sequence $ replicate nwords generate) ((non_word,non_word),mkStdGen seed)) (evalState buildMap (singleton (non_word,non_word) [], (non_word,non_word), words contents)) >>> Nice use of functor application. {-[michael@hostname ~]$ ghc --make markov.hs[1 of 1] Compiling Main ( markov.hs, markov.o ) Linking markov ...[michael@hostname ~]$ cat psalms | ./markov 111 100Blessed is the LORD, in thine own cause: remember how the foolish people have blasphemed thy name. In the courts of the righteous: The LORD taketh pleasure in the desert. And he led them with the wicked, and with the whole earth, is mount Zion, on the sides of thine only. O God, and was troubled: I complained, and my God. My times are in thy praise. Blessed be God, which is full of the LORD is good: for his wondrous works. Now also when I am small and despised: yet do I put my trust: how say ye to[michael@hostname ~]$ cat psalms | ./markov 666 100 Blessed is the LORD, and cried unto thee, Thy face, LORD, will I remember thee from the beginning: and every one that is weaned of his heart to any wicked transgressors. Selah. They return at evening: they make ready their arrow upon the people; and thou hast destroyed all them that fight against them that trust in thee: and let my tongue cleave to the heavens by his power for ever; and thy lovingkindnesses; for they have laid a snare before them: and that my ways were directed to keep thy word. Mine eyes fail while I have said that [michael@hostname ~]$ --- On Tue, 5/24/11, Alexander Solla <alex.solla(a)gmail.com> wrote: From: Alexander Solla <alex.solla(a)gmail.com> Subject: Re: [Haskell-cafe] [Maybe Int] sans Nothings To: "Haskell Cafe" <haskell-cafe(a)haskell.org> Date: Tuesday, May 24, 2011, 5:01 PM > Personally, I find non-functional values without Eq instances to be > degenerate. So I really do not mind superfluous Eq constraints. I > would not hesitate to use filter ((/=) Nothing) in a function whose type > has no free type variables. It's just a bit of plumbing inside of a > more complex function. Sometimes it seems to be better to not allow Eq on Float and Double. Since most algebraic laws do not hold for those types, it is more often an error than an intention to compare two Float values. And how to compare (IO a) values? Floats, Doubles, and IO are all "degenerate" types, for the reasons you outline. (Admittedly, Float and Double have Eq instances, but invalid Eq semantics) Notice how their value semantics each depend on the machine your runtime runs on, as opposed to merely the runtime. Bottom is another one of these degenerate types, since comparisons on arbitrary values are undecidable. Also, by thinking about function types, you often get interesting use cases. Thus I would not assume too quickly that a type will always be instantiated by types other than a function type. Thus I would stick to (filter isJust) and use this consistently for monomorphic and polymorphic types. I am not suggesting (filter ((/=) Nothing)) /over/ (filter isJust). Obviously, once one is aware of a better tool, one should use it. But I am suggesting that for simple cases which are unlikely to change in any substantive way, we should probably just use the tools we already know of, as opposed to searching for the "right" one. Both might involve costs. There is a cost involved in going to Google, thinking up a search term, finding that Data.Maybe has relevant functions, picking the right one. It takes less time to write "filter ..." than to type "haskell removing nothing from list", for example. When dealing with known unknowns, there is a balance to be made, and it is not easy. Michael's choice to ask the list imposed costs. (Not that we mind, we're all volunteers, after all). But it probably took 10 minutes to get the first reply. He could have written a bit of code that worked correctly, given the context of his problem, in 20 seconds. Then again, he probably worked on a different bit of code until somebody sent a solution, so we probably only have to account for the time spent in context switching, for everyone involved. -----Inline Attachment Follows----- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

ANNOUNCE: time-recurrence-0.2
by Chris Heller 25 May '11

25 May '11

Hot on the heels of the 0.1 release of time-recurrence: http://hackage.haskell.org/package/time-recurrence comes your favorite recurring time library: time-recurrence-0.2. At this point the library can generate many of the examples given in section 3.8.5.3 of the iCalendar RFC. The interface has been reworked to make things more concise, an example: > -- Generate every 10 days, 5 occurrences > startDate = utcGregorianWithTime 1997 9 2 14 0 0 -- Y M D HH MM SS > map moment $ take 5 $ recurBy 10 [] $ Daily startDate > [1997-09-02 14:00:00 UTC > ,1997-09-12 14:00:00 UTC > ,1997-09-22 14:00:00 UTC > ,1997-10-02 14:00:00 UTC > ,1997-10-12 14:00:00 UTC] I'm still tweaking the main data structures so things are very unstable right now. There is no support for operators like the iCalendar BYSETPOS, which would allow you to generate "the 30th of the month in June if it is a Week Day otherwise the last Week Day in June". For the future I also am looking at how to enforce some of the more esoteric iCalendar rules, such as using BYMONTHDAY in a MONTHLY frequency when also using BYDAY. Since I am not being strict I can simply punt on the matter, but it would be interesting to support such dependencies. As always I encourage all feedback, suggestions and pull requests. -Chris

1 0

GOA broken with recent lambdabots
by Jacek Generowicz 24 May '11

24 May '11

GOA is broken with recent lambdabots, according to http://hackage.haskell.org/package/goa-3.0.2 It certainly fails to compile for me (like this http://hpaste.org/46994/goa_build_failure ) From the fact that it is known to be broken, should I infer that it is a difficult problem that would take an expert a long time to fix? Or is it broken merely because nobody has got around to fixing it, and would somebody (like me) who is not a Haskell expert and has never looked into the source of lambdabot or GOA, stand a chance of fixing it?

3 4