Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
Excerpts from Albert Y.C.Lai's message of Mon Jun 28 15:44:34 -0400 2010: I propose that at each minor version of base, someone picks an implementation randomly. This has actually been done, in a legitimate language implementation. Check out: http://web.mit.edu/~axch/www/scheme/choices/non-ascii-integer-to-char.html Scheme 48, iirc, adds 1000 to the integer value of an ASCII character. Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
On Mon, Jun 28, 2010 at 07:44:34PM +, Albert Y.C.Lai wrote: I propose that at each minor version of base, someone picks an implementation randomly. Here is a more radical, less labour-intensive solution, if you don't mind a judicious, correctness-preserving use of unsafePerformIO: at the first invocation of the process lifetime, pick an implementation randomly. Over in ##c++, there is sometimes talk about an Evil Standard Library, that attempts to do interesting things in response to any undefined or implementation defined behaviour, triggering things like launching NetHack. -- Lars Viklund | z...@acc.umu.se ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: HaRe, the Haskell Refactorer 0.6
Hello Chris, Chris Brown wrote: we are pleased to announce the availability of HaRe 0.6 Great, I want to try it! While skimming the installation instructions I wondered why I couldn't just do cabal install HaRe Are there any problems with putting HaRe on Hackage? I will probably install HaRe anyway but I guess it would be easier if I could just use cabal-install. Thanks! Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for comments: neither package
Hi Michael If you going to the trouble of constructing a sum type (obliged to be 2 parameter) expressly to play well with the favourite single parameter classes e.g. Functor/ Applicative / Monad [*], maybe it is worth considering new names for the type and its constructors relating to what the Applicative/Monad instances actually model. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for comments: neither package
On Tue, Jun 29, 2010 at 10:18 AM, Stephen Tetley stephen.tet...@gmail.comwrote: Hi Michael If you going to the trouble of constructing a sum type (obliged to be 2 parameter) expressly to play well with the favourite single parameter classes e.g. Functor/ Applicative / Monad [*], maybe it is worth considering new names for the type and its constructors relating to what the Applicative/Monad instances actually model. I'm definitely open to such an approach, but I couldn't come up with any good names ;). I'm open to suggestions. As an aside, my wife is a classics major (Greek and Latin), and she recommended I name the constructors Sinister and Dexter. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: specifying package name in ghci import?
On Mon, 2010-06-28 at 19:29 -0700, Michael Vanier wrote: Hi, Quick question about ghci: when I do this at the prompt: ghci :m +Control.Monad.Cont I get Ambiguous module name `Control.Monad.Cont': it was found in multiple packages: mtl-1.1.0.2 monads-fd-0.0.0.1 Is there any way to fix this from within ghci (i.e. not involving mucking with ghc-pkg)? What I have in mind might be e.g. ghci :m + mtl Control.Monad.Cont or something similar. Thanks, Mike % ghci -hide-package monads-fd ghci import Control.Monad.Cont or ghci :set -hide-package mtl ghci import Control.Monad.Cont Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
Maybe it is because deleteBy is defined wrongly? i.e. it is not logical, doesn't follow the common sense user might expect. It accepts any predicate but narrows requirements only in docs. Maybe best could be to just take a value for comparison and use == against it? (overloaded or built-in (I'm a C++ engineer but as I know it is possible in Haskell as well.)) And to have separate delete which accepts arbitrary predicate. (As it is now.) Regards, Zura Albert Y. C. Lai wrote: The doc of deleteBy states: The deleteBy function behaves like delete, but takes a user-supplied equality predicate. A precondition is that the user-supplied predicate is an equality predicate. (=) is not an equality predicate, be it in the layperson sense of it isn't analogous to (==) or the mathematical sense of it isn't an equivalence relation. -- View this message in context: http://old.nabble.com/whine-and-solution-about-programmers-not-respecting-documentations-tp29017296p29021467.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
On Tuesday 29 June 2010 10:47:40, Zura_ wrote: Maybe it is because deleteBy is defined wrongly? i.e. it is not logical, doesn't follow the common sense user might expect. It accepts any predicate but narrows requirements only in docs. Unfortunately, you can't easily encode the requirement that it ought to be an equivalence relation via types. So putting it in the docs and hoping nobody gets burned too badly is probably the best one can do. Maybe best could be to just take a value for comparison and use == against it? That's the plain delete. (overloaded or built-in (I'm a C++ engineer but as I know it is possible in Haskell as well.)) And to have separate delete which accepts arbitrary predicate. (As it is now.) Regards, Zura Albert Y. C. Lai wrote: The doc of deleteBy states: The deleteBy function behaves like delete, but takes a user-supplied equality predicate. A precondition is that the user-supplied predicate is an equality predicate. (=) is not an equality predicate, be it in the layperson sense of it isn't analogous to (==) or the mathematical sense of it isn't an equivalence relation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: HaRe, the Haskell Refactorer 0.6
Sebastian Fischer s...@informatik.uni-kiel.de writes: Hello Chris, Chris Brown wrote: we are pleased to announce the availability of HaRe 0.6 Great, I want to try it! While skimming the installation instructions I wondered why I couldn't just do cabal install HaRe Are there any problems with putting HaRe on Hackage? Just because they haven't is my guess. I've tried playing with an older version of HaRe; it's build system is a little weird but I'm sure it can be converted into a Cabal-compatible format. Part of the problem if memory serves is the use of embedded libraries that aren't on Hackage either. The other possible problem is the license; I'm not sure what license HaRe is under. I will probably install HaRe anyway but I guess it would be easier if I could just use cabal-install. Of course, it would also be nice if HaRe could parse more than just Haskell98... :p (I know, I know, it isn't easy to change parsers, etc.). Thanks! Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- 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] whine and solution about programmers not respecting documentations
Daniel Fischer daniel.is.fisc...@web.de writes: Maybe it is because deleteBy is defined wrongly? i.e. it is not logical, doesn't follow the common sense user might expect. It accepts any predicate but narrows requirements only in docs. Unfortunately, you can't easily encode the requirement that it ought to be an equivalence relation via types. This is just another way of saying the same thing :-) An important point of a powerful type system is to model your program so that only sensible code is legal. This makes me wonder why deleteBy is defined so loosely, instead of e.g. deleteBy :: (a - Bool) - [a] - [a] I don't think there would be any doubt what 'deleteBy (= 5) [1..10]' would do. And I just don't see what the requirement for an equivalence relation buys you. -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
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
On Tue, Jun 29, 2010 at 11:46 AM, Ketil Malde ke...@malde.org wrote: deleteBy :: (a - Bool) - [a] - [a] I don't think there would be any doubt what 'deleteBy (= 5) [1..10]' would do. And I just don't see what the requirement for an equivalence relation buys you. Your deleteBy is (filter . not), isn't it? --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
On Tuesday 29 June 2010 11:46:47, Ketil Malde wrote: An important point of a powerful type system is to model your program so that only sensible code is legal. That would be an awesomely powerful type system :) This makes me wonder why deleteBy is defined so loosely, instead of e.g. deleteBy :: (a - Bool) - [a] - [a] That would've been the (a) safer choice. I don't think there would be any doubt what 'deleteBy (= 5) [1..10]' would do. Well, if you don't know about filter, you could think it deletes all elements satisfying the predicate, but apart from that, it's clear. And I just don't see what the requirement for an equivalence relation buys you. For the type deleteBy has, predictability. Currently, you can't know whether deleteBy pred x tests pred x y or pred y x without looking at the source. For a symmetric relation, you needn't care. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
Max Rabkin max.rab...@gmail.com writes: On Tue, Jun 29, 2010 at 11:46 AM, Ketil Malde ke...@malde.org wrote: deleteBy :: (a - Bool) - [a] - [a] I don't think there would be any doubt what 'deleteBy (= 5) [1..10]' would do. And I just don't see what the requirement for an equivalence relation buys you. Your deleteBy is (filter . not), isn't it? filter . (not .) 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] whine and solution about programmers not respecting documentations
Max Rabkin max.rab...@gmail.com writes: Your deleteBy is (filter . not), isn't it? With the caveat that I haven't actually used it, my impression is that delete only removes one element, while filter removes all of them. -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
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
Ketil Malde ke...@malde.org writes: Max Rabkin max.rab...@gmail.com writes: Your deleteBy is (filter . not), isn't it? With the caveat that I haven't actually used it, my impression is that delete only removes one element, while filter removes all of them. At most one element, yes; I question why that design decision was made as I'm more likely to want to delete all values rather than just the first one (does anyone actually like/rely on the current functionality of delete/deleteBy w.r.t. repeated values?). -- 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] whine and solution about programmers not respecting documentations
Daniel Fischer daniel.is.fisc...@web.de writes: An important point of a powerful type system is to model your program so that only sensible code is legal. That would be an awesomely powerful type system :) Heh. But while we're waiting for it, we can try to use what we got to eliminate as much non-sensical code as possible. (Which, btw, I think is an under-sold point: people used to C-style type systems think that all the type system does is label variables for you, which dynamic type systems (like our algebraic data types) let you do the same run-time. But you get a lot more mileage by careful type design.) I don't think there would be any doubt what 'deleteBy (= 5) [1..10]' would do. Well, if you don't know about filter, you could think it deletes all elements satisfying the predicate, but apart from that, it's clear. I'd probably call it 'filter1', but that's just my personal convention. And I just don't see what the requirement for an equivalence relation buys you. For the type deleteBy has, predictability. Currently, you can't know whether deleteBy pred x tests pred x y or pred y x without looking at the source. ...which is a worry my implementation removed by letting the user decide through partial application. For a symmetric relation, you needn't care. But the docs (are interpreted to) say equivalence relation, so woe betide you if you give it a symmetric but non-transitive or non-reflexive function! deleteBy (\x y - abs (x-y) == 2) 5 [1..5] Anyway: I guess the point here is that if all 'deleteBy f x ys' does with arguments f and x is apply f to x and then use the result, we might as well feed it that result and eliminate a lot of uncertainity as well as some documentation all too few of us bother to read. -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
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
On Tuesday 29 June 2010 12:46:21, Ivan Lazar Miljenovic wrote: At most one element, yes; I question why that design decision was made as I'm more likely to want to delete all values rather than just the first one That's more common, yes (I don't remember ever having used delete(By) intentionally). But we've filter for that, so it wouldn't make sense to give delete(By) the same semantics. Hence, if you provide both names, what else could deleteBy do? (does anyone actually like/rely on the current functionality of delete/deleteBy w.r.t. repeated values?). I doubt it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
Daniel Fischer daniel.is.fisc...@web.de writes: That's more common, yes (I don't remember ever having used delete(By) intentionally). But we've filter for that, so it wouldn't make sense to give delete(By) the same semantics. Hence, if you provide both names, what else could deleteBy do? That's like asking why we have mapM and forM, etc. -- 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] Call for comments: neither package
Hi Michael Good names are a problem of course. The Applicative Programming with Effects Paper has the monodial accumulating applicative instance on a sum type Conor McBride and Ross Paterson call Except: data Except err a = OK a | Failed err The names are nice and to the point, but they would equally describes the other exception model (monadic - exit on first fail) and having both might be particularly confusing to newcomers: two error types - one with an obvious name, one with an unfamiliar one, the unfamiliar one might be the one they need most often... Sum might be a candidate, were it not already taken as a type name by Data.Monoid: data Sum e a = ??? e | Result a ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: whine and solution about programmers not respecting documentations
Ketil Malde schrieb: [...] I don't think there would be any doubt what 'deleteBy (= 5) [1..10]' would do. Well, if you don't know about filter, you could think it deletes all elements satisfying the predicate, but apart from that, it's clear. I'd probably call it 'filter1', but that's just my personal convention. I've called it 'deleteFirst' in http://hackage.haskell.org/trac/ghc/ticket/3399 I would expect it to be more efficient than filter (with a negated predicate), because no further comparisons are necessary once the element to be deleted has been found. C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
On Tuesday 29 June 2010 12:50:34, Ketil Malde wrote: Daniel Fischer daniel.is.fisc...@web.de writes: An important point of a powerful type system is to model your program so that only sensible code is legal. That would be an awesomely powerful type system :) Heh. But while we're waiting for it, we can try to use what we got to eliminate as much non-sensical code as possible. +1 ...which is a worry my implementation removed by letting the user decide through partial application. Aye. For a symmetric relation, you needn't care. But the docs (are interpreted to) say equivalence relation, so woe betide you if you give it a symmetric but non-transitive or non-reflexive function! deleteBy (\x y - abs (x-y) == 2) 5 [1..5] grin Anyway: I guess the point here is that if all 'deleteBy f x ys' does with arguments f and x is apply f to x and then use the result, we might as well feed it that result and eliminate a lot of uncertainity as well as some documentation all too few of us bother to read. Full agreement! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
On Tuesday 29 June 2010 13:02:20, Ivan Lazar Miljenovic wrote: That's like asking why we have mapM and forM, etc. Yes, why? (okay, I use forM too, it's so much more readable with a short list and a long action) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
Daniel Fischer daniel.is.fisc...@web.de writes: On Tuesday 29 June 2010 13:02:20, Ivan Lazar Miljenovic wrote: That's like asking why we have mapM and forM, etc. Yes, why? (okay, I use forM too, it's so much more readable with a short list and a long action) Exactly; using deleteBy p (if it was fixed in this sense) would be less ambiguous in what it's there for and less repetitive than using filter (not p) all the time. -- 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] Re: ANNOUNCE: HaRe, the Haskell Refactorer 0.6
Hi Sebastian, Great, I want to try it! Thanks for you interest! While skimming the installation instructions I wondered why I couldn't just do cabal install HaRe Are there any problems with putting HaRe on Hackage? I've looked at this before and I must say it's certainly not trivial to do this. In the build of HaRe, we build a (modified) version of Programatica as a dependency to the refactoring engine. We also need to have vim and emacs scripts available to the user after the install. One approach would be to separate out the Programatica part of HaRe into a hare-utils package, and then build hare on top of that dependency. If you have any advice or experience with using cabal or any tips on getting HaRe cabalised we'd love to hear from you. Kindest regards, Chris. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: HaRe, the Haskell Refactorer 0.6
Hi Ivan, I've tried playing with an older version of HaRe; it's build system is a little weird but I'm sure it can be converted into a Cabal-compatible format. Part of the problem if memory serves is the use of embedded libraries that aren't on Hackage either. That's correct. HaRe builds on top of Strafunski and (a slightly modified) Programatica. It may be possible to wrap these up into a utils package for HaRe. Of course, it would also be nice if HaRe could parse more than just Haskell98... :p (I know, I know, it isn't easy to change parsers, etc.). HaRe works over the full Haskell 98 standard. We certainly wish to move HaRe over to GHC Haskell in the future, and this is currently an ongoing effort: if you have any ideas on how to help us do this please contact us. Kindest regards, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Error monads (was: Call for comments: neither package)
* Stephen Tetley stephen.tet...@gmail.com [2010-06-29 12:02:45+0100] The Applicative Programming with Effects Paper has the monodial accumulating applicative instance on a sum type Conor McBride and Ross Paterson call Except: data Except err a = OK a | Failed err The names are nice and to the point, but they would equally describes the other exception model (monadic - exit on first fail) and having both might be particularly confusing to newcomers: two error types - one with an obvious name, one with an unfamiliar one, the unfamiliar one might be the one they need most often... On a slightly related note, in my projects I tend to define my own Error-like types with descriptive names, often more than one failure mode and apropriate instances. For an example of this approach, see http://github.com/feuerbach/loker/blob/master/testingtool.hs#L33 -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error monads (was: Call for comments: neither package)
2010/6/29 Roman Cheplyaka r...@ro-che.info: * Stephen Tetley stephen.tet...@gmail.com [2010-06-29 12:02:45+0100] The Applicative Programming with Effects Paper has the monodial accumulating applicative instance on a sum type Conor McBride and Ross Paterson call Except: data Except err a = OK a | Failed err The names are nice and to the point, but they would equally describes the other exception model (monadic - exit on first fail) and having both might be particularly confusing to newcomers: two error types - one with an obvious name, one with an unfamiliar one, the unfamiliar one might be the one they need most often... On a slightly related note, in my projects I tend to define my own Error-like types with descriptive names, often more than one failure mode and apropriate instances. For an example of this approach, see http://github.com/feuerbach/loker/blob/master/testingtool.hs#L33 From a quick glance at it, I believe it would be easier to use Either MyError MyResult and then have data MyError = All | The | Possible | Descriptive | Errors Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: HaRe, the Haskell Refactorer 0.6
Chris BROWN chr...@cs.st-andrews.ac.uk writes: Of course, it would also be nice if HaRe could parse more than just Haskell98... :p (I know, I know, it isn't easy to change parsers, etc.). HaRe works over the full Haskell 98 standard. We certainly wish to move HaRe over to GHC Haskell in the future, and this is currently an ongoing effort: if you have any ideas on how to help us do this please contact us. I talked with you and Simon Thompson about this at PEPM, and at the time you said that haskell-src-exts didn't have what you needed for HaRe. What exactly do you need in a parser for it to be suitable for HaRe? -- 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] Re: ANNOUNCE: HaRe, the Haskell Refactorer 0.6
On 29 Jun 2010, at 15:55, Ivan Lazar Miljenovic wrote: Chris BROWN chr...@cs.st-andrews.ac.uk writes: Of course, it would also be nice if HaRe could parse more than just Haskell98... :p (I know, I know, it isn't easy to change parsers, etc.). HaRe works over the full Haskell 98 standard. We certainly wish to move HaRe over to GHC Haskell in the future, and this is currently an ongoing effort: if you have any ideas on how to help us do this please contact us. I talked with you and Simon Thompson about this at PEPM, and at the time you said that haskell-src-exts didn't have what you needed for HaRe. What exactly do you need in a parser for it to be suitable for HaRe? We need static semantics, including location information and a preservation of comments. Chris.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: HaRe, the Haskell Refactorer 0.6
Chris Brown wrote: Are there any problems with putting HaRe on Hackage? I've looked at this before and I must say it's certainly not trivial to do this. [...] We also need to have vim and emacs scripts available to the user after the install. The ghc-mod package [1] provides emacs scripts under ~/.cabal/share/. If you can solve the other issues, this would be a sensible option for HaRe too. Cheers, Sebastian [1]: http://www.mew.org/~kazu/proj/ghc-mod/en/ -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error monads (was: Call for comments: neither package)
* Vo Minh Thu not...@gmail.com [2010-06-29 16:26:06+0200] 2010/6/29 Roman Cheplyaka r...@ro-che.info: * Stephen Tetley stephen.tet...@gmail.com [2010-06-29 12:02:45+0100] The Applicative Programming with Effects Paper has the monodial accumulating applicative instance on a sum type Conor McBride and Ross Paterson call Except: data Except err a = OK a | Failed err The names are nice and to the point, but they would equally describes the other exception model (monadic - exit on first fail) and having both might be particularly confusing to newcomers: two error types - one with an obvious name, one with an unfamiliar one, the unfamiliar one might be the one they need most often... On a slightly related note, in my projects I tend to define my own Error-like types with descriptive names, often more than one failure mode and apropriate instances. For an example of this approach, see http://github.com/feuerbach/loker/blob/master/testingtool.hs#L33 From a quick glance at it, I believe it would be easier to use Either MyError MyResult and then have data MyError = All | The | Possible | Descriptive | Errors I would have to have separate constructor for satisfying Error class constraint, which I don't want to deal with later. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for comments: neither package
On Jun 29, 2010, at 6:02 AM, Stephen Tetley wrote: Hi Michael Good names are a problem of course. The Applicative Programming with Effects Paper has the monodial accumulating applicative instance on a sum type Conor McBride and Ross Paterson call Except: data Except err a = OK a | Failed err The applicatives-extra package defines a type: type ErrorMsg = String data Failing a = Failure [ErrorMsg] | Success a Which is a less general version of that type. I am fine with the more general version, but we should make sure that applicative-extras and things which depend on it are updated, so that we don't have a bunch of really similar types floating around. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for comments: neither package
On Tue, Jun 29, 2010 at 02:56:18PM -0500, Jeremy Shaw wrote: On Jun 29, 2010, at 6:02 AM, Stephen Tetley wrote: The Applicative Programming with Effects Paper has the monodial accumulating applicative instance on a sum type Conor McBride and Ross Paterson call Except: data Except err a = OK a | Failed err The applicatives-extra package defines a type: type ErrorMsg = String data Failing a = Failure [ErrorMsg] | Success a Which is a less general version of that type. There's also a generalization, which I was going to put in transformers, but couldn't decide on the best name: data Sum p a = Return a | Others (p a) instance Functor p = Functor (Sum p) where fmap f (Return x) = Return (f x) fmap f (Others m) = Others (fmap f m) instance Applicative p = Applicative (Sum p) where pure = Return Return x * Return y = Return (x y) Return x * Others my = Others (x $ my) Others mx * Return y = Others (mx * pure y) Others mx * Others my = Others (mx * my) instance Alternative p = Alternative (Sum p) where empty = Others empty Return x | _ = Return x Others _ | Return y = Return y Others mx | Others my = Others (mx | my) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Second draft of the Haskell 2010 report available
On Tue, 29 Jun 2010 17:01:54 +0200, Simon Marlow marlo...@gmail.com wrote: Comments on the draft report are welcome, before I finalise this and sign off on Haskell 2010. Subsection 12.3, Language extensions, mentions the FFI as a language extension, but FFI is now part of the standerd; the same goes for the extensions mentioned at the end of the subsection. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: HaRe, the Haskell Refactorer 0.6
Chris BROWN chr...@cs.st-andrews.ac.uk writes: On 29 Jun 2010, at 15:55, Ivan Lazar Miljenovic wrote: I talked with you and Simon Thompson about this at PEPM, and at the time you said that haskell-src-exts didn't have what you needed for HaRe. What exactly do you need in a parser for it to be suitable for HaRe? We need static semantics, including location information and a preservation of comments. The Annotated part of haskell-src-exts provides this I think: http://hackage.haskell.org/packages/archive/haskell-src-exts/1.9.0/doc/html/Language-Haskell-Exts-Annotated.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
[Haskell-cafe] Parsec combinator like Prolog's cut operator?
Hi all, I'm reading John Hughes' paper Generalizing Monads to Arrows and found the statement regarding parser combinators: ... depend on the programmer using an additional combinator similar to Prolog's 'cut' operator do declare that a parser need never backtrack beyond a certain point. Does something like this already exist in Parsec? If not is there a way to write it? Having this would really help with a parsing problem I have. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec combinator like Prolog's cut operator?
On Tue, Jun 29, 2010 at 10:26 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Hi all, I'm reading John Hughes' paper Generalizing Monads to Arrows and found the statement regarding parser combinators: ... depend on the programmer using an additional combinator similar to Prolog's 'cut' operator do declare that a parser need never backtrack beyond a certain point. Does something like this already exist in Parsec? If not is there a way to write it? Having this would really help with a parsing problem I have. Cheers, Erik For Parsec, in the absence of the try combinator, a parser will never back-track once it consumes a portion of the input. If try is pushed out into the leaves of you parser, you shouldn't run in to too much trouble with excessive backtracking. What problems are you running in to? Take care, Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec combinator like Prolog's cut operator?
Antoine Latter wrote: For Parsec, in the absence of the try combinator, a parser will never back-track once it consumes a portion of the input. Thanks for reminding me. If try is pushed out into the leaves of you parser, you shouldn't run in to too much trouble with excessive backtracking. I agree. What problems are you running in to? Unfortunately I have an existing, mostly working and quite complex parser which does indeed use Parsec.try quite close to the root of the tree. I have tried on a number of ocassions to refactor this to remove this particular usage of Parsec.try without success. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
