2010/10/13 Henning Thielemann schlepp...@henning-thielemann.de:
David Virebayre schrieb:
2010/10/12 Gregory Crosswhite gcr...@phys.washington.edu:
Also, I don't see why one would prefer over the standard function
composition operator, ..
With . you have to read right-to-left to follow
On Oct 11, 2010, at 11:48 AM, Gregory Crosswhite wrote:
No, but there is no point in using a formalism that adds complexity
without adding functionality. Arrows are more awkward to use than
monads because they were intentionally designed to be less powerful
than monads in order to cover
2010/10/12 Gregory Crosswhite gcr...@phys.washington.edu:
Also, I don't see why one would prefer over the standard function
composition operator, ..
With . you have to read right-to-left to follow data's path.
For me that reading order isn't natural, and I imagine it is so for
most people
On Oct 11, 3:20 pm, Uwe Schmidt u...@fh-wedel.de wrote:
Hi Gregory,
Is there some benefit that your library gets out of using arrows that I
missed which makes these costs worth it?
I thing, this is not a question of functionality, it's a question of style.
Of course everything in hxt
Hi Gregory,
As I understood, John Hughes invented the arrows as a generalisation
of monads, you say it's a less powerful concept. I'm a bit puzzled with
that. Could you explain these different views.
Consider the following example:
f :: Int - m a
f i = monads !! (i *5
David Virebayre schrieb:
2010/10/12 Gregory Crosswhite gcr...@phys.washington.edu:
Also, I don't see why one would prefer over the standard function
composition operator, ..
With . you have to read right-to-left to follow data's path.
For me that reading order isn't natural, and I
Hi Gregory,
...
No, but there is no point in using a formalism that adds complexity
without adding functionality. Arrows are more awkward to use than
monads because they were intentionally designed to be less powerful than
monads in order to cover situations in which one could not use a
Gregory,
I use arrows (especially list arrows) in a lot of my projects and find them
(after some training) easier to work with than monands. Code that I write
point-free using arrows generally contains fewer bugs than code I write in
monadic style.
On Oct 11, 2010, at 8:48 PM, Gregory
On Tue, Oct 12, 2010 at 8:56 AM, Uwe Schmidt u...@fh-wedel.de wrote:
No, but there is no point in using a formalism that adds complexity
without adding functionality. Arrows are more awkward to use than
monads because they were intentionally designed to be less powerful than
monads in order
Dear Sebastiaan,
I would first refer to the description of the Change function in a
paper by Erik Meijer (an Haskeller among the designers of F#):
http://portal.acm.org/citation.cfm?id=1297027.1297078
In short, programmers will learn something new only if the improvement
is worth the effort of the
On Tue, Oct 12, 2010 at 8:56 AM, Uwe Schmidt u...@fh-wedel.de wrote:
No, but there is no point in using a formalism that adds complexity
without adding functionality. Arrows are more awkward to use than
monads because they were intentionally designed to be less powerful than
monads in
On 10/12/10 5:56 AM, Uwe Schmidt wrote:
Hi Gregory,
As I understood, John Hughes invented the arrows as a generalisation
of monads, you say it's a less powerful concept. I'm a bit puzzled with
that. Could you explain these different views.
Consider the following example:
f :: Int - m a
On Tuesday 12 October 2010 4:02:06 pm Gregory Crosswhite wrote:
Hughes himself said that when your arrow is an instance of ArrowApply,
you are better off just sticking with monads.
Well, this is not necessarily good advice. It is true that ArrowApply will
preclude some sort of static
On 10/12/10 12:39 PM, Gene A wrote:
splitMiddle :: forall a. [a] - ([a], [a])
splitMiddle =
(id (length flip div 2))
(\(xs,a) - splitAt a xs)
But is that really easier to understand at a glance then
splitMiddle xs = splitAt (length xs `div` 2) xs
? It seems to me that while
On 10/12/10 6:29 AM, Sebastiaan Visser wrote:
Gregory,
I use arrows (especially list arrows) in a lot of my projects and find them
(after some training) easier to work with than monands. Code that I write
point-free using arrows generally contains fewer bugs than code I write in
monadic
On Tue, Oct 12, 2010 at 3:00 PM, Paolo G. Giarrusso
p.giarru...@gmail.com wrote:
Were you writing a paper, your comment would be fully valid. Here
we're talking about a library for people to use in practice. In the
middle, somebody should make sure that people without a PhD can learn
arrows,
On 10/12/10 1:22 PM, Dan Doel wrote:
On Tuesday 12 October 2010 4:02:06 pm Gregory Crosswhite wrote:
Hughes himself said that when your arrow is an instance of ArrowApply,
you are better off just sticking with monads.
Well, this is not necessarily good advice. It is true that ArrowApply will
Hi Gregory,
Could you explain to me why HXT uses arrows? I have never been able
to figure out what advantage this gives your library over monads. Since
your arrows in practice implement ArrowApply, they are really just
monads anyway, so it seems to me that using arrows instead of monads
Uwe,
Thank you for your reply.
On 10/11/10 6:20 AM, Uwe Schmidt wrote:
I thing, this is not a question of functionality, it's a question of style.
Of course everything in hxt could have been done with monads,
but does this also mean: Everything must have been done with monads?
No, but there
Gregory Crosswhite schrieb:
In conclusion, while I greatly appreciate you taking the time to explain
your reasoning, it still looks to me like there is nothing you have
gained by using arrows except adding extra unnecessary complexity in
your library.
As a pragmatic question: Would it be
Hi,
Am Montag, den 11.10.2010, 21:29 +0200 schrieb Henning Thielemann:
Gregory Crosswhite schrieb:
In conclusion, while I greatly appreciate you taking the time to explain
your reasoning, it still looks to me like there is nothing you have
gained by using arrows except adding extra
21 matches
Mail list logo
