Hey, sorry for the delay. I’ve been moving and been up to my ears in boxes,
packing and unpacking.
I like the proposal. I’m in favor of qualified syntax in general (that’s
where QualfiedDo came from!), and I think it’s a good way for library
maintainers to provide sane defaults for various use cases.
QualifiedStrings is a clear win, something I would most certainly use
myself. QualifiedNumerics I’m more ambivalent about, I haven’t written
enough numeric code to have a good feel for how clunky it would be in
practice, especially the special handling of negatives.
QualifiedLists, especially the vector example, is compelling, something
that would make it much easier to work with list-like literals. I have a
use-case in our own internal codebase already, to make it easier to work
with N-ary products.
The only downside I see is the introduction of even more language
extensions, but these I imagine would end up in a language edition
eventually. I do think that people would pick up on the syntax quickly (I
imagine QualifiedStrings to become ubiquitous), so i’m not too worried
about the cognitive overhead. In fact I think making it explicit which
module is influencing the interpretation is clearer than the current
Overloaded approach.
There is a risk that library authors could abuse this to write “non-sane”
code, and cause syntax fragmentation. It would indeed be great if we had a
staging environment. Worth keeping an eye on, but not fatal.
So to summarize:
QualifiedStrings: most definitely
QualifiedNumerics: ambivalent, haven’t worked with numeric code enough to
have a good intuition
QualifiedLists: I like this, and I think the pain is worth it
On Tue, Sep 9, 2025 at 13:41 Malte Ott
I have perused the three proposal some more and I have to say they have grown on me. I think they all have merit and I can imagine genuinly using them myself.
I agree that having to implement "fromNumeric" instead of "fromInteger" would be surprising for someone who is a) familiar with the normal desugaring b) tries to guess the semantics of the extension.
Still I am not convinced by "lets do it the old way just to preserve symmetry." I think the new desugaring will be very easy to grasp to anyone who wants to write a module which can be used for that. Users won’t even need to know the difference.
So I am in favor of all proposals. I don’t care much whether they are split or not, although judging every proposal on its own merits surprisingly pushed me over the edge.
Best, Malte
On 2025-09-09 18:45, Moritz Angermann wrote:
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]: [1] https://github.com/ghc-proposals/ghc-proposals/pull/698#issueco mment-3125147164
On Tue, 9 Sept 2025 at 18:09, Malte Ott <[2]malte.ott@maralorn.de> wrote:
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. [3]https://github.com/ghc-proposals/ghc-proposals/pull/698 > 2. [4] https://github.com/brandonchinn178/ghc-proposals/blob/qualified-s trings/proposals/0723-qualified-strings.rst > 3. [5] https://github.com/ghc-proposals/ghc-proposals/pull/698#issuecomm ent-3269584289 _______________________________________________ ghc-steering-committee mailing list -- [6]ghc-steering-committee@haskell.org To unsubscribe send an email to [7]ghc-steering-committee-leave@haskell.org
References
1. https://github.com/ghc-proposals/ghc-proposals/pull/698#issuecomment-3125147... 2. mailto:malte.ott@maralorn.de 3. https://github.com/ghc-proposals/ghc-proposals/pull/698 4. https://github.com/brandonchinn178/ghc-proposals/blob/qualified-strings/prop... 5. https://github.com/ghc-proposals/ghc-proposals/pull/698#issuecomment-3269584... 6. mailto:ghc-steering-committee@haskell.org 7. mailto:ghc-steering-committee-leave@haskell.org
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org