Proposal: Add singleton function to Data.List module

[Dan Burton]

> monomorphize the combinators in Data.List... retire GHC.OldList

Sounds great! Thanks for working on these improvements.

-- Dan Burton


On Sat, Sep 7, 2019 at 10:59 PM Edward Kmett <ekmett at gmail.com> wrote:

> To grant some insight into what is going on behind closed doors. I figured
> I'd unpack a bit of it here.
>
> 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/4304e00f/attachment.html>