<div dir="ltr"><div><br></div><div>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 <br></div><div></div><div><br></div><div> cons = (:)</div><div><br></div><div> empty = []</div><div><br></div><div> toList = id</div><div><br></div><div> fromList = id</div><br><div></div><div>to the List module. For consistency's sake!<br></div><div></div><div></div><div></div><div><br></div><div>This reminds me of the famous quote</div><div><br></div><div></div><div>"A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines."</div><div><br></div><div>In any case I'm -1 on adding singleton or any other consistency-feel-good names to Data.List<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am So., 18. Aug. 2019 um 15:47 Uhr schrieb Alexandre Esteves <<a href="mailto:alexandre.fmp.esteves@gmail.com">alexandre.fmp.esteves@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank">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" target="_blank">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>
_______________________________________________<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></div>