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
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-3125147164
> 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/proposals/0723-qualified-strings.rst
> 5. https://github.com/ghc-proposals/ghc-proposals/pull/698#issuecomment-3269584289
> 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
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org