<div dir="ltr"><div>Thanks for splitting this off, as it really deserves its own conversation.</div><div><br></div><div>% find cryptol -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l</div><div>      49</div><div>% find saw-script -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l</div><div>     242</div><div><br></div><div>I introduced most of these in order to accommodate AMP, and now I learn that there is another proposal that is considered to be part-and-parcel with AMP where I will have to make yet more changes to the same code and presumably introduce another layer of #ifdefs. As proposed, I will spend 2*n hours implementing, testing, and releasing these changes. Had both changes been bundled, it would have been 2*(n+ε).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px"> Also I'm not sure if there would be less complaints if </span><span style="font-size:12.8px">AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on </span><span style="font-size:12.8px">all at once in e.g. `base-5.0`, breaking almost *every* single package </span><span style="font-size:12.8px">out there at once.</span></blockquote><div><br></div><div>I doubt the number of complaints-per-change would be fewer, but I'm strongly in favor of moving away from what feels like a treadmill that doesn't value the time of developers and that doesn't account for the more-than-sum-of-parts cost of the "constant flux".</div><div><br></div><div>Thanks,</div><div>Adam<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 5, 2015 at 7:32 AM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote:<br>
> 2015-10-05 11:59 GMT+02:00 Simon Thompson <<a href="mailto:s.j.thompson@kent.ac.uk">s.j.thompson@kent.ac.uk</a>>:<br>
><br>
>> [...] It’s really interesting to have this discussion, which pulls in all<br>
>> sorts of well-made points about orthogonality, teaching, the evolution of<br>
>> the language and so on, but it simply goes to show that the process of<br>
>> evolving Haskell is profoundly broken. [...]<br>
>><br>
><br>
> I wouldn't necessarily call the process "broken", but it's a bit<br>
> annoying: Because of the constant flux of minor changes in the<br>
> language and the libraries, I've reached the stage where I'm totally<br>
> unable to tell if my code will work for the whole GHC 7.x series. The<br>
> only way I see is doing heavy testing on Travis CI and littering the<br>
> code with #ifdefs after compilation failures. (BTW: Fun exercise: Try<br>
> using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for<br>
> keeping the #ifdefs centralized.  No clue how to do that...) This is<br>
> less than satisfactory IMHO, and I would really prefer some other mode<br>
> for introducing such changes: Perhaps these should be bundled and<br>
> released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way<br>
> some stuff which belongs together (AMP, FTP, kicking out return, etc.)<br>
> comes in slightly larger, but more sensible chunks.<br>
><br>
> Don't get me wrong: Most of the proposed changes in itself are OK and<br>
> should be done, it's only the way they are introduced should be<br>
> improved...<br>
<br>
I think that part of the reason we have seen these changes occur in a<br>
"constant flux" rather than in bigger coordinated chunks is that faith<br>
in the Haskell Report process was (understandably) abandoned. And<br>
without the Haskell Report as some kind of "clock generator" with which<br>
to align/bundle related changes into logical units, changes occur<br>
whenever they're proposed and agreed upon (which may take several<br>
attempts as we've seen with the AMP and others).<br>
<br>
I hope that the current attempt to revive the Haskell Prime process will<br>
give us a chance to clean up the unfinished intermediate `base-4.8`<br>
situation we're left with now after AMP, FTP et al, as the next Haskell<br>
Report revision provides us with a milestone to work towards.<br>
<br>
That being said, there's also the desire to have changes field-tested by<br>
a wide audience on a wide range before integrating them into a Haskell<br>
Report. Also I'm not sure if there would be less complaints if<br>
AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on<br>
all at once in e.g. `base-5.0`, breaking almost *every* single package<br>
out there at once.<br>
<br>
For language changes we have a great way to field-test new extensions<br>
before integrating them into the Report via `{-# LANGUAGE #-}` pragmas<br>
in a nicely modular and composable way (i.e. a package enabling a<br>
certain pragma doesn't require other packages to use it as well) which<br>
have proven to be quite popular.<br>
<br>
However, for the library side we lack a comparable mechanism at this<br>
point. The closest we have, for instance, to support an isolated<br>
Haskell2010 legacy environment is to use RebindableSyntax which IMO<br>
isn't good enough in its current form[1]. And then there's the question<br>
whether we want a Haskell2010 legacy environment that's isolated or<br>
rather shares the types & typeclasses w/ `base`. If we require sharing<br>
types and classes, then we may need some facility to implicitly<br>
instanciate new superclasses (e.g. implicitly define Functor and<br>
Applicative if only a Monad instance is defined). If we don't want to<br>
share types & classes, we run into the problem that we can't easily mix<br>
packages which depend on different revisions of the standard-library<br>
(e.g. one using `base-4.8` and others which depend on a legacy<br>
`haskell2010` base-API).  One way to solve this could be to mutually<br>
exclude depending on both , `base-4.8` and `haskell2010`, in the same<br>
install-plan (assuming `haskell2010` doesn't depend itself on<br>
`base-4.8`)<br>
<br>
In any case, I think we will have to think hard how to address<br>
language/library change management in the future, especially if the<br>
Haskell code-base continues to grow. Even just migrating the code base<br>
between Haskell Report revisions is a problem. An extreme example<br>
is the Python 2->3 transition which the Python ecosystem is still<br>
suffering from today (afaik). Ideas welcome!<br>
<br>
<br>
<br>
 [1]: IMO, we need something to be used at the definition site providing<br>
      desugaring rules, rather than requiring the use-site to enable a<br>
      generalised desugaring mechanism; I've been told that Agda has an<br>
      interesting solution to this in its base libraries via<br>
      {-# LANGUAGE BUILTIN ... #-} pragmas.<br>
<br>
<br>
Regards,<br>
  H.V.Riedel<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div><br></div>