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
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
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
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
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
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:
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:
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
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
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
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.
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
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
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
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:
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
16 matches
Mail list logo
