Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On Thu, Aug 16, 2012 at 11:33:17PM -0400, wren ng thornton wrote: However, there are certainly cases where we have hard upper bounds[1][2][3], and ignoring those is not fine. Circumventing hard upper bounds should require altering the .cabal file, given as getting things to compile will require altering the source code as well. It's ok to have soft and hard upper bounds, but it should be always possible to ignore both - having a separate ignore option for each - without modifying the cabal file. I've the confidence, that most cabal users should be able to handle this. Nothing is more annoying if you know what you're doing, but don't have the power to do it. Greetings, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] phantom types
Hi, I am currently reading documentation on Generalized Algebraic Data Types: http://en.wikibooks.org/wiki/Haskell/GADT I have a question concerning this page. Let us consider the following code proposed in the page: -- -- Phantom type variable a (does not appear in any Expr: it is just a -- dummy variable). data Expr a = I Int | B Bool | Add (Expr a) (Expr a) | Mul (Expr a) (Expr a) | Eq (Expr a) (Expr a) deriving (Show) -- Smart constructors add :: Expr Int - Expr Int - Expr Int add = Add i :: Int - Expr Int i = I b :: Bool - Expr Bool b = B eval :: Expr a - a eval (I n) = n -- I obtain the following error: Phantom.hs:27:14: Couldn't match type `a' with `Int' `a' is a rigid type variable bound by the type signature for eval :: Expr a - a at Phantom.hs:27:1 In the expression: n In an equation for `eval': eval (I n) = n The wiki page explains: But alas, this does not work: how would the compiler know that encountering the constructor I means that a = Int? I don't understand. When we write eval (I n) = n, as I is a constructor which takes an Int as argument, we are able to deduce that the type of n is Int; so the type of eval should be in this case Expr Int - Int. What do I miss? Thanks, TP___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to simplify the code of Maybe within a monad?
On 17 августа 2012 11:48:54 Magicloud Magiclouds wrote:
But how if here maybe[ABC] are like 'IO (Maybe Int)', or foo is type
of 'Int - IO Int'?
Maybe you can help monad transformers and MaybeT? They help you write code
like 'MaybeT f1 MaybeT f2 MaybeT f3 where { f1, f2, f3 :: IO (Maybe Int)
}'.___
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
Brent Yorgey wrote: Yitzchak Gale wrote: For actively maintained packages, I think the problem is that package maintainers don't find out promptly that an upper bound needs to be bumped. One way to solve that would be a simple bot that notifies the package maintainer as soon as an upper bound becomes out-of-date. This already exists: http://packdeps.haskellers.com/ Indeed. It even has RSS feeds, like this http://packdeps.haskellers.com/feed/reactive-banana Extremely useful! Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] phantom types
Hi, I am currently reading documentation on Generalized Algebraic Data Types: http://en.wikibooks.org/wiki/Haskell/GADT I have a question concerning this page. Let us consider the following code proposed in the page: -- -- Phantom type variable a (does not appear in any Expr: it is just a -- dummy variable). data Expr a = I Int | B Bool | Add (Expr a) (Expr a) | Mul (Expr a) (Expr a) | Eq (Expr a) (Expr a) deriving (Show) -- Smart constructors add :: Expr Int - Expr Int - Expr Int add = Add i :: Int - Expr Int i = I b :: Bool - Expr Bool b = B eval :: Expr a - a eval (I n) = n -- I obtain the following error: Phantom.hs:27:14: Couldn't match type `a' with `Int' `a' is a rigid type variable bound by the type signature for eval :: Expr a - a at Phantom.hs:27:1 In the expression: n In an equation for `eval': eval (I n) = n The wiki page explains: But alas, this does not work: how would the compiler know that encountering the constructor I means that a = Int? I don't understand. When we write eval (I n) = n, as I is a constructor which takes an Int as argument, we are able to deduce that the type of n is Int; so the type of eval should be in this case Expr Int - Int. What do I miss? Since the example uses phantom types, the type of n is not actually related to the type of (I n). It is perfectly possible to have, for example, a value of type Expr String created by the I constructor: *Main let expr = I 5 :: Expr String *Main expr I 5 *Main :t expr expr :: Expr String So if we define eval the way it is defined in the example, the compiler cannot infer that the type of (I n) is Expr Int, even though it knows that n's type is Int. We could prevent the creation of values with the wrong types by only exporting the smart constructors, but that is no help for the type system. Declaring eval as Expr Int - Int would make the code compile, but since eval should presumably include patterns for other types, such as eval (B b) = b which would have to be of type Expr Bool - Bool, we cannot do that. I hope I did not misunderstand your question and this helps. Cheers, Florian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 108, Issue 22
I have one unbearable doubt, how do you accent CoCoCo? CóCoCo? CoCóCo? CoCoCó? Facundo Date: Thu, 16 Aug 2012 21:40:28 +0200 From: Doaitse Swierstra doai...@swierstra.net Subject: [Haskell-cafe] [Announce] Compositional Compiler Construction, Oberon0 examples available To: haskell-cafe@haskell.org Cafe haskell-cafe@haskell.org, Haskell List hask...@haskell.org Message-ID: 3b4b9ffc-b1bb-4156-be80-5e60632ee...@swierstra.net Content-Type: text/plain; charset=us-ascii Over the years we have been constructing a collection of Embedded Domain Specific Languages for describing compilers which are assembled from fragments which can be compiled individuallu. In this way one can gradually ``grow a langauge'' in a large number of small steps. The technique replaces things like macro extensions or Template Haskell; it has become feasable to just extend the language at hand by providing extra modules. The nice thing is that existing code does not have to be adapted, nor has to be available nor has to be recompiled. Recently we have been using (and adapting) the frameworks such that we could create an entry in the ldta11 (http://ldta.info/tool.html) tool challenge, where one has to show how one's tools can be used to create a compiler for the Oberon0 language, which is used a a running example in Wirth's compiler construction book. We have uploaded our implementation to hackage at: http://hackage.haskell.org/package/oberon0. More information can be found at the wiki: http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo You may take a look at the various Gram modules to see how syntax is being defined, and at the various Sem modules to see how we use our first class attribute grammars to implement the static semantics associated with the various tasks of the challenge. We hope you like it, and comments are welcome, Marcos Viera Doaitse Swierstra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Announce] Compositional Compiler Construction, Oberon0 examples available
Sorry, fixed the subject. On Fri, Aug 17, 2012 at 11:11 AM, Facundo Domínguez facundoming...@gmail.com wrote: I have one unbearable doubt, how do you accent CoCoCo? CóCoCo? CoCóCo? CoCoCó? Facundo Date: Thu, 16 Aug 2012 21:40:28 +0200 From: Doaitse Swierstra doai...@swierstra.net Subject: [Haskell-cafe] [Announce] Compositional Compiler Construction, Oberon0 examples available To: haskell-cafe@haskell.org Cafe haskell-cafe@haskell.org, Haskell List hask...@haskell.org Message-ID: 3b4b9ffc-b1bb-4156-be80-5e60632ee...@swierstra.net Content-Type: text/plain; charset=us-ascii Over the years we have been constructing a collection of Embedded Domain Specific Languages for describing compilers which are assembled from fragments which can be compiled individuallu. In this way one can gradually ``grow a langauge'' in a large number of small steps. The technique replaces things like macro extensions or Template Haskell; it has become feasable to just extend the language at hand by providing extra modules. The nice thing is that existing code does not have to be adapted, nor has to be available nor has to be recompiled. Recently we have been using (and adapting) the frameworks such that we could create an entry in the ldta11 (http://ldta.info/tool.html) tool challenge, where one has to show how one's tools can be used to create a compiler for the Oberon0 language, which is used a a running example in Wirth's compiler construction book. We have uploaded our implementation to hackage at: http://hackage.haskell.org/package/oberon0. More information can be found at the wiki: http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo You may take a look at the various Gram modules to see how syntax is being defined, and at the various Sem modules to see how we use our first class attribute grammars to implement the static semantics associated with the various tasks of the challenge. We hope you like it, and comments are welcome, Marcos Viera Doaitse Swierstra ___ 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
My thoughts on the matter got a little long, so I posted them here: http://nominolo.blogspot.co.uk/2012/08/beyond-package-version-policies.html On 17 August 2012 12:48, Heinrich Apfelmus apfel...@quantentunnel.dewrote: Brent Yorgey wrote: Yitzchak Gale wrote: For actively maintained packages, I think the problem is that package maintainers don't find out promptly that an upper bound needs to be bumped. One way to solve that would be a simple bot that notifies the package maintainer as soon as an upper bound becomes out-of-date. This already exists: http://packdeps.haskellers.**com/ http://packdeps.haskellers.com/ Indeed. It even has RSS feeds, like this http://packdeps.haskellers.**com/feed/reactive-bananahttp://packdeps.haskellers.com/feed/reactive-banana Extremely useful! Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. ___ 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 see good arguments on both sides of the upper bounds debate, though at the current time I think the best solution is to omit upper bounds (and I have done so for most/all of my packages on hackage).But I cannot agree with this enough: On Thu, Aug 16, 2012 at 4:45 AM, Joachim Breitner m...@joachim-breitner.dewrote: I think what we’d need is a more relaxed policy with modifying a package’s meta data on hackage. What if hackage would allow uploading a new package with the same version number, as long as it is identical up to an extended version range? Then the first person who stumbles over an upper bound that turned out to be too tight can just fix it and upload the fixed package directly, without waiting for the author to react. I think that constraint ranges of a given package should be able to both be extended and restricted after the fact. Those in favor of the reactionary approach (as I am at the moment, or Bryan O'Sullivan) would find the ability of to restrict the version range useful, while those in favor of the proactive approach (like Joachim Breitner or Doug Beardsley) would find the ability to extend the version range useful. I suspect that attitudes towards upper bounds may well change if we can set version ranges after the fact.I know mine very well might.And the difference between reactionary and proactive approaches I think is a potential justification for the hard and soft upper bounds; perhaps we should instead call them reactionary and proactive upper bounds instead. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] phantom types
First, thanks for your answer. On Friday, August 17, 2012 15:31:32 you wrote: So if we define eval the way it is defined in the example, the compiler cannot infer that the type of (I n) is Expr Int, even though it knows that n's type is Int. I think that my problem came from the fact that I have misunderstood type variables. We have seen that the function eval: eval :: Expr a - a eval (I n) = n yields a compilation error: Phantom.hs:37:14: Couldn't match type `a' with `Int' `a' is a rigid type variable bound by the type signature for eval :: Expr a - a A somewhat similar error is found at http://stackoverflow.com/questions/4629883/rigid-type-variable-error test :: Show s = s test = asdasd yields a compilation error: Could not deduce (s ~ [Char]) from the context (Show s) bound by the type signature for test :: Show s = s at Phantom.hs:40:1-15 `s' is a rigid type variable bound by the type signature for test :: Show s = s Both errors contain the expression rigid type variable. The explanation in the Stack Overflow page made me understand my error: test :: Show s = s means for any type s which is an instance of Show, test is a value of that type s. Something like test :: Num a = a; test = 42 works because 42 can be a value of type Int or Integer or Float or anything else that is an instance of Num. However asdasd can't be an Int or anything else that is an instance of Show - it can only ever be a String. As a consequence it does not match the type Show s = s. The compiler does not say: «s is of type String because the return type of test is a String». Identically, in our case, «eval :: Expr a - a» means «for any type a, eval takes a value of type «Expr a» as input, and outputs a value of type a». Analogously to the above case, the compiler does not say «a is of type Int, because n is of type Int». The problem here is that (I n) does not allow to know the type of a. It may be of type Expr String as you have shown: *Main let expr = I 5 :: Expr String *Main expr I 5 *Main :t expr expr :: Expr String So we may have anything for «a» in «Expr a» input type of eval. These multiplicity of values for «a» cannot match the output type of the equation «eval (I n) = n» which is an Int. Thus we get an error. Am I correct? Thanks, TP ___ 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
What if instead of upper (and lower) bounds we just specify our interface requirements? Like package bull-shit should provide value Foo.Bar.baz :: forall a. [a] - [a] - [a] or more general. Sure, it won't help dealing with strictness/lazyness, but it would capture most interface differences. And, in case the requirements aren't specified, we could also specify the default, like bool-shit 2.0 is known to fulfil this requirement; if yours doesn't, consider installing this one. On Aug 17, 2012, at 7:28 PM, Leon Smith leon.p.sm...@gmail.com wrote: I see good arguments on both sides of the upper bounds debate, though at the current time I think the best solution is to omit upper bounds (and I have done so for most/all of my packages on hackage).But I cannot agree with this enough: On Thu, Aug 16, 2012 at 4:45 AM, Joachim Breitner m...@joachim-breitner.de wrote: I think what we’d need is a more relaxed policy with modifying a package’s meta data on hackage. What if hackage would allow uploading a new package with the same version number, as long as it is identical up to an extended version range? Then the first person who stumbles over an upper bound that turned out to be too tight can just fix it and upload the fixed package directly, without waiting for the author to react. I think that constraint ranges of a given package should be able to both be extended and restricted after the fact. Those in favor of the reactionary approach (as I am at the moment, or Bryan O'Sullivan) would find the ability of to restrict the version range useful, while those in favor of the proactive approach (like Joachim Breitner or Doug Beardsley) would find the ability to extend the version range useful. I suspect that attitudes towards upper bounds may well change if we can set version ranges after the fact.I know mine very well might.And the difference between reactionary and proactive approaches I think is a potential justification for the hard and soft upper bounds; perhaps we should instead call them reactionary and proactive upper bounds instead. ___ 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 Fri, Aug 17, 2012 at 12:34 PM, MigMit miguelim...@yandex.ru wrote: What if instead of upper (and lower) bounds we just specify our interface requirements? We already have a simple versioning scheme for which, despite it being easy to grasp, we have amply demonstrated that we cannot make it work well, because it has emergent properties that cause it to not scale well across a large community. Any vastly more complicated and detailed versioning scheme has a huge burden to prove that it won't collapse dramatically more quickly. (Frankly, I think that anything involving specify every detail of your known dependencies is dead on arrival from a practical standpoint: it's way too much work.) For that matter, I think that this burden applies to my own proposal to omit upper bounds unless they're needed. Fortunately, we now have several years of historical dependency data that we can go back and mine, and thereby try to model the effects of particular suggested changes. ___ 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 Aug 18, 2012, at 12:35 AM, Bryan O'Sullivan b...@serpentine.com wrote: We already have a simple versioning scheme for which, despite it being easy to grasp, we have amply demonstrated that we cannot make it work well, because it has emergent properties that cause it to not scale well across a large community. Well, I think that the main reason for this failure is that despite being easy to grasp, this scheme doesn't really reflect the reality. It seems to be chosen arbitrarily. Any vastly more complicated and detailed versioning scheme has a huge burden to prove that it won't collapse dramatically more quickly. (Frankly, I think that anything involving specify every detail of your known dependencies is dead on arrival from a practical standpoint: it's way too much work.) That's not true. All this work can be automated — if you're the developer, you've certainly compiled the code yourself, and the compiler knows what was imported from other packages. The only problem is to make it save this information into a specific file. ___ 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 Fri, Aug 17, 2012 at 4:35 PM, Bryan O'Sullivan b...@serpentine.comwrote: Any vastly more complicated and detailed versioning scheme has a huge burden to prove that it won't collapse dramatically more quickly. (Frankly, I think that anything involving specify every detail of your known dependencies is dead on arrival from a practical standpoint: it's way too much work.) If you do it in terms of hashed signatures, you can make the compiler and toolchain do the work for you. The problem with version numbers is that it *is* manual. It can't catch behavioral changes, though; you probably need some kind of epoch override for that in the case where it doesn't come with corresponding API changes. The reason it's never done is that you can't really do it with C or C++. We can mostly avoid that (the FFI is an issue, but it is anyway: cabal can't really check C stuff, unless you use pkg-config which was two operating modes: exact versions or no versioning). -- 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
I agree that Haskell's design gives us a good leg up on the problem of acquiring and comparing APIs. However, I don't think that this manifest solution really buys us enough to justify the complexity. There're also some specific, perhaps resolvable, but unsightly problems, which I outline here: http://www.reddit.com/r/haskell/comments/ydtl9/beyond_package_version_policies/c5uro04 (also another pitch for my proposed solution to this variety of problems) -mgsloan On Fri, Aug 17, 2012 at 2:34 PM, Brandon Allbery allber...@gmail.com wrote: On Fri, Aug 17, 2012 at 4:35 PM, Bryan O'Sullivan b...@serpentine.com wrote: Any vastly more complicated and detailed versioning scheme has a huge burden to prove that it won't collapse dramatically more quickly. (Frankly, I think that anything involving specify every detail of your known dependencies is dead on arrival from a practical standpoint: it's way too much work.) If you do it in terms of hashed signatures, you can make the compiler and toolchain do the work for you. The problem with version numbers is that it *is* manual. It can't catch behavioral changes, though; you probably need some kind of epoch override for that in the case where it doesn't come with corresponding API changes. The reason it's never done is that you can't really do it with C or C++. We can mostly avoid that (the FFI is an issue, but it is anyway: cabal can't really check C stuff, unless you use pkg-config which was two operating modes: exact versions or no versioning). -- 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
On 8/16/12 11:33 PM, wren ng thornton wrote: [1] Parsec 2 vs 3, for a very long time [2] mtl 1 vs 2, for a brief interim [3] John Lato's iteratee =0.3 vs =0.4, for legacy code ... I think this is a great point! As others have said, maintainers typically, but not always, know when their code is likely to break client libraries and software. But super-major numbers (i.e. the x of x.y) get bumped for other reasons, and sometimes sub-major (majorette?) numbers (i.e. the y of x.y) get bumped for massively breaking changes as well (which is in perfect accord with the PVP). One other solution would be to introduce a new, optional (at least at first) field in cabal files -- perhaps named something like api-version or api-epoch. This is just an integer, and it just gets bumped on massively breaking changes likely to force all client code to adapt. That way I can specify a traditional package lower bound with a real version number, and also specify (optionally, at least at first) an upper bound of an api-epoch. Most of my packages have never experienced an api-epoch event, and many likely won't ever. Most of their dependencies -- likewise. At the cost of some extra (optional) annotations, this gives us a sort of compromise between the current, very painful, situation and the no-upper-bound situation where occasionally an epoch event breaks an enormous chunk of the ecosystem. Cheers, Gershom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
