Proposal: Add singleton function to Data.List module

Sun Sep 8 05:58:55 UTC 2019

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190907/b65e543e/attachment.html>