Re: [Haskell-cafe] Line noise

2008-12-21 Thread Jon Harrop
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

2008-09-23 Thread Brandon S. Allbery KF8NH

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

2008-09-23 Thread wren ng thornton

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

2008-09-22 Thread Jason Dagit
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

2008-09-22 Thread Brian Hurt



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

2008-09-22 Thread Jake Mcarthur

-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

2008-09-22 Thread Andrew Coppin

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

2008-09-22 Thread Andrew Coppin

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

2008-09-22 Thread Luke Palmer
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

2008-09-22 Thread Sebastian Sylvan
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

2008-09-22 Thread david48
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

2008-09-22 Thread Daniel Fischer
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

2008-09-22 Thread Ketil Malde
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

2008-09-22 Thread Stephan Friedrichs
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

2008-09-21 Thread Andrew Coppin

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

2008-09-21 Thread Andrew Coppin

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

2008-09-21 Thread Richard A. O'Keefe


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

2008-09-21 Thread donn cave
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

2008-09-21 Thread Dan Piponi
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

2008-09-21 Thread wren ng thornton

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

2008-09-21 Thread Albert Y. C. Lai
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

2008-09-21 Thread Mads Lindstrøm
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

2008-09-21 Thread Claus Reinke

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

2008-09-21 Thread Andrew Coppin

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

2008-09-21 Thread Philippa Cowderoy
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