subject:"Re\: \[Haskell\-cafe\] Backward compatibility"



  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 either that culture or the whole project. I often walk into
projects that have been mismanaged for years and try to prop them up. Crap
languages are also to blame and that's why I'm interested in Haskell at
all. But it's the reality I have to live with. It would be a lot easier for
me to sell better languages if they at least paid some heed to backward
compatibility.

Listen: someone within your organization decided to build a product based
 on a very old library which is no longer maintained by anyone. If this
 library were actually critical to your business, you would fork it and
 either get someone in-house or pay a contractor to fix bugs and keep it up
 to date. (And there are plenty of people here who might be interested in a
 contract gig to fix this for you if you asked).


Fine. Go ahead and write yourself a blank cheque on my account. Maintenance
costs are a fact of life anyway. What I don't understand is why people are
trying to maximise them when I'm trying to minimise them.


 Repeatedly claiming in the most histrionic terms that GHC ought to freeze
 forever and never deprecate anything again


Now you're putting words into my mouth. I've said from the very first
posting that I acknowledge the need for change but would like it to be
restricted to stuff that's actually useful and/or necessary instead of
changing things just for the hell of it. I'm asking for a compromise. I
said that from the start.


 newsflash: it's a research platform),


That would be a newsflash. I seem to remember it wanting to be a popular
quasi-standard FP.



 and is not going to garner you any sympathy on this list, either. You
 could practically be the poster boy for why we have the motto avoid
 success at all costs.


Now you're just being rude.


 You have two options: stay on GHC 6.x (the bits didn't get deleted from
 the internet), and if that isn't practical, fix Wash (or pay someone to do
 it if you don't know how) and get on with your life.


I already found newer libs anyway.

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. I said from the start that I think Haskell is cool. I'd just
like it to pay a bit more attention to practical issues whilst making
progress with its theoretical ones.

Why don't you just put it in the forum rules that nobody is ever allowed to
criticise anything?

At the end of the day, I'm just a typical manager who's atypical in wishing
he could tell his programmers to study a bit of Haskell without making it a
synch for the manager next door to knife him in the back for suggesting
something that looks this unstable. This is the real deal on how Haskell
looks out there in the mass market. You can lead a horse to water...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Raphael Gaschignard

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
 thread.  Even though this particular issue is clearly extremely frustrating
 for those involved, it would be great to turn down the emotional
 temperature.


I don’t know why Haskell folk tend to be so generous and helpful, but they
 really are. (Maybe it’s the hylomorphisms.)  Anyway, let’s keep it that way.
 


Agreed, the thing that surprised me the most when I started reading this
list was how nice people were, even when faced with some pretty hostile
people.

I think we all agree that dependency management is hard in any system,
especially with a lot of generally unmaintained pieces. And the fact that
100% backwards compatibility doesn't seem to be a directive in the language
committee like it might be for languages like C++ might frustrate people.

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 to solve this (getting people to maintain their
stuff, for example) we can make the world a better place instead of
bickering about issues that are more or less language-agnostic really.

On a side note is there a place where we can see what packages have broken
on recent releases?




 Simon

 ** **

 *From:* haskell-cafe-boun...@haskell.org [mailto:
 haskell-cafe-boun...@haskell.org] *On Behalf Of *Gregory Collins
 *Sent:* 03 May 2013 08:27
 *To:* Adrian May
 *Cc:* Haskell Cafe
 *Subject:* Re: [Haskell-cafe] Backward compatibility

 ** **

 On Fri, May 3, 2013 at 6:48 AM, Adrian May adrian.alexander@gmail.com
 wrote:

  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 people who inhabit
 this list. But thanks, citing that figure as an excuse to be condescending
 to that person was really worth a giggle this morning. :)

 ** **

 ** **

  That's what I do. I'm not a programmer, I'm a manager. I run teams of a
 few dozen people on subprojects within huge telecom-related projects, and
 my job is to try and keep it all from collapsing in a heap of bugs. 

 ** **

 If you had any experience of that you'd run a mile from any technology
 with this hit and miss attitude. 

  ** **

 You keep saying things like this. Actually, you're in this situation
 because one or more people within your organization have made a succession
 of very bad choices. Haskell is not to blame. Personally, I almost can't
 believe you're taking this tack on the list now that the details of your
 situation are apparent: you've let a 5-10 million line project spiral out
 of control without putting the necessary software engineering
 infrastructure and controls in place.

 ** **

  

  I can't tell people what version they should be using because half of
 them work for a completely different company. They have their own
 dependencies coming from other projects that I'm not even allowed to know
 about.


 ... and the truth emerges. This issue you're having reflects a lot more
 strongly on your technical culture than it does on any instability in GHC.
 

 ** **

 Listen: someone within your organization decided to build a product based
 on a very old library which is no longer maintained by anyone. If this
 library were actually critical to your business, you would fork it and
 either get someone in-house or pay a contractor to fix bugs and keep it up
 to date. (And there are plenty of people here who might be interested in a
 contract gig to fix this for you if you asked).

 ** **

 Repeatedly claiming in the most histrionic terms that GHC ought to freeze
 forever and never deprecate anything again so that you can avoid doing your
 job properly is simply not realistic, especially given Haskell's social
 culture (newsflash: it's a research platform), and is not going to garner
 you any sympathy on this list, either. You could practically be the poster
 boy for why we have the motto avoid success at all costs.
 

 ** **

 You have two options: stay on GHC 6.x (the bits didn't get deleted from
 the internet), and if that isn't practical, fix Wash (or pay someone to do
 it if you don't know how) and get on with your life.

 ** **

 G

 --
 Gregory Collins g...@gregorycollins.net 

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell

Re: [Haskell-cafe] Backward compatibility

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 source of your problems we could work on a solution, and we
would be happy to do that.  However, it is important to keep in mind
that Haskell is very active and things change a lot.  This is not a
problem, it's the mindset of this community.  If you are turning it into
a problem, feel free, but then the only suggestion I can make here is
that Haskell is probably not the right choice for your particular
development strategy.

In other words, for Haskell it's simply wrong to assume that you can use
legacy code that hasn't been maintained for many years.  Regardless of
whether you like it, this is the way to go.  If you want to use Haskell,
be prepared to maintain your code.  This usually boils down to making
small adjustments.  When the big breaking change in the base library
came I had to adjust a number of type signatures in my projects and I
was done.  These adjustments become necessary from time to time, and you
should be ready to perform them.


 I said from the start that I think Haskell is cool.

Unfortunately that doesn't really help.  What you are trying to achieve
is a shift in our fundamental philosophy, which is very unlikely to
happen, even if the shift is small.  Using Haskell is great, but does
require you to keep up to date.

The other option is to go with old compiler and library versions.  They
are all available, if you need them for your project, but this is a bad
solution.


 I'd just like it to pay a bit more attention to practical issues
 whilst making progress with its theoretical ones.

It's very difficult to combine those.  Communities solve these problems
differently.  Most communities try to keep compatible at the expense of
eliminating much of the potential for innovation.  The Haskell community
prefers to go the innovation route and is prepared to repair occasional
breakages.  They do occur, and we fix them.


 Why don't you just put it in the forum rules that nobody is ever
 allowed to criticise anything?

Because that's wrong.  I criticize things a lot, sometimes with a much
stronger tone than you did. =)


 At the end of the day, I'm just a typical manager who's atypical in
 wishing he could tell his programmers to study a bit of Haskell
 without making it a synch for the manager next door to knife him in
 the back for suggesting something that looks this unstable. This is
 the real deal on how Haskell looks out there in the mass market. You
 can lead a horse to water...

If it's your decision, you shouldn't be afraid to make it.  You are the
manager of your team!  Don't let yourself be stabbed by another manager.
Recognize that your choice can lead to higher productivity, if you don't
let yourself be distracted by this pointless matter.  And yes, it is
pointless.  If you simply move on and get to productive Haskell work,
you will find that this is a non-issue.

In particular, you want to make educated decisions, which means that you
should probably research the current standards in the Haskell community.
If you would have performed that research from the beginning, you would
have come to the conclusion that WASH was a bad choice to begin with,
which leads me to another very important point:

I have worked in many SCRUM-based teams.  While I could question the
general usefulness of this paradigm, I have to say that it has taught me
a number of very important things, and one thing in particular:
Programmer choices should be made by programmers.  You shouldn't have
made the decision about the web framework in the first place.  Get a
team of Haskell programmers and let them choose the best tool for the
job.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

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 to solve this (getting
 people to maintain their stuff, for example) we can make the world a
 better place instead of bickering about issues that are more or less
 language-agnostic really.

The problem can't be solved technically.  It's a human problem after all
and it's amplified by the experimentalism in this community.  I think
the best we can do is to acknowledge its existence, which places us way
ahead of mainstream programming communities.

We don't pretend that type X in lib-0.1.0 is the same as type X in
lib-0.2.0.  What we need to work on is the ability to actually combine
multiple versions of the same package conveniently, i.e. we shouldn't
view this combination as an error.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Neil Davies

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 that
when we want to recompile it (about every 2/3 years as the systems it interacts 
with are updated)
there will be a cost of change to bring it up to latest libraries etc.

But the joy is that (combined with the regression and property tests around it) 
we can have very high
confidence that once the old stuff recompiles it will operate the same. And 
as it is key to our business
that is a nice feeling - let's me sleep soundly at night.

The beauty of the Haskell ecosystem is that such change is nowhere as hazardous 
as with other approaches.
Therefore its total costs are less.

The experimentalism in this community is to be applauded and encouraged - it is 
spawning robust
solutions to the real underlying problems of constructing a society that can 
actually support the 
technical infrastructure it is creating. Don't forget the motivation for Ada 
was that the projected
costs of supporting the US defence infrastructure was projected to exceed the 
projected GDP of 
the US by 2012. Maintaining essential safety critical systems isn't an optional 
extra.

We see that the same Ada-like scenario is working its way out in companies 
today - large Telcos, 
Goverment projects etc - I also see that formalism, such as embodied in 
Haskell, is the ONLY hope
we have to contain the costs of maintenance complexity. 

Yes, the underlying issue is a human one - but it lies in the low value given 
to medium to long
term sustainability of organisations (e.g Telcos) compared to the relative high 
value that is given 
to novelty. Perhaps this is an inevitable by-product of a marketing driven, 
short term driven 
business culture?

Neil

On 3 May 2013, at 10:04, Ertugrul Söylemez e...@ertes.de wrote:

 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 to solve this (getting
 people to maintain their stuff, for example) we can make the world a
 better place instead of bickering about issues that are more or less
 language-agnostic really.
 
 The problem can't be solved technically.  It's a human problem after all
 and it's amplified by the experimentalism in this community.  I think
 the best we can do is to acknowledge its existence, which places us way
 ahead of mainstream programming communities.
 
 We don't pretend that type X in lib-0.1.0 is the same as type X in
 lib-0.2.0.  What we need to work on is the ability to actually combine
 multiple versions of the same package conveniently, i.e. we shouldn't
 view this combination as an error.
 
 
 Greets,
 Ertugrul
 
 -- 
 Not to be or to be and (not to be or to be and (not to be or to be and
 (not to be or to be and ... that is the list monad.
 ___
 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] Backward compatibility

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 made in the base library or in one of the platform
libraries:

  * base: Eq and Show independent of Num.  Broke a lot of code.  Reason:
Makes function-like numeric types possible.

  * base: Deprecated and finally removed the old exception system.
Replaced by extensible exceptions, added new masking system.  Broke
a lot of code.  Reason:  Makes the whole exception handling more
sensible.

  * mtl: Unified transformer and Identity variants.  Broke some code.
Reason:  Makes the internals much more maintainable and the whole
library design more sensible.

  * Haskell: Changed the type specializing behavior in local bindings.
Broke a lot of code.  Reason:  Makes type inference infer more
specialized types, makes code more concise, but occasionally
requires a type signature when you specifically want more
polymorphic types.

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 code.

  * base: Fix the numeric type classes.  The other most commonly
demanded change.  Will break lots and lots of code, including most
of the base library.  Reason:  Would make numeric code much more
sensible and algebraic.

My personal demands.  Unlikely to happen in the near future:

  * Add RankNTypes, ScopedTypeVariables, TupleSections and TypeFamilies
to standard Haskell.  Shouldn't break any existing code.

  * Replace all special arrow classes by category classes, i.e. turn
ArrowChoice and ArrowLoop into CategoryChoice and CategoryLoop.
Introduce ApplicativeFix.  Will break some existing code.

  * Factor Applicative and Alternative into four classes:
  - (Functor f) = Apply f  (*)
  - (Apply f)   = Applicative fpure
  - (Functor f) = Plus f   (|)
  - (Plus f)= Alternative  empty
Would break everything.  Everything.

I could go on.  The point is that you are probably the first person to
complain about those changes. =)


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

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

-- 
Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility


 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
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Guy


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 code.

   * base: Fix the numeric type classes.  The other most commonly
 demanded change.  Will break lots and lots of code, including most
 of the base library.  Reason:  Would make numeric code much more
 sensible and algebraic.


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 because of the fear that new GHC won't compile old code.


Perhaps we need some system for maintainers to vote on whether they consider the value of a breaking change to be worth 
the effort of fixing their packages to work with it. In my own code, I usually find that this effort is minor, and I'm 
more than happy to do it in return for a better language/library.


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.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Tobias Dammers

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 because of the fear
 that new GHC won't compile old code.

 
 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 everything changes would require something similar
to what Python is doing with the 2 - 3 transition, and considering how
painfully slowly it is progressing there, I understand perfectly well why
people don't want to go there.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility



 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 you need some kind of versioning system for the libraries. Why not
put them all in a public source control server and have ghc force people to
say which snapshot they wanted. That would be your final breaking change,
and it's a one-liner in the Makefile. Then you could thrash around as much
as you liked and people like me would have nothing to complain about.
Naturally, the compiler itself should keep supporting old modes.

Adrian.





 __**_
 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] Backward compatibility

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 the author of the Netwire library, a library for functional
reactive programming.  Before that change you would write the following
code to express a clock that runs twice as fast as the real time clock
and oscillates up and down while gradually increasing:

liftA2 (\t o - 2*t + sin o) time (integral_ 0 . v)

Thanks to the change you can now write it as:

2*time + sin (integral_ 0 . v)


Greets,
Ertugrul

-- 
Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Michael Sloan

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 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
something like this seem reasonable is heartening.

Of course, even if we had good tools that automatically refactored code to
use new APIs, it wouldn't be possible for any non-superficial changes.
 Even so, if a good enough refactoring tool existed, and it was popular
with both authors and users, a lot of the annoyance of dependency breakages
could be removed.

-Michael

[1]
http://haskellwiki.gitit.net/The%20Monad.Reader/Issue2/EternalCompatibilityInTheory



On Fri, May 3, 2013 at 2:04 AM, Ertugrul Söylemez e...@ertes.de wrote:

 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 to solve this (getting
  people to maintain their stuff, for example) we can make the world a
  better place instead of bickering about issues that are more or less
  language-agnostic really.

 The problem can't be solved technically.  It's a human problem after all
 and it's amplified by the experimentalism in this community.  I think
 the best we can do is to acknowledge its existence, which places us way
 ahead of mainstream programming communities.

 We don't pretend that type X in lib-0.1.0 is the same as type X in
 lib-0.2.0.  What we need to work on is the ability to actually combine
 multiple versions of the same package conveniently, i.e. we shouldn't
 view this combination as an error.


 Greets,
 Ertugrul

 --
 Not to be or to be and (not to be or to be and (not to be or to be and
 (not to be or to be and ... that is the list monad.

 ___
 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] Backward compatibility

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 random example:  Eq and Show are no longer superclasses
 of Num.  I'm the author of the Netwire library, a library for functional
 reactive programming.  Before that change you would write the following
 code to express a clock that runs twice as fast as the real time clock
 and oscillates up and down while gradually increasing:

 liftA2 (\t o - 2*t + sin o) time (integral_ 0 . v)

 Thanks to the change you can now write it as:

 2*time + sin (integral_ 0 . v)


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 controlling all the standard modules is the only general
solution.

You'd have them all in a git ... ahem ... darcs repo which every dev would
clone the entire history of. Something prominent in the project would say
which version you want. (We could brainstorm about hierarchies of that but
it probably wouldn't work anyway.) GHC would just switch its internals
according to that number and fetch the right version of the module out of
darcs as part of the compilation process.

If you really wanted to protect people from future changes, you'd make it
obligatory to tell ghc which version you want, but seeing as I seem to be
more worried about this than anybody else around here, I might as well
assume you'd default to the latest, but please, at least issue a warning so
that people know this offbeat system even exists.
)
I could have my project source in a completely different source control
system cos this darcs interaction is internal to the compiler.

This ain't gonna mean I don't have to maintain stuff, but having the choice
about when to do so would be a great help. Better still, I could take a
fifty year old codebase, build it out of the box, and nudge the version
along one step at a time so I have some kind of chance, which would render
my original post completely redundant.

But best of all, I'd no longer care which dev had which Haskell Platform
version. They'd just get nagged into upgrading ghc whenever it saw a too
racy module version. That would mean I could let them finish what they were
doing on their own branch, check it into the old-style mainline and then
tell them to merge it onto the new-style mainline, expecting a few puzzles
along the way. For their next feature they'd branch off the new mainline
and in a few weeks the old one would be history. (I'm not sure you've all
figured out that those few weeks are necessary.)

Seeing as you guys like theoretical rigour so much, maybe I should put it
this way: if you show me a lump of text and call it source code for a
program, I'll think you mean that it contains all the information I need to
turn it into one. If it fails to specify which versions of which external
libraries it assumes are hanging around somewhere, then it hardly meets
that definition. Looking at it that way, compiler errors are not the worst
thing that could happen: it might build an entirely different program. I've
seen two huge projects hit the trash can because of build system vagueness,
and that's what I learned out of it.

Just imagine never having to negotiate with the backward-compatibility
whingers anymore!

Adrian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread David Thomas

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 it has been discussed before someone will probably know where.

The idea is to allow definitions of superclass operations in subclass
instances. If there are such definitions, it's treated as if there were
instances defined for each class (potentially a source translation, even).
I think default definitions of superclass operations in the subclass would
be used last (that is, only for the automatic instance of the superclass,
and only if the superclass didn't have a default for that).

This should allow existing instances of Num to just work (and I think Monad
too, with some care). It would also mean if you're making something that's
a Monad or a Num you could just lay out the one instance in all one place,
reducing a bit of boilerplate. At the same time, you'd have the
flexibility to just use the superclasses where you just want pieces.

On Fri, May 3, 2013 at 3:23 AM, Guy guytsalmave...@yahoo.com wrote:

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 code.

* base: Fix the numeric type classes. The other most commonly
demanded change. Will break lots and lots of code, including most
of the base library. Reason: Would make numeric code much more
sensible and algebraic.

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 because of the fear that new GHC won't
compile old code.

Perhaps we need some system for maintainers to vote on whether they
consider the value of a breaking change to be worth the effort of fixing
their packages to work with it. In my own code, I usually find that this
effort is minor, and I'm more than happy to do it in return for a better
language/library.

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.

__**_
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] Backward compatibility

2013-05-03 Thread Tom Ellis

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 controlling all the standard modules is the only general
 solution.

I think you may be overestimating the severity of the breakage that
applies to the WashNGo package.

In Haskell2010 a number of module locations were renamed in order to reduce
clutter.  For example, IO became System.IO, List became Data.List and Monad
became Control.Monad.

I'm pretty sure that updating all of these module names will fix the
problem.  No one has bothered because the package is very old and there are
more suitable alternatives these days.

Tom

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Alexander Solla

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 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 the author of the Netwire library, a library for functional
 reactive programming.  Before that change you would write the following
 code to express a clock that runs twice as fast as the real time clock
 and oscillates up and down while gradually increasing:

 liftA2 (\t o - 2*t + sin o) time (integral_ 0 . v)

 Thanks to the change you can now write it as:

 2*time + sin (integral_ 0 . v)


 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 controlling all the standard modules is the only general
 solution.


Seeing how type class constraints were removed, obviously, the change could
not have been done without breaking code.

On the other hand, the solution is a regular expression away.  Even a 5-10
million line project could survive that, even if it means issuing a ticket,
going through testing and QA, etc.

GHC changes are an issue management needs to consider, but the maintenance
burden they introduce are minimal and typically mechanically fixable.  If
management is unwilling to allocate resources to deal with these issues,
then it behooves management to settle on a single version of the Haskell
Platform (or even just GHC, if appropriate) or move on to another language,
and lose the productivity benefits of Haskell.


 You'd have them all in a git ... ahem ... darcs repo which every dev would
 clone the entire history of. Something prominent in the project would say
 which version you want. (We could brainstorm about hierarchies of that but
 it probably wouldn't work anyway.) GHC would just switch its internals
 according to that number and fetch the right version of the module out of
 darcs as part of the compilation process.

 If you really wanted to protect people from future changes, you'd make it
 obligatory to tell ghc which version you want, but seeing as I seem to be
 more worried about this than anybody else around here, I might as well
 assume you'd default to the latest, but please, at least issue a warning so
 that people know this offbeat system even exists.


Surely, as a manager, you have taken at least a basic course in economics.
 And you understand how resources, such as open source developer time, are
allocated.  Everybody's time is valuable, and the professional academics
who work on GHC will use the same economic principles you use (making
changes with the highest marginal benefit).  The hobbyist open source
developers will do the same thing, except their utility functions will
include their personal preferences.

Do you really want this done?  I suggest cash payments to the experience
Haskell developer of your choice.

)
 I could have my project source in a completely different source control
 system cos this darcs interaction is internal to the compiler.

 This ain't gonna mean I don't have to maintain stuff, but having the
 choice about when to do so would be a great help.


You already have that choice.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Brandon Allbery

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 these
 things.


This might not be possible because your notion of a justified change may
not align with other people's. IIRC the removal of the Show constraint on
Num was driven by type level natural numbers? which matter to the type
hackers but not to someone whose main concern is getting an unmaintained
web interface running. (OTOH it also may not have any effect on said web
server, since it mostly affected people who take the somewhat risky action
of defining their own Num instances; I suspect the exceptions change would
have more impact on web stuff.)

As for the exceptions stuff, that was a multi-step change. Exception
handling was somewhat unprincipled and came in two forms, which used the
same function names but in different ways. There was support for IO
exceptions in the Prelude and conflicting support for general exceptions,
which behaved somewhat differently when handed an IO exception, in
Control.Exception. One key behavior was that you had to handle all
exceptions or none at all; the only way to choose specific exceptions was
to handle all of them, inspect the exception object, and rethrow if it
wasn't one you wanted to handle. And inspecting the exception object to see
what it had in it could be tricky at times, because there wasn't much
guidance with respect to user defined exceptions and some library
exceptions did things slightly differently from the ones in the base.

The exception cleanup made IO exceptions and other exceptions behave
consistently and got rid of the conflicting definitions. This did require
source changes, as anyone relying on the Prelude exceptions had to add an
import of Control.Exception and anyone using old-style exceptions generally
had to add a type annotation to their handler; more ideally, they'd rewrite
their exception code to handle specific exceptions or exception classes
instead of poking at the exception object to determine whether it was one
they cared about or not --- but this was not necessary to get older code
running again, only the added type annotation was necessary.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility



 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
 something like this seem reasonable is heartening.

 [1]
 http://haskellwiki.gitit.net/The%20Monad.Reader/Issue2/EternalCompatibilityInTheory


Thanks Michael, that seems to be what I was talking about, only 8 years
earlier, better thought through, and somewhat more readable.

So why do you say it doesn't work in general?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Ozgur Akgun

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 everything changes would require something similar
 to what Python is doing with the 2 - 3 transition, and considering how
 painfully slowly it is progressing there, I understand perfectly well why
 people don't want to go there.


There is one very big advantage in the Haskell-world though.
Most of the struggle will be at the compile time. The biggest headache
caused by
the Python 2 - 3 transition is how you get a runtime error 2 weeks after
you think
you've fixed everything!

(Yeah, I know code coverage analysis is an option when you don't have static
type checking, but ...)

Cheers,
Ozgur
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Guy


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 lay it out quickly, and if it has been 
discussed before someone will probably know
where.

The idea is to allow definitions of superclass operations in subclass 
instances.  If there are such definitions, it's
treated as if there were instances defined for each class (potentially a source 
translation, even).  I think default
definitions of superclass operations in the subclass would be used last (that 
is, only for the automatic instance of the
superclass, and only if the superclass didn't have a default for that).

This should allow existing instances of Num to just work (and I think Monad 
too, with some care).  It would also mean if
you're making something that's a Monad or a Num you could just lay out the one 
instance in all one place, reducing a bit
of boilerplate.  At the same time, you'd have the flexibility to just use the 
superclasses where you just want pieces.


http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances

I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind 
of class hierarchy clean-up without breaking lots of code.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread David Thomas

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.  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 it has
 been discussed before someone will probably know
 where.

 The idea is to allow definitions of superclass operations in subclass
 instances.  If there are such definitions, it's
 treated as if there were instances defined for each class (potentially a
 source translation, even).  I think default
 definitions of superclass operations in the subclass would be used last
 (that is, only for the automatic instance of the
 superclass, and only if the superclass didn't have a default for that).

 This should allow existing instances of Num to just work (and I think
 Monad too, with some care).  It would also mean if
 you're making something that's a Monad or a Num you could just lay out
 the one instance in all one place, reducing a bit
 of boilerplate.  At the same time, you'd have the flexibility to just use
 the superclasses where you just want pieces.


 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, seeing as it would allow for this kind of class hierarchy
 clean-up without breaking lots of code.



 __**_
 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] Backward compatibility

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
land in the dustbin due to the evils of imperative coding. The
version-controlled modules thing is immediately comforting for me cos I
know what it is and I could fire it at the manager next door who doesn't
know much but fancies my job.

On 3 May 2013 22:54, 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. 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 it has
been discussed before someone will probably know
where.

The idea is to allow definitions of superclass operations in subclass
instances. If there are such definitions, it's
treated as if there were instances defined for each class (potentially a
source translation, even). I think default
definitions of superclass operations in the subclass would be used last
(that is, only for the automatic instance of the
superclass, and only if the superclass didn't have a default for that).

This should allow existing instances of Num to just work (and I think
Monad too, with some care). It would also mean if
you're making something that's a Monad or a Num you could just lay out
the one instance in all one place, reducing a bit
of boilerplate. At the same time, you'd have the flexibility to just use
the superclasses where you just want pieces.

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, seeing as it would allow for this kind of class hierarchy
clean-up without breaking lots of code.

__**_
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] Backward compatibility

2013-05-03 Thread David Thomas

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.  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 it has
 been discussed before someone will probably know
 where.

 The idea is to allow definitions of superclass operations in subclass
 instances.  If there are such definitions, it's
 treated as if there were instances defined for each class (potentially a
 source translation, even).  I think default
 definitions of superclass operations in the subclass would be used last
 (that is, only for the automatic instance of the
 superclass, and only if the superclass didn't have a default for that).

 This should allow existing instances of Num to just work (and I think
 Monad too, with some care).  It would also mean if
 you're making something that's a Monad or a Num you could just lay out
 the one instance in all one place, reducing a bit
 of boilerplate.  At the same time, you'd have the flexibility to just use
 the superclasses where you just want pieces.


 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, seeing as it would allow for this kind of class hierarchy
 clean-up without breaking lots of code.



 __**_
 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] Backward compatibility

2013-05-03 Thread Brandon Allbery

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, seeing as it would allow for this kind of class hierarchy
 clean-up without breaking lots of code.


IIRC they've been tried and found to actually cause more backward
compatibility issues than they solve because there are so many packages
which have created their own instances, and nobody's found a workaround
that doesn't either do that or lead to bizarre type errors.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Tobias Dammers

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 something that will break a lot of code.
 
  This kind of breaks everything changes would require something similar
  to what Python is doing with the 2 - 3 transition, and considering how
  painfully slowly it is progressing there, I understand perfectly well why
  people don't want to go there.
 
 
 There is one very big advantage in the Haskell-world though.
 Most of the struggle will be at the compile time. The biggest headache
 caused by
 the Python 2 - 3 transition is how you get a runtime error 2 weeks after
 you think
 you've fixed everything!
 
 (Yeah, I know code coverage analysis is an option when you don't have static
 type checking, but ...)

Well; this is an additional problem that comes with the pragmatic choice
for a language that doesn't believe in type checking and compile-time
guarantees, but I think it is largely orthogonal. At least
theoretically, you could have 100% test coverage, which would put the
Python project in the same situation as the Haskell one (except that the
tests themselves would also have to be converted...)

The problem I'm talking about, though, is that such a change would split
the ecosystem in two (say, Traditional Haskell and Functor-Correct
Haskell), just like the 2/3 separation is all over the Python ecosystem
and causes all sorts of headaches. Should I be using Python 2 or 3 is
not a question that has a simple answer, and that *is* a problem.

 
 Cheers,
 Ozgur

 ___
 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] Backward compatibility

2013-05-03 Thread Niklas Hambüchen

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 https://github.com/nh2/flippi (note that I have
never seen this code before nor even known about it).

https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313d

Had to delete 5 imports and convert one time value.

Took me around 3 minutes.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Edward Kmett

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 somehow seen as enterprise ready.

-Edward

On Fri, May 3, 2013 at 6:52 AM, Adrian May
adrian.alexander@gmail.comwrote:

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 you need some kind of versioning system for the libraries. Why not
put them all in a public source control server and have ghc force people to
say which snapshot they wanted. That would be your final breaking change,
and it's a one-liner in the Makefile. Then you could thrash around as much
as you liked and people like me would have nothing to complain about.
Naturally, the compiler itself should keep supporting old modes.

Adrian.

__**_
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] Backward compatibility

2013-05-03 Thread Edward Kmett

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, 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 https://github.com/nh2/flippi (note that I have
 never seen this code before nor even known about it).


 https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313d

 Had to delete 5 imports and convert one time value.

 Took me around 3 minutes.

 ___
 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] Backward compatibility

2013-05-03 Thread Bardur Arantsson

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 because of the syntax change.
 
 I just fixed that in https://github.com/nh2/flippi (note that I have
 never seen this code before nor even known about it).
 
 https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313d
 
 Had to delete 5 imports and convert one time value.
 
 Took me around 3 minutes.
 

+1



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Bardur Arantsson

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 practices as the best in the industry it
 is still somehow seen as enterprise ready.
 
 -Edward

Indeed. It's all turned into absurd hyperbole at this point.

Regards,



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Tom Murphy

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 every
 crumb requires a precise version of every other. If you had my job, you'd
 find out what you needed to know within half an hour.



Rails is in many ways as (more?) backwards-incompatible as Haskell. E.g.,
Rails 4 requires(!) Ruby 1.9.3+. 1.9.3 was released in the fall of 2011.
When new major versions of Rails or Ruby come out, developers are generally
expected to make the incremental changes to keep up. It's the donkey in a
well thing -- you never get buried if you make small changes over time.

Tom
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Hilco Wijbenga

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 it because of the syntax change.

 I just fixed that in https://github.com/nh2/flippi (note that I have
 never seen this code before nor even known about it).

 https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313d

 Had to delete 5 imports and convert one time value.

 Took me around 3 minutes.

It seems fair to say that Haskell's designers lean more to evolution
than maintaining backward compatibility. This reminds me of Go (the
programming language). The approach chosen by Go's designers was to
create a tool (gofix) that would automatically fix one's code to
comply with the latest standard. See
[http://talks.golang.org/2012/splash.article#TOC_17.] (yes, include
that last period).

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 there
is a tool that moves (most of) one's code from Haskell version n to
n+1 then making breaking changes would be even less of an issue.

Just an idea, I have no clue about its feasibility...

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Nicolas Trangez

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 of the syntax change so I
  tried WASH. I couldn't even install it because of the syntax change.
 
  I just fixed that in https://github.com/nh2/flippi (note that I have
  never seen this code before nor even known about it).
 
  https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313d
 
  Had to delete 5 imports and convert one time value.
 
  Took me around 3 minutes.
 
 It seems fair to say that Haskell's designers lean more to evolution
 than maintaining backward compatibility. This reminds me of Go (the
 programming language). The approach chosen by Go's designers was to
 create a tool (gofix) that would automatically fix one's code to
 comply with the latest standard. See
 [http://talks.golang.org/2012/splash.article#TOC_17.] (yes, include
 that last period).
 
 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 there
 is a tool that moves (most of) one's code from Haskell version n to
 n+1 then making breaking changes would be even less of an issue.
 
 Just an idea, I have no clue about its feasibility...

I mentioned the same on #haskell today. Something like Coccinelle
(http://coccinelle.lip6.fr) semantic patches could be really useful to
automate (some) API  language changes. Somewhat like (but better than)
the Python '2to3' tool.

I think some message about a GSoC project regarding an AST-based
refactoring tool was posted to this list. That might be a useful
building block for such tool?

Imagine one day whenever a new HP release is made, GitHub pull-requests
are created automatically based on a automatically-generated patch
verified through a compilationtest-cycle on TravisCI for GH-hosted
packages published on Hackage.

Nicolas


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Niklas Hambüchen

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 there
 is a tool that moves (most of) one's code from Haskell version n to
 n+1 then making breaking changes would be even less of an issue.

 Just an idea, I have no clue about its feasibility...
 
 I mentioned the same on #haskell today. Something like Coccinelle
 (http://coccinelle.lip6.fr) semantic patches could be really useful to
 automate (some) API  language changes. Somewhat like (but better than)
 the Python '2to3' tool.
 
 I think some message about a GSoC project regarding an AST-based
 refactoring tool was posted to this list. That might be a useful
 building block for such tool?

Yes, I proposed that.

It seems to be already in the making by some, but seems to need more
concentrated community effort/support/contribution.

It would also *hugely* reduce the time spent on what my next email is about.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-03 Thread Niklas Hambüchen

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 years to the latest
programming environment.

It being Haskell, I am pretty confident it does *exactly* what it's
supposed to do.

I want to see anyone do that with an equivalently sized + outdated Ruby
/ Python project.


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
 persisted for a while but gave up because getPackageId doesn't exist in
 any form at all anymore. This was only the install script: what would
 WASH itself have in store for me to get my brain around?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Byron Hale


Hello, everyone,

I was just in the process of trying to get Haskell 7.6 installed. First 
I surveyed all the current OSes that seemed to support it. FreeBSD 9.1 
seemed like a good candidate.  However, FreeBSD 9.1 has many practical 
problems of its own.  So far, I have 7.4 installed, but not 7.6.  Would 
the MAC be better at this? Anyway,  it seems that much of Hackage will 
not be usable. Perhaps I should just run it on Windows, as it seems 
likely to install there and much of Hackage already didn't work there.


I welcome any constructive suggestions.

Best Regards,

Byron Hale

On 5/1/2013 10:27 PM, Adrian May wrote:

Hi All,

Please don't interpret this as a rant: I'm just feeling a bit 
disappointed about probably having to give up on Haskell.


Let's face it: this decision to change the default syntax in GHC7 
means that right now Haskell looks about as stable as Ruby on Rails.


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 
persisted for a while but gave up because getPackageId doesn't exist 
in any form at all anymore. This was only the install script: what 
would WASH itself have in store for me to get my brain around?


What are my choices here:

1) Revert to GHC6 or put pragmas and compiler switches everywhere, 
switch 2010 off globally with cabal or even make an alias of ghc: That 
means I'll gradually clash with people who decide ...
2) Convert all my code and a lot of other peoples' to the new syntax, 
thereby exacerbating the problem that ruled out 1.


Either way, we're looking at a long period during which a large 
portion of the libraries will be incompatible with the other portion, 
and nobody will know which style to write. I don't know if or when 
WASH or any other library will convert, or even if I'd prefer that to 
happen sooner or later, because that would depend on when other 
libraries do and how I'd worked around it in the meantime. Altogether 
that means I can't sensibly decide to rely on any library, so I can't 
use Haskell. I'll just have to go back to fumbling around in XSL, PHP 
and the like. Is Haskell 2010 really so much better that it justifies 
this?


I just saw that movie The Words: the moral of the story is that you 
shouldn't try to change your mistakes.


...

Apparently it's not only 2010. I now find that buildng the Haskell 
Platform wants GHC 7.4.2, not 7.4.1 because of the line import 
Prelude (if I remember rightly,) and even when I follow the rules 
precisely I still get several different deprecation warnings. The 
prelude is not exactly obscure. If you deprecate that you've broken 
everything. Is it really impossible to keep such a basic mantra 
meaningful from one minor version to the next? Java was fond of 
deprecating things in the early days, but when they said deprecated 
they didn't mean switched off, let alone that it would lead to a 
syntax error. They just meant not trendy anymore.


It's a very common illusion to believe that the central thing in your 
life is also the central thing in everybody else's. That's why things 
like Norton take over your whole machine: those guys believe that the 
only reason you bought the computer was to fight viruses, because 
that's what most of the machines in their office were bought for.


There seems to be something similar going on in the way Haskellers are 
expected to update all their code whenever GHC decide to issue an 
update. But in reality we have jobs of our own. I'd like to choose 
Haskell over XSL because I think it'll enable me to write web sites 
more efficiently, not because I want to forget all about my job and 
savour the brilliance of the latest Haskell version. But in reality 
I'm just sitting here waiting for the Platform to compile just in case 
it's the Ubuntu package's fault, but I know it won't help. I'll just 
get other problems instead. Reality is that the whole ecosytem is in 
disarray because of this lack of respect for backward compatibility. 
At least Rails can plead that it's relatively new, but Haskell has 
been around for over 20 years.


I understand that progress has to be made, and it would be nice if 
people did just update all their code quickly so you could switch off 
old stuff and move on. But it's not hard to survey the code that's out 
there and see how much stuff you'd be breaking if you did. If it's not 
a lot, then switching it off to wake them up would be an acceptable 
compromise. But it looks to me as if a lot of very important stuff is 
still failing on the GHC from November 2010, so clearly things are 
going too fast. Adding new stuff is great, and sometimes the new stuff 
clashes with the old stuff. But how much of that deprecated stuff 
really *needed* to be switched off, and couldn't the new stuff 
have been designed so as not to force that?


In principle this is the best language on the planet, but with all 
these version gotchas I don't know that I can use it

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Johannes Waldmann

Adrian May adrian.alexander.may at gmail.com writes:

  this decision to change the default syntax in GHC7 

what decision? what syntax? here's the release notes (7 vs. 6)
http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/release-7-0-1.html

I guess you are referring to hierarchical module names?
(import List = import Data.List)

Indeed, I cannot build
WASH http://hackage.haskell.org/package/WashNGo-2.12.0.1
on ghc-7.6.3, and I don't see how it could have worked on 7.0,
as hackage claims it did. 

(building the executables: 
when using base and haskell89, import Prelude is ambiguous; 
when using haskell98 only, modules like System.Exit are not available.)

I think this could be fixed in a straightforward way,
but that fixing it is necessary at all, just proves your point.

- J.W.




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Johannes Waldmann

Byron Hale byron.hale at einfo.com writes:

   I was just in the process of trying to get Haskell 7.6 installed.

You cannot install Haskell 7.6. Haskell is a language. 

You can install a language implementation (compiler/interpreter).
There may be several. You can also install a set of libraries.
These may be bundled (one compiler with one set of libraries).
One such bundle is called the Haskell platform.
Is this what you are trying to install? (But then the version is nothing
like 7.6, this looks more like a compiler version.)

Of course this naming error is directly suggested by haskell.org, where 
we have the equally meaningless Download Haskell right on the front page.

- J.W.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

Adrian May adrian.alexander@gmail.com wrote:

 Please don't interpret this as a rant: I'm just feeling a bit
 disappointed about probably having to give up on Haskell.

 [rant that update broke stuff]

Well, it is a rant, so you can just as well concede it. =)

The Haskell community and its descendants (Agda, Disciple, Idris, ...)
differ from all other developer communities I know in one point:  We
don't fear change.  There is a reason why other communities do:
Non-downward-compatible changes will break stuff.  We are aware of that.

Occasionally things will break, when they worked perfectly before an
update.  Does that mean that Haskell sucks?  Not really.  It means that
some library developers will have to get rid of their old bad habits.
This is unlikely to happen for unmaintained projects like WASH.  So the
question you should be asking yourself is:  Do you really want to use
WASH?  I'm surprised that you could build it with any GHC 7.x at all.

If you don't like this experimentalism and the rigor with which we get
rid of old problems (which isn't even that rigorous -- Functor and Monad
are still independent classes even today), then Haskell may indeed be
the wrong choice for you.  However, you should always ask yourself:  Who
is the one with bad habits?

Consider PHP:  It was broken since the beginning and is still broken
today.  The developers carefully make sure that it stays broken, because
fixing it would break applications.  They don't want them to break.
That means that you can rely on all of your old bad habits, keep your
SQL injection vulnerabilities, your broken program logic, etc.  Is this
good or bad?

Consider Debian, the PHP of Linux distributions:  Their philosophy is
never to touch a running system, so instead of employing architectural
changes they keep the old code bases as long as possible and follow a
rigorous backporting policy.  They don't want you to have to rewrite
your configuration files or update your shell scripts or whatever
at-most-five-minutes steps would usually be necessary after an update.
It should Just Work.  Is this good or bad?

To express this question in a broader context:  Are you leaving a broken
tool and replacing it with a new shiny one?  Or are you really just
replacing a small problem by a big one?  Haskell's change policy is a
small problem that prevents you from big problems.  PHP is a big problem
all by itself.  Do you really want to leave this wonderful realm just
because of one setback?  Keep in mind that this setback is an integral
part of why Haskell shines where PHP sucks.

Think about it. ;)


 In principle this is the best language on the planet, but with all
 these version gotchas I don't know that I can use it anymore. What a
 tragedy. I can't even think of a suggestion as to how Haskell should
 try to get out of this mess now.

We all have to deal with these gotchas.  However, I'm still much more
productive with Haskell than with any other language.  When I go to a
new GHC major version I always expect some old packages to fail, and I'm
often surprised by the small number of packages that actually do.

So my closing comment is:  Haskell is one of the best languages, but
that greatness comes at a price.  Deal with it.  Going back to PHP is
not the answer.

Instead you should recognize that now is the time to look into one of
the big three web frameworks of today:  Happstack, Snap and Yesod.  The
tool that is broken and needs to be replaced is WASH, not Haskell.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

Hi Ertugrul,

 Well, it is a rant, so you can just as well concede it. =)

By my standards that was a lullaby ;-)

Everything you said is correct. Just like everything I said.

The best policy lies between the two extremes. Your extreme would be fine
if Haskell presented itself as a purely theoretical research tool. But it
actually wants people to use it for stuff that peoples' livelihoods depend
on.

So there are some shiny new frameworks out there which unlike WASH didn't
break yet. Thanks for the pointers. I tripped over blaze a moment ago (so
no I didn't stomp back to PHP after all) which mentions something called
Snap. I'll check out your other suggestions too.

But what about two years from now? Will they still be working by then or
will their developers have got just as sick of continually moving goalposts
as those of WASH evidently did? Or would I be taking on the job of
maintaining it myself? I guess you'll be telling me that Happstack is a bad
habit of mine and I should rewrite my whole system in whatever the new
thing is by then.

I mentioned this trade-off that you talk about towards the end of my
rantaby. It's true that we can't have the best of both worlds but perhaps a
little restraint would be appropriate. I mean, are you saying that Haskell
was really bad when it could make up its mind what import Prelude meant?
If you really want to change something that basic, how about calling the
new one Prelude2? I kinda liked Haskell even in 1998. I just don't see why
switching new things on has to mean switching old things off. You can't
have your cake and eat it, but I see no reason to shit all over one half of
the cake just because you're more interested in the other half.

Also, there's no real value in blaming these problems on the maintainers
for retaining the bad habits that they learned from Haskell. The reality
is that the forums are crammed with people suffering this kind of thing. It
doesn't make a difference who you blame. Either way, the ecosystem looks
untrustworthy, so fewer people will adopt it, and it'll be retreating from
its original stated goal, which IIRC was to be a standard and widely used
FL. It might be very rigorous and clever, but that's not much use if it's
only being used by the people who have a full time job making it even
cleverer.

Not a lot of people in industry are using Haskell. More are using Erlang,
Ocaml, XSL, J#, etc so it can't be just because they're scared of FP. If
you'd rather see more using Haskell, I strongly suggest you get a grip on
what real companies actually have to worry about. It ain't mathematical
rigour. Backward compatibility is a big chunk of it.

Adrian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Alexander V Vershilov

Hello.


On 2 May 2013 14:33, Adrian May adrian.alexander@gmail.com wrote:

 Hi Ertugrul,

  Well, it is a rant, so you can just as well concede it. =)

 By my standards that was a lullaby ;-)

 Everything you said is correct. Just like everything I said.

 The best policy lies between the two extremes. Your extreme would be fine
 if Haskell presented itself as a purely theoretical research tool. But it
 actually wants people to use it for stuff that peoples' livelihoods depend
 on.


There are 2 extremes: 1). [enterprise extream] do thing once - let it work
forever without changes, 2). [developer extreme] - change your applications
in a continuous way. Both extremes are not right: first hides a problem,
and when a problem got revealed everything is so terribly broken that you
need to start from the begining, second extreme require work on things as
soon as environment changes (dependencies updates, libraries changes, bugs
revealed and fixed). The correct way is scheduled upgrade and Haskell in
very close to it. If you see a bug or missfieature or improvement, and it's
better - deprecate old, and do changes, then give a time gap for others to
fix. That is a really good way, if you have to do changes it means that
smth have not done right. As for WASH it has extremely long gap to be
fixed, and it simply should be fixed without any philosophical letters to
ML.

So there are some shiny new frameworks out there which unlike WASH didn't
 break yet. Thanks for the pointers. I tripped over blaze a moment ago (so
 no I didn't stomp back to PHP after all) which mentions something called
 Snap. I'll check out your other suggestions too.

 But what about two years from now? Will they still be working by then or
 will their developers have got just as sick of continually moving goalposts
 as those of WASH evidently did? Or would I be taking on the job of
 maintaining it myself? I guess you'll be telling me that Happstack is a bad
 habit of mine and I should rewrite my whole system in whatever the new
 thing is by then.

 I mentioned this trade-off that you talk about towards the end of my
 rantaby. It's true that we can't have the best of both worlds but perhaps a
 little restraint would be appropriate. I mean, are you saying that Haskell
 was really bad when it could make up its mind what import Prelude meant?
 If you really want to change something that basic, how about calling the
 new one Prelude2? I kinda liked Haskell even in 1998. I just don't see why
 switching new things on has to mean switching old things off. You can't
 have your cake and eat it, but I see no reason to shit all over one half of
 the cake just because you're more interested in the other half.

 Also, there's no real value in blaming these problems on the maintainers
 for retaining the bad habits that they learned from Haskell. The reality
 is that the forums are crammed with people suffering this kind of thing. It
 doesn't make a difference who you blame. Either way, the ecosystem looks
 untrustworthy, so fewer people will adopt it, and it'll be retreating from
 its original stated goal, which IIRC was to be a standard and widely used
 FL. It might be very rigorous and clever, but that's not much use if it's
 only being used by the people who have a full time job making it even
 cleverer.


At least in Gentoo you can just use a wrapper for haskell packages there
are ~600-700 pkgs like in debian but with difference that they can be built
on ghc-6.1(not everytime), 7.4, 7.6, and some on HEAD, and we use frontline
versions (latest available+some more for quickly changing packages) is
used. All packages are patched accordingly if compatibility between them is
broken and we tries to send patches upstream.

Not a lot of people in industry are using Haskell. More are using Erlang,
 Ocaml, XSL, J#, etc so it can't be just because they're scared of FP. If
 you'd rather see more using Haskell, I strongly suggest you get a grip on
 what real companies actually have to worry about. It ain't mathematical
 rigour. Backward compatibility is a big chunk of it.

 Adrian.



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe




-- 
Alexander
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread John Lato

On Thu, May 2, 2013 at 5:30 PM, Ertugrul Söylemez e...@ertes.de wrote:


 To express this question in a broader context:  Are you leaving a broken
 tool and replacing it with a new shiny one?


So I read the original post, and it really wasn't clear to me what exact
changes were causing the issues; I don't think I'm alone in thinking the OP
could have been a bit more explicit about the nature of the problem.  Also,
at least Flippa is explicitly unmaintained (according to the first hit
googling Flippa Haskell), and I hadn't seen mention of WASH for a year or
more.  And of course, ghc-7.0 was released 2.5 years ago, ghc-7.6 is the
current version, and there's been ample time for incompatibilities to
accumulate.

Despite those issues I'm rather sympathetic to the OP, in part because most
of these breaking changes aren't replacing a broken tool.  If the
Functor/Applicative/Monad hierarchy were fixed it would cause a lot of
breakage, and I (like many of us I'm sure) would have to update a lot of
packages, but I wouldn't mind because that would be a clear improvement.
But replacing import List with import Data.List?  That's not even a
problem.  Consider another breaking change, requiring newtype constructors
be in scope for foreign imports.  This required a lot of code churn,
especially as IIRC the CDouble constructor wasn't exported previously (for
reasons of abstraction, which I can also rant about), so of course it
wouldn't have been in explicit import lists.  At least this has some
marginal utility if you care about Safe Haskell.

I did a lot of work to get packages compilable with ghc-7.6 and submitted
patches to probably a dozen different repos.  Aside from one exception
(related to the FFI), every breaking change was either related to
namespacing/import issues, or bumping versions in .cabal files (I consider
the whole try/catch mess to be an import issue, although at least in that
case the benefit is more obvious).  Two pragmas existed that duplicate
functionality, one was deprecated in the last release and now the other one
is deprecated while the first has been un-deprecated.  It's just
rearranging deck chairs.  It doesn't feel like a significant improvement,
and it's even harder to bill as one.

I don't think there's anything wrong with moving at a fast pace, nor do I
think backwards compatibility should be maintained in perpetuity.
Unfortunately this leaves a lot of scope for migrations to be handled
poorly, and for unintended consequences of shiny new systems.  IMHO both
have caused issues for Haskell developers and users in the recent and more
distant past.  This is an issue where I think the community should
continually try to improve, and if a user calls out a difficulty we should
at least try to learn from it and not repeat the same mistake.

(Unfortunately I'm not really sure what we can learn from this particular
case, but maybe somebody wiser than me could point the way)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

Adrian May adrian.alexander@gmail.com wrote:

 [...] If you'd rather see more using Haskell, I strongly suggest you
 get a grip on what real companies actually have to worry about. It
 ain't mathematical rigour. Backward compatibility is a big chunk of
 it.

I'm not saying that you are wrong, but you may be looking at it from the
wrong angle:  Unmaintained projects depending on one of the major web
frameworks still compile today.  The strong version constraints used by
packages and taught by the package versioning policy makes this
possible.  When you install it, it does the right thing.

WASH on the other hand is really a legacy from the stone age of real
world development in Haskell.  As said, I'm surprised that you could
even compile it today.  I consider it a proof of concept that web
application development is very possible with Haskell and the community
has moved on to implement real web frameworks made for production use.

This happens for all languages, not only Haskell.  You may find that one
or the other C/C++ package breaks with GCC 4 when it compiled just fine
with GCC 2.  This is why we have the major/minor/patch-level split in
the first place.  You can't expect that nothing will break when you
update from GCC 3 to GCC 4.  The same holds for GHC and even for
strongly keep-being-retarded language implementations like PHP.

At some (quite recent) point in time the whole language was revised and
is called Haskell 2010 now.  You can still compile with Haskell 98 and
many old packages should still work, unless they are broken by the new
base library.  With the new language it's simply that the type system
has changed in an incompatible way.  It's not that features have been
removed, but simply that you have to express them differently now.  This
is most noticable for local bindings, but you will also find that the
base library has undergone some breaking changes.  This was the most
legacy-breaking change I can remember, but it was necessary.  We all
suffered from bad decisions made in the old days.  This is also likely
the change that broke WASH.

Other than this the Haskell ecosystem is actually comparatively stable.
It is so stable that actually we run into another problem, which we
refer to as the Cabal Dependency Hell.  Semisolutions like cabal-dev are
available, but we really need to do some work here.  This is probably
the weakest part of the Haskell ecosystem right now.  However, it's also
actually a very hard problem.  Other languages have the same problem,
but they fix it by ignoring it.  Programmers in those languages just
pretend that it's impossible to install multiple versions of the same
package, but if operating systems like NixOS gain more popularity they
will have to reconsider their philosophy when they face sudden
segfaults.  Haskell's Cabal would have warned them.  They don't have
such a tool.

In other words, you are likely suffering from the one big breaking
change made in Haskell's modern history (i.e. post 1998).  Don't be
discouraged by that and enjoy the improved language and base library.
Enjoy an ecosystem that acknowledges the existence of problems and the
tools you get to find a solution that fits you.  You are going into the
right direction now. =)


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

John Lato jwl...@gmail.com wrote:

 I don't think there's anything wrong with moving at a fast pace, nor
 do I think backwards compatibility should be maintained in perpetuity.

I think this statement pretty much covers the mindset of the Haskell
community and also explains the higher breakage rate of Haskell packages
when compared to other languages, in particular non-static ones:  We
move at a very fast pace.  Innovations are made all the time.  Without
this feature we wouldn't be where we are today.

Of course Haskell, being a rigorously static and correct language and a
community that equally rigorously insists on correctness of design
patterns we have to live with the fact that we need to fix the breakages
we introduce, and we do that.  This is a good thing.


 Unfortunately this leaves a lot of scope for migrations to be handled
 poorly, and for unintended consequences of shiny new systems.  IMHO
 both have caused issues for Haskell developers and users in the recent
 and more distant past.  This is an issue where I think the community
 should continually try to improve, and if a user calls out a
 difficulty we should at least try to learn from it and not repeat the
 same mistake.

I think we do that.  The most severe breakages are introduced by new GHC
versions.  That's why there is the Haskell Platform.  If users decide to
move to new versions sooner they should be prepared to handle the
breakages.  In particular a Haskell beginner simply shouldn't use
GHC-HEAD.  Our type system makes us aware of the breakages we introduce
and gives us the opportunity to fix them properly before exposing them
to the users.

With this in mind I don't think there is anything to learn from this
particular case.  You wouldn't use WASH today for the same reasons you
wouldn't use Linux 0.x.  It's a legacy, and the ideas from it have
inspired the more recent web frameworks, which are more convenient,
faster, more real-world-oriented.  In fact I totally expect a new
generation of web frameworks to pop up in the future, more categorical,
even more convenient and less error-prone.


Greets,
Ertugrul

-- 
Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Brandon Allbery

On Thu, May 2, 2013 at 1:27 AM, Adrian May
adrian.alexander@gmail.comwrote:

 Let's face it: this decision to change the default syntax in GHC7 means
 that right now Haskell looks about as stable as Ruby on Rails.

 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
 persisted for a while but gave up because getPackageId doesn't exist in any
 form at all anymore. This was only the install script: what would WASH
 itself have in store for me to get my brain around?


I'm going to give you the flip side of this one.

I've been active in the Perl community (admittedly in something of an off
and on fashion for health reasons) for years. Perl 5 is in some ways the
epitome of maintain backward compatibility: there is a lot of Perl code
out there that was written under Perl 4 or earlier. (cpanel, I'm looking at
you. Among others. I recently got to debug some code related to someone's
RADIUS server that looked like it hadn't been touched since perl3.)

And this is the direct cause of the Perl ecosystem being a sewer. Nobody is
willing to take the step of making Perl default to the eminently sane
behavior of checking for invalid inputs, because it will break too much
existing (already horribly broken, in reality) code. Nobody will risk
disabling the walking security hole and encouragement of sloppy, buggy code
that is Perl's 2-argument open(). (If you ever wondered why Perl 6 decided
to throw out source compatibility, here's your reason.)

The Haskell98 ecosystem wasn't nearly that bad, but maintaining
compatibility with it did prevent fixing various flaws in things like
exception handling. Between the two, I'd rather see older code broken in
the name of current code actually working correctly. And in Haskell I get a
lot of help from the compiler to bring that older code up to date.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

So WASH is ancient history. OK, lets forget it.

How about the Haskell Platform? Is that ancient history? Certainly not: it
doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2.
Now that's rapid maintenance, but it's still version hell because you've
got to have that compiler installed first (even though HP is supposed to be
a way to acquire haskell) and you probably haven't. You've probably got the
one from the linux package which hasn't been maintained since, ooh, must
have been at least a week ago, so you install the new one and you've
trashed cabal. How long is that puzzle gonna take to unravel? That's how I
spent my afternoon today, instead of getting on with my job. Now you might
think I was silly not to have uninstalled the linux package first, but I
tried, and then decided against it because it thought the entire OS
depended on it and actually proposed to remove everything from clib to
googleearth as a solution. It's not Haskell's fault that linux package
management is as broken as any other for the same reasons, but in an
imperfect world, it's better not to keep moving the furniture around.

Why was I trying to build the Haskell Platform at all? Because it wasn't
obvious to me that a 7 year old library would be doomed. I find it
perfectly normal to be able to compile C code from the 1970s but still run
STL through the same compiler. That's why I blamed the system instead of
the library. And unless somebody can explain to me how I would rescue my
business now if I had opted for WASH in that long-forgotten era when Barack
Obama was barely known, a Russian spy was poisoned with Polonium and a
Sudanese man was ordered to marry a goat he was caught in an intimate
position with, then I still see it that way.

Adrian.








On 2 May 2013 19:57, Ertugrul Söylemez e...@ertes.de wrote:

 John Lato jwl...@gmail.com wrote:

  I don't think there's anything wrong with moving at a fast pace, nor
  do I think backwards compatibility should be maintained in perpetuity.

 I think this statement pretty much covers the mindset of the Haskell
 community and also explains the higher breakage rate of Haskell packages
 when compared to other languages, in particular non-static ones:  We
 move at a very fast pace.  Innovations are made all the time.  Without
 this feature we wouldn't be where we are today.

 Of course Haskell, being a rigorously static and correct language and a
 community that equally rigorously insists on correctness of design
 patterns we have to live with the fact that we need to fix the breakages
 we introduce, and we do that.  This is a good thing.


  Unfortunately this leaves a lot of scope for migrations to be handled
  poorly, and for unintended consequences of shiny new systems.  IMHO
  both have caused issues for Haskell developers and users in the recent
  and more distant past.  This is an issue where I think the community
  should continually try to improve, and if a user calls out a
  difficulty we should at least try to learn from it and not repeat the
  same mistake.

 I think we do that.  The most severe breakages are introduced by new GHC
 versions.  That's why there is the Haskell Platform.  If users decide to
 move to new versions sooner they should be prepared to handle the
 breakages.  In particular a Haskell beginner simply shouldn't use
 GHC-HEAD.  Our type system makes us aware of the breakages we introduce
 and gives us the opportunity to fix them properly before exposing them
 to the users.

 With this in mind I don't think there is anything to learn from this
 particular case.  You wouldn't use WASH today for the same reasons you
 wouldn't use Linux 0.x.  It's a legacy, and the ideas from it have
 inspired the more recent web frameworks, which are more convenient,
 faster, more real-world-oriented.  In fact I totally expect a new
 generation of web frameworks to pop up in the future, more categorical,
 even more convenient and less error-prone.


 Greets,
 Ertugrul

 --
 Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de
 FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
 Keysrv: hkp://subkeys.pgp.net/

 ___
 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] Backward compatibility

2013-05-02 Thread David Thomas

If you are actively using something then keep it up to date, encourage
someone to keep it up to date, pay someone to keep it up to date, or
migrate off of it.  If you try building with a fresh set of packages every
so often, you can catch breaking changes early and deal with them when it's
typically pretty clear why things broke.
On May 2, 2013 6:33 AM, Adrian May adrian.alexander@gmail.com wrote:

 So WASH is ancient history. OK, lets forget it.

 How about the Haskell Platform? Is that ancient history? Certainly not: it
 doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2.
 Now that's rapid maintenance, but it's still version hell because you've
 got to have that compiler installed first (even though HP is supposed to be
 a way to acquire haskell) and you probably haven't. You've probably got the
 one from the linux package which hasn't been maintained since, ooh, must
 have been at least a week ago, so you install the new one and you've
 trashed cabal. How long is that puzzle gonna take to unravel? That's how I
 spent my afternoon today, instead of getting on with my job. Now you might
 think I was silly not to have uninstalled the linux package first, but I
 tried, and then decided against it because it thought the entire OS
 depended on it and actually proposed to remove everything from clib to
 googleearth as a solution. It's not Haskell's fault that linux package
 management is as broken as any other for the same reasons, but in an
 imperfect world, it's better not to keep moving the furniture around.

 Why was I trying to build the Haskell Platform at all? Because it wasn't
 obvious to me that a 7 year old library would be doomed. I find it
 perfectly normal to be able to compile C code from the 1970s but still run
 STL through the same compiler. That's why I blamed the system instead of
 the library. And unless somebody can explain to me how I would rescue my
 business now if I had opted for WASH in that long-forgotten era when Barack
 Obama was barely known, a Russian spy was poisoned with Polonium and a
 Sudanese man was ordered to marry a goat he was caught in an intimate
 position with, then I still see it that way.

 Adrian.








 On 2 May 2013 19:57, Ertugrul Söylemez e...@ertes.de wrote:

 John Lato jwl...@gmail.com wrote:

  I don't think there's anything wrong with moving at a fast pace, nor
  do I think backwards compatibility should be maintained in perpetuity.

 I think this statement pretty much covers the mindset of the Haskell
 community and also explains the higher breakage rate of Haskell packages
 when compared to other languages, in particular non-static ones:  We
 move at a very fast pace.  Innovations are made all the time.  Without
 this feature we wouldn't be where we are today.

 Of course Haskell, being a rigorously static and correct language and a
 community that equally rigorously insists on correctness of design
 patterns we have to live with the fact that we need to fix the breakages
 we introduce, and we do that.  This is a good thing.


  Unfortunately this leaves a lot of scope for migrations to be handled
  poorly, and for unintended consequences of shiny new systems.  IMHO
  both have caused issues for Haskell developers and users in the recent
  and more distant past.  This is an issue where I think the community
  should continually try to improve, and if a user calls out a
  difficulty we should at least try to learn from it and not repeat the
  same mistake.

 I think we do that.  The most severe breakages are introduced by new GHC
 versions.  That's why there is the Haskell Platform.  If users decide to
 move to new versions sooner they should be prepared to handle the
 breakages.  In particular a Haskell beginner simply shouldn't use
 GHC-HEAD.  Our type system makes us aware of the breakages we introduce
 and gives us the opportunity to fix them properly before exposing them
 to the users.

 With this in mind I don't think there is anything to learn from this
 particular case.  You wouldn't use WASH today for the same reasons you
 wouldn't use Linux 0.x.  It's a legacy, and the ideas from it have
 inspired the more recent web frameworks, which are more convenient,
 faster, more real-world-oriented.  In fact I totally expect a new
 generation of web frameworks to pop up in the future, more categorical,
 even more convenient and less error-prone.


 Greets,
 Ertugrul

 --
 Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de
 FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
 Keysrv: hkp://subkeys.pgp.net/

 ___
 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

Re: [Haskell-cafe] Backward compatibility

On Thu, May 02, 2013 at 09:26:15PM +0800, Adrian May wrote:
 How about the Haskell Platform? Is that ancient history? Certainly not: it
 doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2.

I'm uninformed in such matters, but from

http://www.haskell.org/platform/changelog.html

it looks like GHC 7.4.2 is *part* of Haskell Platform 2012.4.0.0, so it
doesn't make sense to talk about the latest Platform without 7.4.2.

I know that sounds like a technicality, but I don't think it actually is! 
The important question is whether *your* old code breaks with the latest
Platform, not whether the latest Platform breaks with GHC 7.4.1.

Tom

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility


 If you are actively using something then keep it up to date, encourage
 someone to keep it up to date, pay someone to keep it up to date, or
 migrate off of it.  If you try building with a fresh set of packages every
 so often, you can catch breaking changes early and deal with them when it's
 typically pretty clear why things broke.

Not necessarily. Let's take Flippi as an example. What seems to be
happening there is that Text.Html is incompatible with CGI.Html, or
something like that. Those are both vanilla modules that would not be under
my control. If somebody else decides to make them incompatible, there's
nothing I can do. Not without a total rewrite, but by then I might have 20
man-years invested in it. Nobody is gonna do a big project in a language
with this attitude.

What if Android were written in Haskell for instance. At the famous 10:1
ratio there'd be roughly 5 million lines of it. Nice update guys - we only
had to rewrite 100,000 lines this time. Then you'd be afraid of change cos
it would be your own phone you were breaking.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Mark Lentczner

On Thu, May 2, 2013 at 6:26 AM, Adrian May
adrian.alexander@gmail.comwrote:

 How about the Haskell Platform? Is that ancient history? Certainly not: it
 doesn't compile on anything but the very newest GHC.


I think you're missing the point of the platform! It is an explicit set of
versions, including GHC, that make a stable reference set of packages on
which to build, test, and deploy. Each version of the platform explicitly
states with equality constraints the exact version of each component so
that it will be the same for everyone.

You use the HP - with the GHC it comes with (or specifies) - as a set. You
want to use GHC 7.4.1? Use HP 2012.2.0.0. Once installed you can install
newer versions of the component packages if needed (though cabal-dev or
cabal sandboxing is strongly encouraged in such a case to avoid cabal
hell.)

And unless somebody can explain to me how I would rescue my business now if
 I had opted for WASH


By patching it. Surely we are talking about minor changes here.

- Mark
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility



 I think you're missing the point of the platform!


I suppose I did miss the point of the platform: I was trying to build it,
which requires at least part of the platform. As I say, the reason I was
trying to build it was that I wrongly blamed the ubuntu package for WASH
not working. But that was not dumb unless you consider it obvious that 7
year old code would be broken, in which case it would be obvious that
nobody would trust this language in production.

  And unless somebody can explain to me how I would rescue my business
now if I had opted for WASH
 By patching it. Surely we are talking about minor changes here.

Yeah but how many minor changes? This trigger-happiness is rife.

And that's the first time anybody suggested the necessary changes to WASH
should be minor. Everybody else thinks I was nuts to expect anything from 7
year old code. I don't know because I couldn't get past the install.
Somebody had deleted getPackageId.

Please would somebody explain to me what getPackageId did to incriminate
itself? I'm sure there's something much groovier now, like getting it
inside a monad in case it changes during the installation itself (pretty
likely AFAICT) but it's really just a package id. Can we honestly
philosophise about the mathematical rigour of getPackageId?

It was needlessly assassinated. For all I know WASH might be just fine
apart from that, and maybe I would have liked it, even if it is from the
dark ages.

Yes there are times when something has to change. I acknowledged that in my
original post. But I see no evidence whatsoever that anybody in control of
Haskell is holding fire even on things as innocent as getPackageId or as
ubiquitous as the prelude. I'm not asking for the opposite extreme of
conservatism, just a bit of common sense instead of this bloodbath.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Brandon Allbery

On Thu, May 2, 2013 at 10:36 AM, Adrian May
adrian.alexander@gmail.comwrote:

 I think you're missing the point of the platform!


 I suppose I did miss the point of the platform: I was trying to build it,
 which requires at least part of the


Having to build it already indicates that something is wrong, unless you're
porting to an unsupported OS/hardware.


 platform. As I say, the reason I was trying to build it was that I wrongly
 blamed the ubuntu package for


That said, may I point out that the Ubuntu packages *are* broken? They
shipped a mangled Platform which can't be relied on for much; instead of a
well-tested set of packages, they took a good Platform and replaced bits
with minimal testing. Yes, this has actually caused problems for people.

Yes there are times when something has to change. I acknowledged that in my
 original post. But I see no evidence whatsoever that anybody in control of
 Haskell is holding fire even on things as innocent as getPackageId or as
 ubiquitous as the prelude. I'm not asking for the opposite extreme of
 conservatism, just a bit of common sense instead of this bloodbath.


You're assuming here that someone deliberately targeted your favorite pet.
I don't know the details but I VERY STRONGLY doubt anyone said oh, we
should break that function. But I ALSO find it likely that it was the
victim of something sufficiently pervasive that the options were break it
or live with something else being broken forever, just like Perl vs.
cpanel!

This, sadly, is the real world. The holy grail of fixing bugs without
breaking any program ever anywhere is impossible, and even fix this bug
without breaking many other programs is extremely unlikely. Your choices
are this, or Perl/PHP we do not dare fix bugs or misdesigns because
someone's pet program will die.

(Other examples of this:

- Python 3. Note how many existing Python packages still require Python 2.
- The C and C++ standards are increasingly Byzantine due in large part to
backward compatibility issues; but I'm guessing from your complaints that
this is your ideal model because old programs still work. Lucky you, you
can happily pretend that it's because they have found some magical way to
do the fundamentally impossible --- right up until reality bites back.
)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Mark Lentczner

On Thu, May 2, 2013 at 7:36 AM, Adrian May
adrian.alexander@gmail.comwrote:

 I suppose I did miss the point of the platform: I was trying to build it,
 which requires at least part of the platform.


This is not for the faint of heart. Like *ALL* language distributions I
know (C++ included), boot-strapping the next rev is never easy. Consider
building the stdc and stl for version gcc x with gcc x-1 - Or trying to
assemble and test packages for python 2.x with only python 2.(x-1)

 just a bit of common sense instead of this bloodbath.


Now you're being hysterical. The changes don't rise to that level at all.
Vast swaths of haskell code have continued to work just fine over the last
many years of changes. And many more have continued to work with only
minimal maintenance.

The changes over the last several years are no more extreme than I see in
other systems. Consider that Mac OS X ships with Python2.5 and 2.6 and 2.7
all installed because of incompatibilities in the base set of libraries.

If you are comparing it C++ library stability you are being myopic: The
situation in C++ system libraries was so complex that it spurred the
monster that is autoconf! That the most common libs have settled into a
very stable set that can be expected to work over several years and major
releases, has only been true in the last decade. The prior three decades of
C (and later C++) were filled with tons of this sort of
versioning difficulty, compounded by multiple systems.

- Mark
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

On Thu, May 02, 2013 at 10:36:18PM +0800, Adrian May wrote:
 Please would somebody explain to me what getPackageId did to incriminate
 itself?

What's getPackageId?  It does not appear in the WASH source.

Tom

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility



 What's getPackageId?  It does not appear in the WASH source.


It's in Setup.lhs, in WashNGo.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

On Thu, May 02, 2013 at 11:10:33PM +0800, Adrian May wrote:
  What's getPackageId?  It does not appear in the WASH source.

 It's in Setup.lhs, in WashNGo.

Which source of WashNGo are you using?  It doesn't appear in either of these
versions:

http://hackage.haskell.org/package/WashNGo-2.12
http://hackage.haskell.org/package/WashNGo-2.12.0.1

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility



 Which source of WashNGo are you using?  It doesn't appear in either of
 these
 versions:

 http://hackage.haskell.org/package/WashNGo-2.12
 http://hackage.haskell.org/package/WashNGo-2.12.0.1


http://www.informatik.uni-freiburg.de/~thiemann/WASH/WashNGo-2.12.tgz




 ___
 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] Backward compatibility

On Thu, May 02, 2013 at 11:23:12PM +0800, Adrian May wrote:
  Which source of WashNGo are you using?  It doesn't appear in either of
  these
  versions:
 
  http://hackage.haskell.org/package/WashNGo-2.12
  http://hackage.haskell.org/package/WashNGo-2.12.0.1

 http://www.informatik.uni-freiburg.de/~thiemann/WASH/WashNGo-2.12.tgz

I get a 403 FORBIDDEN on that.  How did you get it?


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Ivan Lazar Miljenovic

On 3 May 2013 01:04, Brandon Allbery allber...@gmail.com wrote:
 On Thu, May 2, 2013 at 10:36 AM, Adrian May adrian.alexander@gmail.com
 wrote:

 I think you're missing the point of the platform!


 I suppose I did miss the point of the platform: I was trying to build it,
 which requires at least part of the

 Having to build it already indicates that something is wrong, unless you're
 porting to an unsupported OS/hardware.

Or you have a source-based distro, or you prefer building it yourself
rather than using distro packages (as they might be out of date or
b0rked), etc. ... ;-)

-- 
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] Backward compatibility

Adrian May adrian.alexander@gmail.com wrote:

 I attached the tarball. Don't say you got it from me, OK.

That's a weird thing to demand in a public mailing list with public
search-engine-locatable archives. =)


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

On Thu, May 02, 2013 at 11:35:27PM +0800, Adrian May wrote:
  I get a 403 FORBIDDEN on that.  How did you get it?

 I guess you just gotta know the right people ;-)
 
 I attached the tarball. Don't say you got it from me, OK.

That tarball still doesn't contain the string getPackageId.

You're complaining that you can't build a package, which hasn't been
maintained for several years, which you got from a secret source, and whose
whose Hackage page specifically says it doesn't build beyond GHC 7.0.  I
don't think this is indicative of a serious failure of Haskell.

Tom

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Stephen Tetley

Hi Adrian

I don't want to argue against your rant for the sake of it, but
Haskell is a fairly conservative language. The Glasgow Haskell
Compiler supports it's own dialect Glasgow Haskell which is fast
moving, but the developers of GHC do work hard to maintain
compatibility with standard Haskell 98 and Haskell 2010 (optionally
enabled with compiler flags). Afterall Haskell now is fairly widely
used as a teaching language which befits stability as course
textbooks, lecture plans etc. can't be in hock to a language that
changes every year.

Best wishes

Stephen

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Patrick Wheeler

@Adrian May if you want that much backward compatibility you probably need
to move to an operating system that suports it.

NixOS, already mentioned by another commentator,  would be
my recommendation if you really need the backward compatibility  I just
finished compiling both Flippi and WashNGo with ghc-7.0.4.

I do not want the GHC maintainers to be tied down
by maintenance concerns any more then they already are, there time is
more productively spent on concerns other then increasing
backward compatibility.

For anyone who works on GHC thank you for helping support such a great
ecosystem that enables this level of experimentation and rate of new
features.

Patrick Wheeler


On Thu, May 2, 2013 at 11:50 AM, Tom Ellis 
tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:

 On Thu, May 02, 2013 at 11:35:27PM +0800, Adrian May wrote:
   I get a 403 FORBIDDEN on that.  How did you get it?
 
  I guess you just gotta know the right people ;-)
 
  I attached the tarball. Don't say you got it from me, OK.

 That tarball still doesn't contain the string getPackageId.

 You're complaining that you can't build a package, which hasn't been
 maintained for several years, which you got from a secret source, and whose
 whose Hackage page specifically says it doesn't build beyond GHC 7.0.  I
 don't think this is indicative of a serious failure of Haskell.

 Tom

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe




-- 
Patrick Wheeler
patrick.john.whee...@gmail.com
patrick.j.whee...@rice.edu
patrick.whee...@colorado.edu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

I'm sorry: it was showPackageId. And the tarball came from this page:
http://www.informatik.uni-freiburg.de/~thiemann/WASH/ which certainly isn't
secret to Gooliath: I got it by searching for haskell cgi html. I don't
know why you can't download it.

Anyway, I've noted your opinions but today I really need to get something
done. Thanks for the discussion.

Adrian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Alexander Solla

On Thu, May 2, 2013 at 6:26 AM, Adrian May
adrian.alexander@gmail.comwrote:

 So WASH is ancient history. OK, lets forget it.

 How about the Haskell Platform? Is that ancient history? Certainly not: it
 doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2.


GHC is up to 7.6.


 Now that's rapid maintenance, but it's still version hell because you've
 got to have that compiler installed first (even though HP is supposed to be
 a way to acquire haskell) and you probably haven't. You've probably got the
 one from the linux package which hasn't been maintained since, ooh, must
 have been at least a week ago, so you install the new one and you've
 trashed cabal. How long is that puzzle gonna take to unravel?


About 12 seconds, if you read http://www.haskell.org/platform/linux.html:

Download the source tarball for Unix-like systems: here


   -  
*haskell-platform-2012.4.0.0.tar.gzhttp://lambda.haskell.org/platform/download/2012.4.0.0/haskell-platform-2012.4.0.0.tar.gz
  *
  - SHA-1: 7976508c50305969f64c721a1d095ae22efff8b7

Get and install GHC 7.4.2 prior to building the platform:


   - GHC 7.4.2 http://haskell.org/ghc/download_ghc_7_4_2.html

Finally, unpack the Haskell Platform source tarball, and run (possibly with
'sudo'):

./configure

make

make install
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Carter Schonwald

Emphatic agreement on this point.

Likewise, the strong type system and the often helpful type error messages
make it really easy to update code to work with more modern libs!

-Carter


On Thu, May 2, 2013 at 9:39 AM, David Thomas davidleotho...@gmail.comwrote:

 If you are actively using something then keep it up to date, encourage
 someone to keep it up to date, pay someone to keep it up to date, or
 migrate off of it.  If you try building with a fresh set of packages every
 so often, you can catch breaking changes early and deal with them when it's
 typically pretty clear why things broke.
  On May 2, 2013 6:33 AM, Adrian May adrian.alexander@gmail.com
 wrote:

 So WASH is ancient history. OK, lets forget it.

 How about the Haskell Platform? Is that ancient history? Certainly not:
 it doesn't compile on anything but the very newest GHC. Not 7.4.1 but
 7.4.2. Now that's rapid maintenance, but it's still version hell because
 you've got to have that compiler installed first (even though HP is
 supposed to be a way to acquire haskell) and you probably haven't. You've
 probably got the one from the linux package which hasn't been maintained
 since, ooh, must have been at least a week ago, so you install the new one
 and you've trashed cabal. How long is that puzzle gonna take to unravel?
 That's how I spent my afternoon today, instead of getting on with my job.
 Now you might think I was silly not to have uninstalled the linux package
 first, but I tried, and then decided against it because it thought the
 entire OS depended on it and actually proposed to remove everything from
 clib to googleearth as a solution. It's not Haskell's fault that linux
 package management is as broken as any other for the same reasons, but in
 an imperfect world, it's better not to keep moving the furniture around.

 Why was I trying to build the Haskell Platform at all? Because it wasn't
 obvious to me that a 7 year old library would be doomed. I find it
 perfectly normal to be able to compile C code from the 1970s but still run
 STL through the same compiler. That's why I blamed the system instead of
 the library. And unless somebody can explain to me how I would rescue my
 business now if I had opted for WASH in that long-forgotten era when Barack
 Obama was barely known, a Russian spy was poisoned with Polonium and a
 Sudanese man was ordered to marry a goat he was caught in an intimate
 position with, then I still see it that way.

 Adrian.








 On 2 May 2013 19:57, Ertugrul Söylemez e...@ertes.de wrote:

 John Lato jwl...@gmail.com wrote:

  I don't think there's anything wrong with moving at a fast pace, nor
  do I think backwards compatibility should be maintained in perpetuity.

 I think this statement pretty much covers the mindset of the Haskell
 community and also explains the higher breakage rate of Haskell packages
 when compared to other languages, in particular non-static ones:  We
 move at a very fast pace.  Innovations are made all the time.  Without
 this feature we wouldn't be where we are today.

 Of course Haskell, being a rigorously static and correct language and a
 community that equally rigorously insists on correctness of design
 patterns we have to live with the fact that we need to fix the breakages
 we introduce, and we do that.  This is a good thing.


  Unfortunately this leaves a lot of scope for migrations to be handled
  poorly, and for unintended consequences of shiny new systems.  IMHO
  both have caused issues for Haskell developers and users in the recent
  and more distant past.  This is an issue where I think the community
  should continually try to improve, and if a user calls out a
  difficulty we should at least try to learn from it and not repeat the
  same mistake.

 I think we do that.  The most severe breakages are introduced by new GHC
 versions.  That's why there is the Haskell Platform.  If users decide to
 move to new versions sooner they should be prepared to handle the
 breakages.  In particular a Haskell beginner simply shouldn't use
 GHC-HEAD.  Our type system makes us aware of the breakages we introduce
 and gives us the opportunity to fix them properly before exposing them
 to the users.

 With this in mind I don't think there is anything to learn from this
 particular case.  You wouldn't use WASH today for the same reasons you
 wouldn't use Linux 0.x.  It's a legacy, and the ideas from it have
 inspired the more recent web frameworks, which are more convenient,
 faster, more real-world-oriented.  In fact I totally expect a new
 generation of web frameworks to pop up in the future, more categorical,
 even more convenient and less error-prone.


 Greets,
 Ertugrul

 --
 Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de
 FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
 Keysrv: hkp://subkeys.pgp.net/

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Alexander Solla




 Now that's rapid maintenance, but it's still version hell because you've
 got to have that compiler installed first (even though HP is supposed to be
 a way to acquire haskell) and you probably haven't. You've probably got the
 one from the linux package which hasn't been maintained since, ooh, must
 have been at least a week ago, so you install the new one and you've
 trashed cabal. How long is that puzzle gonna take to unravel?


 About 12 seconds, if you read http://www.haskell.org/platform/linux.html:

 Download the source tarball for Unix-like systems: here


-  
 *haskell-platform-2012.4.0.0.tar.gzhttp://lambda.haskell.org/platform/download/2012.4.0.0/haskell-platform-2012.4.0.0.tar.gz
   *
   - SHA-1: 7976508c50305969f64c721a1d095ae22efff8b7

 Get and install GHC 7.4.2 prior to building the platform:


- GHC 7.4.2 http://haskell.org/ghc/download_ghc_7_4_2.html

 Finally, unpack the Haskell Platform source tarball, and run (possibly
 with 'sudo'):

 ./configure

 make

 make install


Also, the Haskell Platform ./configure step checks which version of GHC you
have installed, and requires you to pass the option --enable-*unsupported*-*
ghc*-version in order to compile it with anything other than GHC 7.4.2.

Did you try an unsupported version?  And now you're complaining?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility



 Also, the Haskell Platform ./configure step checks which version of GHC
 you have installed, and requires you to pass the option --enable-*
 unsupported*-*ghc*-version in order to compile it with anything other
 than GHC 7.4.2.

 Did you try an unsupported version?  And now you're complaining?


This is getting into minutia now, but yes I tried the unsupported flag and
as I already explained it barfed about the prelude. So I installed 7.4.2
from source but that confused cabal because my attempt to uninstall the
ubuntu package with 7.4.1 in had failed with dependency-hell. Figuring out
why (or even that) my packages weren't being seen was the puzzle I was
referring to. The point is that we wouldn't have to be talking about this
at all if people didn't move the furniture around all the time.

 Likewise, the strong type system and the often helpful type error
messages
 make it really easy to update code to work with more modern libs!

I'm also a big fan of the error messages, but it's nice to know if I caused
them or somebody else did.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility

2013-05-02 Thread Alexander Solla

On Thu, May 2, 2013 at 8:43 PM, Adrian May
adrian.alexander@gmail.comwrote:


 Also, the Haskell Platform ./configure step checks which version of GHC
 you have installed, and requires you to pass the option --enable-*
 unsupported*-*ghc*-version in order to compile it with anything other
 than GHC 7.4.2.

 Did you try an unsupported version?  And now you're complaining?


 This is getting into minutia now, but yes I tried the unsupported flag and
 as I already explained it barfed about the prelude.


How is it minutia that you expect an unsupported version of GHC to work?

Yes, I try it out sometimes.  And if it works, great.  If not, too bad,
I'll wait until the next Haskell Platform.  I don't whine about it in
public.


 So I installed 7.4.2 from source but that confused cabal because my
 attempt to uninstall the ubuntu package with 7.4.1 in had failed with
 dependency-hell. Figuring out why (or even that) my packages weren't being
 seen was the puzzle I was referring to.


So the complaint is about Ubuntu?


 The point is that we wouldn't have to be talking about this at all if
 people didn't move the furniture around all the time.


That's not a very good point. It sounds as though you're the one who moved
furniture around, considering that you managed to mix up Ubuntu's GHC
package with your hand-built ones.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backward compatibility