Proposal: Add singleton function to Data.List module

Mon Sep 9 02:38:01 UTC 2019

https://groups.google.com/forum/#!forum/haskell-core-libraries should link
to the CLC mailing list archive. As far as I can tell it should be public.

-Edward

On Sat, Sep 7, 2019 at 11:53 PM Helmut Schmidt <
helmut.schmidt.4711 at gmail.com> wrote:

> Am So., 8. Sept. 2019 um 05:59 Uhr schrieb Edward Kmett <ekmett at gmail.com
> >:
>
>> To grant some insight into what is going on behind closed doors. I
>> figured I'd unpack a bit of it here.
>>
>
> Why is it necessary this gets discussed behind closed doors in the first
> place? Why can't we get more insight into the decision process of such a
> highly controversial proposal?
>
>
>>
>> The current resolution is to treat this as step one in a longer maneuver.
>>
>> *We'll be adding *singleton* to *Data.List*, immediately.*
>>
>> The headache has really been the issue mentioned above wherein Data.List
>> has historically been treated as an unqualified export that shouldn't clash
>> with the Prelude in any way.
>>
>> This is mostly a historical accident and doesn't really match up with the
>> way any of the other "container" like modules are expected to be used. It
>> has led to the somewhat messy state of dozens of other combinators in Data.List
>> such as foldr having to be generalized by the Foldable/Traversable
>> Proposal and other language warts starting to accumulate over time. It is
>> disproportionately difficult to add things to Data.List, so we're going
>> to fix that. -- We'd intended to fix that wart since GHC 7.10, but lacked a
>> sufficient forcing function. Expanding the API of Data.List is acting as
>> that forcing function.
>>
>> *We are going to be switching the usage pattern for *Data.List* to
>> expect a qualified or explicit import list like *Data.Text,
>> Data.ByteString, Data.Set,* etc.*
>>
>> This also helps allow for easier expansion of Data.List, which has been
>> pretty stagnant other than a non-report-specified uncons slipping in
>> stealthily in GHC 7.10.
>>
>> It also helps ameliorate any long term concerns with this taking a name,
>> as it is now something placed in a module where name collisions are okay,
>> as usage is qualified or explicit. Meanwhile, Ryan GL Scott managed to
>> accumulate enough data to show that breakage this one combinator would
>> introduce was pretty minor after all, so we're going to go ahead with
>> adding singleton before the rest of this happens.
>>
>> To get *there*, we'll need a slightly longer timeline, and some support
>> from GHC HQ to craft an appropriate warning. This will allow us to
>> monomorphize the combinators in Data.List yielding a sane ending state
>> that doesn't require a PhD in the History of Haskell to fully understand,
>> and we'll be able to retire GHC.OldList once an appropriate 3-release
>> policy compatible migration plan has been fully hammered out.
>>
>> Normally, I'd wait until we had a full plan with all the migration issues
>> posted rather than shooting off half-cocked like this, but I wanted to be
>> clear about what was causing the communication delay.
>>
>> -Edward
>>
>> On Wed, Aug 28, 2019 at 12:57 PM Keith <keith.wygant at gmail.com> wrote:
>>
>>> For what it's worth, when starting out I found the disconnect between
>>> list sugar and list constructor/destructors extremely confusing.
>>> In retrospect it seems pretty silly, but I could not figure out how
>>> lists were consumed as (x : xs) but often produced with [x, x1, ...].
>>> Mistakes like [x, xs] were common.
>>> When I finally realized that I could construct lists with the list
>>> constuctors, I started using them exclusively.
>>>
>>> Simplcity and straightforwardness help understanding. It was much easier
>>> for me to understand a singleton list as (x : []) than [x]. Having to deal
>>> with '(singleton x)' (at the time not knowing the definition of
>>> 'singleton') would have been another layer of confusion.
>>>
>>> I get that 'singleton' is library design, since in shows up in Map,
>>> Array, Set, etc. But for me trying to use lists, it would have only been
>>> useful if I defined it myself as a way to learn that constuctors are
>>> fuctions, and that 'singleton' means 'single'.
>>>
>>> On August 23, 2019 7:56:41 AM UTC, Sven Panne <svenpanne at gmail.com>
>>> wrote:
>>>>
>>>> Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe <
>>>> kris.nuttycombe at gmail.com>:
>>>>
>>>>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne <svenpanne at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>  I think there's a significant difference between "little helper" and
>>>>>> "the monomorphic function that is used to implement `pure`" - with a
>>>>>> slightly different framing, we might be able to come to an agreement that
>>>>>> both the monomorphic an polymorphic versions of this function are useful in
>>>>>> different contexts. [...]
>>>>>>
>>>>>
>>>> I think we can agree that we disagree here. ;-) My brain is too small
>>>> to remember the names of myriads of trivial helpers, so I very much prefer
>>>> general, orthogonal things. In our case: If we have a general, polymorphic
>>>> function (often from a type class), just use that. If for some reason
>>>> (rarely!) I want a more monomorphic function, I can just add a plain old
>>>> type signature somewhere (no need for funky language extensions like type
>>>> applications). This radically reduces the number of things one has to
>>>> remember. In our case: Know type classes + know a way to make things more
>>>> monomorphic.
>>>>
>>>>
>>>>> My guiding principle for API design is that one should always expose
>>>>> the fundamental building blocks as a low-level API, and then provide a
>>>>> smaller interface for the common use cases. Typeclass instances are no
>>>>> different - they are the general interface that allows us to invoke what is
>>>>> ultimately a monomorphic, low-level building block function in a
>>>>> polymorphic context.
>>>>>
>>>>
>>>> This is exactly the opposite API design principle I have: Do not expose
>>>> the monomorphic functions if they are already in a type class. You can
>>>> easily reconstruct them as a library user via type signtures if this is
>>>> really needed (still haven't seen many convincing examples of that), but
>>>> you can' do it the other way round. Less things exposed, no generality/use
>>>> cases lost => easier to remember.
>>>>
>>>> The thing we can probably agree on: API design is hard and it's not an
>>>> exact science, more a kind of art which is assessed in a subjective way...
>>>> :-)
>>>>
>>>>>
>>> Keith
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190908/f804806c/attachment.html>