[Haskell-cafe] Re: about Haskell code written to be "too smart"

[Achim Schneider]

Colin Adams  wrote:

> 2009/3/27 Achim Schneider :
> > wren ng thornton  wrote:
> >
> >> Colin Adams wrote:
> >> > A reference to a research paper is fine to show where the ideas
> >> > came from, but that is not where the library documentation
> >> > should be.
> >>
> >> Yeah, that's bad. 'Documentation' like that should be corrected
> >> with Extreme Prejudice.
> 
> I think I agree with that (I say I think, as I'm not sure what Extreme
> Prejuidice means).
> 
Shoot err... rewrite before asking. If in doubt, annihilate.
Considering all options, just do it. Pity is a thing for judges, not
hackers. Something along those lines.

> >
> > The main problem with research papers as documentation is the papers
> > usually being outdated wrt. the current library version: Literate
> > Haskell is utterly underused.
> >
> 
> That's surely a problem, and a significant one.
> 
> But what irks me is the time taken to find one small piece of
> information (how to use a single function).
> I would guess on average about the time to read 1/3 of the paper
> (since the back matter needn't be examined).
>
Hm. Yes. OTOH, I very much appreciate background information, it
usually contains very insightful information about the overall idea and
behaviour of a library. I'm by no means a domain expert for any
and every library I want to use.

In school, we were required to write both user[1] as well as
developer[2] documentation alongside to commenting our code. I tended
to loathe it, but it's very, very sensible in retrospect.

There was some discussion a while back here on the cafe about enabling
users to write additional documentation into a wikised hackage;
together with an #haskell-doc-tutor irc channel, we could have an
excellent solution to both lacking documentation as well as newbies
not being sure were to start and/or intimidated by pointless usage of
(.). Additionally, you get the chance of earning credits and naming and
shaming Haskell's godfathers[1].


[1] In the sense of using the code, either as app or library
[2] In the sense of editing/reading the code. Understanding [2] usually
involves understanding [1].
[3] Judging from his code, I guess dons' apartment looks just like
mine: Lots of left-over bits lying around that you tend to stumble
over and are unsure about why they are still there. I swear, someday
I'm going to use those two 5 1/4" floppy drives...

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Colin Adams]

2009/3/27 Achim Schneider :
> wren ng thornton  wrote:
>
>> Colin Adams wrote:
>> > 2009/3/25 wren ng thornton :
>> > when I look up the Haddock-generated documentation for a function, I
>> > DON'T appreciate it if that is in the form of a hyperlink to a
>> > research paper.
>> > And that occurs in several of the libraries shipped with GHC for
>> > instance.
>> >
>> > A reference to a research paper is fine to show where the ideas came
>> > from, but that is not where the library documentation should be.
>>
>> Yeah, that's bad. 'Documentation' like that should be corrected with
>> Extreme Prejudice.

I think I agree with that (I say I think, as I'm not sure what Extreme
Prejuidice means).

>>
> The main problem with research papers as documentation is the papers
> usually being outdated wrt. the current library version: Literate
> Haskell is utterly underused.
>

That's surely a problem, and a significant one.

But what irks me is the time taken to find one small piece of
information (how to use a single function).
I would guess on average about the time to read 1/3 of the paper
(since the back matter needn't be examined).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: about Haskell code written to be "too smart"

[Achim Schneider]

wren ng thornton  wrote:

> Colin Adams wrote:
> > 2009/3/25 wren ng thornton :
> > when I look up the Haddock-generated documentation for a function, I
> > DON'T appreciate it if that is in the form of a hyperlink to a
> > research paper.
> > And that occurs in several of the libraries shipped with GHC for
> > instance.
> > 
> > A reference to a research paper is fine to show where the ideas came
> > from, but that is not where the library documentation should be.
> 
> Yeah, that's bad. 'Documentation' like that should be corrected with 
> Extreme Prejudice.
> 
The main problem with research papers as documentation is the papers
usually being outdated wrt. the current library version: Literate
Haskell is utterly underused.


-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: about Haskell code written to be "too smart"

[wren ng thornton]

John Lato wrote:

> From: wren ng thornton 
> 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 and building things
> upwards from those. Coinduction is the dual and can be thought of as
> starting from the ceiling and building your way downwards (until you hit
> the base cases, or possibly forever).

( quite a lot of text trimmed for brevity)

Wren, thank you for contributing this post.  Coming from the point of
view of someone who doesn't grok it all yet, this is the best
commentary I've read on deforestation/fusion, and in fact is helpful
for category theory newbies as well (at least I found it so).  It
really should go on a wiki somewhere.


If you haven't read Rewriting Haskell Strings[1] yet, it's an excellent 
paper. There are a number of other canonical fusion papers, but RHS has 
the best introduction I've seen and it goes into both the build/fold and 
unfold/destroy styles. It doesn't have much on the category theory and 
recursion theory side of things though.


[1] http://www.cse.unsw.edu.au/~dons/papers/CSL06.html

--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: about Haskell code written to be "too smart"

[John Lato]

> From: wren ng thornton 
> 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 and building things
> upwards from those. Coinduction is the dual and can be thought of as
> starting from the ceiling and building your way downwards (until you hit
> the base cases, or possibly forever).
>

( quite a lot of text trimmed for brevity)

Wren, thank you for contributing this post.  Coming from the point of
view of someone who doesn't grok it all yet, this is the best
commentary I've read on deforestation/fusion, and in fact is helpful
for category theory newbies as well (at least I found it so).  It
really should go on a wiki somewhere.

John Lato
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Peter Verswyvelen]

After reading the chapter about parsers in Bird's book, I tried to implement
a simple parser myself, and this was a great experience, a real eye opener
on how declarative and composable Haskell can be. Haskell is... well magic
:-) It gave me same kind of joy I had when I made my first moving sprite on
the Commodore 64 in 1985.
On Thu, Mar 26, 2009 at 12:44 AM, Heinrich Apfelmus <
apfel...@quantentunnel.de> wrote:

> Manlio Perillo wrote:
> > Heinrich Apfelmus ha scritto:
> >>
> >> I think you'd have had a much easier time by starting with a proper book
> >> right away, like Richard Bird's "Introduction to Functional Programming
> >> in Haskell", accompanied by Real World Haskell.
> >
> > Unfortunately, one year ago Real World Haskell was not here.
> > And note that I have no problems with basic functional programming
> > concepts.
> > My problems are specific to Haskell.
>
> Despite the title, Bird's book is quite specific to Haskell, in
> particular concerning the philosophy of composing solutions from
> building blocks as opposed to primitive recursion.
>
> I'd say that every serious Haskell programmer should have it on his
> bookshelf (even if only for show ;) ).
>
>
> Regards,
> apfelmus
>
> --
> http://apfelmus.nfshost.com
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: about Haskell code written to be "too smart"

[Heinrich Apfelmus]

Manlio Perillo wrote:
> Heinrich Apfelmus ha scritto:
>>
>> I think you'd have had a much easier time by starting with a proper book
>> right away, like Richard Bird's "Introduction to Functional Programming
>> in Haskell", accompanied by Real World Haskell. 
> 
> Unfortunately, one year ago Real World Haskell was not here.
> And note that I have no problems with basic functional programming
> concepts.
> My problems are specific to Haskell.

Despite the title, Bird's book is quite specific to Haskell, in
particular concerning the philosophy of composing solutions from
building blocks as opposed to primitive recursion.

I'd say that every serious Haskell programmer should have it on his
bookshelf (even if only for show ;) ).


Regards,
apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Ryan Ingram]

On Wed, Mar 25, 2009 at 8:25 AM, Jonathan Cast
 wrote:
> On Wed, 2009-03-25 at 15:09 +, Simon Marlow wrote:
>> the ordering that the state monad expects
>> (and I can never remember which way around they are in Control.Monad.State).
>
> Really?  I found it obvious once I figured out it how simple it made
> (>>=).  With the order from Control.Monad.State (with constructors
> ignored):
>
>    a >>= f = \ s -> case s a of
>       (x, s') -> f x s'
>
> Reversing the order of the components of the result gives you
>
>    a >>= f = \ s -> case s a of
>        (s', x) -> f x s'
>
> which just looks weird.

However, if you are used to thinking in terms of type composition, s
-> (s, a) makes more sense, because it is effectively

  (s ->) . (s,) . Identity

whose "functor-ness" is automatic via composition of functors:

newtype Identity a = Identity a
inIdentity f (Identity a) = Identity (f a)

instance Functor Identity where
fmap f = inIdentity f

instance Functor ((,) a) where
fmap f (a, x) = (a, f x)
instance Functor ((->) a) where
fmap f k a = f (k a)

newtype O f g x = O (f (g x))
inO f (O a) = O (f a)
instance (Functor f, Functor g) => Functor (O f g) where
fmap f = inO (fmap (fmap f))
-- or fmap = inO . fmap . fmap

-- not valid haskell, but if there were sections at the type level it would be.
type State s = (s ->) `O` (s,) `O` Identity

  -- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Conal Elliott]

or via Arrow:

swap = snd &&& fst

On Wed, Mar 25, 2009 at 9:16 AM, David Menendez  wrote:

> On Wed, Mar 25, 2009 at 11:32 AM, Simon Marlow  wrote:
> > Jonathan Cast wrote:
> >>
> >> Define
> >>
> >>swap (a, b) = (b, a)
> >
> > ew, that's far too crude.  I think you mean
> >
> >  swap = uncurry $ flip (,)
>
> On the theme of using monads where you might not expect,
>
> swap = liftA2 (,) snd fst
>
> --
> Dave Menendez 
> >
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Jake McArthur]

Simon Marlow wrote:
> Jonathan Cast wrote:
>> Define
>>
>> swap (a, b) = (b, a)
>
> ew, that's far too crude.  I think you mean
>
>   swap = uncurry $ flip (,)

I think I would prefer something that mirrors flip more closely:

swap :: ((a,b) -> c) -> (b,a) -> c
swap = uncurry . flip . curry

- Jake
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Jonathan Cast]

On Wed, 2009-03-25 at 15:32 +, Simon Marlow wrote:
> Jonathan Cast wrote:
> > On Wed, 2009-03-25 at 15:09 +, Simon Marlow wrote:
> >> the ordering that the state monad expects 
> >> (and I can never remember which way around they are in 
> >> Control.Monad.State).
> > 
> > Really?  I found it obvious once I figured out it how simple it made
> > (>>=).  With the order from Control.Monad.State (with constructors
> > ignored):
> > 
> > a >>= f = \ s -> case s a of
> >(x, s') -> f x s'
> > 
> > Reversing the order of the components of the result gives you
> > 
> > a >>= f = \ s -> case s a of
> > (s', x) -> f x s'
> > 
> > which just looks weird.
> 
> It might look weird to you, but that's the way that GHC's IO and ST monads 
> do it.  It looks perfectly natural to me!

Right.  Consider this an argument for fixing IO/ST(/STM?) to conform to
the self-evidently correct ordering of Control.Monad.State :)

> (and you have the a and s the 
> wrong way around in 'case s a', BTW).

Um, yes.  /Mea culpa/.

> >> Try doing it with mapAccumL, which is arguably the right abstraction,
> >> but 
> >> has the components the other way around.
> > 
> > Define
> > 
> > swap (a, b) = (b, a)
> 
> ew, that's far too crude.  I think you mean
> 
>swap = uncurry $ flip (,)

Ah, yes.

jcc


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[David Menendez]

On Wed, Mar 25, 2009 at 11:32 AM, Simon Marlow  wrote:
> Jonathan Cast wrote:
>>
>> Define
>>
>>    swap (a, b) = (b, a)
>
> ew, that's far too crude.  I think you mean
>
>  swap = uncurry $ flip (,)

On the theme of using monads where you might not expect,

swap = liftA2 (,) snd fst

-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Jonathan Cast]

On Wed, 2009-03-25 at 03:01 +, Robin Green wrote:
> On Wed, 25 Mar 2009 08:25:40 -0700
> Jonathan Cast  wrote:
> 
> > Define
> > 
> > swap (a, b) = (b, a)
> 
> By the way, if you want to be "too smart", there's a generalised
> version of swap in Control.Category.Braided in the category-extras
> package.

Thanks, I'll check it out.

> That might be a bit overkill though.

What is this word `overkill' you use?

jcc


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Robin Green]

On Wed, 25 Mar 2009 08:25:40 -0700
Jonathan Cast  wrote:

> Define
> 
> swap (a, b) = (b, a)

By the way, if you want to be "too smart", there's a generalised
version of swap in Control.Category.Braided in the category-extras
package.

That might be a bit overkill though.
-- 
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Jake McArthur]

Simon Marlow wrote:

Jonathan Cast wrote:

Define

swap (a, b) = (b, a)


ew, that's far too crude.  I think you mean

  swap = uncurry $ flip (,)


I think I would prefer something that mirrors flip more closely:

swap :: ((a,b) -> c) -> (b,a) -> c
swap = uncurry . flip . curry

- Jake
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Peter Verswyvelen]

On Wed, Mar 25, 2009 at 4:09 PM, Simon Marlow  wrote:

> But it only works out nicely because the ordering of the components of the
> pair returned by splitAt matches the ordering that the state monad expects
> (and I can never remember which way around they are in Control.Monad.State).
>

Now you mention this, I often had to write a little function

swap :: (a,b) -> (b,a)

It seems many other authors have done the same in their own modules. Maybe
this should be part of the Prelude?


>
>
> Try doing it with mapAccumL, which is arguably the right abstraction, but
> has the components the other way around.
>
> Cheers,
>Simon
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Simon Marlow]

Jonathan Cast wrote:

On Wed, 2009-03-25 at 15:09 +, Simon Marlow wrote:
the ordering that the state monad expects 
(and I can never remember which way around they are in Control.Monad.State).


Really?  I found it obvious once I figured out it how simple it made
(>>=).  With the order from Control.Monad.State (with constructors
ignored):

a >>= f = \ s -> case s a of
   (x, s') -> f x s'

Reversing the order of the components of the result gives you

a >>= f = \ s -> case s a of
(s', x) -> f x s'

which just looks weird.


It might look weird to you, but that's the way that GHC's IO and ST monads 
do it.  It looks perfectly natural to me!  (and you have the a and s the 
wrong way around in 'case s a', BTW).



Try doing it with mapAccumL, which is arguably the right abstraction,
but 
has the components the other way around.


Define

swap (a, b) = (b, a)


ew, that's far too crude.  I think you mean

  swap = uncurry $ flip (,)

Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Jonathan Cast]

On Wed, 2009-03-25 at 15:09 +, Simon Marlow wrote:
> the ordering that the state monad expects 
> (and I can never remember which way around they are in Control.Monad.State).

Really?  I found it obvious once I figured out it how simple it made
(>>=).  With the order from Control.Monad.State (with constructors
ignored):

a >>= f = \ s -> case s a of
   (x, s') -> f x s'

Reversing the order of the components of the result gives you

a >>= f = \ s -> case s a of
(s', x) -> f x s'

which just looks weird.

> Try doing it with mapAccumL, which is arguably the right abstraction,
> but 
> has the components the other way around.

Define

swap (a, b) = (b, a)

You'll never worry about the order of components of a pair again.  This
function is as indispensable as flip.

jcc


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: about Haskell code written to be "too smart"

[Simon Marlow]

Dan Piponi wrote:

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 see that
evalState and State are just noise for the type inferencer so we just
need to think about mapM splitAt. This turns a sequence of integers
into a sequence of splitAts, each one chewing on the leftovers of the
previous one. *Way* easier than both the zipWith one-liner and the
explicit version. It says exactly what it means, almost in English.


But it only works out nicely because the ordering of the components of the 
pair returned by splitAt matches the ordering that the state monad expects 
(and I can never remember which way around they are in Control.Monad.State).


Try doing it with mapAccumL, which is arguably the right abstraction, but 
has the components the other way around.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: about Haskell code written to be "too smart"

[Achim Schneider]

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".
> 
Well, you're going to have a hard time writing a BASIC tutorial without
mentioning GOTO. While surely it has to be there, for the sake of
completeness of fundamentals, I completely agree that...

> - high level, Haskell specific, abstractions, are *not* explained in
>normal tutorials or books.
>The libraries where these concepts are implemented, are not well
>documented.
>Most of the "documentation" is in research papers, and a "normal"
>programmer don't want to read these papers.
> 
>Only in the recent "Real World Haskell", all these high level
>abstraction have been properly documented
>
...GOTO alone doesn't teach you how to write a loop, trust me, I was
stuck there for a good while, eons ago.

The prelude, as well as commonly used functions that should be in
there, utterly lack accompanying documentation. There should be no
function without a usage, as in foldl/sum/product, and no usage without
explanation why foldl is chosen over foldl' and foldr. Think of a
Preludopedia, accompanying the Typeclassopedia: Documentation where you
don't have to snatch understanding out of assem^H^H^H^H^H^H code
written using primitive recursion, to make it a bit easier to see the
wood despite of all those trees.

PS: Shouldn't zipWith be defined in terms of zip, uncurry and map
instead of 
zipWith f (a:as) (b:bs) = f a b : zipWith f as bs
zipWith _ _  _  = []
?

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: about Haskell code written to be "too smart"

[Achim Schneider]

"Alberto G. Corona "  wrote:

> However, reusability of source code and maintainability has never
> been taken seriously by haskell programmers, simply because there are
> no industrial projects in Haskell with dozens of people with
> different skills that come and go.
>
Now that's a claim.

In the sense that I don't do commercial haskell coding, but know what
maintainability is, anyway: I've maintained everything from utterly
atrocious to mindboggingly elegant java code for a living. I can tell
you with 110% confidence that maintainability is about composibility,
_on_every_level_: Not just on statement-level. Otherwise, I wouldn't
have cussed that much. Curiously enough, as soon as the code
didn't make you whince, it was easily maintainable. This is closely
related to Linus' observation that good [imperative] code is
data-structure centred, and Greenspun's Tenth Rule.


With Haskell, there's finally a language that makes large-scale changes
as easy as small-scale changes without having to resort to implement an
interpreter for a functional language. As the position of changes tends
to travel upwards in a bottom-up approach and small-scale changes are
easy to pull off (you already understand what you need to do since
otherwise you wouldn't have identified the need for a small-scale
change and continued to add onion layers), caring about editability on
function level just doesn't pay off.


That's why I don't care whether or not I have to re-write a whole
function to change it: If it's going to change, which isn't all that
likely, I can cope with renaming it and write another say 160
characters directly below it. Adding a proper quickcheck property (if
it didn't exist, yet, or the semantics changed) is usually more work:
You don't only need to get the preposition right, but also the test
case generator.


-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"

[Manlio Perillo]

Heinrich Apfelmus ha scritto:

Manlio Perillo wrote:

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:

[steps 1) - 9), mostly internet tutorials ]


I think you'd have had a much easier time by starting with a proper book
right away, like Richard Bird's "Introduction to Functional Programming
in Haskell", accompanied by Real World Haskell. 


Unfortunately, one year ago Real World Haskell was not here.
And note that I have no problems with basic functional programming concepts.
My problems are specific to Haskell.


You see, the reason that
books cost money is (should be) high quality content. :)




Manlio
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: about Haskell code written to be "too smart"

[Heinrich Apfelmus]

Dan Piponi wrote:
>> 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 see that
> evalState and State are just noise for the type inferencer so we just
> need to think about mapM splitAt. This turns a sequence of integers
> into a sequence of splitAts, each one chewing on the leftovers of the
> previous one. *Way* easier than both the zipWith one-liner and the
> explicit version. It says exactly what it means, almost in English.

I couldn't agree more. In other words,  splitAt  is really to be thought
of as a function that lives in the state monad.


Regards,
apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: about Haskell code written to be "too smart"

[Heinrich Apfelmus]

Manlio Perillo wrote:
> 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:
> 
> [steps 1) - 9), mostly internet tutorials ]

I think you'd have had a much easier time by starting with a proper book
right away, like Richard Bird's "Introduction to Functional Programming
in Haskell", accompanied by Real World Haskell. You see, the reason that
books cost money is (should be) high quality content. :)


Regards,
apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe