Re: [Haskell-cafe] Line noise
On Tuesday 23 September 2008 02:27:17 Brian Hurt wrote: > On Sun, 21 Sep 2008, wren ng thornton wrote: > > Even with functionalists ---of the OCaml and SML ilk--- > > this use of spaces can be confusing if noone explains that function > > application binds tighter than all operators. > > Bwuh? Ocaml programmers certainly know that application binds tighter > than operators. And as: > > let f x y = ... in > f a b > > is more efficient (in Ocaml) than: > > let f (x, y) = ... in > f (a, b) > > (Ocaml doesn't optimize away the tuple allocation)... That is incorrect. OCaml does optimize away that tuple: both forms compile to the same 2-argument function. OCaml does not optimize away this tuple: let a, b = 1, 2 So, when efficiency is important, you write: let a = 1 and b = 2 -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On 2008 Sep 21, at 15:10, Andrew Coppin wrote: Philippa Cowderoy wrote: On Sun, 21 Sep 2008, Andrew Coppin wrote: - Several standard library functions have names which clash badly with the usual meanings of those names - e.g., "break", "return", "id". For this one, I'm inclined to say "welcome to a new paradigm". Though having to tell my dad briefly that do isn't a loop construct was odd for a moment. I think "return" is a rather bad choice of name. But on the other hand, I can't think of a better one. And let's face it, anything has to be better than (>>=). (Most cryptic name ever?) Applicative and Arrow have the replacement for "return" right: "pure". No argumnt about (>>=), but on the other hand I remember (>>=) but never remember the arrow or Applicative operators. Idiomatic Haskell seems to consist *only* of single-letter variable names. When did you last see a pattern like (customer:customers)? No, it'd be (c:cs), which isn't very self- I tend to use something like cust:custs; I prefer to be able to read it. If the code is generic then I'll use generic names --- which alerts me to its genericness. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Brian Hurt wrote: On Sun, 21 Sep 2008, wren ng thornton wrote: > Even with functionalists ---of the OCaml and SML ilk--- this use of > spaces can be confusing if noone explains that function application > binds tighter than all operators. Bwuh? Ocaml programmers certainly know that application binds tighter than operators. And as: Not being of either ilk, perhaps I mis-relayed the confusions of a friend recently converted to Haskell :) The issue I was raising had not so much to do with un/currying of functions but rather whether something like "foo bar %^& baz" means "(foo bar) %^& baz" or "foo (bar %^& baz)". I believe this was voiced as an SML issue more than an OCaml issue, though honestly I don't know enough of the differences to distinguish them. Before I mentioned that function/prefix application always binds tighter than operator/infix application, he was using many redundant parentheses, thanks to defensive programming against whichever dialect was at fault. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Mon, Sep 22, 2008 at 6:27 PM, Brian Hurt <[EMAIL PROTECTED]> wrote: > > > On Sun, 21 Sep 2008, wren ng thornton wrote: > >> Even with functionalists ---of the OCaml and SML ilk--- this use of spaces >> can be confusing if noone explains that function application binds tighter >> than all operators. > > Bwuh? Ocaml programmers certainly know that application binds tighter than > operators. And as: > >let f x y = ... in >f a b > > is more efficient (in Ocaml) than: > >let f (x, y) = ... in >f (a, b) > > (Ocaml doesn't optimize away the tuple allocation), the former > (Haskell-like) is generally preferred by Ocaml programmers. That's odd. My experience from trying to learn ocaml at one point was that the tuple notation is preferable because you can do pattern matching on every value in the tuple whereas with the other one you can match on either the first or second parameter but not both without nesting ocaml's version of 'case ... of' (match ... with?). One of the things I really like about Haskell syntax is that you can pattern match on any number of parameters without having to nest 'case ... of' expressions. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Sun, 21 Sep 2008, wren ng thornton wrote: Even with functionalists ---of the OCaml and SML ilk--- this use of spaces can be confusing if noone explains that function application binds tighter than all operators. Bwuh? Ocaml programmers certainly know that application binds tighter than operators. And as: let f x y = ... in f a b is more efficient (in Ocaml) than: let f (x, y) = ... in f (a, b) (Ocaml doesn't optimize away the tuple allocation), the former (Haskell-like) is generally preferred by Ocaml programmers. SML programmers do use the second form, I'll grant you. Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Most people seem far more confused by what a "fold" might be. A fold by any other name would smell as sweet. ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjYE7kACgkQTkPEVFd3yxh7HwCfVzopoOCgg49YI0Y88g9rjXqI DvcAn3Buv4FmqcYrK5pDLr1iUc7XRpO5 =CKiH -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Ketil Malde wrote: The rationale for having long names is that you have too many names, and too large a scope to keep track of them all in your head. Needing long names is a symptom that your code is too complex, and that you should refactor it. Well, yeah. In Haskell, functions tend to be rather shorter than in procedural languages, so there's less call for dissambiguation because there are fewer variables in scope. The other problem with "descriptive" names is that it is not automatically checked by the compiler, and thus it often ends up being misleading. Incorrect documentation is worse than no documentation. That's true enough. Nobody is going to realise that "[x]" means a list. And C is utterly incomprehensible, since from my Pascal background, I just *know* that curly braces denote comments. Come on, expecting somebody to understand a language without an extremely basic understanding of fundamental syntactical constructs is futile. Point taken. I still think "List x" would have been clearer, but nobody is going to change the Haskell Report now... well you can see why people are getting lost! ;-) Yes, by refusing to adapt to any syntax but the single one they know. Some people will glance at Haskell and think "hey, that doesn't look like source code, I can't read that". But given the number of times I've explained all this stuff, you'd think one or two people would have got it by now... Only if you can figure out that "Map" means what every other programming language on the face of the Earth calls a "dictionary". (This took me a while!) Except for where it is called an "associative array" or "hash table"? Terminology is inconsistent, Haskell happens to draw more of it from math than from other programming languages. Heh, let's not argue over technical terms... ;-) Most people seem far more confused by what a "fold" might be. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Stephan Friedrichs wrote: Andrew Coppin wrote: [...] - Variable names such as "x" and "f" aren't fabulously helpful to lost programmers trying to find their way. I'm not a fan of cryptic variable names, either, and I try to use descriptive names wherever I can. But in Haskell... - ... you often have variables, which have a scope of far less than a line such as in "map (\(x, (_, y)) -> (x, y) ..." (cleaning intermediate results from a list). - ... things often get very abstract, so that it just feels wrong matching on, say, (socket:sockets) instead of (x:xs). ...so, more or less the reason why mathematical formulas usually end up with non-descriptive variable names then. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Sun, Sep 21, 2008 at 1:10 PM, Andrew Coppin <[EMAIL PROTECTED]> wrote: > I posted a snippet of code which included the phrase > > mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..] > vs) > > To somebody familiar with Haskell, that is as clear as day. But to a > newbie... well *you* try explaining that you start at the left end, take the > thing in brackets, process it from left to right, then take the other thing > in brackets, process the right side of it, then pass that to putStrLn, oh, > but that thing right at the left edge is the argument list, and then pass > the whole lot to mapM_, which is... are you still with me?? > > As one experienced C++ programmer put it, "there is no clear flow from left > to right or right to left". This is actually one of the two main metrics I use when I'm writing code -- I try to keep the information content in my code local, so you don't have to scan across the screen to see what n corresponds to. This is equivalent to maintaining a left-to-right or right-to-left flow (and really which direction it is depends more on reading style than writing style). The other one I picked up from Perl of all places, and that is end weight. In English we tend to put the important parts (the "essence") of the sentence at the front, and leave the details for the end. So I like to emulate that in Haskell when I can. There is little I loathe more than the style: map (\x -> ... ... ... ... ...) xs As such, the probability that I would have written the mapM_ line above is very low, since it violates both of these. In this case, switching to forM_ brings it much closer to my style: forM_ (zip [0..] vs) $ \(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v That is because the details of this sentence are in the function, so I put it at the end. Also the corresponding [0..] and n are close together, as are the corresponding vs and v. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Mon, Sep 22, 2008 at 1:50 PM, Daniel Fischer <[EMAIL PROTECTED]>wrote: > Am Montag, 22. September 2008 08:32 schrieb Andrew Coppin: > > > However, I will grant you that Map k v, could have used longer type > > > variables. But we are not alone with using one letter type variable > > > names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . > And > > > frankly, in this specific case, I think most programmers (Haskell or > > > non-Haskell) will be able to guess what k and v means, when they are > > > standing right after Map. > > > > Only if you can figure out that "Map" means what every other programming > > language on the face of the Earth calls a "dictionary". (This took me a > > while!) > > So, when did Java leave the face of the earth? At the same time as C++ presumably. I hadn't really noticed, but I'll be the first to say: Good riddance! -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Sun, Sep 21, 2008 at 10:04 PM, Claus Reinke <[EMAIL PROTECTED]> wrote: > Once your readers understand > your code, you can add the one-liner and ask for applause This should make it HWN's quotes of the week ! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Am Montag, 22. September 2008 08:32 schrieb Andrew Coppin: > > However, I will grant you that Map k v, could have used longer type > > variables. But we are not alone with using one letter type variable > > names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And > > frankly, in this specific case, I think most programmers (Haskell or > > non-Haskell) will be able to guess what k and v means, when they are > > standing right after Map. > > Only if you can figure out that "Map" means what every other programming > language on the face of the Earth calls a "dictionary". (This took me a > while!) So, when did Java leave the face of the earth? Seriously, I find Map a far clearer term than dictionary and would've had problems grokking the latter. I guess you've just been exposed to the wrong languages for too long. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Andrew Coppin <[EMAIL PROTECTED]> writes: >>> Idiomatic Haskell seems to consist *only* of single-letter variable >>> names. Good thing, too. > Well, qsort (element : list) would be maximally intuitive, but who's > going to implement it like that? ;-) Why not listElement : restOfList ? The rationale for having long names is that you have too many names, and too large a scope to keep track of them all in your head. Needing long names is a symptom that your code is too complex, and that you should refactor it. The other problem with "descriptive" names is that it is not automatically checked by the compiler, and thus it often ends up being misleading. Incorrect documentation is worse than no documentation. > qsort:: (Ord x) => [x] -> [x] > > Nobody is going to realise that "[x]" means a list. And C is utterly incomprehensible, since from my Pascal background, I just *know* that curly braces denote comments. Come on, expecting somebody to understand a language without an extremely basic understanding of fundamental syntactical constructs is futile. > well you can see why people are getting lost! ;-) Yes, by refusing to adapt to any syntax but the single one they know. > Only if you can figure out that "Map" means what every other > programming language on the face of the Earth calls a > "dictionary". (This took me a while!) Except for where it is called an "associative array" or "hash table"? Terminology is inconsistent, Haskell happens to draw more of it from math than from other programming languages. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Andrew Coppin wrote: > [...] > - Variable names such as "x" and "f" aren't fabulously helpful to lost > programmers trying to find their way. I'm not a fan of cryptic variable names, either, and I try to use descriptive names wherever I can. But in Haskell... - ... you often have variables, which have a scope of far less than a line such as in "map (\(x, (_, y)) -> (x, y) ..." (cleaning intermediate results from a list). - ... things often get very abstract, so that it just feels wrong matching on, say, (socket:sockets) instead of (x:xs). > > [...] > //Stephan -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Mads Lindstrøm wrote: Andrew Coppin wrote: Idiomatic Haskell seems to consist *only* of single-letter variable names. The more abstract (generic) thing gets, the less likely you will be able to find a telling name. And if you cannot find a telling name, you can just as well make it short. And as Haskell is more abstract, we get more short identifiers. E.g. in your earlier sorting function: qsort (x:xs) = ... what would you propose to call the elements? Well, qsort (element : list) would be maximally intuitive, but who's going to implement it like that? ;-) Now of course in C, you'd be forced to write something like list qsort(int x, list xs) which makes it completely unambiguous what these things are - what their type is. But in Haskell, even if you add a type signature: qsort:: (Ord x) => [x] -> [x] Nobody is going to realise that "[x]" means a list. And it's still not clear where ":" comes from, or... well you can see why people are getting lost! ;-) However, I will grant you that Map k v, could have used longer type variables. But we are not alone with using one letter type variable names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And frankly, in this specific case, I think most programmers (Haskell or non-Haskell) will be able to guess what k and v means, when they are standing right after Map. Only if you can figure out that "Map" means what every other programming language on the face of the Earth calls a "dictionary". (This took me a while!) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Dan Piponi wrote: I suspect that most of the complaints about line noise stem from this - to beginners Haskell expressions just look like sequences of identifiers with no apparent grammar to "bind" them together. This was the exact complaint that some people voiced, yes. (The (.) and ($) operators just compound the problem.) Somebody else then came to my rescue and pointed out that "everybody says Lisp is unreadable because it has too many brackets - despite the fact that those brackets theoretically make parsing utterly trivial". ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On 22 Sep 2008, at 9:19 am, Albert Y. C. Lai wrote: Everyone should use exclusively ancient Egyptian iconography. It is the only universally readable language. I know this was full of (:-) (:-), but it seems like the perfect chance to mention Blissymbols. http://unicode.org/roadmaps/smp/smp-4-14.html (the Unicode SMP road map) has a link to a proposal for adding them to Unicode, and they _are_ in active use... (A Haskell program in Blissymbols would be, well, bigger.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Quoth Andrew Coppin <[EMAIL PROTECTED]>: ... | As one experienced C++ programmer put it, "there is no clear flow from | left to right or right to left". Personally I found that a little ironic | comming from the language that gave us | | while (*x++ = *y++) { } | | which is every bit as non-linear! ;-) Well, to be precise, C++ got that from C. What C++ adds to it: fy(a.fx(b), c) (in Haskell, fy (fx a b) c) I wouldn't worry too much about one letter identifiers and so forth. Many programmers will secretly be rather attracted to this kind of thing. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Sun, Sep 21, 2008 at 7:49 PM, wren ng thornton <[EMAIL PROTECTED]> wrote: > We inherited our use of spaces for function application from Lisp and > friends, so "foo bar baz" looks perfectly natural to functionalists. But to > those used to seeing "foo(bar, baz)" the meaning attached to the spaces is > alien. I have to admit, it took me a long time to be able to parse the ML-style function notation in Haskell. I found it the biggest "barrier to entry". I suspect that most of the complaints about line noise stem from this - to beginners Haskell expressions just look like sequences of identifiers with no apparent grammar to "bind" them together. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Andrew Coppin wrote: I hang out on another forum that is populated by various kinds of computer geeks. There's a fair few programmers in there, as well as nerds of every degree. And yet, every time I post anything written in Haskell, everybody complains that it "looks like line noise". Actually, none of these things were mentioned. The things people have *actually* complained to me about are: - Haskell expressions are difficult to parse. To anyone who doesn't know the language, this seems quite true. Haskell was designed with a hyper-minimalist syntax, whereas C/C++/Java are very heavy with syntactic boilerplate. I am a devout fan of the minimalism, but it is something of a barrier to entry for those unwilling to consider anything that doesn't look familiar. We inherited our use of spaces for function application from Lisp and friends, so "foo bar baz" looks perfectly natural to functionalists. But to those used to seeing "foo(bar, baz)" the meaning attached to the spaces is alien. The 'difference' in meaning for the two spaces only drives the alienness home, since (ubiquitous) currying is not well known or practiced outside of Haskell. Even with functionalists ---of the OCaml and SML ilk--- this use of spaces can be confusing if noone explains that function application binds tighter than all operators. Similarly, we use linebreaks to denote various things whereas the syntax-heavy languages require a semicolon or similar delimiter. We are in fortuitous arms here since we can use the redundant {;} notation to sell new folks. Though it is wise to use the notation with the semicolon trailing on the previous line: do { foo; bar; baz; } rather than the more idiomatic leading version: do { foo ; bar ; baz } Again, the minimalist version that omits the {;} which lends a meaning to whitespace that syntax-heavy users are not familiar with. Here I think is largely a question of knowing your audience; the explicit version is better for any audience with many non-Haskell folks, even if it's a functional audience. We also allow for omitting parentheses in many places required by other languages. In particular, the case...of construct mentioned previously. The if...then...else construct can have similar problems, though they are more easily overlooked by foreigners. Again this is easy to correct for when talking with outsiders: just add redundant parentheses. The meaning of = and how it differs from -> are also quite subtle. Pattern matching and guards, like currying, are concepts that are quite alien to users of most other languages. The simplicity of their syntax in Haskell probably serves to further confuse questions of the syntax associated with =. I know from experience that these simple ideas can be a tough sale. Few languages have the notion that defining a function is the same as any other 'assignment' and so most languages have radically different syntaxes for the two. This trait of treating functions as first-class citizens tends to have large brain-breaking capabilities-- moreso than passing functions as arguments, it seems. All of these are just basic things about Haskell's syntax and have nothing to do with all the interesting higher-order stuff which is really novel. It is unfortunate that there are so many people, intelligent people even, who are so hidebound as to be unwilling to gloss over syntax, but sadly it is the way of things. To be fair to them, the meanings assigned to whitespaces are not the sort of thing which is trivial to intuit. Perhaps we need a _Guide to Reading Haskell (for non-Haskell Programmers)_? -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
I read from many reviews and shootouts that cell phones sold in Japan are more diverse, advanced, and user-friendly than cell phones sold in the US. So I bought one, but to my dismay, both the offline manual and the on-screen menu are line noise. Then I found a web dictionary to translate them word-for-word. The result is still unparsible, like "water submerge in don't ever". Are we supposed to be human beings or are we supposed to be all Master Yoda's? Why and how the whole Japanese population put up with this epic fail is beyond me. Everyone should use exclusively ancient Egyptian iconography. It is the only universally readable language. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Andrew Coppin wrote: > Idiomatic Haskell seems to consist *only* of single-letter variable > names. When did you last see a pattern like (customer:customers)? No, > it'd be (c:cs), which isn't very self-documenting. Ditto for type > variables by the way. (Map k v, anyone?) It also seems to be Haskell > convention to use "a" as a type variable; personally I always use "x". I > guess that's the algebra in my blood or something... > The more abstract (generic) thing gets, the less likely you will be able to find a telling name. And if you cannot find a telling name, you can just as well make it short. And as Haskell is more abstract, we get more short identifiers. E.g. in your earlier sorting function: qsort (x:xs) = ... what would you propose to call the elements? Yes, if it sorted customers, you call 'em (customer:customers). But you have made a very abstract sorting function, which sorts a lot besides customers. And then you are bound to end up with a non-telling name. However, I will grant you that Map k v, could have used longer type variables. But we are not alone with using one letter type variable names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And frankly, in this specific case, I think most programmers (Haskell or non-Haskell) will be able to guess what k and v means, when they are standing right after Map. Greetings, Mads ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
I posted a snippet of code which included the phrase mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..] vs) "Don't do that, then"?-) mapM_ putStrLn $ map (\(n,v) -> "[" ++ show n ++ "] = " ++ show v) (zip [0..] vs) -> mapM_ putStrLn $ map (\(n,v) -> "[" ++ show n ++ "] = " ++ show v) (addIndices vs) where addIndices vs = zip [0..] vs -> mapM_ putStrLn (map formatPair (addIndices vs)) where { addIndices vs = zip [0..] vs; formatPair (n,v) = "[" ++ show n ++ "] = " ++ show v } -> ... printList (map formatPair (addIndices vs)) where { foreach :: [i] -> (i->IO ()) -> IO (); foreach list action = mapM_ action list; printList :: [String] -> IO (); printList strings = foreach strings (\string->putStrLn string); addIndices :: [x] -> [(Integer,x)]; addIndices vs = zip [0..] vs; formatPair :: Show x => (Integer,x) -> String formatPair (n,v) = "[" ++ show n ++ "] = " ++ show v } Add comments (or replace types with comments, if you don't want to explain type classes), perhaps use an explicit loop instead of mapM_, add salt and pepper (or some more parens), check for correctness, etc. Not as cute as the one-liner, but quite possibly easier to read and explain. Haskell isn't APL - boldly break the line barrier, if you want to be understood by non-Haskellers. Breaking stuff up into digestible pieces, and going more slowly than necessary, might also help. Once your readers understand your code, you can add the one-liner and ask for applause (or show how to derive the one-liner from the long-hand version if you want to motivate people to read about Haskell). Just another opinion, Claus "Dr., it hurts when I do that." ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Philippa Cowderoy wrote: On Sun, 21 Sep 2008, Andrew Coppin wrote: Actually, none of these things were mentioned. The things people have *actually* complained to me about are: - Haskell expressions are difficult to parse. This is partly an "it's not braces, semicolons and function(application)" complaint, though not entirely. One person complained that "case compare guess target of" was unclear. Of course, you and I know that "case" and "of" are actually language keywords, and hence this is really "case (compare guess target) of", which makes far more sense. (Your suggestion about syntax hilighting is relevant here!) - Several standard library functions have names which clash badly with the usual meanings of those names - e.g., "break", "return", "id". For this one, I'm inclined to say "welcome to a new paradigm". Though having to tell my dad briefly that do isn't a loop construct was odd for a moment. Haha! Nice... I think "return" is a rather bad choice of name. But on the other hand, I can't think of a better one. And let's face it, anything has to be better than (>>=). (Most cryptic name ever?) - Variable names such as "x" and "f" aren't fabulously helpful to lost programmers trying to find their way. So don't use them? Though I think f in particular has its place in higher order functions. Idiomatic Haskell seems to consist *only* of single-letter variable names. When did you last see a pattern like (customer:customers)? No, it'd be (c:cs), which isn't very self-documenting. Ditto for type variables by the way. (Map k v, anyone?) It also seems to be Haskell convention to use "a" as a type variable; personally I always use "x". I guess that's the algebra in my blood or something... The people I spoke to also seemed pretty confused about the usage of (.) and ($), even after I explained it a few times. Several people also voiced being puzzled about Haskell's layout rules Pointless style is definitely newbie-unfriendly. I can understand being puzzled by layout: ultimately I had to go read the description in the Report to be happy. I posted a snippet of code which included the phrase mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..] vs) To somebody familiar with Haskell, that is as clear as day. But to a newbie... well *you* try explaining that you start at the left end, take the thing in brackets, process it from left to right, then take the other thing in brackets, process the right side of it, then pass that to putStrLn, oh, but that thing right at the left edge is the argument list, and then pass the whole lot to mapM_, which is... are you still with me?? As one experienced C++ programmer put it, "there is no clear flow from left to right or right to left". Personally I found that a little ironic comming from the language that gave us while (*x++ = *y++) { } which is every bit as non-linear! ;-) Have you tried showing people code that's been syntax highlighted? It's likely to help, especially with things like "does function application bind tighter?" where the highlighting is something of a cue. So is marking out = as important! I'd just like to mention that HPaste is invaluable here! ;-) Oddly, nobody seemed to take much notice when I did this though. (I guess most people had seen "oh look, another Haskell thread" and hit the thread-kill button by that point...) Btw, (> x) reads much more easily as a predicate to most people than (x <=). Er, yeah, you're probably right. IIRC, (> x) is actually implemented as (flip (>) x), whereas (x <) isn't. I doubt there's any efficiency difference though. (Surely GHC would inline such a trivial function...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Sun, 21 Sep 2008, Andrew Coppin wrote: > Actually, none of these things were mentioned. The things people have > *actually* complained to me about are: > - Haskell expressions are difficult to parse. This is partly an "it's not braces, semicolons and function(application)" complaint, though not entirely. > - Several standard library elements have unhelpful names such as "elem", "Eq" > and "fst". (My favourite has to be "Ix". I mean, WTH?) > - Several standard library functions have names which clash badly with the > usual meanings of those names - e.g., "break", "return", "id". For this one, I'm inclined to say "welcome to a new paradigm". Though having to tell my dad briefly that do isn't a loop construct was odd for a moment. > - Variable names such as "x" and "f" aren't fabulously helpful to lost > programmers trying to find their way. > So don't use them? Though I think f in particular has its place in higher order functions. > The people I > spoke to also seemed pretty confused about the usage of (.) and ($), even > after I explained it a few times. Several people also voiced being puzzled > about Haskell's layout rules. > Pointless style is definitely newbie-unfriendly. I can understand being puzzled by layout: ultimately I had to go read the description in the Report to be happy. > I'm not sure what we *do* with all this data, but I found it interesting so I > thought I'd share. ;-) I've spent the last few years trying to convert a few > people to The Haskell Way(tm), but so far I haven't succeeded in the > slightest. I just get yelled at for pointing white noise. Heh. Oh well! > Have you tried showing people code that's been syntax highlighted? It's likely to help, especially with things like "does function application bind tighter?" where the highlighting is something of a cue. So is marking out = as important! Btw, (> x) reads much more easily as a predicate to most people than (x <=). -- [EMAIL PROTECTED] Sometimes you gotta fight fire with fire. Most of the time you just get burnt worse though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe