Derek Elkins writes:

...

parseCSVFromFile "in.csv" >>= return . either (const "error!")

Whenever you see this >>= return . f pattern think liftM or fmap or <$>.

...and "return . f >>= action" is just "action . f", no? -k -- If I haven't seen further, it is by standing in the footprints of giants

Op woensdag 01-10-2008 om 10:15 uur [tijdzone +0200], schreef Ketil Malde:

Derek Elkins writes:

...

...

parseCSVFromFile "in.csv" >>= return . either (const "error!")

...

Whenever you see this >>= return . f pattern think liftM or fmap or <$>.

...and "return . f >>= action" is just "action . f", no?

Maybe you meant "return f >>= action" is the same as "action f". Greetings. -- marcot Página: http://marcotmarcot.iaaeee.org/ Blog: http://marcotmarcot.blogspot.com/ Correio: marcot@riseup.net XMPP: marcot@jabber.org IRC: marcot@irc.freenode.net Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil

2008/9/30 wman <666wman@gmail.com>:

Thanks a lot, I've had a hunch it was possible to get rid of those those liftM's. I turned it into:

(writeFile "output.csv") . printCSV . (map updateLine) . (either (error "Chyba pri cteni CSV.") id) =<< parseCSVFromFile "input.csv"

and am sincerely hoping he will try to decypher it's meaning ;-)))

It looks like you've added some good error-czeching code here. :-; G

On Tue, 30 Sep 2008, wman wrote:

Thanks a lot, I've had a hunch it was possible to get rid of those those liftM's. I turned it into:

(writeFile "output.csv") . printCSV . (map updateLine) . (either (error "Chyba pri cteni CSV.") id) =<< parseCSVFromFile "input.csv"

You may even remove parentheses around 'writeFile', 'map' and 'either'.

Thats why i put those quotation marks around that part of sequence ;-)) AFAIK one-liners never were about comprehensibility, just about what you can cram into one line of code. Any programmer should have no problems guessing what the line does does (even more so when looking at the "final" version without the abundant liftM's), the beauty of it lies in figuring how the heck it does what it does. And figuring that out should bring the "profound enlightenment experience; that experience which should make you a better programmer for the rest of your days, even if you never actually use Lisp -erm Haskell- itself a lot" (my apologies, P. Graham, for cannibalizing your words). I should probably get myself a signature stating that i will explicitly warn the reader when being serious ;-) PS: Sorry, Andrew, that I first posted the reply directly to you, still getting used to the fact that gmail kindly replies to the user on whose behalf the message was sent, not to the list. On Wed, Oct 1, 2008 at 9:51 PM, Andrew Coppin wrote:

wman wrote:

...

Long story short, I promised him a one-liner to "show the power and beauty of Haskell".

(writeFile "output.csv") =<< (liftM printCSV $ liftM (map updateLine) $ parseCSVFromFile "input.csv")

Is there room for improvement ?

Um... Does anybody else find it interesting that we are "showing the beauty of Haskell" by attempting to construct the most terse, cryptic, unmaintainable tangle of point-free code that the combined mindpower of the entire mailing list can produce?

Yes, there is much to be said for the power and brevity of Haskell. But you *can* go over the top here, people! o_O

Keep it short _yet comprehensible_, IMHO.

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

Op woensdag 01-10-2008 om 13:25 uur [tijdzone -0700], schreef Martin DeMello:

2008/10/1 wman <666wman@gmail.com>:

...

PS: Sorry, Andrew, that I first posted the reply directly to you, still getting used to the fact that gmail kindly replies to the user on whose behalf the message was sent, not to the list.

I think that's a list setting, not a gmail one.

The list could set reply-to, which is usually not very recommended in netiquettes. And gmail doesn't have a reply-to-list option, which is very useful when the lists doesn't set reply-to, like haskell-cafe. Greetings. -- marcot Página: http://marcotmarcot.iaaeee.org/ Blog: http://marcotmarcot.blogspot.com/ Correio: marcot@riseup.net XMPP: marcot@jabber.org IRC: marcot@irc.freenode.net Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil

Op woensdag 01-10-2008 om 18:59 uur [tijdzone -0700], schreef Jason Dusek:

Reply to all?

No. Reply-to-list is a different thing. When you reply-to-all to a person who is in the list, the person gets two copies of the e-mail with different headers, which messes with filters and replies. Greetings. -- marcot Página: http://marcotmarcot.iaaeee.org/ Blog: http://marcotmarcot.blogspot.com/ Correio: marcot@riseup.net XMPP: marcot@jabber.org IRC: marcot@irc.freenode.net Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil

On Wed, Oct 1, 2008 at 10:40 PM, Andrew Coppin wrote:

Maybe I should start a new tradition where Haskellers have a blob of Haskell as their sig?

(I can't *wait* to see what the luminaries such as dons, dcoutts and igloo come up with...)

Some haskell equivalent of : (((((lambda(x)((((((((x x)x)x)x)x)x)x)x)) (lambda(x)(lambda(y)(x(x y))))) (lambda(x)(x)x)) (lambda()(printf "Greetings, Jos~n")))) ? ;-))) and seeing ketil's sig, i cannot keep to myself this beautiful bastardization of the "shoulders of giants" line which i found today: Most men stand on the shoulders of giants. Matthew Garrett stamps on the testicles of midgets. PS: it seems the list won't re-send the message to people to whom it was directly addressed. so to stay in my on-click lazy mode, i'm trying the reply-to-all button. In the case i start flooding your mailboxes, just kindly kick my butt. thx

Andrew Coppin writes:

...

(writeFile "output.csv") =<< (liftM printCSV $ liftM (map updateLine) $ parseCSVFromFile "input.csv")

Um... Does anybody else find it interesting that we are "showing the beauty of Haskell" by attempting to construct the most terse, cryptic, unmaintainable tangle of point-free code

I don't agree at all! How could a pipeline like this possibly be more clearly expressed than by the pattern: readInputFile "input" >>= mungeStuff >>= writeOutputFile "output" ? The OP asks for improvements, which got rid of a couple of gratuitous liftMs and such, but otherwise I think it's a pretty straightforward idiom. -k -- If I haven't seen further, it is by standing in the footprints of giants