[Haskell-cafe] Pure extremism (was: Re: Why?)
On Fri, Dec 11, 2009 at 7:07 PM, Jason Dusek jason.du...@gmail.com wrote: 2009/12/11 Luke Palmer lrpal...@gmail.com: The idea being that any code that is pure could be evaluated anywhere with a very simple interpreter. If you have pure code, you can trace it back and evaluate it in a sandbox where you don't need a C runtime, a linker, or really anything but the simplest substitution engine. *All* effects bubble their way up to the top level, so that we know from the type signature of a value the machinery we will need to run it. This sounds good but there is something puzzling about it. Where do we draw the line between machinery and packages? The types don't tell us what libraries we need. I don't follow this. Do you mean external libraries, such as the library used to execute an IO type? That makes sense to me, though in that case the types do tell. Or you might mean what *haskell* libraries does a piece of code depend on? To address that, note that I consider a statement like: import Control.Monad.State As a form of impurity in a sense (it is hard to say what I consider it, actually, but I think it inhibits reasoning and verification). What version are you importing? From where are you importing it ; where is it defined? These things depend on the compiler environment, which means that the meaning of a piece of code depends on who is compiling it. I have brainstormed solutions to this problem while thinking about my (currently on hold or dead) Udon project: http://lukepalmer.wordpress.com/2008/11/19/udon-sketch-2/ . But it is just a brainstorm, nothing I would sign in blood. I'd love it if more people were thinking about these kinds of problems (Any papers you well-read folks know about?) They don't tell us how much RAM/CPU we need, either. And these! My ideas for these are now firmly beyond Haskell and way out in the ill-defined vaporware space. I discuss in abstract the idea of distinguishing the performance semantics from the denotation of a piece of code here: http://lukepalmer.wordpress.com/2009/06/12/the-role-of-a-core-calculus/ . Brainstorm disclaimer applies, and I want to see more research! (Papers?) Pure functional code as the minimal essence of pure computation -- everything else an EDSL. Partial or total code? When the state of the art catches up, total for sure. Why reason with DCPOs when you can reason with the mathematical objects themselves? But when you require functions to be total, you end up needing to prove a lot more about them just to convince the compiler that they will terminate. Functional proof assistants are a wonderful area of research, but are still very early and it is frickin' hard to prove stuff about code. My belief is that time is all that is necessary here -- the research will continue and it will become easier and easier to prove properties about code (probably never completely automatic, but someday I hope to handwave the essence of a proof and have the computer fill in the bullshit details). But when it's easy enough, then partiality is definitely an effect to be modeled as well. It has the advantage, unlike most effects, that given a good model, you can prove your way out of it. I.e. write a function with a partiality effect, then elsewhere prove that it actually is total so you can drop the effect. I seem to recall a proof-of-concept of this idea for Coq. There are many levels to purity, and I think as research progresses we will gradually be able to go to the stricter levels while remaining productive. It gives me comfort to see a long road ahead -- I don't like to see perfect languages, because that's just me seeing my own ignorance :-) Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hledger 0.7 released
I'm pleased to announce hledger 0.7. Thanks to Marko Kocić who contributed many fixes for hlint warnings. To install/upgrade: cabal update cabal install hledger [-fweb] [- fvty] Documentation: http://hledger.org Release notes: * price history support (first cut): P directives now work, though differently from c++ ledger. Each posting amount takes its fixed unit price from the price history (or @) when available. This is simple and useful for things like foreign currency expenses (but not investment tracking). Like ledger, balance and register don't show amount prices any more, and don't separate differently-priced amounts. Unlike ledger, print shows all amount prices, and supports -B. * --effective option, will use transactions' effective dates if any * convert: new rules file format, find/create rules file automatically, more robust parsing, more useful --debug output * print: always sort by date, fix long account name truncation, align amounts, show end of line comments, show all amounts for clarity (don't elide the final balancing amount) * ui: use vty 4, fixes non-ascii and gnome terminal problems (issues #3, #4) * web: allow data entry, react to data file changes, better layout, help links, remove histogram command and filter fields for now, fix bad localhost redirect, filter form did not work in eg firefox (issue #7), reset link did not work in all browsers * parsing: require whitespace between date and status code, allow (and ignore) a time in price records, better error messages, non-zero exit code on parse failure * display non-ascii error messages properly (issue #5) * fix an arithmetic bug that occasionally rejected valid transactions * fix a regex bug in showtree * don't break if HOME is undefined * --debug now implies --verbose * add functional tests like ledger's, use test-framework for speedy running, release shelltestrunner as a separate package * many hlint cleanups (Marko Kocić) * many site and documentation updates Stats: 2 contributors, 175 days since release, 182 commits, 3320 non-test code lines, 97 tests, 53% test coverage, performance: similar (http://hledger.org/profs/200912111852.bench) Best, -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: [BostonHaskell] Next meeting: December 17th at MIT (32-G882)
Hello Ravi, Saturday, December 12, 2009, 9:48:28 AM, you wrote: Based on the responses to my previous message, our featured presenter will be Ryan Newton who will talk about the Intel Concurrent Collections for Haskell. awesome! you may try it on many typical unix text processing tasks, such as word frequencies counting, or building statistics from logfiles -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
2009/12/12 Tom Tobin korp...@korpios.com: 1) Can the author of Y legally distribute the *source* of Y under a non-GPL license, such as the 3-clause BSD license or the MIT license? Hello Tom If the answer to this isn't yes, I'll buy a hat and eat it... As source, Y (the BSD3 library) can surely be distributed as the author sees fit. The author could even distribute Y as source under a non-GPL _compatible_ license. This would hamper the utility Y, neither the author of Y nor anyone else could distribute an executable that agglomerates X and Y, but I honestly can't see how the existence of library X (GPL) can make it illegal to distribute other distinct works (my emphasis on _distinct_). Now, author X could choose to sue author Y for copyright infringement. If such a case happened it might set the precedent for what a 'derived work' is - vis-a-vis GPL and libraries - from my cursory web searching, such a case hasn't happened. From the 'Linking and derived works' bit in the Wikipedia page, the judgement on copyright law notes the infringing work must incorporate a portion of the copyrighted work in some form, surely the judges would have to decide whether or not calling API's and reusing datatypes is incorporation. http://en.wikipedia.org/wiki/GNU_General_Public_License 3) If the answer to 1 is yes, what specifically would trigger the redistribution of a work in this scenario under the GPL? Is it the distribution of X+Y *together* (whether in source or binary form)? Don't know. In the case of Hakyll and other packages on Hackage, the distribution is in source form. If someone wanted to repackage the code from Hackage as a binary distro they would have different obligations. 4) If the answer to 1 is yes, does this mean that a BSD-licensed library does not necessarily mean that closed-source software can be distributed which is based upon such a library (if it so happens that the library in turn depends on a copylefted library)? The 'closed-source' software here still depends on a 'copyleft' library - if the library is GPL then the terms of the GPL apply. Whether there is an intermediary BSD licensed library is surely immaterial. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parallel foldl doesn't work correctly
Hello,
This compiles and if I monitor my CPUs it starts to use both cores, but
after approx 10 seconds, one core drops to low rate (I'm using a 2 core
machine).
Just a shot in the dark: what OS are you using? I have had some
problems with GHC 6.10.4 and Ubuntu Karmic Koala{1[, which are fixed
for me in GHC 6.12 RC1.
- Michael
[1]
http://www.mlesniak.com/2009/12/01/ghc-6-12-rc1-and-ubuntu-9-10-karmic-koala/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Parallel foldl doesn't work correctly
On Sat, 2009-12-12 at 02:57 +, Philip Beadling wrote: Hi, Can anyone put me right here. I am trying to use a setup similar to parMap to spark each valuation in a list in parallel, where the resulting (evaluated) list is folded to produce a final single result. Having done the obligatory google, I modified a few common examples to give: pfoldl f acc xs = foldl' f acc (xs `using` parList rwhnf) This compiles and if I monitor my CPUs it starts to use both cores, but after approx 10 seconds, one core drops to low rate (I'm using a 2 core machine). The end result is that -N2 is actually a bit slower than -N1! I'm guessing I haven't grasped the concept properly - although as map is just 'foldl (+) 0' I'm at a loss to see why this approach wouldn't work given it is pretty similar to parMap - could anyone point out what I'm missing? If it's any use the context of the code is below. Many thanks! Phil. At least IMHO foldl cannot be pararalized since it have rather strong dependencies i.e. only calculation of acc and first value of list. If operation is associative it can be done using divide et impera spliting list in half and operating on it pararerlly then split in half etc. 8 stages (the same number (O n) as normally + cost of synchronization etc). 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 3 operations (to be more specific O (log n)): 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 Regards PS. I don't know nor understend the pararell library. Maybe I don't understend something but without associativity IMHO data is too interdependent IMHO to do something. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
2009/12/12 Stephen Tetley stephen.tet...@gmail.com: 2009/12/12 Tom Tobin korp...@korpios.com: 1) Can the author of Y legally distribute the *source* of Y under a non-GPL license, such as the 3-clause BSD license or the MIT license? Hello Tom If the answer to this isn't yes, I'll buy a hat and eat it... As source, Y (the BSD3 library) can surely be distributed as the author sees fit. The author could even distribute Y as source under a non-GPL _compatible_ license. This would hamper the utility Y, neither the author of Y nor anyone else could distribute an executable that agglomerates X and Y, but I honestly can't see how the existence of library X (GPL) can make it illegal to distribute other distinct works (my emphasis on _distinct_). Now, author X could choose to sue author Y for copyright infringement. If such a case happened it might set the precedent for what a 'derived work' is - vis-a-vis GPL and libraries - from my cursory web searching, such a case hasn't happened. From the 'Linking and derived works' bit in the Wikipedia page, the judgement on copyright law notes the infringing work must incorporate a portion of the copyrighted work in some form, surely the judges would have to decide whether or not calling API's and reusing datatypes is incorporation. http://en.wikipedia.org/wiki/GNU_General_Public_License 3) If the answer to 1 is yes, what specifically would trigger the redistribution of a work in this scenario under the GPL? Is it the distribution of X+Y *together* (whether in source or binary form)? Don't know. In the case of Hakyll and other packages on Hackage, the distribution is in source form. If someone wanted to repackage the code from Hackage as a binary distro they would have different obligations. 4) If the answer to 1 is yes, does this mean that a BSD-licensed library does not necessarily mean that closed-source software can be distributed which is based upon such a library (if it so happens that the library in turn depends on a copylefted library)? The 'closed-source' software here still depends on a 'copyleft' library - if the library is GPL then the terms of the GPL apply. Whether there is an intermediary BSD licensed library is surely immaterial. I'd like to point out a possible situation, that makes the questions even more interesting. Say the author of Y (the BSD licensed code) is used to install its code, Y, along of its requisite X (under GPL) to customer locations. Note that Y and X are not (re)distributed in compiled form. In fact, the client could have the internal resource to install and configure Y and its requisite himself (if Y was made available to him). Is it ok in regard of the GPL ? Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] wiki in hackage
i think to add a wiki to each package is a great idea. as a default, it could be started automatically by uploading to hackage and filled with the readme.txt file (if availble) in the tar uploaded. if it is empty and exist, it is a point to check for when a package does not install immediately. alternatively, one has to search the web to see if there is some place with notices about this package. i would have loved to see wiki's for packages to post my result of work- arounds for problems with dependencies, small changes in source code etc. that could be posted there till the maintainer finds time to produce a new version. great idea! andrew frank ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] -- comments
On Sat, Dec 12, 2009 at 5:34 AM, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On Dec 11, 2009, at 23:30 , michael rice wrote: I'm just noticing that -- comments don't seem to work properly when the first character following them is a '*'. I believe the spec only treats -- as a comment leader; this is why Haddock markup has a space between the -- and the markup. The spec [1] treats anything that starts with two or more dashes not followed by a non-symbol to be the start of a comment. [1] http://www.haskell.org/onlinereport/syntax-iso.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
Hi Thu That would sound like 'private use' to me[1] which is permitted by the GPL. If the client later wanted to *distribute* the agglomerated work the GPL would apply. Distribution being the key point, as at that stage the client is no longer using the agglomeration privately. Best wishes Stephen [1] insert the usual caveats for 'interpretation' - I'm not a lawyer, your mileage may vary, etcetera. Similar the limits on 'client' would need some definition vis-a-vis distribution, one person would surely be fine, extrapolating up to multi-national companies I'm not sure. 2009/12/12 minh thu not...@gmail.com: I'd like to point out a possible situation, that makes the questions even more interesting. Say the author of Y (the BSD licensed code) is used to install its code, Y, along of its requisite X (under GPL) to customer locations. Note that Y and X are not (re)distributed in compiled form. In fact, the client could have the internal resource to install and configure Y and its requisite himself (if Y was made available to him). Is it ok in regard of the GPL ? Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: [BostonHaskell] Next meeting: December 17th at MIT (32-G882)
--- On Sat, 12/12/09, Bulat Ziganshin bulat.zigans...@gmail.com wrote: From: Bulat Ziganshin bulat.zigans...@gmail.com Subject: Re: [Haskell-cafe] Fwd: [BostonHaskell] Next meeting: December 17th at MIT (32-G882) To: Ravi Nanavati rav...@alum.mit.edu Cc: haskell-cafe@haskell.org Date: Saturday, December 12, 2009, 3:40 AM Hello Ravi, Saturday, December 12, 2009, 9:48:28 AM, you wrote: Based on the responses to my previous message, our featured presenter will be Ryan Newton who will talk about the Intel Concurrent Collections for Haskell. awesome! you may try it on many typical unix text processing tasks, such as word frequencies counting, or building statistics from logfiles -- Best regards, Bulat Perhaps something like http://www.tbray.org/ongoing/When/200x/2009/12/08/WF-Tuning-Clojure :-) Doug ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: What about adding a wiki for each haskell project?
Excerpts from Duncan Coutts's message of Sat Dec 12 03:26:30 +0100 2009: On Sat, 2009-12-12 at 01:00 +0100, Marc Weber wrote: hackage is success because: a) many (most) people do use it (by uploading packages) b) it is a comprehensive list of availible packages if not the most comprehensive one Duncan, can you write about your concerns briefly why some maintainers may dislike this idea ? I added a section to the wiki page you created. I didn't paste the link earlier because I was no longer sure whether a wiki page is the best thing todo. Anyway here it is: http://haskell.org/haskellwiki/Hackage_wiki_page_per_project_discussion Duncan added this section: 3 Concerns My (DuncanCoutts) concern is about the consent from package authors. Hackage is a social bargain. We ask package authors to distribute their work through hackage because it provides benefits to the community. If we impose too much on package authors then they may decide it's just not worth it. In particular, if we automatically create a wiki page for every package then we are imposing additional obligations on package authors. As a package author I might be concerned that this wiki page duplicates an existing home page or bug tracking system. If there's a wiki page about my project then I am effectively obligated to check it from time to time, since users will inevitably report bugs etc there. It is that extra obligation that package authors may resent. There is no problem with such a feature being opt-in, but whether it is something we require and impose on package authors needs much more of a social consensus before we go ahead. So how do we reach this consensus? Is it feasable to ask all package authors which uploaded anything to hackage? Duncan, can you also separate your thoughts and switch in two different roles: a) You as package maintainer (eg supporting cabal) b) You as cabal ( hackage) maintainer thinking about package maintainers contributing to hackage. Thus are you concerned yourself ? Would you prefer opt-in for the projects *you* maintain ? Do you think package authors which do care (and which have a bug tracking system and a home page (eg gtk2hs)) would be willing to add those links to the wiki? It could look like this: Dear user. Let me tell you about: * package bug tracking system (link) * package homepage (link) * package mailinglist (...) * package repository: darcs get . And people will follow those links and create a bug report. Moreover I think they would be even thankful! If they don't they are just stupid. And you'll always meet this kind of users.. And again: We generated value because you don't have to upload a new package to tell users about a new homepage or a new bug tracking system or whatever. They will find it by themselves without magic and without contacting you and without looking at the darcs repository (which may take much time ..) If you have time to maintain a package you also have time to ad 4 links or less. If you don't this means you don't care which is also fine. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: ANN: hakyll-0.1
Hello Stephen, Saturday, December 12, 2009, 3:32:09 PM, you wrote: the GPL would apply. Distribution being the key point, as at that your mileage may vary, etcetera. Similar the limits on 'client' would need some definition vis-a-vis distribution, one person would surely be fine, extrapolating up to multi-national companies I'm not sure. afaik, it's still ok while inside one company -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Parallel foldl doesn't work correctly
On Sat, Dec 12, 2009 at 10:08 AM, Maciej Piechotka uzytkown...@gmail.com wrote: If operation is associative it can be done using divide et impera spliting list in half and operating on it pararerlly then split in half etc. I implemented something like this as an exercise: http://benmachine.co.uk/parconcat.hs It took me a little while to get everything to par as it should and I'm still not sure I'm doing it in the most efficient way, but there it is. (If the output is nonsense, you might try changing hPutStrLn stderr into putStrLn so that it's buffered and arrives in blocks). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why?
pbrowne wrote: 2) What, if anything, prevents the execution of a Haskell term from being a proof in equational logic? I have done some checking to try to answer my own question. The answer *seems* to be that there *seems* to be three things that prevent Haskell terms being true equations. Any feedback on these three reason would be welcome. If they are valid reasons, what is their possible impact? Pat Reason (1)-- There are some equations that are not expressible in Haskell. Quoting form: http://www.mail-archive.com/haskell-cafe@haskell.org/msg64843.html Is there any way to achieve such a proof in Haskell itself? GHC appears to reject equations such has mirror (mirror x) = x mirror (mirror(Node x y z)) = Node x y z Eugene Kirpichov Fri, 25 Sep 2009 04:19:32 -0700 It is not possible at the value level, because Haskell does not support dependent types and thus cannot express the type of the proposition forall a . forall x:Tree a, mirror (mirror x) = x, and therefore a proof term also cannot be constructed. Another example from [5]. A partial order that is also linear is called a total order. The class linorder of total orders is specified using the usual total order axioms. Of course, such axiomatizations are not possible in Haskell. Reason (2)-- According to Thompson [1] the equations in Miranda (and I assume Haskell) are not pure mathematical equations due to *where* and other reasons. According to Danielsson [2] the fact that they are not always structurally equations does not prevent functional programmers from using them as if they were valid equations. Danielsson show that this informal *fast and loose* use of equational axioms and theorems is *morally correct*. In particular, it is impossible to transform a terminating program into a looping one. These results justify the informal reasoning that functional programmers use. Reason (3)-- There is no formal specification for the meaning of a Haskell program (i.e. its meaning is not defined in a logic). At the level of precise logical specification and logical interoperability this could be a problem (e.g. semantic web likes logic). This should not be a problem for programming tasks, after all most languages like Java do not have a formal semantic definition in logic (ML, Maude[3] and CafeOBJ[4] do). [1]A Logic for Miranda, Revisited (1994) by Simon Thompson http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.55.149 [2] Fast and Loose Reasoning is Morally Correct - Danielsson, Hughes http://citeseer.ist.psu.edu/733155.html [3] http://maude.cs.uiuc.edu/ [4] http://www.ldl.jaist.ac.jp/cafeobj/ [5]Translating Haskell to Isabelle: Torrini, Lueth,Maeder,Mossakowski http://es.cs.uni-kl.de/TPHOLs-2007/proceedings/B-178.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 status and features
2009/12/12 Rafael Gustavo da Cunha Pereira Pinto rafaelgcpp.li...@gmail.com: I know I should probably be asking to the GHC list, but is there any update on 6.12 since October? Any probable release date? It looks like haskell.org just acquired this page, though it's not yet linked to from anywhere else: http://haskell.org/ghc/download_ghc_6_12_1.html BTW, is there any feature list for the release? http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-1.html Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Am Freitag 11 Dezember 2009 01:20:55 schrieb Richard O'Keefe: On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote: Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others Come ON. Argue honestly! Thanks, but I have to return that compliment. The problem with that text is *NOT* the underscores but the insanely heavy abbreviation. As stated in the parenthesis immediately afterwards. We all agree that insanely heavy abbreviation is bad, but do you *really* want to claim that mbT'sBcs the ndrscrStl isConsidered farUglier and lessReadable byOthers is readable? I claim that the part not using insanely abbreviated words (isConsidered, farUglier, byOthers) *is* readable. Also that moderately abbreviated words are readable in camelCase as well as under_score. (granted, underscore-style with nonabbreviated words is not unreadable, but still extremely ugly)? Who grants that underscore separation with fully written words is still extremely ugly? Not me! Is that remark really unclear, or did you intentionally choose the bracketing you did to make a polemical point? (This is a serious enquiry about the English language. In German, the analogous construction to granted, a, but b [zugegeben, a, aber b] is parsed (granted, a), but b, can it really be parsed as granted, (a, but b) in English?) (granted, ... is not unreadable. But it is still ...) Clearly, *I* grant - or admit, concede - that it is *readable*. Nobody *grants* anything is ugly or not, that is an aesthetic judgment, as such entirely a matter of personal preference - you can agree with it or not. I don't believe that it _is_ a matter of personal preference. I believe that even readability is strongly influenced by personal preference (more by experience - what you're used to). However, the sentence about preference was more concerned with aesthetics. I have not been able to discover an experimental study of word separation style effect on readability in programming. I've been wondering about running a small one myself, next year. But there is enough experimentally determined about reading in general to be certain that visible gaps between words materially improves readability, and internal capital letters harm it. Now that applies to ordinary text, but until there's evidence to show that it doesn't apply to program sources, it's a reasonable working assumption that it does. I doubt that. Sourcecode is so different from ordinary text (a line of sourcecode rarely contains more than four or five words), that I'd be very wary to transfer the findings for one to the other. If somebody claimed that of x - take_while some_condition some_list and x - takeWhile someCondition someList either was objectively more readable than the other, I wouldn't believe it without lots and lots of hard evidence. I believe you find the first more readable, however, for me the underscores push the space-separated parts together, so that I have the tendency to bracket it x - take (while some) (condition some) list on first glance. It resolves when focusing on the line, however. (And, of course, the problem doesn't turn up for x - take_while (= 1000) [3,7 .. ] or similar.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
x - take_while some_condition some_list and x - takeWhile someCondition someList x - take-while some-condition some-list As someone who is dyslexic, I find both camelCase and dashes far easier to read than underscores. I find it hard to count the words in the underscore version - the underscores and spaces confuse me. Dashes do not, presumably because they are 'within' the line of sight for the letters. However, I can't help feeling that if we use good IDEs, we could 'internationalize' identifiers into english/french/chinese/camel/dash or whatever. Matthew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
On Fri, Dec 11, 2009 at 6:00 PM, Marc Weber marco-owe...@gmx.de wrote: Hackage is missing one feature: It is very static. I mean if you have a patch or a question or a comment you have to lookup the darcs repository, write the patch then contact the author and wait.. If the author replies everything is fine. If he doesn't you don't know what to do. And if he does your commitment still doesn't show up on hackage. Using a wiki page for each project enables anybody to add comments. I'm thinking about this kind of comments: Interlude doesn't work for me. It looks like the interlude.h file passes a tuple to the reportError function which doesn't expect a tuple. You can fix it by removing the , in the .h file. Try this patch: http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch One thing you can do today is enter a homepage URL into your .cabal file which is a link to the haskell-wiki. From there you can construct the initial pages of the wiki in a manner that makes it obvious you welcome participation. This also means we're not creating a wiki for the more mature projects like darcs whose hompage already is a wiki, and who have active mailing lists and the like. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Preserving data type information
I am writing URL parsing library which works the following way: - User have a spec of URL, like this: f :: String f = /archive/int:number - There is data type and parser for specs: data Value = IntegerValue Integer | CharValue Char parseSpec :: Parser (Parser (Map String Value)) - So after parsing spec I have parser for URLs and after parsing them — I have mapping from strings to Value values extracted from URL and then I can process them. Now, I want to others to extend my specs by providing additional types, for example: spec :: String spec = /archive/year:archiveyear And store year in: data Year = Year Integer But for that I need to extend Value data type too: data Value = Integer Value | CharValue Char | YearValue Year Which is undesirable... So, I decide to use type class instead of Value type: class Value a instance Value Integer instance Value Char instance Value Year parseSpec :: (Value a) = Parser (Parser (Map String a)) But after parsing URL I have mapping from string to some values of type (Value a) = a which I can't process, but only by applying functions from Value type class, which is limited. So, is there any way to extract type information from containers like (Value a) = Map String a? Something like this: getInteger :: (Value a) = Map String a - Maybe Integer Or maybe, am I doing something wrong from the beginning? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preserving data type information
Hi Andrey Dynamic types are a possibility, if you want to handle an 'open set' of types: http://www.haskell.org/ghc/docs/6.10.3/html/libraries/base/Data-Dynamic.html http://people.cs.uu.nl/arthurb/dynamic.html Although I don't see your use case as needing heterogeneous lists, section 2 of the HList paper enumerates the design options available for 'open types' (the authors conclude against dynamics in this case). http://homepages.cwi.nl/~ralf/HList/ Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
Hi Antoine. One of the main goals is to have a place to a put information when you're not the maintainer. Of course I can put everything into *my* cabal files. I don't want to do this for projects I don't maintain. I'd like to ask maintainers first. But while this question - reply cycle is in progress I'd like to add a link to my patches. About darcs: Sure. Nobody want's to duplicate the contents of the darcs web page. However you can add a link to it. I wonder which is the way to ask all maintainers how they like this idea or more important: Why they might dislike having a wiki page others may edit as well. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Sat, Dec 12, 2009 at 4:54 AM, minh thu not...@gmail.com wrote: I'd like to point out a possible situation, that makes the questions even more interesting. Say the author of Y (the BSD licensed code) is used to install its code, Y, along of its requisite X (under GPL) to customer locations. Note that Y and X are not (re)distributed in compiled form. In fact, the client could have the internal resource to install and configure Y and its requisite himself (if Y was made available to him). Is it ok in regard of the GPL ? I think the answer to this will be the same as the answer to question 1. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
What about if during the Checking a Cabal package upload step there was a check to see if there was a homepage in the cabal file? If there is no homepage we could have something like: Your cabal file does not contain a link to a project homepage. You may want to add a haskell wiki link as your homepage by adding the following line to your cabal file... This would not force the wiki page on anyone but it would add a nudge to anyone who just didn't think about it. -Keith On Sat, Dec 12, 2009 at 12:09 PM, Marc Weber marco-owe...@gmx.de wrote: Hi Antoine. One of the main goals is to have a place to a put information when you're not the maintainer. Of course I can put everything into *my* cabal files. I don't want to do this for projects I don't maintain. I'd like to ask maintainers first. But while this question - reply cycle is in progress I'd like to add a link to my patches. About darcs: Sure. Nobody want's to duplicate the contents of the darcs web page. However you can add a link to it. I wonder which is the way to ask all maintainers how they like this idea or more important: Why they might dislike having a wiki page others may edit as well. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 status and features
On Sat, Dec 12, 2009 at 8:22 AM, Max Bolingbroke batterseapo...@hotmail.com wrote: 2009/12/12 Rafael Gustavo da Cunha Pereira Pinto rafaelgcpp.li...@gmail.com: I know I should probably be asking to the GHC list, but is there any update on 6.12 since October? Any probable release date? It looks like haskell.org just acquired this page, though it's not yet linked to from anywhere else: http://haskell.org/ghc/download_ghc_6_12_1.html Aw, no OS X package yet ... :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap
Hi Heinrich, On Sat, Dec 12, 2009 at 2:42 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Jason Dagit wrote: My next experiment will be to find ways to express take this operation and apply it to a stream without letting the stream leak. One implication is that gzReadFilePS should not be used outside of a core set of modules which have been auideted to be resource concious. Another implication is that we need to be really careful about wether or not we allow returning of sequences of patches. Possibly, we need several foldl-like functions that open the stream internally. For example, to process the pending maybe we should have: withPending :: (a - Patch - a) - IO a And withPending would start the streaming and make sure that the stream cannot be visible as a data dependency outside of withPending. Just a small comment on a potential flaw in this scheme and the observation that even the rank-2 type trick from the ST s monad wouldn't help. I would say it does help, but it doesn't make it perfect. Namely, withPending does not guarantee that the stream does not leak, it only makes it more natural/convenient to formulate one's code so that it doesn't leak. In particular, using (:) as argument pretty much defeats the whole purpose: Right. And the iteratee library points out that your iteratees have to be well-behaved (I think there they say bounded). I'm well aware of this issue and thanks for pointing it out for others who are reading along. withPending (flip (:)) Fortunately, the type system can ensure that the patches don't leak. withPending :: (forall s. a - Patch s - a) - IO a Now, a may not mention s and the type checker will reject flip (:) as argument. See also Oleg Kiselyov, Chung-chieh Shan. Lightweight Monadic Regions. http://www.cs.rutgers.edu/~ccshan/capability/region-io.pdfhttp://www.cs.rutgers.edu/%7Eccshan/capability/region-io.pdf for an elaboration of this technique. I'm still on the fence as to whether this style of writing it will add value greater than the complexity it brings. I am certainly considering it :) The darcs source does other things that are also fairly complex. However, the line between leaking and not leaking is very thin here. As soon as we are given for example a function name :: Patch s - String that discards the s , its results can leak, in the sense that we could now build a list of names foo :: IO [String] foo = withPending . flip $ (:) . name Even worse, any type a that doesn't have O(1) space usage will leak bar :: IO [()] bar = withPending . flip $ const (() :) In other words, exporting only a foldl' -like interface does not really prevent us from writing functions that have O(n) instead of O(1) space usage. But trying to rectify that with the forall s trick is a doomed idea, too. I realize it's not perfect, but the problem we have now is that it's too easy to write things that have dismal space usage. If we can't force proper space usage, how can we make it more natural to have bounded space? Or at least a good approximation. It seems that: * foldl'-style helps * rank-n can help * no approach I've seen *forces* the behavior we want * existing code and bug reports demonstrate we need to improve the situation I'm open to suggestions on how to ensure the code has the space behavior I want. Lazy IO* and streams of patches is more compositional and natural to Haskell programmers, but it seems that it's too hard to ensure the code has reasonable space usage. At least where the darcs source is concerned. Therefore, I think the status quo demonstrates that in the darcs source it's worth experimenting with alternatives to lazy io and streams. In other words, the human effort to make the code behave how we want is currently too high and that's the issue I want to address. I don't know how we could make it impossible to have space leaks, although that would be interesting. (*) Note: Lazy IO itself is used in very few places in darcs these days because it has lead to serious bugs. These days me point is more about big streams getting retained. Finding where and why has proven difficult. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preserving data type information
Hi, Stephen. Thanks a lot — HList paper gave me a good overview of possible soultions. For the first try I will stuck with Data.Dynamic. On Sat, Dec 12, 2009 at 7:18 PM, Stephen Tetley stephen.tet...@gmail.com wrote: Hi Andrey Dynamic types are a possibility, if you want to handle an 'open set' of types: http://www.haskell.org/ghc/docs/6.10.3/html/libraries/base/Data-Dynamic.html http://people.cs.uu.nl/arthurb/dynamic.html Although I don't see your use case as needing heterogeneous lists, section 2 of the HList paper enumerates the design options available for 'open types' (the authors conclude against dynamics in this case). http://homepages.cwi.nl/~ralf/HList/ Best wishes Stephen -- С уважением, Андрей Попп. +7 911 740 24 91 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Token parsers in parsec consume trailing whitespace
I recently ran into a nasty little bug where token parsers in parsec consume trailing whitespace, which were consuming newlines and thus bamboozling a higher-level sepBy combinator. I replaced my instances of 'natural' with 'read $ many1 digit', but this gave rise to the following questions: 1. Is there a more elegant way of doing number parsing? In particular, are there token parsers that don't consume trailing whitespace, or is there a better way to do this with the primitives. 2. It seems that the token approach of parsing lends itself to a different style of parsing than the one I'm doing, namely, instead of assuming all of your parsers consume exactly what they need, and no more, you assume that they consume what they need and spaces. Thus, code that looks like: do foo - fooParser spaces bar - barParser spaces baz - bazParser return $ FooBarBaz foo bar baz becomes: FooBarBaz $ fooParser * barParser * bazParser And instead of using sepBy you just use many. One of the problems I see with this approach is if I was using sepBy newline, the new token oriented parser has no way of distinguishing foo bar baz\nfoo bar baz from foo bar baz foo bar baz, which is something I might want to care about. Which method do you prefer? 3. Not so much a question as a comment: when parsing entire files, be sure to add the eof combinator at the end! Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] writing graphs with do-notation
Hi!
Some time ago, i needed to write down graphs in Haskell. I wanted to be able
to write them down without to much noise, to make them easily maintainable. I
came up with a way to define graphs using monads and the do notation. I thought
this might be interesting to someone, so i wrote a small script to illustrate
the idea. Here's an example:
example :: Graph String
example = buildGraph $ do
a - mkNode A []
b - mkNode B [a]
mkNode C [a, b]
In this graph there are three nodes identified by [A, B, C] and three
edges ([(A, B), (A, C), (B, C)]). Think of the variables a and b
as outputs of the nodes A and B. Note that each node identifier needs to be
mentioned only once. Also the definition of edges (references to other nodes
via the outputs) can be checked at compile time.
The attachment is a little script that defines a Graph-type (nothing
elaborate), the buildGraph function and an example graph that is a little
more complex than the above. The main function of the script prints the
example graph to stdout to be read by dot (or similar).
By the way, it is possible to define cyclic graphs using mdo (RecursiveDo).
I haven't come across something similar, so i thought, i'd share it. What do
you think?
Sönke
{-# language RecursiveDo #-}
import Data.Map ((!), fromList)
import Control.Monad.State
import qualified Text.Dot as Dot
-- * Graph definition
-- | type of Graphs.
data Graph node
= Graph {
nodes :: [node],
edges :: [(node, node)]
}
deriving Show
-- | The empty Graph.
emptyGraph :: Graph a
emptyGraph = Graph [] []
-- | Converts a Graph into dot format
toDot :: (Ord s, Show s) = Graph s - String
toDot (Graph nodes edges) = Dot.showDot $ do
ids - mapM (\ l - Dot.node [(label, show l)]) nodes
let idMap = fromList $ zip nodes ids
mapM_ (\ (a, b) - (idMap ! a) Dot..-. (idMap ! b)) edges
-- * GraphMonad
-- | Allows to write directed Graphs in form of monadic statements.
type GraphMonad n a = State (Graph n) a
data Output n = Output n
-- | Builds the Graph given a graph creation command.
buildGraph :: GraphMonad n () - Graph n
buildGraph cmd = snd $ runState cmd emptyGraph
-- | Constructs a node. $inputs$ are all nodes which should be
-- connected (via edges) to this new node.
mkNode :: n - [Output n] - GraphMonad n (Output n)
mkNode node inputs =
State $ \ (Graph nodes edges) -
let newEdges = map (\ (Output input) - (input, node)) inputs
in (Output node, Graph (node : nodes) (edges ++ newEdges))
-- * example graph
-- | This is just an example graph.
example :: Graph String
example = buildGraph $ mdo
mkNode unconnected []
a - mkNode A []
b - mkNode B [a]
mkNode C [a, b]
subgraph a b
c1 - mkNode cyclic [c1, c2]
c2 - mkNode cyclic2 [c1]
return ()
-- | example for encapsulating subgraphs.
-- This doesn't show in the resulting graph.
subgraph :: Output String - Output String - GraphMonad String ()
subgraph a b = do
x - mkNode x [a]
mkNode y [x, b]
return ()
-- | Print out the example graph in dot format to stdout
main = putStrLn $ toDot example
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap
On Dec 12, 7:13 pm, Jason Dagit da...@codersbase.com wrote: Hi Heinrich, On Sat, Dec 12, 2009 at 2:42 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Jason Dagit wrote: My next experiment will be to find ways to express take this operation and apply it to a stream without letting the stream leak. One implication is that gzReadFilePS should not be used outside of a core set of modules which have been auideted to be resource concious. Another implication is that we need to be really careful about wether or not we allow returning of sequences of patches. Possibly, we need several foldl-like functions that open the stream internally. For example, to process the pending maybe we should have: withPending :: (a - Patch - a) - IO a And withPending would start the streaming and make sure that the stream cannot be visible as a data dependency outside of withPending. Just a small comment on a potential flaw in this scheme and the observation that even the rank-2 type trick from the ST s monad wouldn't help. I would say it does help, but it doesn't make it perfect. Namely, withPending does not guarantee that the stream does not leak, it only makes it more natural/convenient to formulate one's code so that it doesn't leak. In particular, using (:) as argument pretty much defeats the whole purpose: Right. And the iteratee library points out that your iteratees have to be well-behaved (I think there they say bounded). I'm well aware of this issue and thanks for pointing it out for others who are reading along. withPending (flip (:)) Fortunately, the type system can ensure that the patches don't leak. withPending :: (forall s. a - Patch s - a) - IO a Now, a may not mention s and the type checker will reject flip (:) as argument. See also Oleg Kiselyov, Chung-chieh Shan. Lightweight Monadic Regions. http://www.cs.rutgers.edu/~ccshan/capability/region-io.pdfhttp://www.cs.rutgers.edu/%7Eccshan/capability/region-io.pdf for an elaboration of this technique. I'm still on the fence as to whether this style of writing it will add value greater than the complexity it brings. I am certainly considering it :) The darcs source does other things that are also fairly complex. However, the line between leaking and not leaking is very thin here. As soon as we are given for example a function name :: Patch s - String that discards the s , its results can leak, in the sense that we could now build a list of names foo :: IO [String] foo = withPending . flip $ (:) . name Even worse, any type a that doesn't have O(1) space usage will leak bar :: IO [()] bar = withPending . flip $ const (() :) In other words, exporting only a foldl' -like interface does not really prevent us from writing functions that have O(n) instead of O(1) space usage. But trying to rectify that with the forall s trick is a doomed idea, too. I realize it's not perfect, but the problem we have now is that it's too easy to write things that have dismal space usage. If we can't force proper space usage, how can we make it more natural to have bounded space? Or at least a good approximation. It seems that: * foldl'-style helps * rank-n can help * no approach I've seen *forces* the behavior we want * existing code and bug reports demonstrate we need to improve the situation I'm open to suggestions on how to ensure the code has the space behavior I want. Lazy IO* and streams of patches is more compositional and natural to Haskell programmers, but it seems that it's too hard to ensure the code has reasonable space usage. At least where the darcs source is concerned. Therefore, I think the status quo demonstrates that in the darcs source it's worth experimenting with alternatives to lazy io and streams. In other words, the human effort to make the code behave how we want is currently too high and that's the issue I want to address. I don't know how we could make it impossible to have space leaks, although that would be interesting. As a beginner to Haskell, I am only 1/3 through RWH, those lines scare me in a sense to question my effort. I simply can not distinguish if this discussion is somewhat pathological in a sense that every access to the outside world imposes dangers and an additional exception handler here and there and an additional if-statement to handle error return codes will suffice. Or lazy evaluation, IO monads and the whole story behind unsafePerformIO was an additional layer of self-deception and unpredictable effects from the outside world and lazy evaluation can NEVER be satisfactory handled. (*) Note: Lazy IO itself is used in very few places in darcs these days because it has lead to serious bugs. These days me point is more about big streams getting retained. Finding where and why has proven difficult. Thanks, Jason
Re: [Haskell-cafe] GHC 6.12 status and features
THANKS!! Just in time for Christmas!! On Sat, Dec 12, 2009 at 12:22, Max Bolingbroke batterseapo...@hotmail.comwrote: 2009/12/12 Rafael Gustavo da Cunha Pereira Pinto rafaelgcpp.li...@gmail.com: I know I should probably be asking to the GHC list, but is there any update on 6.12 since October? Any probable release date? It looks like haskell.org just acquired this page, though it's not yet linked to from anywhere else: http://haskell.org/ghc/download_ghc_6_12_1.html BTW, is there any feature list for the release? http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-1.html Cheers, Max -- Rafael Gustavo da Cunha Pereira Pinto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint causes GHCi linker error under Windows
Hi, Martin Do you have a complete example one can use to reproduce this behavior? (preferably a short one! :P) In any case, I'm resending your message to the glasgow-haskell-users list to see if a ghc guru recognize the error message. It is strange that the problem only manifests on Windows Daniel On Dec 11, 2009, at 7:04 AM, Martin Hofmann wrote: The following hint code causes GHCi to crash under Windows: runInterpreter $ loadModules [SomeModule.hs] The error message is: GHCi runtime linker: fatal error: I found a duplicate definition for symbol _hs_gtWord64 whilst processing object file C:\Programme\Haskell Platform\2009.2.0.2\ghc-prim-0.1.0.0 HSghc-prim-0.1.0.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. The problem does not occur under Unix or with a compiled program. IMHO hint tries to start a second instance of GHCi which is not allowed/possible under Windows. If this is the case a more telling error message would be helpful. I used the Haskell Platform, version 2009.2.0.2 under Windows XP. My package.conf is: C:/Programme/Haskell Platform/2009.2.0.2\package.conf: Cabal-1.6.0.3, GHood-0.0.3, GLUT-2.1.1.2, HTTP-4000.0.6, HUnit-1.2.0.3, MonadCatchIO-mtl-0.2.0.0, OpenGL-2.2.1.1, QuickCheck-1.2.0.0, Win32-2.2.0.0, ansi-terminal-0.5.0, ansi-wl-pprint-0.5.1, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bimap-0.2.4, bytestring-0.9.1.4, cgi-3001.1.7.1, containers-0.2.0.1, cpphs-1.9, directory-1.0.0.3, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), extensible-exceptions-0.1.1.0, fgl-5.4.2.2, filepath-1.1.0.2, (ghc-6.10.4), ghc-mtl-1.0.1.0, ghc-paths-0.1.0.6, ghc-prim-0.1.0.0, haddock-2.4.2, haskeline-0.6.2.2, haskell-src-1.0.1.3, haskell-src-exts-1.3.4, haskell98-1.0.1.0, hint-0.3.2.1, hpc-0.5.0.3, html-1.0.1.2, integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.4, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1, pointless-haskell-0.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4, utf8-string-0.3.6, xhtml-3000.2.0.1, zlib-0.5.0.0 Thanks, Martin ___ 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] Re: [darcs-users] Iteratees, streams, and mmap
On Sat, Dec 12, 2009 at 1:37 PM, Johann Höchtl johann.hoec...@gmail.comwrote: On Dec 12, 7:13 pm, Jason Dagit da...@codersbase.com wrote: Hi Heinrich, On Sat, Dec 12, 2009 at 2:42 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Jason Dagit wrote: My next experiment will be to find ways to express take this operation and apply it to a stream without letting the stream leak. One implication is that gzReadFilePS should not be used outside of a core set of modules which have been auideted to be resource concious. Another implication is that we need to be really careful about wether or not we allow returning of sequences of patches. Possibly, we need several foldl-like functions that open the stream internally. For example, to process the pending maybe we should have: withPending :: (a - Patch - a) - IO a And withPending would start the streaming and make sure that the stream cannot be visible as a data dependency outside of withPending. Just a small comment on a potential flaw in this scheme and the observation that even the rank-2 type trick from the ST s monad wouldn't help. I would say it does help, but it doesn't make it perfect. Namely, withPending does not guarantee that the stream does not leak, it only makes it more natural/convenient to formulate one's code so that it doesn't leak. In particular, using (:) as argument pretty much defeats the whole purpose: Right. And the iteratee library points out that your iteratees have to be well-behaved (I think there they say bounded). I'm well aware of this issue and thanks for pointing it out for others who are reading along. withPending (flip (:)) Fortunately, the type system can ensure that the patches don't leak. withPending :: (forall s. a - Patch s - a) - IO a Now, a may not mention s and the type checker will reject flip (:) as argument. See also Oleg Kiselyov, Chung-chieh Shan. Lightweight Monadic Regions. http://www.cs.rutgers.edu/~ccshan/capability/region-io.pdfhttp://www.cs.rutgers.edu/%7Eccshan/capability/region-io.pdf http://www.cs.rutgers.edu/%7Eccshan/capability/region-io.pdf for an elaboration of this technique. I'm still on the fence as to whether this style of writing it will add value greater than the complexity it brings. I am certainly considering it :) The darcs source does other things that are also fairly complex. However, the line between leaking and not leaking is very thin here. As soon as we are given for example a function name :: Patch s - String that discards the s , its results can leak, in the sense that we could now build a list of names foo :: IO [String] foo = withPending . flip $ (:) . name Even worse, any type a that doesn't have O(1) space usage will leak bar :: IO [()] bar = withPending . flip $ const (() :) In other words, exporting only a foldl' -like interface does not really prevent us from writing functions that have O(n) instead of O(1) space usage. But trying to rectify that with the forall s trick is a doomed idea, too. I realize it's not perfect, but the problem we have now is that it's too easy to write things that have dismal space usage. If we can't force proper space usage, how can we make it more natural to have bounded space? Or at least a good approximation. It seems that: * foldl'-style helps * rank-n can help * no approach I've seen *forces* the behavior we want * existing code and bug reports demonstrate we need to improve the situation I'm open to suggestions on how to ensure the code has the space behavior I want. Lazy IO* and streams of patches is more compositional and natural to Haskell programmers, but it seems that it's too hard to ensure the code has reasonable space usage. At least where the darcs source is concerned. Therefore, I think the status quo demonstrates that in the darcs source it's worth experimenting with alternatives to lazy io and streams. In other words, the human effort to make the code behave how we want is currently too high and that's the issue I want to address. I don't know how we could make it impossible to have space leaks, although that would be interesting. As a beginner to Haskell, I am only 1/3 through RWH, those lines scare me in a sense to question my effort. I simply can not distinguish if this discussion is somewhat pathological in a sense that every access to the outside world imposes dangers and an additional exception handler here and there and an additional if-statement to handle error return codes will suffice. We're not talking about exception handling :) And yes, Heinrich is talking about pathological cases. Or lazy evaluation, IO monads and the whole story behind unsafePerformIO
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
Marc Weber marco-owe...@gmx.de wrote: Hackage is missing one feature: It is very static. I mean if you have a patch or a question or a comment you have to lookup the darcs repository, write the patch then contact the author and wait.. If the author replies everything is fine. If he doesn't you don't know what to do. And if he does your commitment still doesn't show up on hackage. Using a wiki page for each project enables anybody to add comments.[...] Because of Duncan's concerns about imposing too much burden on authors, and because there are many mature projects which already have wikis etc, I have a counter-proposal. We already have community.haskell.org for authors to host their webpages and Darcs repos. And apparently they offer Trac and MailMan since last I checked. It seems to me that the proper place to offer services like wikis (Trac has one) and task trackers (Trac has one of those too) is through the community.haskell.org server. These services are essential for project maintinence, but Hackage doesn't seem like the right place for adding them. Rather than giving Hackage wikis, perhaps it would be better to point more people towards community.haskell.org and maybe increase the options offered there (in case people dislike Trac). One simple improvement to Hackage which would be nice and which would integrate well with community.haskell.org is if there were additional (optional) fields added to give urls for the wiki and task tracker separately from the main project homepage. Naturally, the homepage should have links to the wiki and tracker as well, but having direct links from Hackage would lower the cost for users to find out where they can post patches, comments, etc. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
patch-tag.com has wikis now. They are some buggy behaviors I still need to address so I haven't blogged or otherwise drawn attention to it (arrrg) but my hope is that, quite soon, this will be quite slick and quite useful. 2009/12/11 Marc Weber marco-owe...@gmx.de hackage is success because: a) many (most) people do use it (by uploading packages) b) it is a comprehensive list of availible packages if not the most comprehensive one Duncan, can you write about your concerns briefly why some maintainers may dislike this idea ? Hackage is missing one feature: It is very static. I mean if you have a patch or a question or a comment you have to lookup the darcs repository, write the patch then contact the author and wait.. If the author replies everything is fine. If he doesn't you don't know what to do. And if he does your commitment still doesn't show up on hackage. Using a wiki page for each project enables anybody to add comments. I'm thinking about this kind of comments: Interlude doesn't work for me. It looks like the interlude.h file passes a tuple to the reportError function which doesn't expect a tuple. You can fix it by removing the , in the .h file. Try this patch: http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch Of course I mailed the author. Looking at the package again I noticed that it was uploaded by someone else: GwernBranwen. gwern on #haskell told me that the author is responsive so I'll just wait some days, but others will try and fail as well. If the other person is new to haskell he may not find the fix fast. He just wants to know which of the heads is causing trouble.. Another use case would be users adding If you're interested in this topic also have a look at XXX Yet another use case is someone figuring out that function X was removed in version Y. He could than add a note x vanished since v.10 and everybody who wants to update cabal dependency constraints doesn't have to download the darcs repo to figure out that he should use package = v.10 . Of course contents of wiki pages may be totally wrong because the contents were written by people knowing the package less than the maintainers and authors. But everyone knows this and will take care. This wiki can server as fail over if the maintainer is on holiday. This wiki page will prevent people blogging about packages and benchmark results anywhere on the internet. So it's much more likely that this information is read and maintained. If you use google to look for bug fixes or such you may have success. But very often you end up reading pages dated 3 years ago which are outdated. This wiki page would be I simple effective way letting users annotate packages. Costs: Make hackage add one link. It would look like this: http://mawercer.de/~marc/hackage-link-example.jpg This link should point to the existing haskell wiki on haskell.org: http://haskell.org/haskellwiki/project-name-without-version Even if the maintainer is availible 24/h a day he won't upload a new minor version to hackage for each change. But maybe he'll paste a small note that the darcs repo is more up to date fixing issue x/y. You don't want to upload a new version because you added some documentation. Why don't you want to do that ? It's because hackage will keep every version which was uploaded once by design. Having 50 versions of one package just causes much more work for tools such as cabal install or hack-nix. Figuring out a solution to install all packages is hard enough. Maintainers can create the wiki page and subscribe to change notifications. So I don't think it'll be that much work for them to keep an eye on those wiki pages. How do you think about it? It's about centralizing information and saving your and my time. Many packages aready do have a wiki page. So why not make it easier for all to add one? Thoughts ? Currently my goal is updating some common packages so that they use extensible exceptions and base4. But when working on some patches I'd like to tell people that I'm doing so. I can't in an easy way. That's why I'm starting this thread. Marc Weber ___ 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] What about adding a wiki for each haskell project?
Hi Wren, Thank you for taking the time for replying. Can you reread the wiki section labeled implementation details? I don't want hackage to be the wiki. I only want hackage to host a link to the wiki. There maybe reasons to host the wiki on hackage. Eg hackage does know when a package get's updated. Thus it could update some information on the wiki automatically. But it could do so on the community server as well. I proposed reusing the existing haskell.org/haskellwiki. If all features of the wiki are use its fine. The main idea is provide some minimal editable content so that you don't have to upload new cabal packages because of some small changes. One simple improvement to Hackage which would be nice and which would integrate well with community.haskell.org is if there were additional (optional) fields added to give urls for the wiki and task tracker separately from the main project homepage. EvanMartin asked for this wiki: field feature as well. Do you think changing the homepage field to contain a list would suffice? Or do you feel having an explicit wiki field is preferable? should have links to the wiki and tracker as well, but having direct links from Hackage would lower the cost for users to find out where they can post patches, comments, etc. Yes. That's one main point. Hackage is the entry point many users find. It's kind of standard. But hackage itself is too static. Uploading a new .cabal file is not the perfect way to add a link to a blog post or such. The easiest idea I came up was provide a link to the haskell.org/haskellwiki. The second thought I had in mind was Don't spend too much time on this. Anyway I feel this is important. So may I ask you to add the alternative that the community server can be used equally well to the wiki page? http://haskell.org/haskellwiki/?title=Hackage_wiki_page_per_project_discussionaction=edit Keep in mind that if we host the wiki pages on haskell.org they are found by the haskell.org search. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
