Please excuse the delay in replying; the recent pandemic got me a bit distracted.
On 2020-02-29 at 19:54:12 -0500, Cale Gibbard wrote:
> Is there a list of differences between the Haskell 2020 draft
> implementation package and the libraries in base?
Yes, mostly the Foldable/Traversable related changes haven't been integrated
yet as I pointed out in step "1.)"
...and obviously hundreds of extra modules which simply don't exist in
I can try to find some time to review base-4.15 against the
`haskell2020`-package-subset to see what I missed besides the FTP
> I would hope that by the time H2020 gets published, that list is
> approximately empty (apart from possible intentional exclusions from
> the Report?),
Ok, this covers a detail which I haven't re-iterated yet, specifically
the relationship between `base` and the haskell-report:
The original idea I had in mind was to define the haskell-report in a
way, that there is a way to write "standard Haskell" programs in a way
such that a compliant implementation will be able to succesfully
compile/interprete the program.
There's the trivial way to achieve this, by demanding that a haskell
implementation provides a "strict" mode which only provides the exact
set of definitions with the exact same type-signatures as the haskell
For Haskell2010 this could roughly be achieved with GHC 7.0.4 by setting
`-XHaskell2010` *and* depending on the `haskell2010` package (while
*not* depending on `base` which would clash with it).
The `base` library traditionally contains a large superset of the
Haskell Lib Report mandated API; just like GHC by default doesn't
operate in a strict Haskell2010 mode (if you don't set -XHaskell2010 you
get a subtly different "default" language mode whose meaning may change
between major versions of GHC).
Consequently, you can't expect a program written naively against the API
defined in the Haskell report to be guaranteed to be compilable against
GHC if you don't take some measures.
However, we can define a less-strict compatibility mode/contract, by
stating that a compliant implementation may also provide extensions
relative to the Haskell Report, and that Haskell2020 programs adhering to a couple
"compatibility rules" are guaranteed to be compilable by such an
implementation. Such rules could be:
`base` Modules may export additional functions that aren't defined in
the report which have a risk of clashing with local defined ones; hence
1.) Use defensive `imports` for H2020 modules other than `Prelude`
(i.e. use either explicit import lists or qualified imports)
Since we may want to have the Haskell Report avoid certain language
warts such as a redundant `Monad(return)` method (and we might instead
merely provide a top-level function `return :: Monad m => a -> m a` for
legacy compat), or maybe some methods will just be omitted completely
(e.g. if we added Semigroup, we might opt to not include
Semigroup(sconcat) to avoid having to drag in `Data.List.NonEmpty` into
But the compiler-implementation might opt to promote some
class-constrained functions into class-methods (of classes defined in
the Haskell Report) or define additional class-methods (which must then
have default implementations)
2a.) Programs must be written defensive against class-constrained
functions being promoted into respective class-methods.
2b.) Use explicit class-method imports; avoid importing class-method via
wildcards (e.g. `Monad(..)`) as the set of imported symbols may be
larger than the set of methods defined in the report
In other words, since the purpose of a standard is to be able to write a
program against the standard, and have it compatible with any given
compiler that comforms to the standard, an approach like above would
IMO give enough flexibility to define a "clean" haskell report, while
allowing implementations a certain level of flexibility in adding
"benign" extensions to the APIs within certain limits.
> either by releasing changes to base ahead of it to whatever extent
> that's possible, or by documenting things as-is even though we expect
> them to change in future versions of base. I think a lot of the
> trouble with the Haskell Report process stalling out historically has
> been that it hasn't really been treated as a
> documentation-of-what-already-exists project.
Yes; and by now we have accumulated so many deltas over a decade that
IMO we need to do a big monolithic update rather than try the IMO
hopeless approach of trying to incrementally replay all the changes in
small individual RFCs... but once we have synced up, we can certainly
try to be more principled like what you seem to suggest by tracking
changes to base more closely in a "live" draft of the haskell report --
but that's the future; I'd like to focus on the current goal of syncing
up to a Haskell2020 state to fix this technical-debt at last...
> It's way easier to decide how to document stuff when that stuff is a
> known quantity.
> The ideal version of how it would work in my head is that the Report
> would be in some form of version control,
That's already the case (i.e. we have it under version control already)
> and once changes landed in GHC and/or base, we'd then be able to have
> PRs making corresponding changes to the Report, along with ongoing
> corrections and clarifications (and especially keen people making
> proposals about changes to GHC or libraries could optionally supply
> WIP PRs against the Report where it would be affected). Reports could
> be produced monthly or weekly or continuously at that point, because
> it's just a matter of pointing at a hash of the repo and building the
> PDFs/HTML/whatever artifacts.
Sure, I even started working on the CI for that, see
that would produce pdfs & html -- I just need a target to publish them
to (and hack up the respective scripting). Afaik, readthedocs.org
doesn't support LaTex otherwise we could just use that and I'm not sure
if there's is currently a readthedocs-like service for LaTex documents.
> That's not to say that we can't remark on changes to base that we
> expect to see happen in the future in the Report, but I would say
> let's try to make sure we're documenting reality first, and that way
> we can worry about potential futures in a separate process that's a
> bit closer to the tangible running code.
The long-standing plan I outlined above about defining a library report
that represents a clean subset of the `base` library while making sure
to avoid having to keep warts (such as `Monad(return)`) by giving enough
rope for an implementation to diverge in benign ways would IMO get us to
the point of "documenting reality" -- but I strongly oppose documenting
`base` as-is w/o making any effort at cleaning it up.
Note that the `haskell2020` package is evidence that we *can* provide a
compatibility-layer that strictly (except when additional typeclass
instances are exposed as we can't control their re-export) implements a
clean subset of the full `base` -- including hiding class methods we
don't want to be visible as methods.
"Elegance is not optional" -- Richard O'Keefe