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? Oca
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 "welc
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 applicat
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 operato
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
-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
DvcAn3Buv
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
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...
- ..
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...
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 htt
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
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 thi
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 rat
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, whic
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 sh
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
($) op
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
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-lin
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 space
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".
Actual
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 th
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 H
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) -> "["
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(app
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 n
25 matches
Mail list logo
