On Fri, May 3, 2013 at 6:48 AM, Adrian May
adrian.alexander@gmail.comwrote:
May I venture a guess that you never tried to manage a 5-10 million line
project?
I build a project a couple orders of magnitude bigger than that dozens of
times every day. Similar stories are not uncommon among
One of the great things about the Haskell mailing lists is the supportive,
respectful tone that is the dominant mode of discourse. I sense that things
are getting a little out of control in this particular thread. Even though
this particular issue is clearly extremely frustrating for those
you've let a 5-10 million line project spiral out of control without
putting the necessary software engineering infrastructure and controls in
place ... This issue you're having reflects a lot more strongly on your
technical culture than it does on any instability in GHC.
I can't dictate
On Fri, May 3, 2013 at 4:37 PM, Simon Peyton-Jones simo...@microsoft.comwrote:
One of the great things about the Haskell mailing lists is the
supportive, respectful tone that is the dominant mode of discourse. I
sense that things are getting a little out of control in this particular
Adrian May adrian.alexander@gmail.com wrote:
I really don't know why somebody can't make a simple and well
intentioned point without getting attacked by people who feel
threatened over every little thing.
It's because we're failing to see the problem. I mean, if you can
pinpoint the
Raphael Gaschignard dasur...@gmail.com wrote:
I'm pretty sure most of us have experienced some issue with
dependencies breaking , and its probably the most frustrating problem
we can have have in any language. It's hard not to take this all a bit
personally. Maybe if we think more about how
How about this: can you guys give me a detailed example of a justified
deprecation: one so extremely obviously called for that even I would agree.
I just want to understand the kind of logic that's applied over these
things.
___
Haskell-Cafe mailing list
Isn't this a problem of timescale?
Nothing can be backward compatible for ever (or at least nothing that
is being developed or maintained)
There will be, in the life of non-trival length project, change.
We rely (and I mean rely) on Haskell s/w that was written over 10 years ago -
we accept
Adrian May adrian.alexander@gmail.com wrote:
How about this: can you guys give me a detailed example of a justified
deprecation: one so extremely obviously called for that even I would
agree. I just want to understand the kind of logic that's applied over
these things.
Changes already
Neil Davies semanticphilosop...@gmail.com wrote:
Isn't this a problem of timescale?
Nothing can be backward compatible for ever (or at least nothing that
is being developed or maintained)
I was referring to the Dependency Hell. I don't consider breaking
changes a problem.
Greets,
Ertugrul
Changes already made in the base library or in one of the platform
libraries:
So could you pick the most unassailable and tell me more about it please?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Ertugrul Söylemez wrote:
Often demanded changes that may or may not happen in the future:
* base: Make Functor a superclass of Monad. One of the two most
commonly demanded change to the base library. Will break lots and
lots of code. Reason: Would greatly simplify a lot of
On Fri, May 03, 2013 at 01:23:55PM +0300, Guy wrote:
That's what I thought of when I saw the original complaint - GHC is
too backwards compatible! There's far too much boilerplate because
of the Functor = Applicative = Monad mess. Float/Double being
Enums is ridiculous. None of this gets fixed
PS The proposal to fix Functor = Applicative = Monad has patches
attached for GHC and base, but the backwards compatibility bogeyman always
seems to trump something that will break a lot of code.
I think that should be fixed as well, but it would be tantamount to a new
language.
I guess
Adrian May adrian.alexander@gmail.com wrote:
Changes already made in the base library or in one of the platform
libraries:
So could you pick the most unassailable and tell me more about it
please?
I'll just pick a random example: Eq and Show are no longer superclasses
of Num. I'm
Dependency breakage is certainly an unavoidable problem. However, I think
Haskell is also in a much better position for having a technical solution
to the frustration of breakages.
Barring issues with changing datatypes / class instances, we can already
express many of the API changes you'd want
On 3 May 2013 18:56, Ertugrul Söylemez e...@ertes.de wrote:
Adrian May adrian.alexander@gmail.com wrote:
Changes already made in the base library or in one of the platform
libraries:
So could you pick the most unassailable and tell me more about it
please?
I'll just pick a
I'd also like to see these two. It occurs to me there may be language
tweak that could reduce breakage and add some convenience in both cases.
It would not surprise me at all if this has been thought of, examined, and
discarded, but I don't have time to dig so I'll just lay it out quickly,
and if
On Fri, May 03, 2013 at 09:34:21PM +0800, Adrian May wrote:
I never doubted that people add new stuff for valid reasons. What I'm
interested in is whether or not it could have been done without breaking
anything. But having thought about it for a while, I'm tending to think
that version
On Fri, May 3, 2013 at 6:34 AM, Adrian May
adrian.alexander@gmail.comwrote:
On 3 May 2013 18:56, Ertugrul Söylemez e...@ertes.de wrote:
Adrian May adrian.alexander@gmail.com wrote:
Changes already made in the base library or in one of the platform
libraries:
So could you
On Fri, May 3, 2013 at 5:30 AM, Adrian May
adrian.alexander@gmail.comwrote:
How about this: can you guys give me a detailed example of a justified
deprecation: one so extremely obviously called for that even I would agree.
I just want to understand the kind of logic that's applied over
Barring issues with changing datatypes / class instances, we can already
express many of the API changes you'd want to make to some library [1].
Now, no one actually does what this proposal suggests - it's a lot of
work, and it doesn't work in general. However, the fact that Haskell makes
The answer to your question is given in Boehm's theorem, and the answer
is no, as you suspect.
For the untyped lambda-calculus, alpha-equivalence of beta-eta normal
forms is the same as observational equivalence. Or put the other way
round, two normal forms which are not alpha-equivalent can
Hi,
On 3 May 2013 11:43, Tobias Dammers tdamm...@gmail.com wrote:
PS The proposal to fix Functor = Applicative = Monad has patches
attached for GHC and base, but the backwards compatibility bogeyman
always seems to trump something that will break a lot of code.
This kind of breaks
runhaskell -fno-warn-unused-matches Myfile.hs
[some compile error]
runhaskell -fno-warn-unused-matches Myfile.hs
[no output whatsoever but exit code 127]
runhaskell -asdf Myfile.hs
ghc: unrecognised flags: -asdf
runhaskell -fasdf Myfile.hs
[no output whatsoever but exit code 127]
Not sure
On Fri, May 3, 2013 at 10:35 AM, Niklas Hambüchen m...@nh2.me wrote:
runhaskell -fno-warn-unused-matches Myfile.hs
[some compile error]
runhaskell -fno-warn-unused-matches Myfile.hs
[no output whatsoever but exit code 127]
runhaskell -asdf Myfile.hs
ghc: unrecognised flags: -asdf
David Thomas wrote:
I'd also like to see these two. It occurs to me there may be language tweak
that could reduce breakage and add some
convenience in both cases. It would not surprise me at all if this has been
thought of, examined, and discarded, but I
don't have time to dig so I'll just
That's approximately what I was describing, yes. Thanks!
On Fri, May 3, 2013 at 7:54 AM, Guy guytsalmave...@yahoo.com wrote:
David Thomas wrote:
I'd also like to see these two. It occurs to me there may be language
tweak that could reduce breakage and add some
convenience in both cases.
I'm having a bit of trouble getting my brain around that, but if anybody
cares about attracting new users, that might be relevant in itself. Perhaps
I could be seen as an example of your swing-state. I'm no Haskell expert
but I'd like to push it if I could cos I'm so sick of seeing huge codebases
That's approximately what I was describing, yes. Thanks!
On Fri, May 3, 2013 at 7:54 AM, Guy guytsalmave...@yahoo.com wrote:
David Thomas wrote:
I'd also like to see these two. It occurs to me there may be language
tweak that could reduce breakage and add some
convenience in both cases.
On Fri, May 3, 2013 at 10:54 AM, Guy guytsalmave...@yahoo.com wrote:
http://hackage.haskell.org/**trac/ghc/wiki/**DefaultSuperclassInstanceshttp://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
I'm surprised that the various superclass proposals haven't got more
attention,
At Fri, 03 May 2013 16:34:28 +0200,
Andreas Abel wrote:
The answer to your question is given in Boehm's theorem, and the answer
is no, as you suspect.
For the untyped lambda-calculus, alpha-equivalence of beta-eta normal
forms is the same as observational equivalence. Or put the other way
On Fri, May 03, 2013 at 03:35:08PM +0100, Ozgur Akgun wrote:
Hi,
On 3 May 2013 11:43, Tobias Dammers tdamm...@gmail.com wrote:
PS The proposal to fix Functor = Applicative = Monad has patches
attached for GHC and base, but the backwards compatibility bogeyman
always seems to trump
While I certainly enjoy the discussion, how about addressing one of the
original problems:
On 02/05/13 13:27, Adrian May wrote:
I just tried to use Flippi. It broke because of the syntax change so I
tried WASH. I couldn't even install it because of the syntax change.
I just fixed that in
Tantamount to a new language to fix a minor detail in a typeclass
hierarchy? That is just histrionic. *No* language is that stable.
Scala makes dozens of changes like that between *minor* versions, and while
I hardly hold up their development practices as the best in the industry it
is still
So basically it boiled down drop the haskell98 package dependency and use
the new exception system, and import the right things to avoid the use of
the no longer exported Prelude catch?
On Fri, May 3, 2013 at 12:44 PM, Niklas Hambüchen m...@nh2.me wrote:
While I certainly enjoy the discussion,
On 05/03/2013 06:44 PM, Niklas Hambüchen wrote:
While I certainly enjoy the discussion, how about addressing one of the
original problems:
On 02/05/13 13:27, Adrian May wrote:
I just tried to use Flippi. It broke because of the syntax change so I
tried WASH. I couldn't even install it
On 05/03/2013 06:49 PM, Edward Kmett wrote:
Tantamount to a new language to fix a minor detail in a typeclass
hierarchy? That is just histrionic. *No* language is that stable.
Scala makes dozens of changes like that between *minor* versions, and while
I hardly hold up their development
On Thu, May 2, 2013 at 9:48 PM, Adrian May
adrian.alexander@gmail.comwrote:
Is anybody in the Haskell community still interested in attracting new
users? If so I suggest you go play with Ruby on Rails. Then you'll know
what it's like to approach a complex and unfamiliar system where
On 3 May 2013 09:44, Niklas Hambüchen m...@nh2.me wrote:
While I certainly enjoy the discussion, how about addressing one of the
original problems:
On 02/05/13 13:27, Adrian May wrote:
I just tried to use Flippi. It broke because of the syntax change so I
tried WASH. I couldn't even install
On Fri, 2013-05-03 at 10:40 -0700, Hilco Wijbenga wrote:
On 3 May 2013 09:44, Niklas Hambüchen m...@nh2.me wrote:
While I certainly enjoy the discussion, how about addressing one of the
original problems:
On 02/05/13 13:27, Adrian May wrote:
I just tried to use Flippi. It broke because
On 04/05/13 01:52, Nicolas Trangez wrote:
On Fri, 2013-05-03 at 10:40 -0700, Hilco Wijbenga wrote:
Given the apparent simplicity of the changes needed to keep one's
Haskell code up to snuff and the strong typing inherent in Haskell
code, would it not be possible to create something similar? If
Hi,
Just to share my excitement with you:
https://twitter.com/AGoCorona/status/329648864082677760
See the link in the tweet for an explanation
Best Regards,
--
Alberto.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
All right, here you go: https://github.com/nh2/WashNGo
https://github.com/nh2/WashNGo/commit/08010e7404219470a827f3e4172004f9d2aedc29
Took me around 75 minutes.
Think about it a bit:
I just ported thirty thousand lines of code that I have never seen
before and that has bit-rotted for over six
Not sure what you mean; if I just run `runhaskell`, it reads from stdin.
In any way, if runhaskell exits with error code 127, should it not
print what the error is?
On Fri 03 May 2013 22:48:33 SGT, Brandon Allbery wrote:
If you type just 'runhaskell' you will get an error message which
*Update:*
- BayHac '13 http://www.haskell.org/haskellwiki/BayHac2013 is just *two
weeks away*.
- We have *over 60* sign-ups!
- Please sign
uphttps://docs.google.com/forms/d/1u502QHmyFC_Wi4fqv_jYTTRun8E6D_gwcbf6bB3dvrs/viewform,
if you haven't already.
- We've added an optional
46 matches
Mail list logo
