Re: [Haskell-cafe] *GROUP HUG*
On 25/05/2011, at 12:41 AM, Johannes Waldmann wrote: Yves Parès limestrael at gmail.com writes: For instance, one of my friends asked me once why the operation of calculating the length of list has an O(n) complexity, since to his opinion, you could just store the size inside the list and increment it when elements are appended. Then tell me, why does calculating the length of a (Haskell) list has O(n) complexity. Because it is a rather rare operation and the cost of doing this would be far higher than you think. I could just store the length of the list Let's take abcdef as an example. This is a list of length 6, containing a list of length 5, containing a list of length 4, containing a list of length 3, containing a list of length 2, containing a list of length 1, containing a list of length 0 (which can be shared). So for this little example, you're saying why not store six more numbers? And I say, why push up the space and time requirements so high for something that is so very seldom useful? Then of course there are lists like fibs = 1 : 1 : zipWith (+) fibs (tail fibs) that don't _have_ a finite length. On the other hand, there are implementations of strict sequences with an O(1) size implemenation. http://hackage.haskell.org/packages/archive/containers/0.4.0.0/doc/html/Data-Sequence.html#v:length The O(1) size comes at a cost; if all you need is what lists do well, it's a good idea to avoid finger trees. If you DO need the things that finger trees do well, by all means use them. The contrast here is not that Haskell doesn't store the length of lists and Java does, but that Java doesn't do plain lists at all, and Haskell does. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] *GROUP HUG*
On 24/05/11 22:41, Johannes Waldmann wrote: Then tell me, why does calculating the length of a (Haskell) list has O(n) complexity. Infiniticity aside, tail would become O(n) if you store a length with each cons cell. -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] *GROUP HUG*
Why so? I think it wouldn't. data FList a = FNil | FCons Int a (FList a) empty = FNil len FNil = 0 len (FCons n _) = n cons x xs = FCons (1 + len xs) x xs tail (FCons _ _ xs) = xs 2011/5/24 Tony Morris tonymor...@gmail.com: On 24/05/11 22:41, Johannes Waldmann wrote: Then tell me, why does calculating the length of a (Haskell) list has O(n) complexity. Infiniticity aside, tail would become O(n) if you store a length with each cons cell. -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] *GROUP HUG*
On 25/05/11 16:46, Eugene Kirpichov wrote: data FList a = FNil | FCons Int a (FList a) empty = FNil len FNil = 0 len (FCons n _) = n cons x xs = FCons (1 + len xs) x xs tail (FCons _ _ xs) = xs My mistake, sorry. Currently looking for original reason to have accidentally come to believe that. -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: time-recurrence-0.1
I wrote: 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. Chris Heller wrote: are you suggesting something like doing modulo arithmetic rather than calling error on undefined values? Well, the standard safe interface would just wrap the return type in Maybe, like fromGregorianValid does. Then you might use it something like this: maybe [] (map moment . take 5 . recurBy 10 [] . Daily) maybeStartDate Using modulo arithmetic for toEnum would indeed make the function safe, but I'm not sure that would give the results that users are expecting. For the start date of a recurrence, though, you are right that you might be able to do better than just using Maybe. Suppose you had a function that rounds an invalid Gregorian date forward to the nearest valid date. Then a user that asks for a recurrence starting with, say, Feb. 30 would get dates starting at the beginning of March, which is probably what was intended. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] *GROUP HUG*
Tony Morris schrieb: On 25/05/11 16:46, Eugene Kirpichov wrote: data FList a = FNil | FCons Int a (FList a) empty = FNil len FNil = 0 len (FCons n _) = n cons x xs = FCons (1 + len xs) x xs tail (FCons _ _ xs) = xs My mistake, sorry. Currently looking for original reason to have accidentally come to believe that. Maybe you thought of 'take'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code critique - Was [Maybe Int] sans Nothings
Alexander Solla schrieb:
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
case words of
[] - {- no more words -} ...
w:ws - ...
would work perfectly.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Second CFP: Continuation Workshop 2011
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
Re: [Haskell-cafe] *GROUP HUG*
Richard O'Keefe o...@cs.otago.ac.nz writes: Then tell me, why does calculating the length of a (Haskell) list has O(n) complexity. Because it is a rather rare operation and the cost of doing this would be far higher than you think. I suspect that if you store the length non-strictly, it would build up thunks, causing a stack overflow when evaluated. If it is strict, it would make a lot of operations that are O(1) today into O(n) operations. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: haskell-src-exts 1.11.1
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal upload failure
Yep, works fine now, thanks! /Niklas On Tue, May 24, 2011 at 2:52 PM, Ross Paterson r...@soi.city.ac.uk wrote: Version skew problem -- I hope it's fixed now. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Function application layout
Hi,
Would it be possible to allow this in Haskell (where applied to is some
new operator or keyword):
f applied to {x a;y b;z c}
As an equivalent to:
f (x a) (y b) (z c)
Of course my intention is that the new keyword should initiate layout syntax
so we can write this:
f applied to
x a
y b
z c
In addition to the case where you have a big function application, this is
useful for defining trees:
Branch applied to
Branch applied to
Leaf
Leaf
Leaf
Has something like this been suggested before? Are there any disadvantages
other than a new keyword and some potential confusion for readers?
Any suggestions for a good keyword? I suppose some variant of $ makes sense,
a textual keyword like with would be nice but probably break a lot of
code.
Regards,
Jonas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] uniplate (was: code review?)
From: Neil Mitchell ndmitch...@gmail.com While I'm on the topic, I recently wrote a tool that wanted to traverse deep data structures as produced by haskell-src-exts. ?I wound up with about 50 lines of case expressions and around the time my hands were literally beginning to hurt decided that enough was enough and I should try a generic approach. ?I heard uniplate was pretty easy to use, and was pretty pleased to turn the entire thing into a single line. ?It took me a little longer to figure out I needed to use universeBi since all the examples were monotyped, but once I did it Just Worked. ?Amazing. ?So thanks again! ?And maybe you could mention universeBi in the instant introduction? Yes, I probably should - I'll try and get to that. Of course, I'd also happily accept a patch against http://community.haskell.org/~ndm/darcs/uniplate I use Uniplate inside HLint, and it's invaluable - there are a lot of times when List Comp + universeBi really hits the spot. Does Uniplate include an instance for: instance Uniplate a = Biplate [a] a ? Since lists are a common case, I was surprised that this instance wasn't included. Is there a reason it shouldn't exist? I was importing Data.Generics.Uniplate.Direct FWIW. Thanks, John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] code review?
On Tue, May 24, 2011 at 7:18 PM, Neil Mitchell ndmitch...@gmail.com wrote: Before doing a code review I always demand that the author runs over the code with HLint (http://community.haskell.org/~ndm/hlint) - they Very good point. In fact you just inspired me to finally download it and run it on my own code. Thanks for the great tool! Glad you like it. While I'm on the topic, I recently wrote a tool that wanted to traverse deep data structures as produced by haskell-src-exts. I wound up with about 50 lines of case expressions and around the time my hands were literally beginning to hurt decided that enough was enough and I should try a generic approach. I heard uniplate was pretty easy to use, and was pretty pleased to turn the entire thing into a single line. It took me a little longer to figure out I needed to use universeBi since all the examples were monotyped, but once I did it Just Worked. Amazing. So thanks again! And maybe you could mention universeBi in the instant introduction? Yes, I probably should - I'll try and get to that. Of course, I'd also happily accept a patch against http://community.haskell.org/~ndm/darcs/uniplate I use Uniplate inside HLint, and it's invaluable - there are a lot of times when List Comp + universeBi really hits the spot. +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? :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
On 2011 May 25, at 05:53, Mark Wright wrote: On Wed, 25 May 2011 02:20:39 +0200, Jacek Generowicz jacek.generow...@cern.ch wrote: I have recenly installed lambdabot. Its response to *each* *and* *every* hoogle command is *always* A Hoogle error occurred. I'm hoping that someone on Cafe might be able to offer a more helpful diagnosis than this ... erm ... terse ... error message. Hi Jacek, Hi Mark, The lambdabot hoogle command requires hoogle to be installed locally, and to work. Ah. Thank you. I had assumed that it connected to a server. (Maybe my assumption was not entirely unfounded, given that the installation instructions for lambdabot blithely state that you just cabal install lambdabot, nowhere suggesting that you might need to *manually* install some of its dependencies.) Hence the first thing to ty is to run the hoogle command line version, something like: hoogle '[a] - a' If that doesn't work, maybe try building some hoogle databases. First I needed to 'cabal install hoogle'. Having done that, I needed to do what you suggested: hoogle data Which works swimmingly on Ubuntu, but fails on OS X, because wget seems to be hard-wired. I seem to recall that at least one of the packages that I installed over the last 2 days, automatically selected wget on Ubuntu, and curl on OS X. Any pointers to the least painful way of getting 'hoogle data' to work on OS X? Once I have the hoogle command line version working, it seems that lambdabot truncates its output to just the first 3 lines. Is this normal? Is there a way of customizing or changing this behaviour? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] *GROUP HUG*
So it seconds my initial point: you can't store the size because it has no sense. 2011/5/25 Ketil Malde ke...@malde.org Richard O'Keefe o...@cs.otago.ac.nz writes: Then tell me, why does calculating the length of a (Haskell) list has O(n) complexity. Because it is a rather rare operation and the cost of doing this would be far higher than you think. I suspect that if you store the length non-strictly, it would build up thunks, causing a stack overflow when evaluated. If it is strict, it would make a lot of operations that are O(1) today into O(n) operations. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
On Wed, 25 May 2011 12:22:24 +0200, Jacek Generowicz jacek.generow...@cern.ch wrote: On 2011 May 25, at 05:53, Mark Wright wrote: On Wed, 25 May 2011 02:20:39 +0200, Jacek Generowicz jacek.generow...@cern.ch wrote: I have recenly installed lambdabot. Its response to *each* *and* *every* hoogle command is *always* A Hoogle error occurred. I'm hoping that someone on Cafe might be able to offer a more helpful diagnosis than this ... erm ... terse ... error message. Hi Jacek, Hi Mark, The lambdabot hoogle command requires hoogle to be installed locally, and to work. Ah. Thank you. I had assumed that it connected to a server. (Maybe my assumption was not entirely unfounded, given that the installation instructions for lambdabot blithely state that you just cabal install lambdabot, nowhere suggesting that you might need to *manually* install some of its dependencies.) Hence the first thing to ty is to run the hoogle command line version, something like: hoogle '[a] - a' If that doesn't work, maybe try building some hoogle databases. First I needed to 'cabal install hoogle'. Having done that, I needed to do what you suggested: hoogle data Which works swimmingly on Ubuntu, but fails on OS X, because wget seems to be hard-wired. I seem to recall that at least one of the packages that I installed over the last 2 days, automatically selected wget on Ubuntu, and curl on OS X. Any pointers to the least painful way of getting 'hoogle data' to work on OS X? Hi Jacek, Sorry I have no idea about OS X, hopefully someone else might know. I assume your test on OS X was with the latest hoogle version so that old issues would no longer be relevant: http://code.google.com/p/ndmitchell/issues/detail?id=429 Once I have the hoogle command line version working, it seems that lambdabot truncates its output to just the first 3 lines. Is this normal? Yes. Is there a way of customizing or changing this behaviour? No (other than patching lambdabot), so the obvious workaround is to run the hoogle from the command line. Regards, Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code critique - Was [Maybe Int] sans Nothings
Yes, very nice. Thanks.
Michael
--- On Wed, 5/25/11, Henning Thielemann schlepp...@henning-thielemann.de
wrote:
From: Henning Thielemann schlepp...@henning-thielemann.de
Subject: Re: [Haskell-cafe] Code critique - Was [Maybe Int] sans Nothings
To: michael rice nowg...@yahoo.com
Cc: Haskell Cafe haskell-cafe@haskell.org
Date: Wednesday, May 25, 2011, 3:41 AM
Alexander Solla schrieb:
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
case words of
[] - {- no more words -} ...
w:ws - ...
would work perfectly.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot check
Hi Mark, Thanks for your wonderfully lucid, concise and complete explanation of the problem and its solution (included below). When I apply your patch and reinstall lambabot, I now get the following problem: lambdabot check True Could not find module `ShowIO`: It is a member of the hidden package `show-0.3.4`. Use -v to see a list of the files searched for. I recognize the message about -v as a ghci one. How could I inject this -v into lambabot ? I get the same error on both of the machines on which I am trying this. On one of them I already have show-0.3.4 and show-0.4.1.1, on the other I have only show-0.4.1.1. Any suggestions? On 2011 May 25, at 06:06, Mark Wright wrote: Hi Jacek and Gwern, In the upgrade from mueval from 0.8 to 0.8.1, some of the mueval command line options were changed: --loadfile = --load-file --noimports = --no-imports For Plugins/Check.hs I change --loadfile to -l. To convince lambdabot to run on gentoo, I patch it to use --no- imports to avoid this problem: % mueval -e '1 + 2' Ambiguous module name `Control.Monad.Cont': it was found in multiple packages: monads-fd-0.1.0.2 mtl-2.0.1.0 monads-tf-0.1.0.0 % And I patch the lambdabot /usr/share/lambdabot-4.2.3.2/ghc-7.0.3/ State/L.hs to used -XPackageImports. Then mueval works: % mueval --no-imports -l ~/.lambdabot/State/L.hs -e '1 + 2' 3 % And lambdabot works: % lambdabot Initialising plugins ... done. lambdabot @check True +++ OK, passed 100 tests. OK, passed 100 tests. lambdabot The patch is here: https://github.com/markwright/gentoo-haskell/blob/master/dev-haskell/lambdabot/files/lambdabot-4.2.3.2-eval.patch Regards, Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
On 2011 May 25, at 13:10, Mark Wright wrote: I assume your test on OS X was with the latest hoogle version so that old issues would no longer be relevant: I would be surprised if it weren't the latest, as I started installing everything from scratch a couple of days ago. Anyway, my hoogle version is 4.2.3, which is the most recent, AFAICT (ie, it's the highest version number on hackage) but I have tripped over so many things on this trip, that I wouldn't be surprised by anything any more. Once I have the hoogle command line version working, it seems that lambdabot truncates its output to just the first 3 lines. Is this normal? Yes. Is there a way of customizing or changing this behaviour? No (other than patching lambdabot), so the obvious workaround is to run the hoogle from the command line. Understood. Thank you. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Policy for taking over a package on Hackage
With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc. I was thinking of doing so, and in such a case it would probably make the most amount of sense to actually then migrate the package back to the wl-pprint package instead of defining yet another package (and corresponding namespace), especially as I recalled from when I first started hacking on wl-pprint-text at the beginning of the year that the last (and only) upload had been in 2007 by Stefan O'Rear. As such, I was going to email Stefan and asked if he minded if I took over maintaining wl-pprint. However, when I went to the package page to get his email address, I saw that Otakar Smrz had released a new version about a month ago, and that the only change in the package that I could find was that OverlappingInstances was added to the .cabal file (which I thought wouldn't make a difference anyway). Now, for all I know, Otakar had already asked Stefan for permission to take over the package (I've CC'd both of them just in case). But even if he didn't, we don't officially have any policies set in place - especially ones that are enforced by requiring registering a package and specifying a maintainer - to indicate that such a thing shouldn't be done. Furthermore, if packages aren't announced then there's no way for people to know that there _is_ a new maintainer. This situation also arose last year [1], and was resolved by someone volunteering to take over a package. However, no formal policy was set in place (despite one being proposed). As such, I'd like to propose the following policy based upon the one Ben Millwood proposed last time on how to take over maintainership of a package that hasn't been updated for a while: 1. Email the current listed maintainer and wait a specified period of time (e.g. 2 weeks). 2. Email haskell-cafe, explicitly CC'ing maintainers of reverse dependencies (at least those that are themselves still active) and request permission to take over. This way, people who know the maintainer might point out that they are indeed still around, etc. 3. If no-one objects within another two weeks, announce that you have taken over maintainership with a new email (in case people are ignoring the previous thread). 4. Upload a point release of the previous package (assuming it follows the PVP) with yourself as the new maintainer (just to get it out there). Alternatively, if you already have a new version ready to go then upload that. Of course, having a policy like this is useless if there is no way to enforce it. Is it possible at the very least to have Hackage note when a new version of a package is uploaded with a new maintainer and require it to be approved by someone before it iis officially available? I think this would be the bare minimum (as opposed to requiring explicit logins on a per-package basis or some kind of signing) required for this kind of scheme to be effective. [1]: http://www.haskell.org/pipermail/haskell-cafe/2010-August/081353.html and http://www.haskell.org/pipermail/haskell-cafe/2010-August/082319.html -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
Hi Ivan Forks are good, no? The Parsec experience has suggested to me at least, that new author's capping another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone. As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application layout
2011/5/25 Jonas Almström Duregård jonas.dureg...@chalmers.se
Would it be possible to allow this in Haskell (where applied to is some
new operator or keyword):
f applied to {x a;y b;z c}
Sounds like idiom brackets to me.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 25 May 2011 22:17, Stephen Tetley stephen.tet...@gmail.com wrote: Hi Ivan Forks are good, no? The Parsec experience has suggested to me at least, that new author's capping another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone. As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better. Such as? I'm _hopeless_ at making up names... ;-) Having a new package would require a new name and new module namespace, let alone thinking up new names for combinators... Also, by clashes with Applicative, are you referring to empty and $ ? I'm not sure if a better name than empty can be found; as for $, maybe using pretty's notation of $$ and $+$ rather than $ and $$ ? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
2011/5/25 Ivan Lazar Miljenovic ivan.miljeno...@gmail.com: On 25 May 2011 22:17, Stephen Tetley stephen.tet...@gmail.com wrote: Hi Ivan Forks are good, no? The Parsec experience has suggested to me at least, that new author's capping another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone. As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better. Such as? I'm _hopeless_ at making up names... ;-) Having a new package would require a new name and new module namespace, let alone thinking up new names for combinators... Also, by clashes with Applicative, are you referring to empty and $ ? I'm not sure if a better name than empty can be found; as for $, maybe using pretty's notation of $$ and $+$ rather than $ and $$ ? What about 'emptyDoc'? Moreover, if you are changing the names of combinators, then moving them away from Applicative and Arrow would be a good idea; i.e., don't use +, as it already used by ArrowPlus. Moreover, if you can make a Monoid instance such that `mappend` equals , you would also make the library compatible to a future introduction of () = mappend. best regards, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On Wed, May 25, 2011 at 2:01 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc. I'm a bit skeptical of using type classes to abstract over Unicode string types and byte sequence types. The only API shared by the two kind of types is that of a sequence. Things like dot , spaces, etc. don't make much sense on binary data. You must assume that the ByteString contains text in some encoding to make sense of such concepts. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Names for pretty-printing combinators
(Changing the subject as it's going off-topic from the original email :p) On 25 May 2011 22:45, Simon Meier iridc...@gmail.com wrote: 2011/5/25 Ivan Lazar Miljenovic ivan.miljeno...@gmail.com: Also, by clashes with Applicative, are you referring to empty and $ ? I'm not sure if a better name than empty can be found; as for $, maybe using pretty's notation of $$ and $+$ rather than $ and $$ ? What about 'emptyDoc'? It's a bit more of a mouthful, and getting a bit close to Hungarian Notation, isn't it? :p Also, empty is already used a fair amount in other libraries as it stands (admittedly, most of those are in modules that are typically imported qualified...). Moreover, if you are changing the names of combinators, then moving them away from Applicative and Arrow would be a good idea; i.e., don't use +, as it already used by ArrowPlus. *sigh* We really need to get a list of used operators somewhere so that libraries can stake a claim :p Moreover, if you can make a Monoid instance such that `mappend` equals , you would also make the library compatible to a future introduction of () = mappend. I was thinking about that actually... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 25 May 2011 22:52, Johan Tibell johan.tib...@gmail.com wrote: On Wed, May 25, 2011 at 2:01 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc. I'm a bit skeptical of using type classes to abstract over Unicode string types and byte sequence types. The only API shared by the two kind of types is that of a sequence. Things like dot , spaces, etc. don't make much sense on binary data. You must assume that the ByteString contains text in some encoding to make sense of such concepts. Well, using the Char8 version. I was thinking of a class looking something like: class (IsString s, Monoid (Builder s)) = Prettyable s where type Builder s toBuilder :: s - Builder s fromBuilder :: Builder s - s And then Doc now takes in a type parameter, which needs to be an instance of Prettyable. The IsString constraint is so that combinators like int and double can be defined via show (rather than have them being class-level methods), toBuilder is used to convert an actual s value to (Doc s) and fromBuilder is used for the final rendering at the end. The only other thing I can think of that _may_ need to be done on a class level is the allowable size lengths of values (Int64 for lazy ByteString and Text, and possibly just Int for convenience with String). Though if displayIO is going to be kept some kind of s - IO () method will also be needed, though arguably displayIO isn't that necessary. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 25 May 2011 23:23, Otakar Smrz otakar.s...@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.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot check
On Wed, 25 May 2011 13:20:19 +0200, Jacek Generowicz jacek.generow...@cern.ch
wrote:
Hi Mark,
Thanks for your wonderfully lucid, concise and complete explanation of
the problem and its solution (included below).
When I apply your patch and reinstall lambabot, I now get the
following problem:
lambdabot check True
Could not find module `ShowIO`:
It is a member of the hidden package `show-0.3.4`.
Use -v to see a list of the files searched for.
I recognize the message about -v as a ghci one. How could I inject
this -v into lambabot ?
Hi Jacek,
I don't know how to inject the -v into lambdabot, I guess I must
of debugged this earlier by grep'ing in the lambdabot and show source
files for ShowIO.
I get the same error on both of the machines on which I am trying
this. On one of them I already have show-0.3.4 and show-0.4.1.1, on
the other I have only show-0.4.1.1.
Any suggestions?
The show module names were changed in the upgrade from show 0.3.4 to
show 0.4.1.1. On gentoo I conditionally sed lambdabot to account
for this, then print out a note that the user may need to copy
the State/* files, in particular L.hs and Pristine.hs for this problem,
to ~/.lambdabot/State.
src_prepare() {
cd ${S}
epatch ${FILESDIR}/${P}-eval.patch
if has_version dev-haskell/mtl-2.0.0.0; then
epatch ${FILESDIR}/${P}-mtl-1.patch
fi
if has_version =dev-haskell/show-0.4.1.1; then
sed -e 's@import ShowIO@import ShowFun@' \
-i ${S}/State/L.hs \
-i ${S}/State/Pristine.hs \
|| die Could patch State/L.hs and State/Pristine.hs
for show upgrade
fi
}
pkg_postinst() {
ghc-package_pkg_postinst
elog It may be necessary to: mkdir -p ~/.lambdabot/State cp
/usr/share/lambdabot-*/ghc-*/State/* ~/.lambdabot/State
}
Thanks, Mark
PS the lambdabot gentoo ebuild is here:
https://github.com/gentoo-haskell/gentoo-haskell/blob/57501a585edd8587d89ed64b43f6b4876316e6f7/dev-haskell/lambdabot/lambdabot-4.2.3.2.ebuild
On 2011 May 25, at 06:06, Mark Wright wrote:
Hi Jacek and Gwern,
In the upgrade from mueval from 0.8 to 0.8.1, some of the mueval
command
line options were changed:
--loadfile = --load-file
--noimports = --no-imports
For Plugins/Check.hs I change --loadfile to -l.
To convince lambdabot to run on gentoo, I patch it to use --no-
imports to
avoid this problem:
% mueval -e '1 + 2'
Ambiguous module name `Control.Monad.Cont':
it was found in multiple packages:
monads-fd-0.1.0.2 mtl-2.0.1.0 monads-tf-0.1.0.0
%
And I patch the lambdabot /usr/share/lambdabot-4.2.3.2/ghc-7.0.3/
State/L.hs
to used -XPackageImports. Then mueval works:
% mueval --no-imports -l ~/.lambdabot/State/L.hs -e '1 + 2'
3
%
And lambdabot works:
% lambdabot
Initialising
plugins ... done.
lambdabot @check True
+++ OK, passed 100 tests.
OK, passed 100 tests.
lambdabot
The patch is here:
https://github.com/markwright/gentoo-haskell/blob/master/dev-haskell/lambdabot/files/lambdabot-4.2.3.2-eval.patch
Regards, Mark
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
On Wed, May 25, 2011 at 6:22 AM, Jacek Generowicz jacek.generow...@cern.ch wrote: I had assumed that it connected to a server. It did at one point, but Hoogle had downtime and the local hoogle command was just as good and worked offline. (Maybe my assumption was not entirely unfounded, given that the installation instructions for lambdabot blithely state that you just cabal install lambdabot, nowhere suggesting that you might need to *manually* install some of its dependencies.) Well, does every lambdabot user want mueval and hoogle installed? In those specific cases because they export libraries as well, I could add a dependency on the library; but cabal doesn't support dependencies for pure executable packages. Once I have the hoogle command line version working, it seems that lambdabot truncates its output to just the first 3 lines. Is this normal? Is there a way of customizing or changing this behaviour? It's normal, yeah. Don't want to spam #haskell with 100 lines of useless matches. Configurable? Not really. -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Names for pretty-printing combinators
Hi Ivan empty is fine as is, obviously with a Monoid instance as well, people can choose to use mempty which removes potential name clashes. I was thinking of ($) and (+), though I was forgetting that (+) is actually ArrowPlus. If you are mostly gifting angles as notation to Applicative, maybe a pretty print library can live with fewer infix ops? Though you could still define fixities for the binary cases: infixr 6 `sep1` Or maybe steal the notation form Vector-Space (^+^) as cases where you would want both imported at the same time may be uncommon. Although trivial proposals often get rejected for changes to Base, I suspect a proposal for () as a synonym for `mappend` might have legs, it would certainly have a lot of support... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
On 2011 May 25, at 16:41, Gwern Branwen wrote: On Wed, May 25, 2011 at 6:22 AM, Jacek Generowicz jacek.generow...@cern.ch wrote: I had assumed that it connected to a server. It did at one point, but Hoogle had downtime and the local hoogle command was just as good and worked offline. Makes sense. (Maybe my assumption was not entirely unfounded, given that the installation instructions for lambdabot blithely state that you just cabal install lambdabot, nowhere suggesting that you might need to *manually* install some of its dependencies.) Well, does every lambdabot user want mueval and hoogle installed? Quite possibly not, but it would it be too much to ask, to have the documentation mention that they need to be installed separately if you intend to use them through lambdabot? I've already stumbled across mueval and hoogle as things that need to be installed separately before the full advertized features of lambdabot work. With this experience under my belt and the benefit of hindsight, I vaguely, almost, kinda, maybe see how I could have guessed that the stubborn response A Hoogle error occurred. to any hoogle command in lambdabot, means that I need to install hoogle locally: 'hoogle ...' -- A Hoogle error occurred. == install hoogle. But how on earth was I supposed to guess that in order to make 'check' work, the package to install was 'mueval', given that the error message was Terminated? 'check ...' -- Terminated == install mueval. Hmmm. What other lambdabot features rely on packages that need to be installed separately? Once I have the hoogle command line version working, it seems that lambdabot truncates its output to just the first 3 lines. Is this normal? Is there a way of customizing or changing this behaviour? It's normal, yeah. Don't want to spam #haskell with 100 lines of useless matches. Agreed. I guessed that this would be the motivation. Configurable? Not really. OK. Thank you. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application layout
I don't see the similarity (from reading this:
http://www.haskell.org/haskellwiki/Idiom_brackets). My suggestion is
just a way of using layout to avoid parenthesis.
/J
2011/5/25 Brandon Allbery allber...@gmail.com:
2011/5/25 Jonas Almström Duregård jonas.dureg...@chalmers.se
Would it be possible to allow this in Haskell (where applied to is some
new operator or keyword):
f applied to {x a;y b;z c}
Sounds like idiom brackets to me.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On Wed, 18 May 2011 20:01:48 -0700, wren ng thornton w...@freegeek.org wrote: 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. I agree with these disagreements. Web apps have long been touted as a replacement for desktop apps. For certain specific kinds of domains people have been able to realize them sufficiently well as web apps. But I am still of the firm belief that there are numerous domains where browser-based UIs are wholly inappropriate. There are interesting scenarios where a browser is not required. I haven't worked with Snoyman's wai-handler-webkit which may be along these lines, but there's also https://developer.mozilla.org/en/xulrunner which provides the intriguing capability of an application that has (cross-platform) native-looking local windows but which can also interact via a (local or remote) browser. Clearly there's a gap between here and there, but part of that gap is the ability to simply and easily generate internal Javascript (to drive xulrunner) without actually programming in Javascript (it's just an API layer to the display, which is what I interpreted Jurriën Stutterheim's comments to be referring to). -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
On Wed, May 25, 2011 at 11:08 AM, Jacek Generowicz jacek.generow...@cern.ch wrote: Quite possibly not, but it would it be too much to ask, to have the documentation mention that they need to be installed separately if you intend to use them through lambdabot? I've just added them to the dependencies. I've already stumbled across mueval and hoogle as things that need to be installed separately before the full advertized features of lambdabot work. With this experience under my belt and the benefit of hindsight, I vaguely, almost, kinda, maybe see how I could have guessed that the stubborn response A Hoogle error occurred. to any hoogle command in lambdabot, means that I need to install hoogle locally: 'hoogle ...' -- A Hoogle error occurred. == install hoogle. But how on earth was I supposed to guess that in order to make 'check' work, the package to install was 'mueval', given that the error message was Terminated? 'check ...' -- Terminated == install mueval. You weren't really meant to - lambdabot isn't exactly meant for anyone who won't look at the source when something goes wrong. It's only half-maintained by me; I do easy fixes but nothing else since the lambdabot codebase is large and IMO rotten. Hmmm. What other lambdabot features rely on packages that need to be installed separately? Brainfuck and unlambda are separate executables, but they already have deps. -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On Wed, 25 May 2011 05:17:46 -0700, Stephen Tetley stephen.tet...@gmail.com wrote: Hi Ivan Forks are good, no? The Parsec experience has suggested to me at least, that new author's capping another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone. As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better. At the risk of returning to a recurring theme that often comes up but never gets resolved satisfactorily, I'd like to make a cabal proposal: Add to the .cabal file the following optional field: Related-package: ACTION NAME VERSION Information - The first word is the ACTION and is one of: Replaces, Redesigns, Extends, or Alternative. - The second word is the NAME of the related package. - The third word is the VERSION of the related package. - Any additional text is information describing how the packages relate in descriptive terms and could be a multi-line paragraph like the existing Description: field. There may be multiple Related-package entries specifying different packages and actions. Conceptually, the ACTION indicates: - Replaces: This package is intended as a newer replacement to use instead of the older package. It intends to provide all the functionality of the existing package, although perhaps with API or dependency modifications and will probably evolve to provide additional functionality as well (this is probably what Ivan's new package would specify). - Redesigns: This package is intended as a replacement for the older package. It intends to provide similar functionality, but using a new approach and the API (and probably dependencies) is expected to have significant changes. An example of this would be Parsec2 and Parsec3. - Alternative: This package is a horizontal replacement for the other package providing the same type of functionality. The API or dependencies may be a bit different (e.g. mtl and transformers would be Alternatives of each other) but the overall intent of the package is the same. The Information should describe the difference between the two. - Extends: This package uses the previous package and extends it with complementary functionality. For example, attoparsec-binary extends attoparsec. I would suggest the ACTION be limited to known terms such as the above, whereas the Information is free-form for more clarification. The VERSION is important to know where the relationship was established, especially for a Replaces or Alternative type of package where the reference package continues to evolve as well. The HackageDB could the provide this information in the description page of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section This package has a Redesign: parsec3. The redesign states: ...[Information]... This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations). Thoughts? -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On Wed, May 25, 2011 at 5:01 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc. I don't think that's actually a good idea. The internals of your package will be a soggy mess, and the public APIs will be hard to follow. I'm also unclear on why you'd want to use something like wl-pprint for bytestrings at all. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On Wed, May 25, 2011 at 5:59 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Well, using the Char8 version. Just because you *could* do that, it doesn't mean that you *should*. It's a bad idea to use bytestrings for manipulating text, yet the only plausible reason to have wl-pprint handle bytestrings is so that they can be used as text. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On May 25, 2011 11:08 AM, KQ qu...@sparq.org wrote: On Wed, 25 May 2011 05:17:46 -0700, Stephen Tetley stephen.tet...@gmail.com wrote: Hi Ivan Forks are good, no? The Parsec experience has suggested to me at least, that new author's capping another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone. As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better. At the risk of returning to a recurring theme that often comes up but never gets resolved satisfactorily, I'd like to make a cabal proposal: Add to the .cabal file the following optional field: Related-package: ACTION NAME VERSION Information - The first word is the ACTION and is one of: Replaces, Redesigns, Extends, or Alternative. - The second word is the NAME of the related package. - The third word is the VERSION of the related package. - Any additional text is information describing how the packages relate in descriptive terms and could be a multi-line paragraph like the existing Description: field. There may be multiple Related-package entries specifying different packages and actions. Conceptually, the ACTION indicates: - Replaces: This package is intended as a newer replacement to use instead of the older package. It intends to provide all the functionality of the existing package, although perhaps with API or dependency modifications and will probably evolve to provide additional functionality as well (this is probably what Ivan's new package would specify). - Redesigns: This package is intended as a replacement for the older package. It intends to provide similar functionality, but using a new approach and the API (and probably dependencies) is expected to have significant changes. An example of this would be Parsec2 and Parsec3. - Alternative: This package is a horizontal replacement for the other package providing the same type of functionality. The API or dependencies may be a bit different (e.g. mtl and transformers would be Alternatives of each other) but the overall intent of the package is the same. The Information should describe the difference between the two. - Extends: This package uses the previous package and extends it with complementary functionality. For example, attoparsec-binary extends attoparsec. I would suggest the ACTION be limited to known terms such as the above, whereas the Information is free-form for more clarification. The VERSION is important to know where the relationship was established, especially for a Replaces or Alternative type of package where the reference package continues to evolve as well. The HackageDB could the provide this information in the description page of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section This package has a Redesign: parsec3. The redesign states: ...[Information]... This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations). Thoughts? The only thing I'd add would be the additional actions ReplacedBy, ExtendedBy and RedesignedBy. Antoine -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
Quoting Antoine Latter aslat...@gmail.com: On May 25, 2011 11:08 AM, KQ qu...@sparq.org wrote: The HackageDB could the provide this information in the description page of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section This package has a Redesign: parsec3. The redesign states: ...[Information]... This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations). Thoughts? The only thing I'd add would be the additional actions ReplacedBy, ExtendedBy and RedesignedBy. Antoine I was actually thinking that this was the part that HackageDB could do automatically on the page that the actionBy applied to. There should be enough information in the DB (somewhat like Roel's reverse dependencies work) and the alternative would be having to re-release a package (that you don't necessarily own) to add the actionBy field. -KQ - This mail sent through IMP: http://horde.org/imp/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
I wanted the second set because I may want to establish the link even if I'm not the maintainer of the second package. I would imagine that the second set of actions would be otherwise identical, and the link would show up on either package regardless of which set of verbs was used. Antoine On May 25, 2011 12:50 PM, qu...@sparq.org wrote: Quoting Antoine Latter aslat...@gmail.com: On May 25, 2011 11:08 AM, KQ qu...@sparq.org wrote: The HackageDB could the provide this information in the description page of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section This package has a Redesign: parsec3. The redesign states: ...[Information]... This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations). Thoughts? The only thing I'd add would be the additional actions ReplacedBy, ExtendedBy and RedesignedBy. Antoine I was actually thinking that this was the part that HackageDB could do automatically on the page that the actionBy applied to. There should be enough information in the DB (somewhat like Roel's reverse dependencies work) and the alternative would be having to re-release a package (that you don't necessarily own) to add the actionBy field. -KQ - This mail sent through IMP: http://horde.org/imp/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] uniplate and haskell-src-exts (was: Re: code review?)
+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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] code review?
Hi Niklas, I use Uniplate inside HLint, and it's invaluable - there are a lot of times when List Comp + universeBi really hits the spot. +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? :-) I'm happy to have it included. The only likely change is that I currently have basically two versions of all modules (Data.Generics.PlateData and Data.Generics.Uniplate.Data). I'll upload a version 1.7 of Uniplate marking those deprecated, then a 1.8 removing them, and then I'd love to get included in the Platform. Of course, whether it goes in the platform is not really up to me, it's up to the community - but if someone proposes it I'll back it. Thanks, Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Thanks, John. Encouraging bit of news. Please do let us know what you learn when you try. - Conal On Tue, May 24, 2011 at 1:28 AM, John Lato jwl...@gmail.com wrote: You can use gtkglext to get OpenGL support. With the official release of gtkglext-1.2.0 there's a bit of hacking involved (that was probably me you're referring to), but it looks like the repo head has native Quartz. With any luck, you just need to build gtkglext from the repo, then the gtkglext package. I might have some time to try this later today; I'll report back if I get results. John Lato On Tue, May 24, 2011 at 6:01 AM, Conal Elliott co...@conal.net wrote: Last I tried, there wasn't native support for OpenGL with gtk, and I need OpenGL. Then more recently, I heard of some progress in that area, but requiring lots of hacking to get it all compiling. Any recent news? - Conal On Mon, May 23, 2011 at 2:33 AM, John Lato jwl...@gmail.com wrote: Message: 17 Date: Fri, 20 May 2011 15:59:51 -0700 From: Evan Laforge qdun...@gmail.com Subject: Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics To: Erik Hesselink hessel...@gmail.com Cc: haskell-cafe@haskell.org Message-ID: BANLkTi=74mm6ortu2e192jtoot9g49f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. I used to use this combination regularly. IME the difficulties are primarily with getting a working gtk+osx build. Once that was accomplished, gtk2hs was a straightforward install, provided you build from the src repo with the -quartz flag. Recently I've switched to using macports gtk2 with the quartz, no-x11 variant, which also uses native cocoa. This is much more reliable than gtk+osx. I don't know if it supports Glade though. My biggest problem with wx is that there's no support for building 64-bit wx applications on OS X. If that were fixed I might prefer it. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
Hi Jacek, Which works swimmingly on Ubuntu, but fails on OS X, because wget seems to be hard-wired. I seem to recall that at least one of the packages that I installed over the last 2 days, automatically selected wget on Ubuntu, and curl on OS X. I see someone raised a bug for this: http://code.google.com/p/ndmitchell/issues/detail?id=434 - it's a very reasonable idea, which I'll include in the next version. Then if you have either wget or curl it will work. Any pointers to the least painful way of getting 'hoogle data' to work on OS X? Set up a shell alias so wget just calls curl? Install wget on OS X? If neither of these is feasible let me know and I'll rush out a new version of Hoogle. Thanks, Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Names for pretty-printing combinators
One drastic approach I've used in personal libraries--operator-heavy EDSLs specifically--is to define everything first with alphanumeric names, then put operators in their own modules. In some cases I'd have three such modules: One providing a minimal set of operators that don't clash with anything significant, one providing a larger set of operators that clash with one or more common modules (often deliberately, e.g. duplicating Arrow combinators for some type with similar semantics but no valid Arrow instance), and one providing a bunch of gratuitous Unicode operators that look pretty in my code editor but I don't know how to type in GHCi. I'm not sure if I've seen that approach anywhere else, however, so it might not be something most people would care for. - C. On Wed, May 25, 2011 at 10:45 AM, Stephen Tetley stephen.tet...@gmail.comwrote: Hi Ivan empty is fine as is, obviously with a Monoid instance as well, people can choose to use mempty which removes potential name clashes. I was thinking of ($) and (+), though I was forgetting that (+) is actually ArrowPlus. If you are mostly gifting angles as notation to Applicative, maybe a pretty print library can live with fewer infix ops? Though you could still define fixities for the binary cases: infixr 6 `sep1` Or maybe steal the notation form Vector-Space (^+^) as cases where you would want both imported at the same time may be uncommon. Although trivial proposals often get rejected for changes to Base, I suspect a proposal for () as a synonym for `mappend` might have legs, it would certainly have a lot of support... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
On 2011 May 25, at 21:04, Neil Mitchell wrote: Hi Jacek, Hi Neil, Any pointers to the least painful way of getting 'hoogle data' to work on OS X? Set up a shell alias so wget just calls curl? Their interfaces are different. (Though maybe there's some option which makes curl sufficiently similar to wget, but I haven't bothered to look because ...) Install wget on OS X? Yes. Download, untar, configure, make, sudo make install ... did the trick in about two minutes. (Kinda obvious really, wasn't it! I plead mitigating circumstances because my brain has been beaten to a pulp by all the stumbling through installations I have been doing over the last 3 days.) Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
On 2011 May 25, at 17:42, Gwern Branwen wrote: On Wed, May 25, 2011 at 11:08 AM, Jacek Generowicz jacek.generow...@cern.ch wrote: I've already stumbled across mueval and hoogle as things that need to be installed separately before the full advertized features of lambdabot work. With this experience under my belt and the benefit of hindsight, I vaguely, almost, kinda, maybe see how I could have guessed that the stubborn response A Hoogle error occurred. to any hoogle command in lambdabot, means that I need to install hoogle locally: 'hoogle ...' -- A Hoogle error occurred. == install hoogle. But how on earth was I supposed to guess that in order to make 'check' work, the package to install was 'mueval', given that the error message was Terminated? 'check ...' -- Terminated == install mueval. You weren't really meant to - lambdabot isn't exactly meant for anyone who won't look at the source when something goes wrong. Understood. Fair enough. I feel a bit guilty about spamming the list with all my stupid problems: I would prefer to find my own way around, but if I had to dive in and rummage around the source for every problem that I encounter, I would not get very far. What other lambdabot features rely on packages that need to be installed separately? Brainfuck and unlambda are separate executables, but they already have deps. I must admit that hoogle and check were far stronger incentives to try to intstall lambdabot, than brainfuck and unlambda :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application layout
2011/5/25 Jonas Almström Duregård jonas.dureg...@chalmers.se I don't see the similarity (from reading this: http://www.haskell.org/haskellwiki/Idiom_brackets). My suggestion is just a way of using layout to avoid parenthesis. This is exactly the applicative style, where idiom brackets come from. Use Control.Applicative: f $ x a * y b * z c You can use the identity functor to recover plain old function application. Idiom brackets abstract the $ (fmap) and (*) operators away. And yes, you are right that applicative style is very useful. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
fltk supports OpenGL on windows, X11, and OS X, though I've never used it. The thing it doesn't have is a haskell binding, but as I mentioned I just bind whatever I need when I need it and since I don't need much it's easy. Dunno if this applies in your case though. Maybe it's my NIH, but I like to start with something too simple and add what I need rather than start with something that has more than I need and try to get it working. On Wed, May 25, 2011 at 11:58 AM, Conal Elliott co...@conal.net wrote: Thanks, John. Encouraging bit of news. Please do let us know what you learn when you try. - Conal On Tue, May 24, 2011 at 1:28 AM, John Lato jwl...@gmail.com wrote: You can use gtkglext to get OpenGL support. With the official release of gtkglext-1.2.0 there's a bit of hacking involved (that was probably me you're referring to), but it looks like the repo head has native Quartz. With any luck, you just need to build gtkglext from the repo, then the gtkglext package. I might have some time to try this later today; I'll report back if I get results. John Lato On Tue, May 24, 2011 at 6:01 AM, Conal Elliott co...@conal.net wrote: Last I tried, there wasn't native support for OpenGL with gtk, and I need OpenGL. Then more recently, I heard of some progress in that area, but requiring lots of hacking to get it all compiling. Any recent news? - Conal On Mon, May 23, 2011 at 2:33 AM, John Lato jwl...@gmail.com wrote: Message: 17 Date: Fri, 20 May 2011 15:59:51 -0700 From: Evan Laforge qdun...@gmail.com Subject: Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics To: Erik Hesselink hessel...@gmail.com Cc: haskell-cafe@haskell.org Message-ID: BANLkTi=74mm6ortu2e192jtoot9g49f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. I used to use this combination regularly. IME the difficulties are primarily with getting a working gtk+osx build. Once that was accomplished, gtk2hs was a straightforward install, provided you build from the src repo with the -quartz flag. Recently I've switched to using macports gtk2 with the quartz, no-x11 variant, which also uses native cocoa. This is much more reliable than gtk+osx. I don't know if it supports Glade though. My biggest problem with wx is that there's no support for building 64-bit wx applications on OS X. If that were fixed I might prefer it. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Calling a C function that returns a struct by value
From Haskell, I want to call a C function that returns a struct by
value (rather than, say, returning a pointer). For example:
typedef struct { double x; double y; } point_t;
point_t polar(double theta);
I can create a Haskell type Point and make it an instance of Storable
easily enough:
data Point = Point CDouble CDouble
instance Storable Point where -- insert obvious code here
And now I want to do something like this:
foreign import ccall unsafe polar :: CDouble - IO Point
...but that doesn't appear to be legal (at least in GHC 6.12). Is
there any way to import this C function into Haskell _without_ having
any additional wrapper C code? I mean, I suppose I could write
something like:
// C:
void polar_wrapper(double theta, point_t* output) {
*output = polar(theta);
}
-- Haskell:
foreign import ccall unsafe polar_wrapper :: CDouble - Ptr Point -
IO ()
polar :: CDouble - IO Point
polar theta = do -- insert obvious code here
...but that's a lot of extra boilerplate if I have many such functions
to wrap, and it seems like GHC should be able to do that sort of thing
for me. P-:
Cheers,
-Matt
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Calling a C function that returns a struct by value
On 2011-05-25 16:19 -0400, Matthew Steele wrote:
From Haskell, I want to call a C function that returns a struct by
value (rather than, say, returning a pointer). For example:
typedef struct { double x; double y; } point_t;
point_t polar(double theta);
I can create a Haskell type Point and make it an instance of Storable
easily enough:
data Point = Point CDouble CDouble
instance Storable Point where -- insert obvious code here
Note that there may be an arbitrary amount of padding bytes between the
two members of your struct, as well as after the last member, so
defining this Storable instance portably is somewhat tricky and
non-obvious.
And now I want to do something like this:
foreign import ccall unsafe polar :: CDouble - IO Point
...but that doesn't appear to be legal (at least in GHC 6.12). Is
there any way to import this C function into Haskell _without_ having
any additional wrapper C code?
No, the Haskell FFI simply cannot describe C functions with struct
parameters or return values. You will need to call this function with a
C wrapper.
Assuming you got the Storable instance correct, something like
void wrap_polar(double theta, point_t *out)
{
*out = polar(theta);
}
should do nicely. Alternately, you can avoid the tricky business of
defining a Storable instance for your struct entirely with something
like:
void wrap_polar(double theta, double *x, double *y)
{
point_t tmp = polar(theta);
*x = tmp.x;
*y = tmp.y;
}
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
From: Jacek Generowicz Sent: May 25, 2011 2:45 PM On 2011 May 25, at 17:42, Gwern Branwen wrote: On Wed, May 25, 2011 at 11:08 AM, Jacek Generowicz jacek.generow...@cern.ch wrote: I've already stumbled across mueval and hoogle as things that need to be installed separately before the full advertized features of lambdabot work. With this experience under my belt and the benefit of hindsight, I vaguely, almost, kinda, maybe see how I could have guessed that the stubborn response A Hoogle error occurred. to any hoogle command in lambdabot, means that I need to install hoogle locally: 'hoogle ...' -- A Hoogle error occurred. == install hoogle. But how on earth was I supposed to guess that in order to make 'check' work, the package to install was 'mueval', given that the error message was Terminated? 'check ...' -- Terminated == install mueval. You weren't really meant to - lambdabot isn't exactly meant for anyone who won't look at the source when something goes wrong. Understood. Fair enough. I feel a bit guilty about spamming the list with all my stupid problems: I would prefer to find my own way around, but if I had to dive in and rummage around the source for every problem that I encounter, I would not get very far. I'm not particularly interested in lambdabot myself, but this seems like a reasonable conversation for this list, and the sort of thing that's nice to have recorded in the mailing list archives - and hopefully folded back into appropriate package descriptions and wiki pages. I wonder a few quick greps for error messages in the source code might have turned up something useful without too much trouble, but from skimming messages it seems your efforts have been at least as much as can reasonably be expected for installing a cabal package without big giant disclaimers. Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot check
On 2011 May 25, at 16:09, Mark Wright wrote: Hi Jacek, Hi Mark, Thanks once again for your excellent answer. The show module names were changed in the upgrade from show 0.3.4 to show 0.4.1.1. OK, I see that in show.cabal, ShowIO disappears from the exposed- modules section. This is confirmed by the fact that Show.hs has disappeared from the source. The contents of the latter were just a single instance declaration which now appears in ShowFun.hs. From all this I infer that lambdabot uses show, and in the process wants to import ShowIO: Such imports are indeed found in State/L.hs and State/Pristine.hs. Given that everything that used to live in ShowIO has been swallowed by ShowFun, we could just import ShowFun at those to place instead. On gentoo I conditionally sed lambdabot to account for this, then print out a note that the user may need to copy the State/* files, in particular L.hs and Pristine.hs for this problem, With you so far .. to ~/.lambdabot/State. Huh? is ~/.packagename/ some sort of cabal convention? Or are you using it as a shorthand for ~/.cabal/packages/yaddayadda/packagename ? Or is it some way in which you *could* organize your Cabal packages which happens to be different from what I have on my systems (by default)? Ah, it is nothing to do with cabal, it's just lambdabot's personal data! (Which needs to have State/L.hs in it. It seems to work without Pristine.hs. Fine, at this stage I'm just prepared to accept this directory as magic). I seem to have a working lambabot check. (i.e. 'lambdabot check True' claims to pass 100 tests.) Thank you. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
On 2011 May 25, at 23:20, Brandon Moore wrote: From: Jacek Generowicz Sent: May 25, 2011 2:45 PM I feel a bit guilty about spamming the list with all my stupid problems: I would prefer to find my own way around, but if I had to dive in and rummage around the source for every problem that I encounter, I would not get very far. I'm not particularly interested in lambdabot myself, but this seems like a reasonable conversation for this list, and the sort of thing that's nice to have recorded in the mailing list archives - and hopefully folded back into appropriate package descriptions and wiki pages. I'm hoping to find some time at the end of this journey to gather together what I have learned on the way, and to try to feed some of the information back into relevant places. (Any pointers on how to do this most productively would be welcome.) But my fear is that by the time I am done, I will have used up all my Haskell time for this quarter. I wonder a few quick greps for error messages in the source code might have turned up something useful without too much trouble, I wonder myself too. From my point of complete ignorance about how the packages are put together, and almost complete ignorance about cabal, it's difficult to judge when (and for how long) it's worth digging in with grep etc.: sometimes it will be a fruitful exercise, and sometimes not. Sometimes someone else will understand my problem faster than I can type grep, and sometimes not. So my tactic is to dig a little, then send out a cry for help, before digging further. but from skimming messages it seems your efforts have been at least as much as can reasonably be expected for installing a cabal package without big giant disclaimers. Thank you for your kind words. I hope that most others find my spam as inoffensive as you do. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 5/25/11 1:56 PM, Antoine Latter wrote: On May 25, 2011 12:50 PM,qu...@sparq.org wrote: Quoting Antoine Latteraslat...@gmail.com: The only thing I'd add would be the additional actions ReplacedBy, ExtendedBy and RedesignedBy. I was actually thinking that this was the part that HackageDB could do automatically on the page that the actionBy applied to. There should be enough information in the DB (somewhat like Roel's reverse dependencies work) and the alternative would be having to re-release a package (that you don't necessarily own) to add the actionBy field. I wanted the second set because I may want to establish the link even if I'm not the maintainer of the second package. I would imagine that the second set of actions would be otherwise identical, and the link would show up on either package regardless of which set of verbs was used. Exactly. Sometimes the new package designer may be unaware of the prior art, or may be too timid to declare obviating another's work. Also, allowing for both sides to declare the link can help to serve as verification of the relationship. If someone uploads the 'awesome' package which declares itself to replace everything on Hackage, should we just accept it at face value? Moreover, a feature like this new field would be useful for pruning the list of packages shown on the index, but do we want to allow the maintainer of package A to simply fiat that package B shouldn't be shown on the index anymore? We have a nice community, but security and validation are still good things to plan into the design. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 5/25/11 1:03 PM, Bryan O'Sullivan wrote: On Wed, May 25, 2011 at 5:59 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Well, using the Char8 version. Just because you *could* do that, it doesn't mean that you *should*. It's a bad idea to use bytestrings for manipulating text, yet the only plausible reason to have wl-pprint handle bytestrings is so that they can be used as text. It's worth highlighting that even with the Char8 version of ByteStrings you still run into encoding issues. Remember the days before Unicode came about? True, 8-bit encodings are often ASCII-compatible and therefore the representation of digits and whitespace are consistent regardless of (ASCII-compatible) encoding, but that's still just begging for issues. What are the semantics of the byte 0xA0 with respect to pretty-printing issues like linewraps? Are they consistent among all extant 8-bit encodings? What about bytes in 0x80..0x9F? What about 0x7F for that matter? I won't say that ByteStrings should never be used for text (there are plenty of programs whose use of text involves only whitespace splitting and moving around the resultant opaque blobs of memory). But at a bare minimum, the use of ByteStrings for encoding text needs to be done via newtype wrapper(s) which keep track of the encoding. Especially for typeclass instances. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 26 May 2011 08:49, wren ng thornton w...@freegeek.org wrote: On 5/25/11 1:03 PM, Bryan O'Sullivan wrote: On Wed, May 25, 2011 at 5:59 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Well, using the Char8 version. Just because you *could* do that, it doesn't mean that you *should*. It's a bad idea to use bytestrings for manipulating text, yet the only plausible reason to have wl-pprint handle bytestrings is so that they can be used as text. It's worth highlighting that even with the Char8 version of ByteStrings you still run into encoding issues. Remember the days before Unicode came about? True, 8-bit encodings are often ASCII-compatible and therefore the representation of digits and whitespace are consistent regardless of (ASCII-compatible) encoding, but that's still just begging for issues. What are the semantics of the byte 0xA0 with respect to pretty-printing issues like linewraps? Are they consistent among all extant 8-bit encodings? What about bytes in 0x80..0x9F? What about 0x7F for that matter? I won't say that ByteStrings should never be used for text (there are plenty of programs whose use of text involves only whitespace splitting and moving around the resultant opaque blobs of memory). But at a bare minimum, the use of ByteStrings for encoding text needs to be done via newtype wrapper(s) which keep track of the encoding. Especially for typeclass instances. *shrug* this discussion on #haskell came about because lispy wanted to generate textual ByteStrings (using just ASCII) and would prefer not to have the overhead of Text. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambdabot hoogle
On 5/25/11 5:20 PM, Brandon Moore wrote: From: Jacek Generowicz Sent: May 25, 2011 2:45 PM On 2011 May 25, at 17:42, Gwern Branwen wrote: I feel a bit guilty about spamming the list with all my stupid problems: I would prefer to find my own way around, but if I had to dive in and rummage around the source for every problem that I encounter, I would not get very far. I'm not particularly interested in lambdabot myself, but this seems like a reasonable conversation for this list, and the sort of thing that's nice to have recorded in the mailing list archives - and hopefully folded back into appropriate package descriptions and wiki pages. I've been curious to try installing lambdabot before, but could never get it working due to stuff like this. So it's nice to see the questions and solutions all laid out :) -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application layout
Hi Alexander, This is exactly the applicative style, where idiom brackets come from. I disagree. Layout has at least two advantages over applicative here: 1) Applicative costs (at least) three additional characters per function parameter. 2) You can not have arbitrary infix operators in the parameters when using applicative. Also your example is not really equivalent to f (x a) (y b) (z c) is it? Idiom brackets abstract the $ (fmap) and (*) operators away. But from what I can tell it also reintroduces the parenthesis? How would you write f (x a) (y b) in idiom brackets? /J On 25 May 2011 22:06, Alexander Solla alex.so...@gmail.com wrote: 2011/5/25 Jonas Almström Duregård jonas.dureg...@chalmers.se I don't see the similarity (from reading this: http://www.haskell.org/haskellwiki/Idiom_brackets). My suggestion is just a way of using layout to avoid parenthesis. This is exactly the applicative style, where idiom brackets come from. Use Control.Applicative: f $ x a * y b * z c You can use the identity functor to recover plain old function application. Idiom brackets abstract the $ (fmap) and (*) operators away. And yes, you are right that applicative style is very useful. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function application layout
2011/5/25 Jonas Almström Duregård jonas.dureg...@chalmers.se
Hi Alexander,
This is exactly the applicative style, where idiom brackets come from.
I disagree. Layout has at least two advantages over applicative here:
1) Applicative costs (at least) three additional characters per function
parameter.
I don't think so. Presumably, you would replace them with spaces, if you
were indenting to tabular form.
2) You can not have arbitrary infix operators in the parameters when using
applicative.
True.
Also your example is not really equivalent to f (x a) (y b) (z c) is it?
It is up to isomorphism, if you use the identity functor:
newtype Id a = Id { unId :: a }
tryItOut :: Id Int
tryItOut = (+) $ 1 * 2
Idiom brackets abstract the $ (fmap) and (*) operators away.
But from what I can tell it also reintroduces the parenthesis? How would
you write f (x a) (y b) in idiom brackets?
I prefer the applicative style, so I would use that.
/J
On 25 May 2011 22:06, Alexander Solla alex.so...@gmail.com wrote:
2011/5/25 Jonas Almström Duregård jonas.dureg...@chalmers.se
I don't see the similarity (from reading this:
http://www.haskell.org/haskellwiki/Idiom_brackets). My suggestion is
just a way of using layout to avoid parenthesis.
This is exactly the applicative style, where idiom brackets come from.
Use Control.Applicative:
f $ x a
* y b
* z c
You can use the identity functor to recover plain old function
application. Idiom brackets abstract the $ (fmap) and (*) operators
away.
And yes, you are right that applicative style is very useful.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANN] Released HSnippets, Emacs YASnippets for Haskell
Just released HSnippets, Emacs YASnippet snippets for Haskell https://github.com/polypus74/HSnippets cheers, _c ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 183
Welcome to issue 180 of the HWN, a newsletter covering developments in the Haskell community. This release covers the week of May 15 to 21, 2011. Announcements Janis Veigtlander announced that the 20th edition of the Haskell Communities and Activities reports is hot off the press! http://goo.gl/GRi7V Simon Marlow announced that he has put together a tutorial on Parallel and Concurrent programming in Haskell. http://goo.gl/LPst8 Quotes of the Week * Sergey Mironov:I looked further and found that 'Oleg already did it'. * monochrom: just say yes Top Reddit Stories * Wolfgang - A Wolfram Alpha clone in Haskell (under heavy load?) Domain: jabberwock.xs4all.nl, Score: 75, Comments: 10 On Reddit: http://goo.gl/okNC7 Original: http://goo.gl/7pSXA * Numeric Haskell: a tutorial about the multi-dimensional, parallel arrays package, Repa Domain: haskell.org, Score: 54, Comments: 7 On Reddit: http://goo.gl/ZRSn3 Original: http://goo.gl/InWB9 * Space leak zoo: a catalog of common space leaks in Haskell programs Domain: blog.ezyang.com, Score: 41, Comments: 7 On Reddit: http://goo.gl/npVLv Original: http://goo.gl/aMbo5 * Exercises in Optimization: A (soon to be) three-part series detailing an adventure in optimizing Haskell code. Domain: csks.wordpress.com, Score: 34, Comments: 0 On Reddit: http://goo.gl/cjWBX Original: http://goo.gl/wPqbl * Tutorial: Parallel and Concurrent Programming in Haskell :: PDF Domain: community.haskell.org, Score: 33, Comments: 7 On Reddit: http://goo.gl/CB1wt Original: http://goo.gl/yzTOU * Anatomy of a thunk leak: How to debug Haskell’s most famous space leak Domain: blog.ezyang.com, Score: 32, Comments: 3 On Reddit: http://goo.gl/f18jX Original: http://goo.gl/PiQ98 * Preview release of diagrams EDSL for declarative drawing Domain: haskell.org, Score: 31, Comments: 9 On Reddit: http://goo.gl/6sykO Original: http://goo.gl/uhbV1 * I/O is not a monad Domain: r6.ca, Score: 31, Comments: 23 On Reddit: http://goo.gl/zAra5 Original: http://goo.gl/mn49r * Eliza in 70 lines of Haskell Domain: github.com, Score: 28, Comments: 7 On Reddit: http://goo.gl/hjgNf Original: http://goo.gl/S7t9m * The Whole Program Fallacy Domain: lukepalmer.wordpress.com, Score: 26, Comments: 10 On Reddit: http://goo.gl/Efja3 Original: http://goo.gl/vzXVK Top StackOverflow Questions * What Haskell representation is recommended for 2D, unboxed pixel arrays with millions of pixels? votes: 48, answers: 3 Read on SO: http://goo.gl/gVpwB * Good introductory text about GHC implementation? votes: 24, answers: 2 Read on SO: http://goo.gl/6MZoh * Questions on a Haskell - C# conversion votes: 13, answers: 3 Read on SO: http://goo.gl/0t3Gu * Can't perform I/O in foldr? votes: 12, answers: 4 Read on SO: http://goo.gl/d9Jg0 * What does this function will fuse mean? votes: 11, answers: 3 Read on SO: http://goo.gl/tMdlR * Haskell function type question votes: 10, answers: 3 Read on SO: http://goo.gl/gyTns * Is this always true: fmap (foldr f z) . sequenceA = foldr (liftA2 f) (pure z) votes: 10, answers: 1 Read on SO: http://goo.gl/emKmg * Difference between hsc2hs and c2hs? votes: 8, answers: 2 Read on SO: http://goo.gl/1wnhC * Is it possible to create PHP extensions in Haskell? votes: 8, answers: 2 Read on SO: http://goo.gl/QwkpK * How can configuration tools like sdl-config be used with a cabalized project? votes: 8, answers: 2 Read on SO: http://goo.gl/vHCOu About the Haskell Weekly News To help create new editions of this newsletter, please send stories to dstc...@gmail.com. Until next time, Daniel Santa Cruz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
