Re: [Haskell-cafe] 3 level hierarchy of Haskell objects
On 8/13/12 5:42 PM, Jay Sulzberger wrote: One difficulty which must impede many who study this stuff is that just getting off the ground seems to require a large number of definitions of objects of logically different kinds. (By logic I mean real logic, not any particular formalized system.) We must have expressions, values, type expressions, rules of transformation at the various levels, the workings of the type/kind/context inference system, etc., to get started. Seemingly Basic and Scheme require less, though I certainly mention expressions and values and types and objects-in-the-Lisp-world in my Standard Rant on^W^WIntroduction to Scheme. Indeed, starting with Haskell's type system is jumping in at the deep end. And there isn't a very good tutorial on how to get started learning type theory. Everyone I know seems to have done the stumble around until it clicks routine--- including the folks whose stumbling was guided by formal study in programming language theory. However, a good place to start ---especially viz a vis Scheme/Lisp--- is to go back to the beginning: the simply-typed lambda-calculus[1]. STLC has far fewer moving parts. You have type expressions, term expressions, term reduction, and that's it. Other lambda calculi add all manner of bells and whistles, but STLC is the core of what lambda calculus and type systems are all about. So you should be familiar with it as a touchstone. After getting a handle on STLC, then it's good to see the Barendregt cube. Don't worry too much about understanding it yet, just think of it as a helpful map of a few of the major landmarks in type theory. It's an incomplete map to be sure. One major landmark that's suspiciously missing lays about halfway between STLC and System F: that's Hindley--Milner--Damas, or ML-style, lambda calculus.[2] After seeing the Barendregt cube, then you can start exploring in those various directions. Notably, you don't need to think about the kind level until you start heading towards LF, MLTT, System Fw, or CC, since those are were you get functions/reduction at the type level and/or multiple sorts at the type level. Haskell98 (and the official Haskell2010) take Hindley--Milner--Damas as the starting point and then add some nice things like algebraic data types and type classes (neither of which are represented on the Barendregt cube). This theory is still relatively simple and easy to understand, albeit in a somewhat ad-hoc manner. Modern Haskell lives somewhere beyond the top plane of the cube. We have all of polymorphism (aka System F, aka second-order quantification; via -XRankNTypes), most of type operators (i.e., extending System F to System Fw; via type families etc), some dependent types (aka first-order quantification; via GADTs), plus things not represented on the cube (e.g., (co)inductive data types, type classes, etc). Trying to grok all of that at once without prior understanding of the pieces is daunting to be sure. [1] Via Curry--Howard, the pure STLC corresponds to natural deduction for the implicational fragment of intuitionistic propositional logic. Of course, you can add products (tuples), coproducts (Either), and absurdity to get natural deduction for the full intuitionistic propositional logic. [2] That is: STLC extended with rank-1 second-order quantification, which is a sweet spot in the tapestry of expressivity, decidability, et al. I don't think anyone knows exactly _why_ it's so sweet, but it truly is. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data structure containing elements which are instances of the same type class
On 8/13/12 9:25 PM, Jay Sulzberger wrote: I did suspect that, in some sense, constraints in combination with forall could give the quantifier exists. It's even easier than that. (forall a. P(a)) - Q = exists a. (P(a) - Q) Where P and Q are metatheoretic/schematic variables. This is just the usual thing about antecedents being in a negative position, and thus flipping as you move into/out of that position. The duality mentioned previously is just for the case where you don't have that handy - Q there. How do we get the universal quantifier into a negative position when there's no implication? Why, we add an implication, of course. Even better, add two. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For consistency; it would be better if the import statement matched the cabal install statement or :m form.
On 15 August 2012 13:04, KC kc1...@gmail.com wrote: :m +Data.Array.Repa.Algorithms.Randomish cabal install repa.algrothms would be more consistent. Why would that be? They look completely different to me... -- -- Regards, KC -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Improvement suggestions
Hello everyone, I am quite new to monadic code so I would like to ask for improvement suggestions on the last line of the code below. I know I could do something like do strs - mapM ...; intercalate ... etc, but I would like to avoid the use of -. Thank you, José data XmlState = XmlState Int type XmlM a = State XmlState a loop :: Document - XmlM String someFn :: [Document] - XmlM String someFn docs = return concat `ap` (sequence $ intersperse (return \n) (map loop docs))--- improve this line -- José António Branquinho de Oliveira Lopes 58612 - MEIC-A Instituto Superior Técnico (IST), Universidade Técnica de Lisboa (UTL) jose.lo...@ist.utl.pt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Upcoming resourcet 0.4
Hi all, I've been working with Aristid on an enhancement to resourcet[1]. Please see the issue for more details, this email isn't about that change. Instead, now that we're looking at a new breaking release, I was wondering if anyone had ideas of something they thought should be changed in resourcet. Thanks, Michael [1] https://github.com/snoyberg/conduit/issues/61 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Improvement suggestions
On 15/08/12 17:01, José Lopes wrote: someFn docs = return concat `ap` (sequence $ intersperse (return \n) (map loop docs)) First of all, return x `ap` y = x `fmap` y or x $ y. fmap (or its infix synonym ($)) is the answer here, you could write: someFn docs = concat . intersperse \n $ mapM loop docs The function Data.List.intercalate is a compation of concat and intersperse, so you could write: someFn docs = intercalate \n $ mapM loop docs or, depending on your preference, someFn = fmap (intercalate \n) . mapM loop Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Improvement suggestions
Try: concat . intersperse \n $ (sequence $ map loop docs) On Wed, Aug 15, 2012 at 11:01 AM, José Lopes jose.lo...@ist.utl.pt wrote: Hello everyone, I am quite new to monadic code so I would like to ask for improvement suggestions on the last line of the code below. I know I could do something like do strs - mapM ...; intercalate ... etc, but I would like to avoid the use of -. Thank you, José data XmlState = XmlState Int type XmlM a = State XmlState a loop :: Document - XmlM String someFn :: [Document] - XmlM String someFn docs = return concat `ap` (sequence $ intersperse (return \n) (map loop docs))--- improve this line -- José António Branquinho de Oliveira Lopes 58612 - MEIC-A Instituto Superior Técnico (IST), Universidade Técnica de Lisboa (UTL) jose.lo...@ist.utl.pt __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Improvement suggestions
Thank you. On 15-08-2012 23:09, Twan van Laarhoven wrote: On 15/08/12 17:01, José Lopes wrote: someFn docs = return concat `ap` (sequence $ intersperse (return \n) (map loop docs)) First of all, return x `ap` y = x `fmap` y or x $ y. fmap (or its infix synonym ($)) is the answer here, you could write: someFn docs = concat . intersperse \n $ mapM loop docs The function Data.List.intercalate is a compation of concat and intersperse, so you could write: someFn docs = intercalate \n $ mapM loop docs or, depending on your preference, someFn = fmap (intercalate \n) . mapM loop Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- José António Branquinho de Oliveira Lopes 58612 - MEIC-A Instituto Superior Técnico (IST), Universidade Técnica de Lisboa (UTL) jose.lo...@ist.utl.pt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data structure containing elements which are instances of the same type class
On Aug 15, 2012 3:21 AM, wren ng thornton w...@freegeek.org wrote: It's even easier than that. (forall a. P(a)) - Q = exists a. (P(a) - Q) Where P and Q are metatheoretic/schematic variables. This is just the usual thing about antecedents being in a negative position, and thus flipping as you move into/out of that position. Most of this conversation is going over my head. I can certainly see how exists a. (P(a)-Q) implies that (forall a. P(a))-Q. The opposite certainly doesn't hold in classical logic. What sort of logic are you folks working in? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [Pipes] Can pipes solve this problem? How?
Hello Cafe. Consider code, that takes input from handle until special substring matched: matchInf a res s | a `isPrefixOf` s = reverse res matchInf a res (c:cs) = matchInf a (c:res) cs hTakeWhileNotFound str hdl = hGetContents hdl = return.matchInf str [] It is simple, but the handle is closed after running. That is not good, because I want to reuse this function. Code can be rewritten without hGetContent, but it is much less comprehensible: hTakeWhileNotFound str hdl = fmap reverse$ findStr str hdl [0] [] where findStr str hdl indeces acc = do c - hGetChar hdl let newIndeces = [ i+1 | i - indeces, i length str, str!!i == c] if length str `elem` newIndeces then return (c : acc) else findStr str hdl (0 : newIndeces) (c : acc) So, the question is - can pipes (any package of them) be the Holy Grail in this situation, to both keep simple code and better deal with handles (do not close them specifically)? How? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data structure containing elements which are instances of the same type class
On 12-08-15 03:20 AM, wren ng thornton wrote: (forall a. P(a)) - Q = exists a. (P(a) - Q) For example: A. (forall p. p drinks) - (everyone drinks) B. exists p. ((p drinks) - (everyone drinks)) In a recent poll, 100% of respondents think A true, 90% of them think B paradoxical, and 40% of them have not heard of the Smullyan drinking paradox. Hehe! http://www.vex.net/~trebla/weblog/any-all-some.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Custom QuickCheck Gens without custom shrinks
I wrote this Gen to generate lines of texts without \NUL and \n: fullLinesProp = forAll linesGen ... linesGen = listOf . listOf $ arbitrary `suchThat` (`notElem` ['\NUL', '\n']) -- alternatively: linesGen = arbitrary `suchThat` (all (all (`notElem` ['\NUL', '\n']))) However, I just realized that QuickCheck disables shrinking when I use this instead of (linesGen = arbitrary :: Gen [String]). Why is that? Is there a way to get what I want + shrinking without defining a custom shrink (e.g. forAllShrink)? Thanks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
Hi, folks - I'm sure we are all familiar with the phrase cabal dependency hell at this point, as the number of projects on Hackage that are intended to hack around the problem slowly grows. I am currently undergoing a fresh visit to that unhappy realm, as I try to rebuild some of my packages to see if they work with the GHC 7.6 release candidate. A substantial number of the difficulties I am encountering are related to packages specifying upper bounds on their dependencies. This is a recurrent problem, and its source lies in the recommendations of the PVP itself (problematic phrase highlighted in bold): When publishing a Cabal package, you should ensure that your dependencies in the build-depends field are accurate. This means specifying not only lower bounds, *but also upper bounds* on every dependency. I understand that the intention behind requiring tight upper bounds was good, but in practice this has worked out terribly, leading to depsolver failures that prevent a package from being installed, when everything goes smoothly with the upper bounds relaxed. The default response has been for a flurry of small updates to packages in which the upper bounds are loosened, thus guaranteeing that the problem will recur in a year or less. This is neither sensible, fun, nor sustainable. In practice, when an author bumps a version of a depended-upon package, the changes are almost always either benign, or will lead to compilation failure in the depending-upon package. A benign change will obviously have no visible effect, while a compilation failure is actually *better* than a depsolver failure, because it's more informative. This leaves the nasty-but-in-my-experience-rare case of runtime failures caused by semantic changes. In these instances, a downstream package should *reactively* add an upper bound once a problem is discovered. I propose that the sense of the recommendation around upper bounds in the PVP be reversed: upper bounds should be specified *only when there is a known problem with a new version* of a depended-upon package. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data structure containing elements which are instances of the same type class
In classical logic A - B is the equivalent to ~A v B
(with ~ = not and v = or)
So
(forall a. P(a)) - Q
{implication = not-or}
~(forall a. P(a)) v Q
{forall a. X is equivalent to there does not exist a such that X doesn't
hold}
~(~exists a. ~P(a)) v Q
{double negation elimination}
(exists a. ~P(a)) v Q
{a is not free in Q}
exists a. (~P(a) v Q)
{implication = not-or}
exists a. (P(a) - Q)
These steps are all equivalencies, valid in both directions.
On Wed, Aug 15, 2012 at 9:32 AM, David Feuer david.fe...@gmail.com wrote:
On Aug 15, 2012 3:21 AM, wren ng thornton w...@freegeek.org wrote:
It's even easier than that.
(forall a. P(a)) - Q = exists a. (P(a) - Q)
Where P and Q are metatheoretic/schematic variables. This is just the
usual thing about antecedents being in a negative position, and thus
flipping as you move into/out of that position.
Most of this conversation is going over my head. I can certainly see how
exists a. (P(a)-Q) implies that (forall a. P(a))-Q. The opposite
certainly doesn't hold in classical logic. What sort of logic are you folks
working in?
___
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] Platform Versioning Policy: upper bounds are not our friends
On Wed, Aug 15, 2012 at 12:38 PM, Bryan O'Sullivan b...@serpentine.com wrote: I propose that the sense of the recommendation around upper bounds in the PVP be reversed: upper bounds should be specified only when there is a known problem with a new version of a depended-upon package. This argument precisely captures my feelings on this subject. I will be removing upper bounds next time I make releases of my packages. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On Wed, Aug 15, 2012 at 3:57 PM, Johan Tibell johan.tib...@gmail.comwrote: On Wed, Aug 15, 2012 at 12:38 PM, Bryan O'Sullivan b...@serpentine.com wrote: I propose that the sense of the recommendation around upper bounds in the PVP be reversed: upper bounds should be specified only when there is a known problem with a new version of a depended-upon package. This argument precisely captures my feelings on this subject. I will be removing upper bounds next time I make releases of my packages. So we are certain that the rounds of failures that led to their being *added* will never happen again? -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery allber...@gmail.comwrote: So we are certain that the rounds of failures that led to their being *added* will never happen again? Of course I am sure that problems will arise as a result of recommending that upper bounds be added reactively; didn't I say as much? I expect that to be a much lesser problem than the current situation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery allber...@gmail.com wrote: So we are certain that the rounds of failures that led to their being *added* will never happen again? It would be useful to have some examples of these. I'm not sure we had any when we wrote the policy (but Duncan would know more), but rather reasoned our way to the current policy by saying that things can theoretically break if we don't have upper bounds, therefore we need them. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
Would it make sense to have a known-to-be-stable-though soft upper bound added proactively, and a known-to-break-above hard bound added reactively, so people can loosen gracefully as appropriate? On Aug 15, 2012 1:45 PM, Johan Tibell johan.tib...@gmail.com wrote: On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery allber...@gmail.com wrote: So we are certain that the rounds of failures that led to their being *added* will never happen again? It would be useful to have some examples of these. I'm not sure we had any when we wrote the policy (but Duncan would know more), but rather reasoned our way to the current policy by saying that things can theoretically break if we don't have upper bounds, therefore we need them. -- Johan ___ 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] Platform Versioning Policy: upper bounds are not our friends
On Wed, Aug 15, 2012 at 1:50 PM, David Thomas davidleotho...@gmail.comwrote: Would it make sense to have a known-to-be-stable-though soft upper bound added proactively, and a known-to-break-above hard bound added reactively, so people can loosen gracefully as appropriate? I don't think so. It adds complexity, but more importantly it's usual for the existing upper bounds to refer to versions that don't exist at the time of writing (and hence can't be known to be stable). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
it's usual for the existing upper bounds to refer to versions that don't exist at the time of writing (and hence can't be known to be stable). Well, known to be stable given semantic versioning, then. http://semver.org/ On Wed, Aug 15, 2012 at 1:55 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Wed, Aug 15, 2012 at 1:50 PM, David Thomas davidleotho...@gmail.com wrote: Would it make sense to have a known-to-be-stable-though soft upper bound added proactively, and a known-to-break-above hard bound added reactively, so people can loosen gracefully as appropriate? I don't think so. It adds complexity, but more importantly it's usual for the existing upper bounds to refer to versions that don't exist at the time of writing (and hence can't be known to be stable). ___ 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] Platform Versioning Policy: upper bounds are not our friends
As someone who recurrently is nudging a large number of maintainers every major ghc release to bump their bounds, I favor the no upper bounds approach! :) plus the whole improving ecosystem of build bot tools which play nice with cabal et al that are cropping up mean that in principal we could debug missing upper bounds via sort of temporal bisecting over the event stream of maximum available versions at a given time to sort that. (but that piece isn't that important) more pragmatically, cabal when used with hackage doesn't let you override version constraints, it just lets you add additional constraints. This makes sense if we assume that the library author is saying things will definitely break if you violate them, but in practice upper bounds are made up guesstimation. YES, its presumably semantic versioning doesn't create a problem, but with the hackage eco system, when dealing with intelligently engineering libs that are regularly maintained, version upper bounds create more problems than than solve. just my two cents. (yes yes yes, please drop upper bounds!) cheers -Carter On Wed, Aug 15, 2012 at 5:04 PM, Michael Blume blume.m...@gmail.com wrote: it's usual for the existing upper bounds to refer to versions that don't exist at the time of writing (and hence can't be known to be stable). Well, known to be stable given semantic versioning, then. http://semver.org/ On Wed, Aug 15, 2012 at 1:55 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Wed, Aug 15, 2012 at 1:50 PM, David Thomas davidleotho...@gmail.com wrote: Would it make sense to have a known-to-be-stable-though soft upper bound added proactively, and a known-to-break-above hard bound added reactively, so people can loosen gracefully as appropriate? I don't think so. It adds complexity, but more importantly it's usual for the existing upper bounds to refer to versions that don't exist at the time of writing (and hence can't be known to be stable). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
I definitely agree! http://www.reddit.com/r/haskell/comments/x4knd/what_is_the_reason_for_haskells_cabal_package/ L. On Wed, Aug 15, 2012 at 12:38:33PM -0700, Bryan O'Sullivan wrote: Hi, folks - I'm sure we are all familiar with the phrase cabal dependency hell at this point, as the number of projects on Hackage that are intended to hack around the problem slowly grows. I am currently undergoing a fresh visit to that unhappy realm, as I try to rebuild some of my packages to see if they work with the GHC 7.6 release candidate. A substantial number of the difficulties I am encountering are related to packages specifying upper bounds on their dependencies. This is a recurrent problem, and its source lies in the recommendations of the PVP itself (problematic phrase highlighted in bold): When publishing a Cabal package, you should ensure that your dependencies in the build-depends field are accurate. This means specifying not only lower bounds, but also upper bounds on every dependency. I understand that the intention behind requiring tight upper bounds was good, but in practice this has worked out terribly, leading to depsolver failures that prevent a package from being installed, when everything goes smoothly with the upper bounds relaxed. The default response has been for a flurry of small updates to packages in which the upper bounds are loosened, thus guaranteeing that the problem will recur in a year or less. This is neither sensible, fun, nor sustainable. In practice, when an author bumps a version of a depended-upon package, the changes are almost always either benign, or will lead to compilation failure in the depending-upon package. A benign change will obviously have no visible effect, while a compilation failure is actually better than a depsolver failure, because it's more informative. This leaves the nasty-but-in-my-experience-rare case of runtime failures caused by semantic changes. In these instances, a downstream package should reactively add an upper bound once a problem is discovered. I propose that the sense of the recommendation around upper bounds in the PVP be reversed: upper bounds should be specified only when there is a known problem with a new version of a depended-upon package. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Lorenzo Bolla http://lbolla.info ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On Wed, Aug 15, 2012 at 4:44 PM, Johan Tibell johan.tib...@gmail.comwrote: On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery allber...@gmail.com wrote: So we are certain that the rounds of failures that led to their being *added* will never happen again? It would be useful to have some examples of these. I'm not sure we had Upper package versions did not originally exist, and nobody wanted them. You can see the result in at least half the packages on Hackage: upper versions came in when base got broken up, and when bytestring was merged into base --- both of which caused massive breakage that apparently even the people around at the time and involved with it no longer remember. I'm not going to argue the point though; ignore history and remove them if you desire. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
no one is disputing that there are conditional changes in dependencies depending on library versions. an interesting intermediate point would be have a notion of testing with constraints in cabal and engineering cabal to support a --withTestedConstraints to have a simple composable way of handling constructing build plans. at the end of the day, its an engineering problem coupled with a social factors problem. Those are hard :) On Wed, Aug 15, 2012 at 5:44 PM, Brandon Allbery allber...@gmail.comwrote: On Wed, Aug 15, 2012 at 4:44 PM, Johan Tibell johan.tib...@gmail.comwrote: On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery allber...@gmail.com wrote: So we are certain that the rounds of failures that led to their being *added* will never happen again? It would be useful to have some examples of these. I'm not sure we had Upper package versions did not originally exist, and nobody wanted them. You can see the result in at least half the packages on Hackage: upper versions came in when base got broken up, and when bytestring was merged into base --- both of which caused massive breakage that apparently even the people around at the time and involved with it no longer remember. I'm not going to argue the point though; ignore history and remove them if you desire. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ 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] Platform Versioning Policy: upper bounds are not our friends
Upper bounds are a bit of a catch-22 when it comes to library authors evolving their APIs: 1) If library clients aren't encouraged to specify which version of the exported API they target, then changing APIs can lead to opaque compile errors (without any information about which API is intended). This could lead the client to need to search for the appropriate version of the library. If library clients are encouraged to specify which versions of the exported API they target, then changing the API breaks all of the clients. There are a couple of hacky ways to do #1 without having the errors be so opaque 1) Start a tradition of commenting the cabal dependencies with the version of the package that worked for the author. 2) Build in support for these known good versions into cabal, perhaps generated on sdistrelease, or with a particular build flag. (they don't need to be stored in the .cabal file) 3) Attempt to post-process GHC error messages to guess when the issue might be caused by the package version being different according to the PVP. This could work alright for scoping but wouldn't work well for type errors (which matter more) I like the idea of doing automated upper-bound-determination! That would be very convenient. It's a bit tricky though - should tests be included? I think the most ideal solution is to attack the core problem: things break when dependencies change their interface. This is pretty expected in the development world at large, but I think that Haskell can do better. The main idea is that package developers should be free to update their API as they realize that new names or interfaces are better. Currently there's the problem that the APIs that actually get used subsequently stagnate due to fear of breakage. The solution that I think makes the most sense is to start exporting modules which express the old interface in terms of the new. What's interesting about this is that most non-semantic changes to things other than ADTs and typeclasses can already be expressed in plain Haskell code. This idea, among other things, inspired the instance templates proposal, which is somewhat related to superclass default instances. With this language extension, it would be possible to express compatibility layers for instance definitions, something that is impossible with Superclass Default Instances. https://github.com/mgsloan/instance-templates I've also got a start on a utility for extracting API signatures from packages. Currently it just pretty prints the API in a fashion that attempts to be amenable to textual diffing: https://github.com/mgsloan/api-compat/ https://github.com/mgsloan/api-compat/blob/master/examples/diagrams-core.api.diff The intent is to make the tool interactive, giving the user a chance to let the tool know which exports / modules have been renamed. After the user provides this information, it should be possible to generate almost all of the compatibility code. In order to make it convenient to use these compatibility modules, we'd want to have some cabal- invoked code generation that would generate proxy modules that re-export the appropriate version. This could all happen in a separate hs-source-dir. The next step in this toolchain is something that's very hard to do nicely, because it can change code layout: automated rewriting of user code to target the new version (this is equivalent to inlining the compatibility module definitions). However, even a tool that would take you to all of the places that need changing would be invaluable. Wouldn't it be excellent, if the Haskell eco-system managed something that no other language affords?: * Automatic refactoring to target new API versions * Expression of these refactorings in the language itself * Rigorous, structured documentation of inter-version changes. This'd also provide a nice place to put haddocks with further change information. -Michael On Wed, Aug 15, 2012 at 2:34 PM, Carter Schonwald carter.schonw...@gmail.com wrote: As someone who recurrently is nudging a large number of maintainers every major ghc release to bump their bounds, I favor the no upper bounds approach! :) plus the whole improving ecosystem of build bot tools which play nice with cabal et al that are cropping up mean that in principal we could debug missing upper bounds via sort of temporal bisecting over the event stream of maximum available versions at a given time to sort that. (but that piece isn't that important) more pragmatically, cabal when used with hackage doesn't let you override version constraints, it just lets you add additional constraints. This makes sense if we assume that the library author is saying things will definitely break if you violate them, but in practice upper bounds are made up guesstimation. YES, its presumably semantic versioning doesn't create a problem, but with the hackage eco system, when dealing with intelligently engineering
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On Wed, Aug 15, 2012 at 6:46 PM, Carter Schonwald carter.schonw...@gmail.com wrote: no one is disputing that there are conditional changes in dependencies depending on library versions. Indeed. But the ghc release that split up base broke cabalised packages with no warning to users until they failed to compile. Upper bounds were put in place to avoid that kind of breakage in the future. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data structure containing elements which are instances of the same type class
I understand this now, though I still don't understand the context. Thanks!
I managed to mix up implication with causation, to my great embarrassment.
On Aug 15, 2012 3:39 PM, Ryan Ingram ryani.s...@gmail.com wrote:
In classical logic A - B is the equivalent to ~A v B
(with ~ = not and v = or)
So
(forall a. P(a)) - Q
{implication = not-or}
~(forall a. P(a)) v Q
{forall a. X is equivalent to there does not exist a such that X doesn't
hold}
~(~exists a. ~P(a)) v Q
{double negation elimination}
(exists a. ~P(a)) v Q
{a is not free in Q}
exists a. (~P(a) v Q)
{implication = not-or}
exists a. (P(a) - Q)
These steps are all equivalencies, valid in both directions.
On Wed, Aug 15, 2012 at 9:32 AM, David Feuer david.fe...@gmail.comwrote:
On Aug 15, 2012 3:21 AM, wren ng thornton w...@freegeek.org wrote:
It's even easier than that.
(forall a. P(a)) - Q = exists a. (P(a) - Q)
Where P and Q are metatheoretic/schematic variables. This is just the
usual thing about antecedents being in a negative position, and thus
flipping as you move into/out of that position.
Most of this conversation is going over my head. I can certainly see how
exists a. (P(a)-Q) implies that (forall a. P(a))-Q. The opposite
certainly doesn't hold in classical logic. What sort of logic are you folks
working in?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 240
Welcome to issue 240 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the week of August 05 to 11, 2012. Quotes of the Week * johnw: Monads are an interface, all bets are off until you see what the interface does for a given Type * Evbn: I heard that Untyped and Well Typed tried to set up a corporate softball league, but they couldn't agree on a ruleset to use. * wuttf: i think i have to learn this language, the type systems i know just dont feel right Top Reddit Stories * Studying protein structures in Haskell Domain: haskellforall.com, Score: 53, Comments: 6 On Reddit: [1] http://goo.gl/94PA4 Original: [2] http://goo.gl/VJJD0 * Haskell Live Episode 2: Time To Refactor is up! Domain: youtube.com, Score: 52, Comments: 14 On Reddit: [3] http://goo.gl/BOmK7 Original: [4] http://goo.gl/5wTVu * Announcing Raskell - user ratings for Hackage Domain: ocharles.org.uk, Score: 43, Comments: 29 On Reddit: [5] http://goo.gl/wgK4E Original: [6] http://goo.gl/7q4RP * Yesod 1.1 Released Domain: yesodweb.com, Score: 38, Comments: 14 On Reddit: [7] http://goo.gl/jiwLx Original: [8] http://goo.gl/B5czq * Running Haskell on Raspberry Pi Domain: alenribic.com, Score: 37, Comments: 5 On Reddit: [9] http://goo.gl/zPcDA Original: [10] http://goo.gl/FsESS * Koka - a function-oriented language with side-effect inteference Domain: rise4fun.com, Score: 36, Comments: 18 On Reddit: [11] http://goo.gl/lyKhA Original: [12] http://goo.gl/n35n1 * Is Haskell liberal or conservative? (Response post to Yegge) Domain: blog.ezyang.com, Score: 34, Comments: 51 On Reddit: [13] http://goo.gl/AJ5Wp Original: [14] http://goo.gl/Juis3 * ANNOUNCE: basic-prelude Domain: haskell.org, Score: 34, Comments: 8 On Reddit: [15] http://goo.gl/iiDLq Original: [16] http://goo.gl/4Taz0 * ANNOUNCE: tardis Domain: haskell.org, Score: 31, Comments: 3 On Reddit: [17] http://goo.gl/e6yi7 Original: [18] http://goo.gl/590QR * Any Hackage mirrors? How do you deal with Hackage outages? Domain: self.haskell, Score: 30, Comments: 27 On Reddit: [19] http://goo.gl/1BOMF Original: [20] http://goo.gl/1BOMF * Is there a standard Haskell development setup for Vim? Domain: self.haskell, Score: 29, Comments: 44 On Reddit: [21] http://goo.gl/gSRWp Original: [22] http://goo.gl/gSRWp * O'Reilly Webinar this Thursday: Designing Type-Safe Haskell APIs Domain: yesodweb.com, Score: 28, Comments: 8 On Reddit: [23] http://goo.gl/GNogN Original: [24] http://goo.gl/ZRkrH * acid-state with Yesod Domain: meadowstalk.com, Score: 25, Comments: 13 On Reddit: [25] http://goo.gl/NM4Bc Original: [26] http://goo.gl/8MDXo * Philip Wadler: Faith, Evolution, and Programming Languages [InfoQ] Domain: infoq.com, Score: 25, Comments: 6 On Reddit: [27] http://goo.gl/WFxLq Original: [28] http://goo.gl/fBqx7 * Hiring Haskell Developers (Singapore) Domain: cufp.org, Score: 22, Comments: 13 On Reddit: [29] http://goo.gl/bhqrb Original: [30] http://goo.gl/umhh4 * Verifying Software Transactional Memory: bisimulation in Agda [pdf] Domain: cs.nott.ac.uk, Score: 22, Comments: On Reddit: [31] http://goo.gl/X1zvj Original: [32] http://goo.gl/vJ1gA * iterate (*2) 1 Domain: postimage.org, Score: 17, Comments: 13 On Reddit: [33] http://goo.gl/lwLv1 Original: [34] http://goo.gl/lfIab * Error Handling: How would you solve this? Domain: self.haskell, Score: 16, Comments: 11 On Reddit: [35] http://goo.gl/jHLZ8 Original: [36] http://goo.gl/jHLZ8 Top StackOverflow Questions * Advice defining a data structure in Haskell votes: 13, answers: 4 Read on SO: [37] http://goo.gl/xVxlx * What is the preferred way to combine two sinks? votes: 13, answers: 2 Read on SO: [38] http://goo.gl/QUczW * Why is numCapabilities a pure function? votes: 12, answers: 1 Read on SO: [39] http://goo.gl/4HU27 * Using generics to convert between types of the same “shape” votes: 10, answers: 1 Read on SO: [40] http://goo.gl/gx8ZL * Controlling parallel execution votes: 9, answers: 2 Read on SO: [41] http://goo.gl/zzvtU * Lists of lists of lists votes: 9, answers: 5 Read on SO: [42] http://goo.gl/HEicW * Positive integer type votes: 8, answers: 5 Read on SO: [43] http://goo.gl/xXY49 * Haskell bit arrays votes: 7, answers: 1 Read on SO: [44] http://goo.gl/g9TDQ * How to keep track of number of guesses in a simple guessing game (Haskell) votes: 6, answers: 2 Read on SO: [45] http://goo.gl/VQaWn * A haskell program that controls the mouse votes: 5, answers: 1 Read on SO: [46]
Re: [Haskell-cafe] Custom QuickCheck Gens without custom shrinks
Oh, this is silly. Of course it is: forAllShrink linesGen shrink ... On 15/08/12 20:35, Niklas Hambüchen wrote: I wrote this Gen to generate lines of texts without \NUL and \n: fullLinesProp = forAll linesGen ... linesGen = listOf . listOf $ arbitrary `suchThat` (`notElem` ['\NUL', '\n']) -- alternatively: linesGen = arbitrary `suchThat` (all (all (`notElem` ['\NUL', '\n']))) However, I just realized that QuickCheck disables shrinking when I use this instead of (linesGen = arbitrary :: Gen [String]). Why is that? Is there a way to get what I want + shrinking without defining a custom shrink (e.g. forAllShrink)? Thanks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On 16 August 2012 08:55, Brandon Allbery allber...@gmail.com wrote: On Wed, Aug 15, 2012 at 6:46 PM, Carter Schonwald carter.schonw...@gmail.com wrote: no one is disputing that there are conditional changes in dependencies depending on library versions. Indeed. But the ghc release that split up base broke cabalised packages with no warning to users until they failed to compile. Upper bounds were put in place to avoid that kind of breakage in the future. There's also the case where people blindly put something like base 10 in the .cabal file, and then it broke on the next GHC release. This happend with ghc-core-0.5: it completely failed to build with base-4 (and because cabal-install kept defaulting packages to use base-3 I think a lot of people missed cases like this and blindly thought it worked). I like having upper bounds on version numbers... right up until people abuse them. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Does someone have a compiled binary of the LLVM for Windows 7 or must one compile the source?
I just want to get started on some matrix operations with REPA. Or is there a library (package?) like REPA without using the LLVM? -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does someone have a compiled binary of the LLVM for Windows 7 or must one compile the source?
On 16 August 2012 11:21, KC kc1...@gmail.com wrote: I just want to get started on some matrix operations with REPA. Or is there a library (package?) like REPA without using the LLVM? If you're referring to your recent problems with repa-algorithms, you can try this: cabal unpack repa-algorithms # Not sure of the syntax for changing directories in the cmd.exe terminal cd repa-algorithms-version # Use a text editor to remove the line -fllvm from the .cabal file cabal install -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On 16 August 2012 03:38, Bryan O'Sullivan b...@serpentine.com wrote: Hi, folks - I'm sure we are all familiar with the phrase cabal dependency hell at this point, as the number of projects on Hackage that are intended to hack around the problem slowly grows. I am currently undergoing a fresh visit to that unhappy realm, as I try to rebuild some of my packages to see if they work with the GHC 7.6 release candidate. Likewise ... A substantial number of the difficulties I am encountering are related to packages specifying upper bounds on their dependencies. This is a recurrent problem, and its source lies in the recommendations of the PVP itself (problematic phrase highlighted in bold): I think part of the problem might be that some packages (like bytestring, transformers?) have had their major version number incremented even despite being backwards-compatible. Perhaps there are incompatible changes, but most of the cabal churn I've seen recently has involved incrementing the bytestring upper bound to 0.11 without requiring any code changes to modules using Data.ByteString. IMO it'd be better to include a separate versioning entry like libtool's version-info, consisting of Current:Revision:Age (http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html), and leave the published version for human, marketing purposes. I remember discussing this with Duncan at ICFP last year, and he suggested that the existing PVP is equivalent to the libtool scheme in that the major release should only be incremented if backwards-compatibility breaks. However I think people also expect to use the published version as a kind of marketing, to indicate that the project has reached some milestone or stability, or is part of some larger, separately versioned group of packages (eg. new compiler or platform release). The PVP pretty much ensures that incrementing a major version for such reasons is going to break your package for all its users. Conrad. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On Wed, Aug 15, 2012 at 9:19 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 16 August 2012 08:55, Brandon Allbery allber...@gmail.com wrote: Indeed. But the ghc release that split up base broke cabalised packages with no warning to users until they failed to compile. Upper bounds were put in place to avoid that kind of breakage in the future. I like having upper bounds on version numbers... right up until people abuse them. I also tend to favor having upper bounds. Obviously they impose a cost, but it's not clear to me at all that getting rid of them is a better tradeoff. I've had projects that I put aside for awhile only to come back and discover that they would no longer build because I hadn't put upper bounds on all my package dependencies. With no upper bounds, a package might not be very likely to break for incremental version bumps, but eventually it *will* break. And when it does it's a huge pain to get it building again. If I have put effort into making a specific version of my package work properly today, I want it to always work properly in the future (assuming that everyone obeys the PVP). I don't think it's unreasonable that some activation energy be required to allow one's project to work with a new version of some upstream dependency. Is that activation energy too high right now? Almost definitely. But that's a tool problem, not a problem with the existence of upper bounds themselves. One tool-based way to help with this problem would be to add a flag to Cabal/cabal-install that would cause it to ignore upper bounds. (Frankly, I think it would also be great if Cabal/cabal-install enforced upper version bounds automatically if none were specified.) Another approach that has been discussed is detecting dependencies that are only used internally[1], and I'm sure there are many other possibilities. In short, I think we should be moving more towards purely functional builds that reduce the chance that external factors will break things, and it seems like removing upper version bounds is a step in the other direction. [1] http://cdsmith.wordpress.com/2011/01/21/a-recap-about-cabal-and-haskell-libraries/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On Wed, Aug 15, 2012 at 11:02 PM, MightyByte mightyb...@gmail.com wrote: be to add a flag to Cabal/cabal-install that would cause it to ignore upper bounds. (Frankly, I think it would also be great if Ignore, or at least treat them as being like flags... if the versions don't converge with them, start relaxing them and retrying, then print a warning about the versions it slipped and attempt the build. That said, I'd be in favor of moving toward something based on ABI versioning instead; package versions as used by the PVP are basically a manual switch emulating that. It's not generally done because other parts of the toolchain (notably ld's shared object versioning) don't support it, but given that Cabal has greater control over the build process for Haskell programs it would be worth exploring having Cabal deal with it. (This is not something you can do with existing C or C++ toolchains; the smarts would need to be in make.) -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On Thu, Aug 16, 2012 at 5:38 AM, Conrad Parker con...@metadecks.org wrote: On 16 August 2012 03:38, Bryan O'Sullivan b...@serpentine.com wrote: Hi, folks - I'm sure we are all familiar with the phrase cabal dependency hell at this point, as the number of projects on Hackage that are intended to hack around the problem slowly grows. I am currently undergoing a fresh visit to that unhappy realm, as I try to rebuild some of my packages to see if they work with the GHC 7.6 release candidate. Likewise ... A substantial number of the difficulties I am encountering are related to packages specifying upper bounds on their dependencies. This is a recurrent problem, and its source lies in the recommendations of the PVP itself (problematic phrase highlighted in bold): I think part of the problem might be that some packages (like bytestring, transformers?) have had their major version number incremented even despite being backwards-compatible. Perhaps there are incompatible changes, but most of the cabal churn I've seen recently has involved incrementing the bytestring upper bound to 0.11 without requiring any code changes to modules using Data.ByteString. In general, I've been taking the approach recently that we have two classes of packages: some (like transformers and bytestring) have mostly-stable APIs, and most code I write only relies on those APIs. If I'm just using Data.ByteString for the ByteString type and a few functions like readFile and map, it's highly unlikely that the next version will introduce some breaking change. In those cases, I've been leaving off the upper bound entirely. For other packages that haven't yet stabilized, I've still been keeping the upper bound. In many cases, even that isn't necessary. I've tried removing the upper bounds on those as well, but I almost always end up getting someone filing a bug report that I left off some upper bound and therefore a compile failed. I agree with Bryan's argument, but I'd like to keep consistency for most packages on Hackage. If the community goes in this direction, I'll go along too. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
