Language Change Management (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

[Herbert Valerio Riedel]

On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote:
> 2015-10-05 11:59 GMT+02:00 Simon Thompson <s.j.thompson at kent.ac.uk>:
>
>> [...] It’s really interesting to have this discussion, which pulls in all
>> sorts of well-made points about orthogonality, teaching, the evolution of
>> the language and so on, but it simply goes to show that the process of
>> evolving Haskell is profoundly broken. [...]
>>
>
> I wouldn't necessarily call the process "broken", but it's a bit
> annoying: Because of the constant flux of minor changes in the
> language and the libraries, I've reached the stage where I'm totally
> unable to tell if my code will work for the whole GHC 7.x series. The
> only way I see is doing heavy testing on Travis CI and littering the
> code with #ifdefs after compilation failures. (BTW: Fun exercise: Try
> using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for
> keeping the #ifdefs centralized.  No clue how to do that...) This is
> less than satisfactory IMHO, and I would really prefer some other mode
> for introducing such changes: Perhaps these should be bundled and
> released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way
> some stuff which belongs together (AMP, FTP, kicking out return, etc.)
> comes in slightly larger, but more sensible chunks.
>
> Don't get me wrong: Most of the proposed changes in itself are OK and
> should be done, it's only the way they are introduced should be
> improved...

I think that part of the reason we have seen these changes occur in a
"constant flux" rather than in bigger coordinated chunks is that faith
in the Haskell Report process was (understandably) abandoned. And
without the Haskell Report as some kind of "clock generator" with which
to align/bundle related changes into logical units, changes occur
whenever they're proposed and agreed upon (which may take several
attempts as we've seen with the AMP and others).

I hope that the current attempt to revive the Haskell Prime process will
give us a chance to clean up the unfinished intermediate `base-4.8`
situation we're left with now after AMP, FTP et al, as the next Haskell
Report revision provides us with a milestone to work towards.

That being said, there's also the desire to have changes field-tested by
a wide audience on a wide range before integrating them into a Haskell
Report. Also I'm not sure if there would be less complaints if
AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on
all at once in e.g. `base-5.0`, breaking almost *every* single package
out there at once.

For language changes we have a great way to field-test new extensions
before integrating them into the Report via `{-# LANGUAGE #-}` pragmas
in a nicely modular and composable way (i.e. a package enabling a
certain pragma doesn't require other packages to use it as well) which
have proven to be quite popular.

However, for the library side we lack a comparable mechanism at this
point. The closest we have, for instance, to support an isolated
Haskell2010 legacy environment is to use RebindableSyntax which IMO
isn't good enough in its current form[1]. And then there's the question
whether we want a Haskell2010 legacy environment that's isolated or
rather shares the types & typeclasses w/ `base`. If we require sharing
types and classes, then we may need some facility to implicitly
instanciate new superclasses (e.g. implicitly define Functor and
Applicative if only a Monad instance is defined). If we don't want to
share types & classes, we run into the problem that we can't easily mix
packages which depend on different revisions of the standard-library
(e.g. one using `base-4.8` and others which depend on a legacy
`haskell2010` base-API).  One way to solve this could be to mutually
exclude depending on both , `base-4.8` and `haskell2010`, in the same
install-plan (assuming `haskell2010` doesn't depend itself on
`base-4.8`)

In any case, I think we will have to think hard how to address
language/library change management in the future, especially if the
Haskell code-base continues to grow. Even just migrating the code base
between Haskell Report revisions is a problem. An extreme example
is the Python 2->3 transition which the Python ecosystem is still
suffering from today (afaik). Ideas welcome!



 [1]: IMO, we need something to be used at the definition site providing
      desugaring rules, rather than requiring the use-site to enable a
      generalised desugaring mechanism; I've been told that Agda has an
      interesting solution to this in its base libraries via 
      {-# LANGUAGE BUILTIN ... #-} pragmas.


Regards,
  H.V.Riedel