<div dir="ltr"><div>If the choice is between adding List.singleton or not, I vote for adding it.</div><div>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. </div><div><br></div><div>But I'd actually prefer a singleton <i>method</i>. 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). </div><div>When I think of a container of <i>x</i>, I think of some data structure with <i>x</i> values inside. Now, they need to be stored/organized/structured *somehow*, and there's a distinction here:</div><div>- some containers require <i>each</i> element to be paired with it's index/key/location (e.g. Map, HashMap, (->))</div><div>- some containers build the entire structure based on a single value/dictionary <i>which can be known ahead of time, before any values are provided</i> (e.g. <i>Set</i> uses <i>Ord</i>, <i>HashSet</i> uses <i>Hashable</i>, <i>List</i> trivially uses the empty constraint <i>()</i>)</div><div><br></div><div>For the second case, we can conceive of a <i>fromList</i> function (left and right inverse of <i>toList</i>), which then gives us <i>singleton = fromList . (:[])</i></div><div>Something like:<br></div><div><br></div><div><span style="font-family:monospace">-- contrast with </span><a href="https://hackage.haskell.org/package/semigroupoids-5.3.2/docs/Data-Semigroup-Foldable.html#t:Foldable1">https://hackage.haskell.org/package/semigroupoids-5.3.2/docs/Data-Semigroup-Foldable.html#t:Foldable1</a><br></div><div><font face="monospace">class Unfoldable1 c a where<br>  fromNonEmpty :: NonEmpty a -> c a<br><br>  singleton :: a -> c a<br>  singleton = fromNonEmptyList . (:|[]) -- moustached gorilla operator<br><br>-- constrast with Foldable<br>class Unfoldable1 c a => Unfoldable c a where<br>  fromList :: [a] -> c a<br><br>  unfoldr :: (b -> Maybe (a, b)) -> b -> c a<br>  unfoldr f = fromList . Data.List.unfoldr f<br><br>instance Unfoldable1 [] a where<br>  fromNonEmpty = toList<br>instance Unfoldable  [] a where<br>  fromList = id<br><br>instance Unfoldable1 NonEmpty a where<br>  fromNonEmpty = id<br><br>instance Ord a => Unfoldable1 Set a where<br>  fromNonEmpty = fromList . toList<br>instance Ord a => Unfoldable Set a where<br>  fromList = Set.fromList<br><br>instance (Eq a, Hashable a) => Unfoldable1 HashSet a where<br>  fromNonEmpty = fromList . toList<br>instance (Eq a, Hashable a) => Unfoldable HashSet a where<br>  fromList = HashSet.fromList<br></font></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 18, 2019 at 3:58 PM Henrik Nilsson <<a href="mailto:Henrik.Nilsson@nottingham.ac.uk">Henrik.Nilsson@nottingham.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 08/13/2019 11:56 PM, Herbert Valerio Riedel wrote:<br>
> But we already have at least two monomorphic variants to express this<br>
> with Haskell's concise native syntax and vocabulary which has by<br>
> design a preferential treatment of lists (it was considered even more<br>
> important than type-sigs so that we got the `:` cons operator for<br>
> lists and the `::` for type-sig annotations) -- so let's not try to<br>
> fight Haskell's core idioms by hiding them behind some trivial<br>
> additional redundant synonyms! I still fail to see the actual<br>
> *technical*  problem being solved by the original proposal asking to<br>
> add yet another, wordy way to construct single-item-lists.<br>
<br>
To me, the main argument for "singleton" is that of consistency with<br>
other container types. But, on balance, I do agree with Herbert<br>
and others: operator sections is a core Haskell idiom, and (:[]) is an <br>
age-old and obvious instance: even beginner Haskell programmers will be<br>
very familiar with (:) for list construction, and along with the basic<br>
arithmetic operators, it is definitely one of the operators most<br>
familiar to Haskell programmers.<br>
<br>
So -1 from me.<br>
<br>
/Henrik<br>
<br>
<br>
<br>
<br>
This message and any attachment are intended solely for the addressee<br>
and may contain confidential information. If you have received this<br>
message in error, please contact the sender and delete the email and<br>
attachment. <br>
<br>
Any views or opinions expressed by the author of this email do not<br>
necessarily reflect the views of the University of Nottingham. Email<br>
communications with the University of Nottingham may be monitored <br>
where permitted by law.<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>