Proposal: Add singleton function to Data.List module

classic Classic list List threaded Threaded
79 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

David Duke
Whilst taking the point, could I just  pit out that, its not just about the form of the final program. One of the
strengths and appeals of FP id the opportunity for program transformation via a useful
repertoire of algebraic law, cf the work on Squiggol, and the numerous pearls by folk including Richard Bird et.al..
This work befits from having concisely-expressed rules that open the road to manipulation - long-winded
identifiers suitable for large libraries are not necessarily ideal here.
Going back to the original proposal, I'm not bothered, I would probably just ignore a singleton library
in favour of  :[]. I'm -1 on philosophical grounds.
I'm used to teaching FP to undergrads and half the battle is encouraging people to think functionally, to
make use of the underlying mathematics and computational model rather than transliterate
Python or <insert your favourite 'bete noir'> into Haskell. That means thinking of building programs from
functional fragments combined by suitable glue, and appreciating that data constructors can be used
as functions Yes takes beginner's time to recognise some of the patterns, but when the light dawns, 
the transformation is rewarding. I've lost count of the number of jaws I've had to pick off the floor :)

So I don't want to make a mountain out of a molehill. If it will really  improve people's programming
lives then fine, But I' not convinced, and but in fretting over final code can we please not   lose
sight of the larger picture and battle..


regards
David Duke.

On Fri, Aug 16, 2019 at 3:21 PM Ignat Insarov <[hidden email]> wrote:
I'd like to derail this conversation into remembering the "C, Unix hoax" joke.
https://www.gnu.org/fun/jokes/unix-hoax.html

> We stopped when we got a clean compile on the following syntax:
>
>     for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

We humans find it easier to think in words, which are singleton blobs
of sense requiring no parsing, no compilation, but immediately
obvious. The "monkey face" here is not one, not two, but four distinct
blobs. This is in fact a technical argument against it, though
referring to the technic of human cognition rather than machine's.

In this perspective, is it not clear that we should strive away from
symbol soup idioms? Let us write programs for people to read.

On Mon, 12 Aug 2019 at 20:03, Herbert Valerio Riedel <[hidden email]> wrote:
>
> > - `(:[])`: Subjectively ugly.
>
> I consider "subjectively ugly" to be a non-technical and thus really
> weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])
> which also happens to be shorter than the proposed alias for it. I for
> one don't see a significant benefit for adding a redundant synonym to
> `Data.List` and are thus -1 on this.
>
> > singleton :: a -> [a]
> > singleton x = [x]
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
David Duke
Professor of Computer Science
School of Computing University of Leeds UK

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Henrik Nilsson-2
In reply to this post by Herbert Valerio Riedel-3
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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:

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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Helmut Schmidt

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

to the List module. For consistency's sake!

This reminds me of the famous quote

"A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines."

In any case I'm -1 on adding singleton or any other consistency-feel-good names to Data.List





Am So., 18. Aug. 2019 um 15:47 Uhr schrieb Alexandre Esteves <[hidden email]>:
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:

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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Oliver Charles-3
On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, <[hidden email]> 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.

Ollie


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Helmut Schmidt


Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles <[hidden email]>:
On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

chessai .
+1

On Sun, Aug 18, 2019, 7:41 PM Helmut Schmidt <[hidden email]> wrote:


Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles <[hidden email]>:
On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

David Duke
In reply to this post by Taylor Fausak
Stepping to one side of the discussion could I just  point out that, notation is not just about the form of the final program. One of the claimed strengths and appeals of FP is the opportunity for program transformation via a useful
repertoire of algebraic law, cf the work on Squiggol, and the numerous functional pearls by folk including Richard Bird et.al..
This work befits from having concisely-expressed rules that open the road to manipulation - long-winded
identifiers suitable for large libraries are not necessarily ideal for algebraic
manipulation. Ye you could treat the two as separate entities, But a pleasant feature of Haskell is the ability to work with the notation both for developmemt and final program.

Going back to the original proposal, I'm not bothered, I would probably just ignore a singleton library.  However I'm -1 on philosophical grounds.
I'm used to teaching FP to undergrads and half the battle is encouraging people to think functionally, to
make use of the underlying mathematics and computational model rather than transliterate <insert your favourite 'bete noir'> into Haskell. That means thinking of building programs from
functional fragments combined by suitable glue, and appreciating that data constructors can be used
as functions Yes it takes beginner's time to recognise some of the patterns,  and (:[] is just one such example(when the light dawns, 
the transformation is rewarding. I've lost count of the number of jaws I've had to pick off the floor :)

So I don't want to make a mountain out of a molehill. If it will really  improve programmers' 
lives then okay, So far I' not convinced, and but in fretting over final code can we please not   lose sight of the 'bigger picture' and challenges..


--

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Andreas Abel
In reply to this post by Helmut Schmidt
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
> <[hidden email] <mailto:[hidden email]>>:
>
>     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>     <[hidden email]
>     <mailto:[hidden email]>> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Helmut Schmidt
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!








Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <[hidden email]>:
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
> <[hidden email] <mailto:[hidden email]>>:
>
>     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>     <[hidden email]
>     <mailto:[hidden email]>> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Taylor Fausak
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!











Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <[hidden email]>:
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
>
>     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>     <[hidden email]
>     <mailto:[hidden email]>> 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 mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Haskell - Libraries mailing list

I guess it's actually 13 people expressing disapproval and I'm -1 on this proposal as well. When I learned Haskell our programming exercises revolved heavily around manipulating and transforming lists. I never felt the urge to use "singleton" as there were always ways to express this more directly in an obvious way. In fact I would be rather confused to see code operating on lists using a noisy "singleton" function and maybe even consider it a code-smell.

On Monday, 19 August 2019, 18:24:41 GMT-7, Taylor Fausak <[hidden email]> 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!











Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <[hidden email]>:
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
>
>     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>     <[hidden email]
>     <mailto:[hidden email]>> 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 mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

John Ky
My wish for Haskell is that it had a standard library that wasn't all tied up in base so that it could be independent of the compiler version, be easier to contribute to and would be structured so as to cater to those who want minimalism as well as those who want consistency/comprehensiveness.

Not sure where that puts me on the -1 to +1 scale.

On Tue, 20 Aug 2019 at 08:17, John Villarreal via Libraries <[hidden email]> wrote:

I guess it's actually 13 people expressing disapproval and I'm -1 on this proposal as well. When I learned Haskell our programming exercises revolved heavily around manipulating and transforming lists. I never felt the urge to use "singleton" as there were always ways to express this more directly in an obvious way. In fact I would be rather confused to see code operating on lists using a noisy "singleton" function and maybe even consider it a code-smell.

On Monday, 19 August 2019, 18:24:41 GMT-7, Taylor Fausak <[hidden email]> 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!











Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <[hidden email]>:
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
>
>     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>     <[hidden email]
>     <mailto:[hidden email]>> 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 mailing list


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Andreas Abel
In reply to this post by Helmut Schmidt
Right, but the ones you quote are all variants of sequences, not
collections in general.  They have append and cons.  An interface for
sequences should name these operations uniformly.  However, I would
restrict the current discussion to construction of collections in
general, with the interface

   mempty     -- construct an empty collection
   singleton  -- construct a collection with one element
   mappend    -- join two collections

There is a (next to virginal) attempt to define an API for collections at

 
http://hackage.haskell.org/package/collections-api-1.0.0.0/docs/Data-Collections.html

Incidentally, it has

   singleton :: i -> c
   Creates a collection with a single element.

Cheers,
Andreas

On 2019-08-19 12:38, 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
> <[hidden email] <mailto:[hidden email]>>:
>
>     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
>      > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>:
>      >
>      >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
>      >     <[hidden email]
>     <mailto:[hidden email]>
>      >     <mailto:[hidden email]
>     <mailto:[hidden email]>>> 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
>      > [hidden email] <mailto:[hidden email]>
>      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>      >
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Standard of approval for library submissions (Was: Proposal: Add singleton function to Data.List module)

Haskell - Libraries mailing list
In reply to this post by Taylor Fausak
Taylor Fausak 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 thought the standard of approval for library proposals was a broad
consensus for adoptation, which we clearly do not have here. It was
supposed to be a reasoned decision based on arguments put forward by
proponents and opponents of the idea. There has always been a tendency
to express agreement or disagreement numerically, but recently these
agreements and disagreements have been treated as a voting system, and
I believe that's an unhealthy trend.

With a simple majority-based straw poll on the mailing list we risk
ending up with a ton of questionable additions to the core libraries
that have a handful of outspoken proponents and nobody who really cares;
the end result will be, predictably, a library full of functions that
nobody ever uses.

In the case of a dispute (which we have here), the decision should be
made by the maintainer(s), i.e. the Core Libraries Committee in this
case. As maintainers, they are also in a better position to address
concerns like consistency (which is hard to obtain by incrementally
adding small functions.)

Perhaps we should also consider that voting takes almost no effort,
whereas composing a coherent argument takes much time and effort.

Overall I believe we should go back to weighing arguments rather than
voting for library proposals.

Cheers,

Bertram
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Haskell - Libraries mailing list
In reply to this post by Taylor Fausak
Taylor Fausak 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've just written about straw polls in a separate mail...

In the particular case of adding `singleton` to `Data.List`, I don't
believe having `singleton` in Data.List will cause much harm beyond
being yet another synonym to remember when reading other people's code,
and inevitably breaking some code. I can even see the consistency
argument, if one views lists as containers. But to me, lists are,
foremost, iterators. (In fact that's why I usually import Data.List
unqualified, because iterators are so common! So the risk of breaking
code is, to me, real.)

I'm pretty sure I will not use `singleton`, having grown used to all
four of (:[]), \x -> [x], `return`, and lately `pure`. So there's no
benefit in having the function.

(If you're counting votes, that's -1 from me.)

Cheers,

Bertram
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

George Wilson
In reply to this post by Taylor Fausak
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 <[hidden email]> 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 <[hidden email]>:
>
> 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
> > <[hidden email] <mailto:[hidden email]>>:
> >
> >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
> >     <[hidden email]
> >     <mailto:[hidden email]>> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Nathan Bouscal
Hi all,

I would strongly encourage anyone inclined to say things like “there's no benefit in having the function” to consider reframing the sentiment as “I wouldn’t benefit from having the function, and don’t understand the benefit others will gain.” Once you’ve done that reframe, you can notice that there’s a lack of understanding toward which the appropriate emotional stance is curiosity, not dismissiveness. A lot of people have clearly expressed in this thread that they would benefit from this function, and when you assert as fact that such benefit does not exist, you’re implicitly dismissing and devaluing their experience. 

Independent of any technical merits or readability concerns per se, there is a signaling aspect to this discussion. Already this thread has been referenced many times on social media, and it’s sending a very loud signal: “we don’t want you here”. Not because of the content of the discussion, but because of its tone. I happen to think that Haskell is a fantastic language for beginners, and I’ve been watching in real time as potential learners are deciding it isn’t for them. I’ve also been seeing experienced Haskellers deciding it’s not worth it to participate in the libraries process. You can argue as much as you want that people are wrong to get that signal from this thread, that they’re misinterpreting the comments here, etc, but none of that changes the outcome. We can do better than this.


On the proposal itself: I’ve been writing Haskell for several years now and have founded a company that uses Haskell in production, so I’d like to think I’m at least a step or two beyond “beginner”, and yet I cannot recall the last time I saw (:[]) in my code or anyone else’s, and seeing it here caused me to double-take and take a moment to mentally parse it. If that’s the case for me, I’m sure it must be far worse for an actual beginner. Building things by composing primitives is good, but if anyone put this operator into my codebase I’d likely flag it in code review. Readability isn’t about whether it’s possible to read something, it’s about how easy it is to read, and for me this operator doesn’t pass that test. Personally I tend to use pure, but a monomorphic option would be better. I would happily change to using singleton if it becomes available, and am a +1 on the proposal for both List and NonEmpty.


Nathan


On Wed, Aug 21, 2019 at 6:32 AM George Wilson <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>
> 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
> > <[hidden email] <mailto:[hidden email]>>:
> >
> >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
> >     <[hidden email]
> >     <mailto:[hidden email]>> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Add singleton function to Data.List module

Haskell - Libraries mailing list

Once you’ve done that reframe, you can notice that there’s a lack of understanding toward which the appropriate emotional stance is curiosity, not dismissiveness. A lot of people have clearly expressed in this thread that they would benefit from this function, and when you assert as fact that such benefit does not exist, you’re implicitly dismissing and devaluing their experience. 

I strongly endorse Nathan’s point here.  

 

I think that a lot of the dismissiveness/devaluing is entirely unintentional -- but that does not reduce its harmful effects.   Nathan does us a service by bringing it to consciousness.  As he says, we can do better than this.

 

I like the emphasis on curiosity.  The GHC Steering Committee has adopted guidelines with similar vocabulary.

 

Simon

 

From: Libraries <[hidden email]> On Behalf Of Nathan Bouscal
Sent: 21 August 2019 11:22
To: Haskell Libraries <[hidden email]>
Subject: Re: Proposal: Add singleton function to Data.List module

 

Hi all,

 

I would strongly encourage anyone inclined to say things like “there's no benefit in having the function” to consider reframing the sentiment as “I wouldn’t benefit from having the function, and don’t understand the benefit others will gain.” Once you’ve done that reframe, you can notice that there’s a lack of understanding toward which the appropriate emotional stance is curiosity, not dismissiveness. A lot of people have clearly expressed in this thread that they would benefit from this function, and when you assert as fact that such benefit does not exist, you’re implicitly dismissing and devaluing their experience. 

 

Independent of any technical merits or readability concerns per se, there is a signaling aspect to this discussion. Already this thread has been referenced many times on social media, and it’s sending a very loud signal: “we don’t want you here”. Not because of the content of the discussion, but because of its tone. I happen to think that Haskell is a fantastic language for beginners, and I’ve been watching in real time as potential learners are deciding it isn’t for them. I’ve also been seeing experienced Haskellers deciding it’s not worth it to participate in the libraries process. You can argue as much as you want that people are wrong to get that signal from this thread, that they’re misinterpreting the comments here, etc, but none of that changes the outcome. We can do better than this.

 

 

On the proposal itself: I’ve been writing Haskell for several years now and have founded a company that uses Haskell in production, so I’d like to think I’m at least a step or two beyond “beginner”, and yet I cannot recall the last time I saw (:[]) in my code or anyone else’s, and seeing it here caused me to double-take and take a moment to mentally parse it. If that’s the case for me, I’m sure it must be far worse for an actual beginner. Building things by composing primitives is good, but if anyone put this operator into my codebase I’d likely flag it in code review. Readability isn’t about whether it’s possible to read something, it’s about how easy it is to read, and for me this operator doesn’t pass that test. Personally I tend to use pure, but a monomorphic option would be better. I would happily change to using singleton if it becomes available, and am a +1 on the proposal for both List and NonEmpty.

 

 

Nathan


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add singleton function to Data.List module

Taylor Fausak
In reply to this post by Nathan Bouscal
Thanks for saying that, Nathan! I agree wholeheartedly.

To George and the CLC: I'm disappointed to hear that I inadvertently suggested something that would require changing the Haskell Language Report. It is my understanding that work on the report has more or less stalled [1], and I would hate for this simple addition to be caught in that quagmire.

Your mention of the report encouraged me to look for differences between the current Data.List module and the one specified in the report [2]. Aside from the obvious Foldable/Traversable changes brought by the FTP proposal, it didn't take long to find a difference: the uncons function [3]. I found its source in GHC.List [4], which pointed me to a Trac issue [5], a mailing list thread [6], and a Phabricator differential [7].

I bring this up not because I expect the process to be exactly the same today as it was five years ago, but because the simple addition of the uncons function was accepted without nearly as much discussion. Also it was notably accepted without any mention of the report at all. Has something changed in the meantime, or did I suggest something that hit a nerve with the community?

Regardless, I'm happy to hear that the CLC is considering my proposal among themselves. Is there an expected timeline? (I'm looking for a rough order of magnitude, not an exact date.) Thanks!


On Wed, Aug 21, 2019, at 6:22 AM, Nathan Bouscal wrote:
Hi all,

I would strongly encourage anyone inclined to say things like “there's no benefit in having the function” to consider reframing the sentiment as “I wouldn’t benefit from having the function, and don’t understand the benefit others will gain.” Once you’ve done that reframe, you can notice that there’s a lack of understanding toward which the appropriate emotional stance is curiosity, not dismissiveness. A lot of people have clearly expressed in this thread that they would benefit from this function, and when you assert as fact that such benefit does not exist, you’re implicitly dismissing and devaluing their experience. 

Independent of any technical merits or readability concerns per se, there is a signaling aspect to this discussion. Already this thread has been referenced many times on social media, and it’s sending a very loud signal: “we don’t want you here”. Not because of the content of the discussion, but because of its tone. I happen to think that Haskell is a fantastic language for beginners, and I’ve been watching in real time as potential learners are deciding it isn’t for them. I’ve also been seeing experienced Haskellers deciding it’s not worth it to participate in the libraries process. You can argue as much as you want that people are wrong to get that signal from this thread, that they’re misinterpreting the comments here, etc, but none of that changes the outcome. We can do better than this.


On the proposal itself: I’ve been writing Haskell for several years now and have founded a company that uses Haskell in production, so I’d like to think I’m at least a step or two beyond “beginner”, and yet I cannot recall the last time I saw (:[]) in my code or anyone else’s, and seeing it here caused me to double-take and take a moment to mentally parse it. If that’s the case for me, I’m sure it must be far worse for an actual beginner. Building things by composing primitives is good, but if anyone put this operator into my codebase I’d likely flag it in code review. Readability isn’t about whether it’s possible to read something, it’s about how easy it is to read, and for me this operator doesn’t pass that test. Personally I tend to use pure, but a monomorphic option would be better. I would happily change to using singleton if it becomes available, and am a +1 on the proposal for both List and NonEmpty.


Nathan


On Wed, Aug 21, 2019 at 6:32 AM George Wilson <[hidden email]> 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.


Cheers,
George





On Tue, 20 Aug 2019 at 11:24, Taylor Fausak <[hidden email]> 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!
>
>
>
>
>
>
>
>
>
>
>
> Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <[hidden email]>:
>
> 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
> >
> >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,
> >     <[hidden email]
> >     <mailto:[hidden email]>> 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 mailing list
>
>
> _______________________________________________
> Libraries mailing list
_______________________________________________
Libraries mailing list
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
1234