Unless I am missing the point, I can’t really make an informed decision before we have concluded our policy discussion, in particular, on whether we want to go towards a future where everyone is welcome to turn extensions on and off to build their little fine-grained preferred language islands, or whether that is something we want to avoid and use extensions only as stepping stones towards a ((eventually) single) future Haskell, at the cost of having to tell some people that they can’t expect that every possible dialect of Haskell will be supported.
I don't think these two are incompatible. Even if we have a "single future
Haskell" in mind, it's fair enough for people to switch things on and off
if they want. Offering flexiblity at low cost seems OK to me; other
things being equal, it's not for us to say what they should or should not
want. (If the implementation or maintenance cost was high I might think
again, but I don't think it is in this case.)
Simon
On Mon, 6 Mar 2023 at 16:58, Joachim Breitner
Hi,
Am Montag, dem 06.03.2023 um 16:04 +0300 schrieb Vladislav Zavialov:
Does anyone have objections? If not, I will mark the proposal accepted in 2 weeks.
not a full fledged objection yet, but I am unsure how that fits with the overall direction we have for namespaces, as outlined in
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-de...
It this meant to be a short-gap measure that helps us to get to towards a bolder destination?
Or is it a half-way step for people who like type-level computation, but don’t want to go all the way, and is expected to stay around?
(Or maybe I am missing the point.)
Unless I am missing the point, I can’t really make an informed decision before we have concluded our policy discussion, in particular, on whether we want to go towards a future where everyone is welcome to turn extensions on and off to build their little fine-grained preferred language islands, or whether that is something we want to avoid and use extensions only as stepping stones towards a ((eventually) single) future Haskell, at the cost of having to tell some people that they can’t expect that every possible dialect of Haskell will be supported.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee