On Mon, Aug 12, 2019 at 6:03 PM Herbert Valerio Riedel 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.

You are of course entitled to see this as a weak argument, but those of us who are writing Haskell for 8 hours a day do not make all of our decisions based on purely "technical" arguments. How easy it is for myself and colleagues to review code is significant. On the other hand, "the existing alternative happens to be shorter" *is* a weak argument to me. There is no tax on characters typed, and IMO we should be evaluating this change on whether or not it contributes to code clarity, rather than "is long to type". Unless you consider "singleton" to be so long it further obscures code, but I have a hard time buying that. Ollie

On Mon, Aug 12, 2019 at 6:10 PM Oliver Charles wrote:

You are of course entitled to see this as a weak argument, but those of us who are writing Haskell for 8 hours a day do not make all of our decisions based on purely "technical" arguments. How easy it is for myself and colleagues to review code is significant.

Apologies, I see now this statement reads like 'I write more code that hvr, so his opinion is worth less'. That wasn't my intention, in fact I wasn't trying to provide any type of judgement as to how much hvr writes (as I understand it, hvr writes plenty!). I was just trying to emphasize how much this proposal means to me as a full time Haskell programmer. Seeing as I'm already derailing the conversation I'll step out of this for now. Turns out I'm weirdly passionate about this single expression!

At the risk of completely derailing the conversation, I have always called this the "robot monkey operator". I fail to see what is so ninja-like about it. Anyway, I think I am +1 on adding Data.List.singleton. -Brent On Mon, Aug 12, 2019, 12:35 PM Zemyla wrote:

I also like the ninja-robot operator, because it's visually interesting and easy to search for.

Also, if you're importing several libraries which already use "singleton", then you have to use "List.singleton" every time, which is far uglier to me.

On Mon, Aug 12, 2019 at 12:03 PM Herbert Valerio Riedel 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Mon, Aug 12, 2019, 12:53 PM Andrew Lelechenko < andrew.lelechenko@gmail.com> wrote:

Adding singleton to Data.List is a breaking change, when Data.Map.singleton was exported unqualified.

Data.Map's documentation states that the entire module should be imported qualified; this is not a reasonable counterargument. RIO even takes the potentially-conflicting List functions out of Prelude, and puts them in a RIO.List module which is also intended for qualified import. I'm +1. Personally I prefer `pure` and have TypeApplication enabled globally; but that's not a universal style, and I see no real cost here (though I agree it shouldn't be exposed in Prelude). NonEmpty should get one too.

Hard -1, , i'm not seeing a useful high impact payoff plus its more verbose and adhoc than pure and more confusing than (:[]) I actually initially thought this thread was about Type Singletons and or Proxy style apis using List as the term level form, it actually took me a few minutes of reading everyone's replies to disambiguate i'm open to changing my mind later if i can convince myself, but -1 for now On Mon, Aug 12, 2019 at 3:53 PM Andrew Lelechenko < andrew.lelechenko@gmail.com> wrote:

- `pure`: Polymorphic, works for any `Functor`.

It is OK to have polymorphic folds and length, so what is wrong with pure?

Adding singleton to Data.List is a breaking change, when Data.Map.singleton was exported unqualified. And there is no singleton in Data.List.NonEmpty as well.

-1 from me.

Best regards, Andrew

On 12 Aug 2019, at 19:36, Brent Yorgey wrote:

At the risk of completely derailing the conversation, I have always called this the "robot monkey operator". I fail to see what is so ninja-like about it.

Anyway, I think I am +1 on adding Data.List.singleton.

-Brent

On Mon, Aug 12, 2019, 12:35 PM Zemyla wrote:

...

I also like the ninja-robot operator, because it's visually interesting and easy to search for.

Also, if you're importing several libraries which already use "singleton", then you have to use "List.singleton" every time, which is far uglier to me.

On Mon, Aug 12, 2019 at 12:03 PM Herbert Valerio Riedel 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

In the Agda code base there is a overloaded version of the singleton function. Even more useful in its overloaded form! https://github.com/agda/agda/blob/master/src/full/Agda/Utils/Singleton.hs As you can see here, singleton exists for many collection types already, it makes very much sense to have it also for List (and List.Nonempty). +1 on Data.List.singleton, (but please not in the Prelude). On 2019-08-12 20:36, Brent Yorgey wrote:

At the risk of completely derailing the conversation, I have always called this the "robot monkey operator".  I fail to see what is so ninja-like about it.

Anyway, I think I am +1 on adding Data.List.singleton.

-Brent

On Mon, Aug 12, 2019, 12:35 PM Zemyla mailto:zemyla@gmail.com> wrote:

I also like the ninja-robot operator, because it's visually interesting and easy to search for.

Also, if you're importing several libraries which already use "singleton", then you have to use "List.singleton" every time, which is far uglier to me.

On Mon, Aug 12, 2019 at 12:03 PM Herbert Valerio Riedel mailto:hvriedel@gmail.com> 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]

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 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 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 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- David Duke Professor of Computer Science School of Computing University of Leeds UK E:duke.j.david@gmail.com W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke

Weak +1, I'd want it in NonEmpty too if it's going into List. On Tue, 13 Aug 2019 at 13:37, Joseph C. Sible wrote:

-1. AFAICT, "Polymorphic, works for any `Functor`" is an upside of just using `pure`, not a downside. (Please correct me if I'm wrong, and there is some disadvantage that I don't see.) Also, it looks like for everything that has a `singleton`, it's something that isn't an applicative functor, so they have them instead of `pure`, not in addition to it.

Joseph C. Sible

On Mon, Aug 12, 2019 at 12:14 PM Taylor Fausak wrote:

...

I originally made this suggestion on GitLab, but I was told to make it here instead.

https://gitlab.haskell.org/ghc/ghc/issues/17042

---

# Add list singleton function

## Motivation

Sometimes it is convenient to have a function to wrap an element in a list. There are many ways to do this already, but none of them are as clear as a separate monomorphic function.

- `pure`: Polymorphic, works for any `Functor`. - `pure @[]`: Noisy, requires `-XTypeApplications`. - `(: [])`: Subjectively ugly. - `(\x -> [x])`: Syntactically noisy.

This Twitter thread includes some additional commentary: https://twitter.com/taylorfausak/status/1159264862247280640

## Proposal

I would like to add a `singleton` function to `Data.List` that mirrors the `singleton` function for other containers: https://www.stackage.org/lts-14.0/hoogle?q=singleton

``` hs singleton :: a -> [a] singleton x = [x] ```

Other Haskell-like languages include this function:

- PureScript: https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.Lis... - Elm: https://package.elm-lang.org/packages/elm/core/latest/List#singleton _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Clear +1 from me. I have defined this function many times. The addition of a one line function does not prevent anyone from using `pure` in their own code if they wish to obfuscate matters. Cheers, Matt On Tue, Aug 13, 2019 at 6:35 AM Elliot Cameron wrote:

Seq is applicative and also has singleton. Some people like to avoid polymorphism when the use case is clearly monomorphic (c.f. discussion about map vs fmap).

I'd like to point out that Pointed is sort of the abstraction we really want for this... But I still want a monomorphic function that doesn't delve into Kmett dependencies.

On Mon, Aug 12, 2019 at 11:59 PM George Wilson wrote:

...

Weak +1, I'd want it in NonEmpty too if it's going into List.

On Tue, 13 Aug 2019 at 13:37, Joseph C. Sible wrote:

...

-1. AFAICT, "Polymorphic, works for any `Functor`" is an upside of just using `pure`, not a downside. (Please correct me if I'm wrong, and there is some disadvantage that I don't see.) Also, it looks like for everything that has a `singleton`, it's something that isn't an applicative functor, so they have them instead of `pure`, not in addition to it.

Joseph C. Sible

On Mon, Aug 12, 2019 at 12:14 PM Taylor Fausak wrote:

...

I originally made this suggestion on GitLab, but I was told to make it here instead.

https://gitlab.haskell.org/ghc/ghc/issues/17042

---

# Add list singleton function

## Motivation

Sometimes it is convenient to have a function to wrap an element in a list. There are many ways to do this already, but none of them are as clear as a separate monomorphic function.

- `pure`: Polymorphic, works for any `Functor`. - `pure @[]`: Noisy, requires `-XTypeApplications`. - `(: [])`: Subjectively ugly. - `(\x -> [x])`: Syntactically noisy.

This Twitter thread includes some additional commentary: https://twitter.com/taylorfausak/status/1159264862247280640

## Proposal

I would like to add a `singleton` function to `Data.List` that mirrors the `singleton` function for other containers: https://www.stackage.org/lts-14.0/hoogle?q=singleton

``` hs singleton :: a -> [a] singleton x = [x] ```

Other Haskell-like languages include this function:

- PureScript: https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.Lis... - Elm: https://package.elm-lang.org/packages/elm/core/latest/List#singleton _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Another advantage to having an explicit singleton function is discoverablity. I distinctly remember looking for exactly this function when I was a beginner and being confused because it didn't seem to exist. Idioms like (:[]) are not intuitive at all. Polymorphic functions like pure require you to know that list is an Applicative, which you won't learn right away. Even if your have learned about Applicatives, it's easy to miss that connection when you're thinking about lists as a data structure rather than as a control structure, which is exactly the scenario I expect people to use a singleton function. On Tue, Aug 13, 2019, 09:44 Matthew Pickering wrote:

Clear +1 from me. I have defined this function many times.

The addition of a one line function does not prevent anyone from using `pure` in their own code if they wish to obfuscate matters.

Cheers,

Matt

On Tue, Aug 13, 2019 at 6:35 AM Elliot Cameron wrote:

...

Seq is applicative and also has singleton. Some people like to avoid

polymorphism when the use case is clearly monomorphic (c.f. discussion about map vs fmap).

...

I'd like to point out that Pointed is sort of the abstraction we really

want for this... But I still want a monomorphic function that doesn't delve into Kmett dependencies.

...

On Mon, Aug 12, 2019 at 11:59 PM George Wilson

wrote:

...

...

Weak +1, I'd want it in NonEmpty too if it's going into List.

On Tue, 13 Aug 2019 at 13:37, Joseph C. Sible

wrote:

...

...

-1. AFAICT, "Polymorphic, works for any `Functor`" is an upside of just using `pure`, not a downside. (Please correct me if I'm wrong, and there is some disadvantage that I don't see.) Also, it looks like for everything that has a `singleton`, it's something that isn't an applicative functor, so they have them instead of `pure`, not in addition to it.

Joseph C. Sible

On Mon, Aug 12, 2019 at 12:14 PM Taylor Fausak

wrote:

...

...

I originally made this suggestion on GitLab, but I was told to make

it here instead.

...

https://gitlab.haskell.org/ghc/ghc/issues/17042

---

# Add list singleton function

## Motivation

Sometimes it is convenient to have a function to wrap an element in

a list. There are many ways to do this already, but none of them are as clear as a separate monomorphic function.

...

- `pure`: Polymorphic, works for any `Functor`. - `pure @[]`: Noisy, requires `-XTypeApplications`. - `(: [])`: Subjectively ugly. - `(\x -> [x])`: Syntactically noisy.

This Twitter thread includes some additional commentary:

https://twitter.com/taylorfausak/status/1159264862247280640

...

## Proposal

I would like to add a `singleton` function to `Data.List` that

mirrors the `singleton` function for other containers: https://www.stackage.org/lts-14.0/hoogle?q=singleton

...

``` hs singleton :: a -> [a] singleton x = [x] ```

Other Haskell-like languages include this function:

- PureScript:

https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.Lis...

...

- Elm: https://package.elm-lang.org/packages/elm/core/latest/List#singleton _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

The reason it's particularly unintuitive for lists is that we almost never explicitly construct lists using : and []. Sections like (+ 1) or (++ "Foo") reflect expressions like x + 1 and str ++ "Foo", but you simply never see x : [] in the wild. (In fact, in code review, I would always expect that to be rewritten as [x].) In turn, this means that (:[]) doesn't convey my intentions as directly as possible. I want to build a list that contains a single element x, which I usually think of as [x]; the fact that I do this by consing x with an empty list is an implementation detail. More generally, lists merit a special case because list notation is *already* a special case, and we can't do anything about that at this point! On Tue, Aug 13, 2019, 10:49 Jon Fairbairn wrote:

Tikhon Jelvis writes:

...

Idioms like (:[]) are not intuitive at all.

Can you explain that? Once one knows that all infix operators can be used in sections (+1), (++"foo"), etc, that notation should be obvious, both in reading and writing. It’s much better to use ideas that are uniformly usable throughout the language and can be learned once than to have to learn numerous specific words.

I’m -1 on the proposal, obviously.

-- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

I'm +1 on this. I've defined this function in my own code before. Using pure instead leads to harder-to-read code for future me and for collaborators. It also leads to worse type errors in the event that I mess something up. On Tue, Aug 13, 2019 at 5:11 AM David Feuer wrote:

I'm moderately +1 for consistency, and for NonEmpty as well. There is a concept here: create a container containing exactly one value. As Tikhon indicates, this is a different concept from pure. For example, a singleton ZipList has one element, while a pure one has infinitely many elements.

On Mon, Aug 12, 2019, 11:14 PM Taylor Fausak wrote:

...

I originally made this suggestion on GitLab, but I was told to make it here instead.

https://gitlab.haskell.org/ghc/ghc/issues/17042

---

# Add list singleton function

## Motivation

Sometimes it is convenient to have a function to wrap an element in a list. There are many ways to do this already, but none of them are as clear as a separate monomorphic function.

- `pure`: Polymorphic, works for any `Functor`. - `pure @[]`: Noisy, requires `-XTypeApplications`. - `(: [])`: Subjectively ugly. - `(\x -> [x])`: Syntactically noisy.

This Twitter thread includes some additional commentary: https://twitter.com/taylorfausak/status/1159264862247280640

## Proposal

I would like to add a `singleton` function to `Data.List` that mirrors the `singleton` function for other containers: https://www.stackage.org/lts-14.0/hoogle?q=singleton

``` hs singleton :: a -> [a] singleton x = [x] ```

Other Haskell-like languages include this function:

- PureScript: https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.Lis... - Elm: https://package.elm-lang.org/packages/elm/core/latest/List#singleton _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

The point is to create a monomorphic variant that avoids the problems with the polymorphic `pure` and would be consistent with the other container-types. A polymorphic `singleton` would be useful, but - in the same way that `Map.fromLIst` and `Set.fromList` are (usefully!) monomorphic despite equivalent `IsList` methods, we'd still want to have a concrete `List.singleton :: a -> [a]`. I see a lot of "Why isn't `pure` good enough here?", so I'd like to reiterate that `pure` has issues: - It's not immediately+syntactically obvious what's being created. List.singleton is unambiguous to read. - Polymorphism can cause unintended changes to behavior if GHC infers a different type than you expect. Consider `length (1,2)` confusion, `fmap (+1) (Left 1)` - while these have an obviously correct instance, it can still be confusing and yield potentially incorrect results. - Monomorphic functions can often be very useful to inform GHC about a specific type you want to fix and allow the rest of inference to work around. Typed-holes provide *much* better information when you have concrete types rather than constrained polymorphic types. - Finally, monomorphic functions can be used to prevent ambiguous type errors in the presence of OverloadedLists and OverloadedStrings, especially when every other method in the chain is written on Foldable or similar constraints. Matt Parsons On Tue, Aug 13, 2019 at 4:13 PM Herbert Valerio Riedel wrote:

...

There is a concept here: create a container containing exactly one value. As Tikhon indicates, this is a different concept from pure.

Fwiw, if you actually want a possibly meaningful/lawful reification of the very specific "create any container containing exactly one item" concept then an obvious approach would be to base it on the existing (IMO under-appreciated) 'IsList' abstraction; in other words basically something like

singleton :: IsList l => Item l -> l singleton = fromListN 1 . (:[])

which could either be a method of `IsList` (with the default impl above and an obvious lawful relationship to `fromList`/`toList`) or just be a top-level binding exported from "GHC.List" and/or "GHC.Exts" (which aren't governed by the Haskell Library Report and thus have a lower barrier to entry). _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

`(\x -> [x])` has the same polymorphism problem in the context of `OverloadedLists` as `pure`. `(:[])` is also unsatisfactory. To parse it properly, you need to: - Know that `:` is only allowed as an operator to prefix data constructors, - Know that `[]` are not legal operator characters, - Infer that you're intended to insert a space between the `:` and `[]` to get `(: [])` - Recognize it as an operator section being used prefix as a normal function I'm neither an expert nor a lifelong Haskeller, but I have been writing it in some professional capacity for four years now, and the operator section trips me up. I can't imagine less experienced folks find it easy or intuitive. You can't even search for it on hoogle: https://hoogle.haskell.org/?hoogle=(%3A%5B%5D) Is `(:[])` a core idiom? I never see it in work code and I've never seen it in Hackage. To check, I grepped my software directory which has all my Haskell code, and got 122 matches of (:[]) over 1,768,231 loc (as given by wc -l **/*.hs). Matt Parsons On Tue, Aug 13, 2019 at 4:56 PM Herbert Valerio Riedel wrote:

...

The point is to create a monomorphic variant [...]

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

`(:[])` is also unsatisfactory

Which is a purely subjective assessment (and one I clearly disagree with)

To parse it properly, you need to:

- Know that `:` is only allowed as an operator to prefix data constructors, - Know that `[]` are not legal operator characters, - Infer that you're intended to insert a space between the `:` and `[]` to get `(: [])` - Recognize it as an operator section being used prefix as a normal function

Indeed, in order to parse a legit Haskell term, be it (0(,)), (:[0]) or (:".exe") or (:[]) you need to know the core Haskell98 syntax. I'm aware that other languages such as Elm or Purescript favor different ideals and design principles but that's not really a good argument to make either; each language has its own idioms and point in the design space. I'm still waiting for a statement of the technical problem we're trying to solve here which requires the introduction of a redundant synonym for a concise facility we already have at our disposal by virtue of the core Haskell98 syntax. Otherwise I'm afraid we're going to be stuck in this discussion as everything on the topic has been said and repeated in one way or another and so far we haven't reached any consensus.

I'd also be interested in a kind of "reverse" argument - *if* we had this added, what are the costs? There are arguments of "no, pure/robot ninja is enough" - fine, we're not taking those away so you aren't required to use singleton But what is the *downside* of having singleton? It's basically write once, so I don't see an increase of maintenance burden in the prelude. Of course, if people start to use it and you don't, there is a bit of conflict when it comes to reading others code. It's a slightly longer name, but the name itself is pretty clear. Even if you don't have it fully qualified, it's clear that it constructs a single element of something - the only syntax with potentially more information is the robot ninja operator (in the absence of overloaded lists), which makes it unambiguously about lists. So I think for people comfortable with pure/robot ninja, they would also be able to understand code using singleton. OTOH, the opposite doesn't seem to follow. So, to the -1s, did I miss anything else? On Wed, 14 Aug 2019, 6:37 pm Matt, wrote:

There have been 19 votes cast so far. We have twelve +1 votes. Of the -1 votes, three are because "`pure` is fine" and four are because "`(:[])` is fine." I summarized the issue with `pure` in my previous email, and there hasn't been any response or comment on the issues raised.

To summarize/quote the issues with `(:[])`:

...

You can't even search for it on hoogle: https://hoogle.haskell.org/?hoogle=(%3A%5B%5D) Another advantage to having an explicit singleton function is discoverablity.

The discoverability of `(:[])` is bad.

...

Is `(:[])` a core idiom? I never see it in work code and I've never seen it in Hackage. To check, I grepped my software directory which has all my Haskell code, and got 122 matches of (:[]) over 1,768,231 loc (as given by wc -l **/*.hs).

`(:[])` is not a common idiom (in the code sample I have; your mileage may vary).

...

All alternatives to construct a list "anonymously" are confusing and take time to parse. The `(:[])` operator takes me a decent amount longer to parse and recognize, and I have seen intermediate-level Haskellers trip up over unspaced operators like this in several contexts.

The operator section is confusing and difficult to parse in this context.

Those are the three main problems that people have with `(:[])`, as far as I can tell.

Matt Parsons

On Wed, Aug 14, 2019 at 11:10 AM Herbert Valerio Riedel < hvriedel@gmail.com> wrote:

...

...

`(:[])` is also unsatisfactory

Which is a purely subjective assessment (and one I clearly disagree with)

...

To parse it properly, you need to:

- Know that `:` is only allowed as an operator to prefix data constructors, - Know that `[]` are not legal operator characters, - Infer that you're intended to insert a space between the `:` and `[]` to get `(: [])` - Recognize it as an operator section being used prefix as a normal function

Indeed, in order to parse a legit Haskell term, be it (0(,)), (:[0]) or (:".exe") or (:[]) you need to know the core Haskell98 syntax. I'm aware that other languages such as Elm or Purescript favor different ideals and design principles but that's not really a good argument to make either; each language has its own idioms and point in the design space.

I'm still waiting for a statement of the technical problem we're trying to solve here which requires the introduction of a redundant synonym for a concise facility we already have at our disposal by virtue of the core Haskell98 syntax. Otherwise I'm afraid we're going to be stuck in this discussion as everything on the topic has been said and repeated in one way or another and so far we haven't reached any consensus. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Sven Panne wrote:

Code is mainly *read*, not written, so the less you need to know to read and understand code, the better it is.

Yes, and this is an argument *for* singleton, not against: 1. singleton is already known to the Haskell reader from the other collection types. 2. singleton is unambiguously invoking the image of creating a singleton collection. In contrast, "pure" invokes the image of creating a effect-free monadic computation. (:[]) invokes the image of a (mechanical) gorilla smiling at you. ;-) All these associations distract from reading the code. In both cases, a mental translation step is needed: a) In the case of "pure", the conscious intervention that here we are not concerned with non-determinism (the list monad), but just creating a singleton collection. b) In the case of "(:[])", the conscious intervention consists of - recognizing the decomposition (: []) - recognizing the operator section - understanding it as "cons something to the empty list" - understanding this as creating a singleton collection. Both interventions hamper the flow of reading. Of course, the procedure b) becomes automatic with use. However, it is still a significant barrier to the newcomer. Cheers, Andreas P.S.: if the gorilla (:[]) is vanishing from the Agda code base, I am mostly to be blamed for this. On 2019-08-14 21:51, Sven Panne wrote:

Am Mi., 14. Aug. 2019 um 21:35 Uhr schrieb Oliver Charles mailto:ollie@ocharles.org.uk>:

I'd also be interested in a kind of "reverse" argument - *if* we had this added, what are the costs? There are arguments of "no, pure/robot ninja is enough" - fine, we're not taking those away so you aren't required to use singleton  But what is the *downside* of having singleton? [...]

A similar argument comes up with basically every extension, and it is a very weak one. Code is mainly *read*, not written, so the less you need to know to read and understand code, the better it is. Lots of different ways to do the same thing makes programs harder to understand, and you ultimately end up with Perl. :-}  And if we take this argument seriously, we should probably add "doubleton" (synonym for "replicate 2"), "tripleton" (synonym for "replicate 3"), etc., too.  Hey, you don't have to use it after all, we're not taking away "replicate"...

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Am Mi., 14. Aug. 2019 um 19:37 Uhr schrieb Matt :

There have been 19 votes cast so far. We have twelve +1 votes.

-1 from me, so we have 7 -1s now. >:-) BTW: Simply counting a tiny amount of votes in a niche mailing list is not the best way to design APIs IMHO.

Of the -1 votes, three are because "`pure` is fine" and four are because "`(:[])` is fine." I summarized the issue with `pure` in my previous email, and there hasn't been any response or comment on the issues raised.

I still fail to see the issues with "pure". Let's be honest: If somebody has problems with polymorphic functions or operator sections, he will have a hard time with Haskell in general. These are fundamental things in your toolbox, and instead of coming up with tons of names which nobody can remember (Fairbairn threshold, anyone?) for trivial things, time is better spent educating people. Compared to the stuff you currently see in most modern libraries (GADTs, lenses, type-level computations, ...) understanding "pure" or "(: [])" will be your least problem.

To summarize/quote the issues with `(:[])`:

...

You can't even search for it on hoogle: https://hoogle.haskell.org/?hoogle=(%3A%5B%5D) Another advantage to having an explicit singleton function is discoverablity.

The discoverability of `(:[])` is bad.

Why should I need to discover it when I can write it with 6 keystrokes (or even 4)? Or as "\x -> [x]", which is basically a matter of taste?

...

Is `(:[])` a core idiom? I never see it in work code and I've never seen it in Hackage. To check, I grepped my software directory which has all my Haskell code, and got 122 matches of (:[]) over 1,768,231 loc (as given by wc -l **/*.hs).

`(:[])` is not a common idiom (in the code sample I have; your mileage may vary).

It is quite obvious to me why you don't find it much in code. You have lots of other ways to express the same thing: * You'll probably just use "[x]" if the argument already has a name. * If the argument doesn't have a name, you can give it one via "\x -> [x]" (which I consider "explicit", not "noisy") or perhaps via eta abstraction. * The code is intended to be polymorphic => "pure" is used. * Even if it's intended to be used monomorphic, there are often type signatures around to make "pure" monomorphic enough. This doesn't leave many sensible places. Perhaps as an argument for a function, with very few type signatures around? Not a very convincing use case IMHO. In a nutshell: Just like Herbert, I can't see the problem we're trying to solve. I would go even further: I would like to see a much more general Prelude/base library, not a more monomorphic one. Pages like https://haskell.fpcomplete.com/tutorial/synonyms cause quite a few "WTF?" moments caused by the (nowadays) useless synonyms...

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.

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 < alexandre.fmp.esteves@gmail.com>:

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles < ollie@ocharles.org.uk>:

On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, < helmut.schmidt.4711@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!

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 mailto:ollie@ocharles.org.uk>:

On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, mailto:helmut.schmidt.4711@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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:con...

https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:app...

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:appen...

http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:c...

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteStrin...

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteStrin...

Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel :

...

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 mailto:ollie@ocharles.org.uk>:

On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, mailto:helmut.schmidt.4711@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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 < libraries@haskell.org> 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 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:con...

https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:app...

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:appen...

http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:c...

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteStrin...

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteStrin...

Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel < andreas.abel@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 mailto:ollie@ocharles.org.uk>:

On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, mailto:helmut.schmidt.4711@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

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 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 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:con...

...

https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:app...

...

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:appen...

...

http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:c...

...

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteStrin...

...

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteStrin...

...

Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <

andreas.abel@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 mailto:ollie@ocharles.org.uk>:

On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, mailto:helmut.schmidt.4711@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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! 1: https://github.com/haskell/rfcs/issues/15 2: https://www.haskell.org/onlinereport/haskell2010/haskellch20.html#x28-228000... 3: https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-List.html#v:unco... 4: https://gitlab.haskell.org/ghc/ghc/blob/83ca42de519cdfa28b38164e90d726034dba... 5: https://gitlab.haskell.org/ghc/ghc/issues/9550 6: https://mail.haskell.org/pipermail/libraries/2014-July/023314.html 7: https://phabricator.haskell.org/D195 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 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 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:con...

https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:app...

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:appen...

http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:c...

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteStrin...

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteStrin...

Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel :

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 mailto:ollie@ocharles.org.uk>:

On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, mailto:helmut.schmidt.4711@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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 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 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:con...

https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:app...

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:appen...

http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:c...

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteStrin...

https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteStrin...

Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel :

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 mailto:ollie@ocharles.org.uk>:

On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, mailto:helmut.schmidt.4711@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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 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@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 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 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@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@ocharles.org.uk <mailto:ollie@ocharles.org.uk>>: >>> >>> On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt, >>> <helmut.schmidt.4711@gmail.com >>> <mailto:helmut.schmidt.4711@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@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries