Haskell2020 library definition, a new hope
63 views
Skip to first unread message
Herbert Valerio Riedel
Feb 29, 2020, 6:02:34 PM2/29/20
to core-librari...@haskell.org
Hello fellow CLC members,
Now that the new composition of the Core library committee has
crystallized (except maybe for the minor detail of inner degree of
freedom regarding seating accommodations...), I'd like to get us going
with a concrete and very achievable mission:
Let us consolidate the last decade of proposed base library proposals
into what could be regarded the "Haskell 2020 Library Report"!
Let me expand a bit more: As you might remember, when the Haskell 2020
committee was formed[1], the CLC was tasked with updating/defining the
base library part of the report:
| The Haskell 2020 committee is a language committee; it will focus its
| efforts on specifying the Haskell language itself. Responsibility for
| the libraries laid out in the Report is left to the Core Libraries
| Committee (CLC)
And while things haven't been worked out in the original timeline
envisioned, I'd like to give this a new try, especially given the
currently encouraging positive reception[2] of the Monad-of-no-return
proposal.
What I'm proposing here is subtly different from creating a new full
Haskell Report; rather I'd like to suggest we -- for now -- merely aim
to produce a /draft/ of what we can agree on a Haskell 2020 report with
merely its library part updated to the current state-of-the-art looks
like -- including a fully working *implementation* of such a
`haskell2020` library. This should hopefully prove to be a less daunting
task, and once we reach that milestone we can decide where to go from
there (including considering aiming for the "official" Haskell Report,
but let's not get ahead of ourselves here).
Long time ago, I actually did start updating the Haskell Library Report
text for fun at
https://github.com/hvr/haskell-report/commits/hvr/h201x
And more recently, I started drafting the implementation of the
Haskell2020 base library under
http://hackage.haskell.org/package/haskell2020
which is an actual proper and working Hackage package!
(In its 0.1.* major API it doesn't yet integrate the foldable/traversable
proposal, as I wasn't sure at the time how properly integrate it due to
the nameclashing w/ the Data.List module; however, since then the
roadmap become more clear to me, and GHC 8.10 fortunately features a new
warning
| Prelude> import Data.List
|
| <interactive>:1:8: warning: [-Wcompat-unqualified-imports]
| To ensure compatibility with future core libraries changes
| imports to Data.List should be
| either qualified or have an explicit import list.
that would help as well in this context.)
However, it's become clear to me, that I don't have enough time to
finish the draft on my own.
I believe the steps to complete this project are relatively
straightforward; here's what I'd strawman-propose (i.e. subject to
bikeshedding as usual):
1.) Complete the haskell2020 draft implementation package by integrating
the missing FTP changes (under the assumption that `Data.List` ought
to be implemented qualified from here on as implied by the new
-Wcompat flags)
2.) Iterate tweaking the haskell2020 draft implementation, until we can
establish enough consensus among CLC members.
3.) Update the Haskell Library Report text to match/reflect the
concrete implementation from step 2.
4.) Announce/publicize "CLC-blessed Haskell2020 library report draft"
or something
5.) Profit; we've achieved *something*!
6.) Consider where to go from here
Long story short, are you, fellow CLC members, interested in helping
achieve the layed out goal of producing a draft of a potential Haskell
2020 Library Report update?
If yes, on which parts would you like to work on? And if not, which
parts would you least dislike to work on? ;->
Jokes aside, this is all up for discussion! Let's see if we can overcome
the first hurde to agree whether to do this at all or not!
...also we're still at the beginning of 2020 -- we can still label this
"Haskell2020" if we don't drag it out for too long... :-P
-- Herbert
[1]: https://mail.haskell.org/pipermail/haskell-prime/2016-April/004050.html
[2]: https://old.reddit.com/r/haskell/comments/f9rh3t/ghc_proposal_monad_of_no_return/
Now that the new composition of the Core library committee has
crystallized (except maybe for the minor detail of inner degree of
freedom regarding seating accommodations...), I'd like to get us going
with a concrete and very achievable mission:
Let us consolidate the last decade of proposed base library proposals
into what could be regarded the "Haskell 2020 Library Report"!
Let me expand a bit more: As you might remember, when the Haskell 2020
committee was formed[1], the CLC was tasked with updating/defining the
base library part of the report:
| The Haskell 2020 committee is a language committee; it will focus its
| efforts on specifying the Haskell language itself. Responsibility for
| the libraries laid out in the Report is left to the Core Libraries
| Committee (CLC)
And while things haven't been worked out in the original timeline
envisioned, I'd like to give this a new try, especially given the
currently encouraging positive reception[2] of the Monad-of-no-return
proposal.
What I'm proposing here is subtly different from creating a new full
Haskell Report; rather I'd like to suggest we -- for now -- merely aim
to produce a /draft/ of what we can agree on a Haskell 2020 report with
merely its library part updated to the current state-of-the-art looks
like -- including a fully working *implementation* of such a
`haskell2020` library. This should hopefully prove to be a less daunting
task, and once we reach that milestone we can decide where to go from
there (including considering aiming for the "official" Haskell Report,
but let's not get ahead of ourselves here).
Long time ago, I actually did start updating the Haskell Library Report
text for fun at
https://github.com/hvr/haskell-report/commits/hvr/h201x
And more recently, I started drafting the implementation of the
Haskell2020 base library under
http://hackage.haskell.org/package/haskell2020
which is an actual proper and working Hackage package!
(In its 0.1.* major API it doesn't yet integrate the foldable/traversable
proposal, as I wasn't sure at the time how properly integrate it due to
the nameclashing w/ the Data.List module; however, since then the
roadmap become more clear to me, and GHC 8.10 fortunately features a new
warning
| Prelude> import Data.List
|
| <interactive>:1:8: warning: [-Wcompat-unqualified-imports]
| To ensure compatibility with future core libraries changes
| imports to Data.List should be
| either qualified or have an explicit import list.
that would help as well in this context.)
However, it's become clear to me, that I don't have enough time to
finish the draft on my own.
I believe the steps to complete this project are relatively
straightforward; here's what I'd strawman-propose (i.e. subject to
bikeshedding as usual):
1.) Complete the haskell2020 draft implementation package by integrating
the missing FTP changes (under the assumption that `Data.List` ought
to be implemented qualified from here on as implied by the new
-Wcompat flags)
2.) Iterate tweaking the haskell2020 draft implementation, until we can
establish enough consensus among CLC members.
3.) Update the Haskell Library Report text to match/reflect the
concrete implementation from step 2.
4.) Announce/publicize "CLC-blessed Haskell2020 library report draft"
or something
5.) Profit; we've achieved *something*!
6.) Consider where to go from here
Long story short, are you, fellow CLC members, interested in helping
achieve the layed out goal of producing a draft of a potential Haskell
2020 Library Report update?
If yes, on which parts would you like to work on? And if not, which
parts would you least dislike to work on? ;->
Jokes aside, this is all up for discussion! Let's see if we can overcome
the first hurde to agree whether to do this at all or not!
...also we're still at the beginning of 2020 -- we can still label this
"Haskell2020" if we don't drag it out for too long... :-P
-- Herbert
[1]: https://mail.haskell.org/pipermail/haskell-prime/2016-April/004050.html
[2]: https://old.reddit.com/r/haskell/comments/f9rh3t/ghc_proposal_monad_of_no_return/
Cale Gibbard
Feb 29, 2020, 7:54:25 PM2/29/20
to Herbert Valerio Riedel, core-librari...@haskell.org
Is there a list of differences between the Haskell 2020 draft
implementation package and the libraries in base? I would hope that by
the time H2020 gets published, that list is approximately empty (apart
from possible intentional exclusions from the Report?), 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. 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, 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.
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.
> --
> You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/87zhd1dmkh.fsf%40gmail.com.
implementation package and the libraries in base? I would hope that by
the time H2020 gets published, that list is approximately empty (apart
from possible intentional exclusions from the Report?), 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. 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, 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.
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.
> You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/87zhd1dmkh.fsf%40gmail.com.
Herbert Valerio Riedel
Mar 28, 2020, 9:07:39 PM3/28/20
to Cale Gibbard, core-librari...@haskell.org
Hi,
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
the report.
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
changes.
> 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
report prescribes.
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
the report);
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
https://github.com/hvr/haskell-report/blob/hvr/h201x/.travis.yml
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.
-- Herbert
--
"Elegance is not optional" -- Richard O'Keefe
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?
yet as I pointed out in step "1.)"
...and obviously hundreds of extra modules which simply don't exist in
the report.
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
changes.
> I would hope that by the time H2020 gets published, that list is
> approximately empty (apart from possible intentional exclusions from
> the Report?),
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
report prescribes.
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
the report);
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.
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,
> 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.
https://github.com/hvr/haskell-report/blob/hvr/h201x/.travis.yml
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.
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.
-- Herbert
"Elegance is not optional" -- Richard O'Keefe
Emily Pillmore
Feb 20, 2021, 1:10:39 PM2/20/21
to Herbert Valerio Riedel, core-librari...@haskell.org, Cale Gibbard
Bumping this for everyone now that we're in the new year.
--
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/87zhd1dmkh.fsf%40gmail.com.
--
"Elegance is not optional" -- Richard O'Keefe
--
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/87wo74ezos.fsf%40gmail.com.
Reply all
Reply to author
Forward
0 new messages