Is there also a Wiki page about things you should avoid?
Since I couldn't find one, I started one on my own:
http://www.haskell.org/hawiki/ThingsToAvoid
I consider 'length', guards and proper recursion anchors.
[Moving the discussion from the wiki to the mailing list until we've
On Wed, Feb 09, 2005 at 02:54:12PM +0100, Henning Thielemann wrote:
On Wed, 9 Feb 2005, Henning Thielemann wrote:
Is there also a Wiki page about things you should avoid?
Since I couldn't find one, I started one on my own:
http://www.haskell.org/hawiki/ThingsToAvoid
I consider
On Thu, 10 Feb 2005, [ISO-8859-1] Thomas Jäger wrote:
Altogether, the spirit of the page seems to be use as little
syntactic sugar as possible which maybe appropriate if it is aimed at
newbies, who often overuse syntactic sugar (do-notation).
This overuse is what I observed and what I like
On Thu, 10 Feb 2005, [ISO-8859-1] Thomas Jäger wrote:
Altogether, the spirit of the page seems to be use as little
syntactic sugar as possible which maybe appropriate if it is aimed at
newbies, who often overuse syntactic sugar (do-notation).
What I forgot: Each new syntactic sugar is
On Thu, 10 Feb 2005 12:50:16 +0100 (MET), Henning Thielemann
[EMAIL PROTECTED] wrote:
On Thu, 10 Feb 2005, [ISO-8859-1] Thomas Jäger wrote:
Altogether, the spirit of the page seems to be use as little
syntactic sugar as possible which maybe appropriate if it is aimed at
newbies, who
On Feb 10, 2005, at 6:50 AM, Henning Thielemann wrote:
On Thu, 10 Feb 2005, [ISO-8859-1] Thomas Jäger wrote:
Altogether, the spirit of the page seems to be use as little
syntactic sugar as possible which maybe appropriate if it is aimed at
newbies, who often overuse syntactic sugar (do-notation).
It's not exactly what you ask for, but I wrote down some of the things I
learned in my early days with Haskell:
http://www.ninebynine.org/Software/Learning-Haskell-Notes.html
#g
--
At 10:31 07/02/05 -0500, Jacques Carette wrote:
The recent post of Graham Klyne (below) reminds me that I have
Jan-Willem Maessen writes:
Is it really clear or obvious what
map . (+)
means?
Yes, it is perfectly obvious once you write it like this:
incrEach :: Integer - [Integer] - [Integer]
incrEach = map . (+)
Now compare that to the following function, which does the
some thing but
Am Donnerstag, 10. Februar 2005 16:53 schrieb Peter Simons:
Jan-Willem Maessen writes:
Is it really clear or obvious what
map . (+)
means?
Yes, it is perfectly obvious once you write it like this:
incrEach :: Integer - [Integer] - [Integer]
incrEach = map . (+)
Yes,
Hello!
I have a list of instances of the ClassifiedImage class, which is defined as
follows.
data ClassifiedImage = ClassifiedImage {imageFileName :: String, subjectID ::
String}
deriving Show
Attribute imageFileName contains a file name of a certain image. I want
to transform the list
Can I use map for readImage function, which is in the IO domain? If not, what
tutorial can help me?
Sorry, by IO domain I mean IO monad.
Dmitri Pissarenko
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
On 10 Feb 2005, Peter Simons wrote:
Now compare that to the following function, which does the
some thing but without point-free notation:
incrEach' :: Integer - [Integer] - [Integer]
incrEach' i is = is = \i' - return (i'+i)
point-free again
is = return . (i+)
:-]
On 10 Feb 2005, at 20:17, Dmitri Pissarenko wrote:
Hello!
I have a list of instances of the ClassifiedImage class, which is
defined as
follows.
data ClassifiedImage = ClassifiedImage {imageFileName :: String,
subjectID ::
String}
deriving Show
Attribute imageFileName contains a file
On Thu, Feb 10, 2005 at 09:17:17PM +0100, Dmitri Pissarenko wrote:
Hello!
Hello!
I have a list of instances of the ClassifiedImage class, which is defined as
follows.
data ClassifiedImage = ClassifiedImage {imageFileName :: String, subjectID ::
String}
deriving Show
On Wed, Feb 09, 2005 at 02:54:12PM +0100, Henning Thielemann wrote:
On Wed, 9 Feb 2005, Henning Thielemann wrote:
Is there also a Wiki page about things you should avoid?
Since I couldn't find one, I started one on my own:
http://www.haskell.org/hawiki/ThingsToAvoid
I consider
Hello,
...
Yeah, as long as it is explained and clearly marked as an opinion (as
it is now), that's ok. One reason that I got so excited about that is
because I don't like the current situation with (n+k)-patterns:
Everybody says they're evil, but hardly anybody can explain why he
thinks
just a few quick observations
comming from an imperative background, I found point free code very
difficult to understand when learning Haskell. It is not that it is
hard to understand the concepts of point-free style, it is that it is
hard to know when something is point-free.
It is another
I have to agree (although I suspect few others will :))
matt
On 11/02/2005, at 1:23 AM, Jan-Willem Maessen wrote:
On Feb 10, 2005, at 6:50 AM, Henning Thielemann wrote:
On Thu, 10 Feb 2005, [ISO-8859-1] Thomas Jäger wrote:
Altogether, the spirit of the page seems to be use as little
syntactic
Jan-Willem Maessen wrote:
] Is it really clear or obvious what
]
] map . (+)
]
] means?
Perhaps the following two examples might be more convincing:
u=uncurry
e=((partition $ u(==)).) . zip
f x=(x\\).(x\\)
It is obviously clear what 'e' and 'f x' do.
The second example, which even
On Thu, 10 Feb 2005 18:04:26 -0800 (PST), [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Jan-Willem Maessen wrote:
] Is it really clear or obvious what
]
] map . (+)
]
] means?
Perhaps the following two examples might be more convincing:
u=uncurry
e=((partition $ u(==)).) . zip
f
Sebastian Sylvan writes:
Points free style is cool in a geeky sort of way, but not really all
that useful when you're trying to write clear code that people can
actually understand.
That's true of badly-written point-free code, certainly. However, anyone
who has spent time doing shell
21 matches
Mail list logo
