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 <mail@joachim-breitner.de> wrote:

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-dependent-type-design.rst

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