takeListSt' = evalState . foldr k (return []) . map (State . splitAt)
where k m m'= cutNull $ do x-m; xs-m'; return (x:xs)
cutNull m = do s-get; if null s then return [] else m
Not only is ths not that elegant anymore, I think it *still* has a
bug, stack overflow against
takeListSt' = evalState . foldr k (return []) . map (State . splitAt)
where k m m'= cutNull $ do x-m; xs-m'; return (x:xs)
cutNull m = do s-get; if null s then return [] else m
|Not only is ths not that elegant anymore,
As I was saying, sequence/mapM with early cutout is
Thanks Claus,
Indeed the problem was that I was using the Strict state monad, with
lazy state it does the right thing when run through testP. I will try
and get back to this thread if I manage the derivation which proves
(or at least supports) that the two versions are equivalent.
2009/4/4
Continuing our adventures into stylistic and semantic differences:-)
Can you write this analysis on the wiki?
Hmm, we tried that in the past, and I haven't seen any indication
that people search for those things, let alone find them (one particular
example I recalled I still haven't been able
2009/3/25 wren ng thornton w...@freegeek.org:
Most of the documentation is in research papers, and a normal
programmer don't want to read these papers.
Yes, and no. There is quite a bit of documentation in research papers, and
mainstream programmers don't read research. However, this is a
2009/3/26 Thomas Hartman tphya...@gmail.com:
Beginner list processing code can and often does go awry when presented with
infinite lists.
I didn't mean code that a beginner would write, I mean code that would
be easy to understand for a beginner to read
For that, in this particular example,
Continuing our adventures into stylistic and semantic differences:-)
Comparing the 'State' and explicit recursion versions
takeListSt = evalState . mapM (State . splitAt)
-- ..with a derivation leading to..
takeListSt []s = []
takeListSt (h:t) s = x : takeListSt t s'
* Claus Reinke wrote:
Continuing our adventures into stylistic and semantic differences:-)
It's good practice to keep a simple minded version of the code and using
quickcheck to try to find differences between the optimized and trivial
version. It's good practice to even check, that the
Claus Reinke ha scritto:
Continuing our adventures into stylistic and semantic differences:-)
Can you write this analysis on the wiki?
Thanks!
Manlio
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
I wonder if JHC
or some other compiler might work better with these examples?
Are you saying that different compilers might give different answers?
Yikes!
Too clever indeed!
2009/3/26 rocon...@theorem.ca:
On Wed, 25 Mar 2009, Thomas Hartman wrote:
With the state version, there's a lot of
On Wed, 25 Mar 2009, Thomas Hartman wrote:
With the state version, there's a lot of behind-the-scenes magic, and
as we've seen, things can go wrong.
Also, the issue isn't infinite lists, but lists that are longer than
the sum of the partitions provided. The state monad partition version
goes
On Thu, 2009-03-26 at 12:29 -0700, Thomas Hartman wrote:
I wonder if JHC
or some other compiler might work better with these examples?
Are you saying that different compilers might give different answers?
Yikes!
Too clever indeed!
No, they might produce code with different
Well, that's reassuring.
The reason I asked is that the testp function didn't just show poor
performance. The state monad implementation actually gave a different
answer -- nonterminating, where the pattern matching solution
terminated.
2009/3/26 Jonathan Cast jonathancc...@fastmail.fm:
On Thu,
Colin Adams wrote:
2009/3/25 wren ng thornton w...@freegeek.org:
Most of the documentation is in research papers, and a normal
programmer don't want to read these papers.
Yes, and no. There is quite a bit of documentation in research papers, and
mainstream programmers don't read
2009/3/24 Jonathan Cast jonathancc...@fastmail.fm:
On Tue, 2009-03-24 at 22:33 +0300, Eugene Kirpichov wrote:
Pretty cool once you know what the function does, but I must admit I
wouldn't immediately guess the purpose of the function when written in
this way.
I wouldn't immediately guess the
What about
import Data.List
partAt n xs =
let (beg,end) = splitAt n xs
in beg : ( case end of
[] - []
xs - partAt n xs)
t = partAt 3 [1..10]
It's tail recursive (I think!) and should be pretty easy to understand
even for a beginner, no?
2009/3/24 Manlio Perillo
sorry, wrong function.
should be
partitions [] xs = []
partitions (n:parts) xs =
let (beg,end) = splitAt n xs
in beg : ( case end of
[] - []
xs - partitions parts xs)
t = partitions [1,2,3] [1..10]
which is not quite as nice, I admit.
2009/3/25 Thomas
wren ng thornton ha scritto:
Manlio Perillo wrote:
[...]
Following directly from the Rule of Least Power, if you can get away
with foreach then that's what you should use. Why? Because the less
power the construct has, the fewer corner cases and generalizations a
reader of the code needs to
The beauty of functional programming is that there doesn't have
to be a conflict between those who prefer explicit and those
who prefer implicit recursion. Think of them as different views
on the same functions - just as with graphical visualizations,
pick the view best suited to your purpose
On Tue, Mar 24, 2009 at 10:32 PM, wren ng thornton w...@freegeek.orgwrote:
Both of these conclusions seem quite natural to me, even from before
learning Haskell. It seems, therefore, that naturality is not the proper
metric to discuss. It's oft overlooked, but the fact is that expressivity
2009/3/25 Zachary Turner divisorthe...@gmail.com:
On the other hand, -certain- languages are more expressive than others. As
an example, I personally find English far more expressive than both
Vietnamese and Japanese, yet English is far more complicated. Japanese, for
Way off topic, but for
Thomas Hartman wrote:
sorry, wrong function.
should be
partitions [] xs = []
partitions (n:parts) xs =
let (beg,end) = splitAt n xs
in beg : ( case end of
[] - []
xs - partitions parts xs)
It's not tail recursive, FWIW. The recursive expression has (:) as
So to be clear with the terminology:
inductive = good consumer?
coinductive = good producer?
So fusion should be possible (automatically? or do I need a GHC rule?) with
inductive . coinductive
Or have I bungled it?
Dan
wren ng thornton wrote:
Thomas Hartman wrote:
sorry, wrong
Are you saying there's a problem with this implementation? It's the
Yes, there is actually a problem with this implementation.
import Data.List
import Control.Monad.State
import Debug.Trace.Helpers
partitions [] xs = []
partitions (n:parts) xs =
let (beg,end) = splitAt n xs
in beg : (
However, there is something to be said for code that just looks like a
duck and quacks like a duck. It's less likely to surprise you.
So... I insist... Easy for a beginner to read == better!
All you have said is that one building a skyscraper will need
scaffolding, blueprints, and a good
On Wed, 2009-03-25 at 12:48 -0700, Dan Weston wrote:
However, there is something to be said for code that just looks like a
duck and quacks like a duck. It's less likely to surprise you.
So... I insist... Easy for a beginner to read == better!
All you have said is that one building a
Oh, and incidentally, if you change to Control.Monad.State.Strict
*Main testP partitionsTooFrickinClever
testP partitionsTooFrickinClever^J*** Exception: stack overflow
Don't get me wrong -- I have learned a lot from this thread, and I
think it would be really cool if there was a way to do this
Since this thread is ostensibly about haskell style, it should also be
about haskell style *today*.
As I think Yitz noted earlier, this is a moving target.
Adoption of haskell by the masses -- moving.
Skill of haskell hordes -- moving.
Abstractions available as part of idiomatic haskell, and
Not only is your simpler function easier to read, it is also more correct.
partitionsHubris xs ns = zipWith take ns . init $ scanl (flip drop) xs ns
partitionsBeginner :: [Int] - [a] - [[a]]
partitionsBeginner [] _ = []
partitionsBeginner _ [] = []
partitionsBeginner (n : ns)
s/Pattern matching is awesome language feature. use it!
/Pattern matching is awesome language feature. Don't be ashamed to use it! /
:)
2009/3/25 Thomas Hartman tphya...@gmail.com:
Not only is your simpler function easier to read, it is also more correct.
partitionsHubris xs ns = zipWith
Manlio Perillo wrote:
The main problem, here, is that:
- recursion and pattern matching are explained in every tutorial about
functional programming and Haskell.
This is the reason why I find them more natural.
- high level, Haskell specific, abstractions, are *not* explained in
normal
Dan Weston wrote:
So to be clear with the terminology:
inductive = good consumer?
coinductive = good producer?
So fusion should be possible (automatically? or do I need a GHC rule?) with
inductive . coinductive
Or have I bungled it?
Not quite. Induction means starting from base cases
On Wed, Mar 25, 2009 at 12:44 PM, Thomas Hartman tphya...@gmail.com wrote:
Are you saying there's a problem with this implementation? It's the
Yes, there is actually a problem with this implementation.
However, there is something to be said for code that just looks like a
duck and quacks
Beginner list processing code can and often does go awry when presented with
infinite lists.
I didn't mean code that a beginner would write, I mean code that would
be easy to understand for a beginner to read -- that is, explicit
pattern matching, explicit recursion, no gratuitous use of state
Hi.
In these days I'm discussing with some friends, that mainly use Python
as programming language, but know well other languages like Scheme,
Prolog, C, and so.
These friends are very interested in Haskell, but it seems that the main
reason why they don't start to seriously learning it, is
These friends are very interested in Haskell, but it seems that the main
reason why they don't start to seriously learning it, is that when they start
reading some code, they feel the Perl syndrome.
That is, code written to be too smart, and that end up being totally
illegible by Haskell
I know what you're saying, in a way. There is much haskell code that's
completely illegible to me. I would say there is a difference between
Haskell and Perl though, in that Perl code is too smart aka. clever,
while Haskell code is usually simply, well, too smart. This means code
written using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manlio Perillo wrote:
| These friends are very interested in Haskell, but it seems that the main
| reason why they don't start to seriously learning it, is that when they
| start reading some code, they feel the Perl syndrome.
|
| That is, code
Well, I'd say that there is something close to the Perl syndrome, in
some sense. After all, code IS usually very smart. The difference is
that in Perl all smartness is about knowing how the computer works, or
how the interpreter works. In Haskell, instead, the smartness is about
knowing -
Tim Newsham ha scritto:
These friends are very interested in Haskell, but it seems that the
main reason why they don't start to seriously learning it, is that
when they start reading some code, they feel the Perl syndrome.
That is, code written to be too smart, and that end up being totally
Jake McArthur ha scritto:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manlio Perillo wrote:
| These friends are very interested in Haskell, but it seems that the main
| reason why they don't start to seriously learning it, is that when they
| start reading some code, they feel the Perl
On Tue, 2009-03-24 at 19:42 +0100, Manlio Perillo wrote:
Tim Newsham ha scritto:
These friends are very interested in Haskell, but it seems that the
main reason why they don't start to seriously learning it, is that
when they start reading some code, they feel the Perl syndrome.
That
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manlio Perillo wrote:
| This is right.
| The problem is that often (IMHO) a function definition can be rewritten
| so that it is much more readable.
|
| As an example, with the takeList function I posted.
I looked at it, found nothing wrong with the
When you think about it, what you are saying is that Haskell programmers
shouldn't take advantage of the extra tools that Haskell provides.
No, I'm not saying this.
But, as an example, when you read a function like:
buildPartitions xs ns = zipWith take ns . init $ scanl (flip drop) xs ns
2009/3/24 Manlio Perillo manlio_peri...@libero.it:
Tim Newsham ha scritto:
These friends are very interested in Haskell, but it seems that the main
reason why they don't start to seriously learning it, is that when they
start reading some code, they feel the Perl syndrome.
That is, code
| As an example, with the takeList function I posted.
I looked at it, found nothing wrong with the original, and absolutely
hated your fixed version. I might have written it like this,
instead:
~buildPartitions xs ns = zipWith take ns . init . scanl (flip
drop)
xs $ ns
Maybe it's
Pretty cool once you know what the function does, but I must admit I
wouldn't immediately guess the purpose of the function when written in
this way.
2009/3/24 Miguel Mitrofanov miguelim...@yandex.ru:
| As an example, with the takeList function I posted.
I looked at it, found nothing wrong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Miguel Mitrofanov wrote:
| Maybe it's just me, but I think that
|
| takeList ns xs = evalState (mapM (State . splitAt) ns) xs
|
| or even
|
| takeList = evalState . map (State . splitAt)
|
| would be much clearer than both versions.
Definitely. I
Jake McArthur ha scritto:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manlio Perillo wrote:
| This is right.
| The problem is that often (IMHO) a function definition can be rewritten
| so that it is much more readable.
|
| As an example, with the takeList function I posted.
I looked at it,
Manlio Perillo complained about:
buildPartitions xs ns = zipWith take ns . init . scanl (flip drop) xs $ ns
Miguel Mitrofanov wrote:
takeList = evalState . mapM (State . splitAt)
Ha! Bravo!
As the author of the offending zipWith/scanl version,
I can say that love those State monad one-liners.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manlio Perillo wrote:
| With the original version, you have to follow 3 separate operations:
|
| Prelude let xs = [1, 2, 3, 4] :: [Int]
| Prelude let ns = [3, 1] :: [Int]
| Prelude let _1 = scanl (flip drop) xs ns
| Prelude let _2 = init _1
| Prelude
On Tue, Mar 24, 2009 at 7:48 PM, Jonathan Cast jonathancc...@fastmail.fmwrote:
On Tue, 2009-03-24 at 19:42 +0100, Manlio Perillo wrote:
But, as an example, when you read a function like:
buildPartitions xs ns = zipWith take ns . init $ scanl (flip drop) xs ns
that can be rewritten
Yitzchak Gale ha scritto:
[...]
So the bottom line is that Manlio is right, really. It's just
that Haskell is still very different than what most
programmers are used to. So it does take a while to
get a feeling for what is too smart.
Right, you centered the problem!
The problem is where to
Jake McArthur ha scritto:
[...]
| With my function, instead, you only have to follow 1 operation:
|
| Prelude (head, tail) = splitAt n xs
I think you are way oversimplifying your own code.
~takeList :: [Int] - [a] - [[a]]
~takeList [] _ = []
~takeList _ [] = []
~
Another helpful strategy for the reader is to get smarter, i.e. to invest
effort in rising to the level of the writer. Or just choose a different
book if s/he prefers. - Conal
On Tue, Mar 24, 2009 at 1:44 PM, Manlio Perillo manlio_peri...@libero.itwrote:
Yitzchak Gale ha scritto:
[...]
So
Recursion is the goto of functional programming. Also, Do not confuse
what is natural with what is habitual. - Conal
On Tue, Mar 24, 2009 at 1:51 PM, Manlio Perillo manlio_peri...@libero.itwrote:
Jake McArthur ha scritto:
[...]
| With my function, instead, you only have to follow 1
Conal Elliott ha scritto:
Another helpful strategy for the reader is to get smarter, i.e. to
invest effort in rising to the level of the writer. Or just choose a
different book if s/he prefers. - Conal
This strategy is doomed to failure, unfortunately.
We live in the real world,
Sometimes that is very hard when the writer is way smarter than the reader
:-)
2009/3/24 Conal Elliott co...@conal.net
Another helpful strategy for the reader is to get smarter, i.e. to invest
effort in rising to the level of the writer. Or just choose a different
book if s/he prefers. -
* Manlio Perillo wrote:
But this may be really a question of personal taste or experience.
What is more natural?
1) pattern matching
2) recursion
or
1) function composition
2) high level functions
Composition of library functions is usually much more readable than hand
written recursion,
Hah! It sure is. :)
On Tue, Mar 24, 2009 at 2:17 PM, Peter Verswyvelen bugf...@gmail.comwrote:
Sometimes that is very hard when the writer is way smarter than the reader
:-)
2009/3/24 Conal Elliott co...@conal.net
Another helpful strategy for the reader is to get smarter, i.e. to invest
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man. - George Bernard Shaw
On Tue, Mar 24, 2009 at 2:11 PM, Manlio Perillo manlio_peri...@libero.itwrote:
Conal Elliott ha
On Tue, Mar 24, 2009 at 10:11 PM, Manlio Perillo
manlio_peri...@libero.itwrote:
This strategy is doomed to failure, unfortunately.
So it is the good strategy, because Haskell's slogan is avoid success at
all cost :-)
We live in the real world, compromises are necessary.
I don't think so.
On Tue, Mar 24, 2009 at 1:42 PM, Manlio Perillo
manlio_peri...@libero.it wrote:
But, as an example, when you read a function like:
buildPartitions xs ns = zipWith take ns . init $ scanl (flip drop) xs ns
that can be rewritten (argument reversed) as:
takeList :: [Int] - [a] - [[a]]
2009/3/24 Peter Verswyvelen bugf...@gmail.com:
But aren't these two definitions different algoritms? At first sight I think
the second one is more efficient than the first one.
Some performance numbers:
--
module Main where
Miguel Mitrofanov wrote:
takeList = evalState . mapM (State . splitAt)
However, ironically, I stopped using them for pretty
much the same reason that Manlio is saying.
Are you saying there's a problem with this implementation? It's the
only one I could just read immediately. The trick is to
On Tue, Mar 24, 2009 at 4:11 PM, Manlio Perillo manlio_peri...@libero.itwrote:
Conal Elliott ha scritto:
Another helpful strategy for the reader is to get smarter, i.e. to invest
effort in rising to the level of the writer. Or just choose a different
book if s/he prefers. - Conal
This
On Tue, 2009-03-24 at 22:33 +0300, Eugene Kirpichov wrote:
Pretty cool once you know what the function does, but I must admit I
wouldn't immediately guess the purpose of the function when written in
this way.
I wouldn't immediately guess the purpose of the function written in any
way.
I
Miguel Mitrofanov wrote:
takeList = evalState . mapM (State . splitAt)
I wrote:
However, ironically, I stopped using them for pretty
much the same reason that Manlio is saying.
Dan Piponi wrote:
Are you saying there's a problem with this implementation? It's the
only one I could just read
On Tue, Mar 24, 2009 at 12:41 PM, Manlio Perillo
manlio_peri...@libero.it wrote:
I too have this feeling, from time to time.
So do I, because I haven't had the time to learn what I need to learn
in order to read the code smoothly. I find that when I do work out
the meaning, most often the
Jonathan Cast ha scritto:
[...]
I think, in general, the best way to document the purpose of the
function is
-- | Split a function into a sequence of partitions of specified
lenth
takeList :: [Int] - [a] - [[a]]
Note that I was not speaking about the best way to document a function.
Manlio Perillo wrote:
I was speaking about the best way to write a function, so that it may
help someone who is learning Haskell.
I've been learning Haskell for about 3 months.
I think its a mistake to write code so that its easy for someone
learning Haskell to read it. Code should be
As (yet another?) Haskell newbie, with a day job using Java (where
keep it simple, stupid is not a principle, it's a language enforced
requirement), I would much prefer the function is implemented in the
most concise and idiomatic style that the writer is capable of. That
is, either the
I'd love to help newbies get the hang of Haskell without having to jump in
the deep (and smart-infested) end first. And I'd love for people to keep
writing smart code for non-newbies to enjoy.
Perhaps a practical suggestion would be some wiki pages devoted to pointing
out code with various
On Tue, 2009-03-24 at 22:43 +0100, Manlio Perillo wrote:
Jonathan Cast ha scritto:
[...]
I think, in general, the best way to document the purpose of the
function is
-- | Split a function into a sequence of partitions of specified
lenth
takeList :: [Int] - [a] - [[a]]
2009/3/24 Manlio Perillo manlio_peri...@libero.it:
Jonathan Cast ha scritto:
[...]
I think, in general, the best way to document the purpose of the
function is
-- | Split a function into a sequence of partitions of specified
lenth
takeList :: [Int] - [a] - [[a]]
*That* was what I
Zachary Turner ha scritto:
[...]
but I do understand that one of the primary uses
cases and/or motivating factors for using Haskell is when you really
just NEED that extra abstraction and power you get from being able to do
these types of things. Someone once said that simple problems
Erik de Castro Lopo ha scritto:
Manlio Perillo wrote:
I was speaking about the best way to write a function, so that it may
help someone who is learning Haskell.
I've been learning Haskell for about 3 months.
I think its a mistake to write code so that its easy for someone
learning Haskell
Conal Elliott ha scritto:
I'd love to help newbies get the hang of Haskell without having to jump
in the deep (and smart-infested) end first. And I'd love for people to
keep writing smart code for non-newbies to enjoy.
Perhaps a practical suggestion would be some wiki pages devoted to
On Tue, Mar 24, 2009 at 8:29 PM, Miguel Mitrofanov miguelim...@yandex.ruwrote:
takeList ns xs = evalState (mapM (State . splitAt) ns) xs
or even
takeList = evalState . map (State . splitAt)
would be much clearer than both versions.
Brilliant. As a newbie, I knew all these functions, I
On Mar 24, 2009, at 1:51 PM, Manlio Perillo wrote:
But this may be really a question of personal taste or experience.
What is more natural?
1) pattern matching
2) recursion
or
1) function composition
2) high level functions
I think, actually, that one of the fundamental intuitions of (modern)
Dan Piponi ha scritto:
Miguel Mitrofanov wrote:
takeList = evalState . mapM (State . splitAt)
However, ironically, I stopped using them for pretty
much the same reason that Manlio is saying.
Are you saying there's a problem with this implementation? It's the
only one I could just read
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manlio Perillo wrote:
| But this may be really a question of personal taste or experience.
| What is more natural?
|
| 1) pattern matching
| 2) recursion
| or
| 1) function composition
| 2) high level functions
Definitely the latter two. They are
On Tue, 2009-03-24 at 23:15 +0100, Manlio Perillo wrote:
Dan Piponi ha scritto:
Miguel Mitrofanov wrote:
takeList = evalState . mapM (State . splitAt)
However, ironically, I stopped using them for pretty
much the same reason that Manlio is saying.
Are you saying there's a problem
And advices to experienced Haskell programmers about how to document their
code so that it may help less experienced programmers.
Manlio -- You may be missing the point of my suggestion, which is to help
people *find* code that suits them, rather than changing anyone's coding
style.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jonathan Cast wrote:
| You know, this might actually need to be looked into.
|
| You need to know recursion and pattern-matching to *write* re-usable
| higher-order functions, but how appropriate is that as the first thing
| taught?
An excellent
Manlio,
We live in the age of participation -- of co-education. Don't worry about
text-books. Contribute to some wiki pages blogs today that share these
smart techniques with others.
twocentsLearning/progress is mainly results when people respond to their
own incomprehension by moving into
This question makes me wonder... why is explicit recursion taught first?
[...]
Perhaps also because teachers, being older than their students, are often
mired in outdated thinking.
On Tue, Mar 24, 2009 at 3:35 PM, Jake McArthur j...@pikewerks.com wrote:
-BEGIN PGP SIGNED MESSAGE-
2009/3/24 Peter Verswyvelen bugf...@gmail.com:
This strategy is doomed to failure, unfortunately.
So it is the good strategy, because Haskell's slogan is avoid success at
all cost :-)
IN THE YEAR 1987, WAR WAS BEGINNING
BIG, IMPERATIVE SOFTWARE BEHEMOTHS CLASHED IN A STATE OF IMPURITY
Conal Elliott ha scritto:
Manlio,
We live in the age of participation -- of co-education. Don't worry
about text-books. Contribute to some wiki pages blogs today that
share these smart techniques with others.
When I started learning Haskell (by my initiative), what I did was:
1) Quick
Conal Elliott ha scritto:
And advices to experienced Haskell programmers about how to document
their code so that it may help less experienced programmers.
Manlio -- You may be missing the point of my suggestion,
Ah, sorry.
which is to
help people *find* code that suits them,
Manlio -- You may be missing the point of my suggestion, which is to help
people *find* code that suits them, rather than changing anyone's coding
style. Optimizing code for one segment of readers is pessimizing it for
another. Instead of dumbing down the smart code, I'd like to help your
Code like that is why I love Haskell, while I haven't written a Haskell
program in years it is still a joy to read (much more so than the pretty
good zipWith version).
In reference to later comments: if you don't know Monads, you don't know
Haskell; that goes double for high order functions.
So
On Tue, 2009-03-24 at 16:43 -0700, Donn Cave wrote:
If he really intended to promote some dumb code as a better
alternative to some otherwise equivalent smart code,
`Smart' is Manlio's term --- or, rather, his characterization of his
friends' reaction upon seeing some inscrutable piece of
Perhaps is much easier to create one line compositions of functions in
haskell rather than in C because the type system helps a lot in the process.
However, reusability of source code and maintainability has never been taken
seriously by haskell programmers, simply because there are no industrial
On Tue, Mar 24, 2009 at 10:29:55PM +0300, Miguel Mitrofanov wrote:
Maybe it's just me, but I think that
takeList ns xs = evalState (mapM (State . splitAt) ns) xs
or even
takeList = evalState . map (State . splitAt)
would be much clearer than both versions.
I love it! It wouldn't occur to
May I suggest that the most important thing missing from
all these versions of the function is a comment?
Most of the time I shouldn't *care* how the function works.
(And that, for me, is one of the key benefits of Haskell.)
___
Haskell-Cafe mailing
Richard O'Keefe wrote:
May I suggest that the most important thing missing from
all these versions of the function is a comment?
Most of the time I shouldn't *care* how the function works.
(And that, for me, is one of the key benefits of Haskell.)
Although in this case, a proper name and type
On Tue, Mar 24, 2009 at 2:42 PM, Manlio Perillo
manlio_peri...@libero.it wrote:
Tim Newsham ha scritto:
These friends are very interested in Haskell, but it seems that the main
reason why they don't start to seriously learning it, is that when they
start reading some code, they feel the Perl
Jake McArthur wrote:
Richard O'Keefe wrote:
May I suggest that the most important thing missing from
all these versions of the function is a comment?
Most of the time I shouldn't *care* how the function works.
(And that, for me, is one of the key benefits of Haskell.)
Although in this
Manlio Perillo wrote:
But this may be really a question of personal taste or experience.
What is more natural?
1) pattern matching
2) recursion
or
1) function composition
2) high level functions
Which is more natural:
* C-style for-loops (aka assembly while-loops), or
* any modern language's
100 matches
Mail list logo
