Proposal: Add singleton function to Data.List module
Elliot Cameron
eacameron at gmail.com
Thu Aug 22 15:19:55 UTC 2019
Hilariously, I just saw this article on my feed which sheepishly admits
that it's example of "singleton" isn't actually a thing in Data.List:
https://typeclasses.com/featured/singleton
On Thu, Aug 22, 2019 at 8:11 AM Elliot Cameron <eacameron at gmail.com> wrote:
> We also use the money face regularly in our code bases, but I think it's
> only because the singleton function for lists is not already defined. Every
> time I see/use it I wince a little.
>
> Some devs I know will go to lengths to avoid an extra import line. So you
> often see 'maybe x id' instead of 'fromMaybe x' and 'flip traverse' instead
> of 'for'.
>
> No other containers are in Prelude and must have their APIs imported
> qualified. So they don't suffer from this bias against imports.
>
> In any code base the defines it's own idioms, like singleton on lists, you
> have to imagine that what's obviously on Hackage and what is proprietary
> will not get the same level of commitment.
>
> P.S. Based on arguments against non-fundanental combinators, I suppose we
> should remove 'fromMaybe' and 'for' since they are not fundamental?
>
> This debate is definitely more ideological than I think anyone quite
> realized at first. At the very least, having the CLC's position clearly
> documented might help in the future.
>
> On Thu, Aug 22, 2019, 7:12 AM Malcolm Wallace via Libraries <
> libraries at haskell.org> wrote:
>
>> I have some data to contribute, from our proprietary codebase of some
>> 4MLoC. We are perhaps unusual in having the singleton function on lists
>> already for 10 years, so it is easy to do a comparison of the frequency of
>> use.
>>
>> The robot monkey (:[]) has 378 uses.
>> Monkey with a space (: []) has 36 uses.
>> The list singleton function has 18 uses.
>>
>> We also have many other singleton functions at more than 20 different
>> types (vector, tuple, map, set, interval, relation, dict, expression, etc),
>> totalling 1893 uses, so the concept/vocabulary is pretty well-known.
>>
>> In addition, I counted the number of direct constructions of lists that
>> use :[] unparenthesised, i.e like x:y:[], and there are 489.
>>
>> I find it interesting that given the choice of “singleton” vs direct
>> construction or a partially applied operator, our devs seem to prefer the
>> brevity and naturality of the colon.
>>
>> Regards,
>> Malcolm
>>
>> > On 21 Aug 2019, at 06:31, George Wilson <george at wils.online> wrote:
>> >
>> > Hi Taylor,
>> >
>> > I'm on the Core Libraries Committee. Thank you for your proposal.
>> > Regarding the +-1 messages in this thread, they are useful to gauge
>> > community opinion, but they are not votes because the libraries
>> > process is not determined by a vote.
>> >
>> > Despite seeming innocuous, the proposed change requires careful
>> > consideration: Data.List is specified by the Haskell Report, so adding
>> > this function would affect the report.
>> > While simple changes to base are typically handled directly by one of
>> > base's maintainers, this change is report-affecting, so it is
>> > "controversial" (as defined in [1]). Hence the CLC is discussing the
>> > proposed change amongst ourselves before a maintainer makes their
>> > decision.
>> >
>> > [1] https://wiki.haskell.org/Library_submissions
>> >
>> > Cheers,
>> > George
>> >
>> >
>> >
>> >
>> >
>> >> On Tue, 20 Aug 2019 at 11:24, Taylor Fausak <taylor at fausak.me> wrote:
>> >>
>> >> It has been a week since I submitted my proposal. During that time, 28
>> people voted, with 16 expressing approval and 12 expressing disapproval. To
>> everyone that voted so far: Thank you! You made for interesting discussion.
>> >>
>> >> I still feel that Haskell would be improved by the addition of a
>> `singleton` function to the `Data.List` module. (And also
>> `Data.List.NonEmpty`, even though that wasn't part of my original
>> proposal.) I would be happy to open a merge request adding code, tests, and
>> documentation.
>> >>
>> >> I haven't done so yet because I don't know what the next steps are.
>> Can someone from the CLC tell me how an official approval or rejection can
>> be reached, and how long that might take? Thanks!
>> >>
>> >> On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:
>> >>
>> >>
>> >> Andreas, you seem to be mistaken there'd only be one container API?
>> But there's several container APIs besides "Data.Set" which provide some
>> collection of elements!
>> >>
>> >>
>> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons
>> >>
>> >>
>> https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append
>> >>
>> >>
>> >>
>> >>
>> >>
>> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons
>> >>
>> >>
>> https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append
>> >>
>> >>
>> http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons
>> >>
>> >>
>> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons
>> >>
>> >>
>> https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append
>> >>
>> >> Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <
>> andreas.abel at ifi.lmu.de>:
>> >>
>> >> Helmut, do you actually know the container APIs?
>> >>
>> >> Show me cons and append in Data.Set!
>> >>
>> >>> On 2019-08-18 19:40, Helmut Schmidt wrote:
>> >>>
>> >>>
>> >>> Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles
>> >>> <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
>> >>>
>> >>> On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>> >>> <helmut.schmidt.4711 at gmail.com
>> >>> <mailto:helmut.schmidt.4711 at gmail.com>> wrote:
>> >>>
>> >>>
>> >>> All these philosophical arguments calling for "consistency"
>> with
>> >>> the container APIs or that function need words for the human
>> >>> mind to comprehend seem short-sighted to me. If we were
>> >>> consistent about the proposal itself we'd also demand to add
>> >>>
>> >>> cons = (:)
>> >>>
>> >>> empty = []
>> >>>
>> >>> toList = id
>> >>>
>> >>> fromList = id
>> >>>
>> >>>
>> >>> I honestly have no problem with any of these.
>> >>>
>> >>>
>> >>> I forgot
>> >>>
>> >>> append = (++)
>> >>>
>> >>> We also need to address another elephant in the room... those pesky
>> >>> tuples and their special privileged non-wordy syntax!
>> >>>
>> >>> pair = (,)
>> >>>
>> >>> triple = (,,)
>> >>>
>> >>> quadruple = (,,,)
>> >>>
>> >>> quituple = (,,,,)
>> >>>
>> >>> sextuple = (,,,,,)
>> >>>
>> >>> septuble = (,,,,,,)
>> >>>
>> >>> octuple = (,,,,,,,)
>> >>>
>> >>> If Haskell were invented in this century's EU Haskell source code
>> would
>> >>> be littered with €s instead of $s but then again I wonder why £ wasn't
>> >>> picked. But I digress. We can kill two birds with one stone here:
>> >>>
>> >>> apply = ($)
>> >>>
>> >>> strictApply = ($!)
>> >>>
>> >>> compose = (.)
>> >>>
>> >>>
>> >>> It's fun to imagine how code using those definitions would like! But
>> >>> it's still a -1 for me, sorry!
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>>
>> _______________________________________________
>> 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/20190822/529ffc82/attachment.html>
More information about the Libraries
mailing list