Proposal: Add singleton function to Data.List module

[Alexandre Esteves]

If the choice is between adding List.singleton or not, I vote for adding it.
The robot-ninja-monkey-gorilla-whathaveyou operator always causes me to do
a double take, and I'm actually displeased with there being special syntax
for `List` alone - I don't see any special syntax for `Set/Map`, or
`Either`, which is even more fundamental, and on pair with tuples.

But I'd actually prefer a singleton *method*. It seems a frequent point of
debate is single-element-intent vs polymorphic-ness. I'd like to note that
they're not mutually exclusive (whether we end up with best of both worlds
or worst is up for discussion).
When I think of a container of *x*, I think of some data structure with *x*
values inside. Now, they need to be stored/organized/structured *somehow*,
and there's a distinction here:
- some containers require *each* element to be paired with it's
index/key/location (e.g. Map, HashMap, (->))
- some containers build the entire structure based on a single
value/dictionary *which can be known ahead of time, before any values are
provided* (e.g. *Set* uses *Ord*, *HashSet* uses *Hashable*, *List*
trivially uses the empty constraint *()*)

For the second case, we can conceive of a *fromList* function (left and
right inverse of *toList*), which then gives us *singleton = fromList .
(:[])*
Something like:

-- contrast with
https://hackage.haskell.org/package/semigroupoids-5.3.2/docs/Data-Semigroup-Foldable.html#t:Foldable1
class Unfoldable1 c a where
  fromNonEmpty :: NonEmpty a -> c a

  singleton :: a -> c a
  singleton = fromNonEmptyList . (:|[]) -- moustached gorilla operator

-- constrast with Foldable
class Unfoldable1 c a => Unfoldable c a where
  fromList :: [a] -> c a

  unfoldr :: (b -> Maybe (a, b)) -> b -> c a
  unfoldr f = fromList . Data.List.unfoldr f

instance Unfoldable1 [] a where
  fromNonEmpty = toList
instance Unfoldable  [] a where
  fromList = id

instance Unfoldable1 NonEmpty a where
  fromNonEmpty = id

instance Ord a => Unfoldable1 Set a where
  fromNonEmpty = fromList . toList
instance Ord a => Unfoldable Set a where
  fromList = Set.fromList

instance (Eq a, Hashable a) => Unfoldable1 HashSet a where
  fromNonEmpty = fromList . toList
instance (Eq a, Hashable a) => Unfoldable HashSet a where
  fromList = HashSet.fromList


On Sun, Aug 18, 2019 at 3:58 PM Henrik Nilsson <
Henrik.Nilsson at nottingham.ac.uk> wrote:

> Hi,
>
> On 08/13/2019 11:56 PM, Herbert Valerio Riedel wrote:
> > But we already have at least two monomorphic variants to express this
> > with Haskell's concise native syntax and vocabulary which has by
> > design a preferential treatment of lists (it was considered even more
> > important than type-sigs so that we got the `:` cons operator for
> > lists and the `::` for type-sig annotations) -- so let's not try to
> > fight Haskell's core idioms by hiding them behind some trivial
> > additional redundant synonyms! I still fail to see the actual
> > *technical*  problem being solved by the original proposal asking to
> > add yet another, wordy way to construct single-item-lists.
>
> To me, the main argument for "singleton" is that of consistency with
> other container types. But, on balance, I do agree with Herbert
> and others: operator sections is a core Haskell idiom, and (:[]) is an
> age-old and obvious instance: even beginner Haskell programmers will be
> very familiar with (:) for list construction, and along with the basic
> arithmetic operators, it is definitely one of the operators most
> familiar to Haskell programmers.
>
> So -1 from me.
>
> /Henrik
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please contact the sender and delete the email and
> attachment.
>
> Any views or opinions expressed by the author of this email do not
> necessarily reflect the views of the University of Nottingham. Email
> communications with the University of Nottingham may be monitored
> where permitted by law.
>
>
>
>
> _______________________________________________
> 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/20190818/f4dee5f4/attachment.html>