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 <kindaro@gmail.com> 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 <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]
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