Dear Simon,
I did comment on it[1], I also agree with Malte that this proposal could
indeed use more guidance from us.
Fundamentally I like all (now) three proposals. I find it a bit challenging
to see the full picture, especially
around the ergonomics of these, without actually using them for a while
actually trying to solve problems.
I wish we had a staging/preview area where we could permit such proposals
to be given a trial run for a
limited time to collect feedback from actually using them.
As I've mentioned in the comment, I do think Bodigrim has a point with his
concern about towering
abstraction. What might be helpful to some in _some_ domain, might not be
helpful to me in a different
domain. We have lots of language extensions already to cater to specific
domains, and sometimes it's
best to use as few extensions as possible, writing very straight forward
code, which is also easy to read
for others. In other scenarios skilled application of language extensions
allows the author to model the
problem much clearer. However, do I want this always enabled? Most likely
not.
My primary concern is always: will this break existing code, as a language
extension behind a language
pragma gate, I'm not very concerned about this.
My secondary concern is that as mentioned above, we build locally optimised
languages for sub problems.
I don't think this is necessarily wrong, ghc haskell has this already in
its dna, but for newcomers this
can be confusing. They don't deal with one, but multiple languages
concurrently.
I personally find most of the ceremonies needed around strings, numbers,
(and lists) quite unsatisfactory,
hence these proposals do appeal to me. Then again my reservation are mostly
around the increasing
complexity of the sublanguages, and uncertainty if I would actually end up
using them down the line?
I wish I could just have them at my disposal for a while to try out and
experiment with, knowing full well
that they might change, or be removed, to get a better feeling for how well
they actually help with
coding problems I have at hand, and if the ergonomics work out for me or
not.
This ended up being a lot longer than I intended it to be, oh well...
Best,
Moritz
--
[1]:
https://github.com/ghc-proposals/ghc-proposals/pull/698#issuecomment-3125147...
On Tue, 9 Sept 2025 at 18:09, Malte Ott
Dear Simon,
just for the record at least Simon and I had voiced our opinion on the mailinglist. (Assuming no mail got lost.) Especially Simons critical comment seems to me to be a driver of the ongoing split.
That being said, you are right this proposal is tricky and we all should contribute to guiding the author forward.
Best, Malte
On 2025-09-09 09:58, Simon Peyton Jones wrote:
Dear Simon, Jakob, Malte, Moritz, Matthias
As you will know, there has been quite a bit of discussion around the GHC proposal for Qualified Literals. But (unless I have missed your contributions) you have not yet contributed to the discussion. As a member of the GHC Steering Committee, especially when there are tricky judgement calls to make (as in this case) I would really appreciate your input. * [1]Discussion * [2]Proposal
Brandon has now split his proposal into three. I have outlined [3]options in this comment.
I feel that we owe the proposer some guidance on the way forward, and we can only do that if we all pay attention, rather than leaving it to Sebastian. (Thanks Sebastian!)
thank you!
Simon
References
1. https://github.com/ghc-proposals/ghc-proposals/pull/698 2. https://github.com/brandonchinn178/ghc-proposals/blob/qualified-strings/prop... 3. https://github.com/ghc-proposals/ghc-proposals/pull/698#issuecomment-3269584...
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org