next, carry, feed, roll
On 6 August 2013 08:37, KC kc1...@gmail.com wrote:
I thought a pure value was being returned from the monad. :)
On Mon, Aug 5, 2013 at 10:32 PM, Christian Sternagel
c.sterna...@gmail.com wrote:
Dear Jurriën.
personally, I like lift (which is of course already
Thanks Chris. Yes, I like lift as well, because I find it a rather intuitive
name. Unfortunately, as you say, it is already a commonly used name as well,
which might make it slightly confusing.
When I hear `unit` I immediately think about generic programming, not so much
about monads. Can you
Hi Tarik,
Could you motivate the choice for these names? Thanks!
On 6 Aug 2013, at 08:14, Tarik ÖZKANLI tozkanli2...@gmail.com wrote:
next, carry, feed, roll
On 6 August 2013 08:37, KC kc1...@gmail.com wrote:
I thought a pure value was being returned from the monad. :)
On Mon, Aug
What about `pure`? It's already used in applicative, and has the
motivation that it's embedding a pure value in some context. Since I
don't know the details of your project, I don't know if you need two
names (one for the applicative version, and one for the monadic
version).
Erik
On Tue, Aug 6,
I have to admit that I am a bit torn about using `pure`. On the one hand, if
you actually have a pure value, it feels pretty intuitive to me. But what about
pure (putStrLn Hi)
`putStrLn Hi` is not a pure value... Or is there another way to interpret the
word pure in this context?
As for
What about 'pack'?
Best,
Karol
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
What about 'inject'?
On 6 August 2013 09:09, Karol Samborski edv.ka...@gmail.com wrote:
What about 'pack'?
Best,
Karol
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Tue, Aug 06, 2013 at 10:03:04AM +0200, J. Stutterheim wrote:
`putStrLn Hi` is not a pure value...
Why not?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
It is a pure value in the context of the outer monad (the one you wrap it
in). I'd say pure is still appropriate.
On Aug 6, 2013 10:14 AM, Tom Ellis
tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:
On Tue, Aug 06, 2013 at 10:03:04AM +0200, J. Stutterheim wrote:
`putStrLn Hi` is not a pure
What about promote ?
On Tue, Aug 6, 2013 at 6:15 PM, Tom Ellis
tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:
On Tue, Aug 06, 2013 at 10:03:04AM +0200, J. Stutterheim wrote:
`putStrLn Hi` is not a pure value...
Why not?
___
Haskell-Cafe
On 08/06/2013 04:30 PM, J. Stutterheim wrote:
Thanks Chris. Yes, I like lift as well, because I find it a rather intuitive
name. Unfortunately, as you say, it is already a commonly used name as well,
which might make it slightly confusing.
When I hear `unit` I immediately think about generic
What about X, Y, Z, ...
We have seen this discussion already a long time ago. The terms unit
and result have been proposed. And others. Somebody (I forgot who)
advocated even the name monad in this context. And this might have
continued forever...
With all my respect, I see that Haskell
Hi,
On 06/08/13 06:14, J. Stutterheim wrote:
Suppose we now have the opportunity to change the name of the
`return` function in Monad, what would be a better name for it?
(for some definition of better)
Rather than proposing a different name, I'm going to challenge the
premise of your
Hi Adam,
Thank you for an interesting thought; an invisible name might actually be on of
the better solutions, although you are right in that your suggestion is a bit
too open for my current project.
Actually, I believe that naming is very important. My goal is to have the
average programmer
That argument makes sense, although I find it a bit counter-intuitive still. If
I saw the function `pure` for the first time, my first impression (however
wrong it may be) would be that it takes a pure value (regardless of context)
and does something with it. Applying `pure` to an IO operation
Le 06/08/2013 11:01, J. Stutterheim a écrit :
... So in reply to Jerzy, I do want to encourage the discussion in the Noble Domain
of Philosophy and I also want to repeat that I am not proposing to change Haskell
or Haskell libraries
Jurriën, I taught Haskell for several years. I saw the
very insightful, thx Jerzy.
imho, this is a good reason not to use already known words like
lift,return,inject,pure etc. while still using the word Monad. (this is
something that bothered me for years.)
no one -of those who say no one- does understand Monads because it does not
explain itself
But IO actions *are* pure values. What side effects do they have? None! You
can do whatever you want with them with no harmful effects in any Haskell
expression. They only special thing about them is that they have a run
function that is not itself provided in Haskell. The run function is
actually
Could you add some documentation on how to use this with cabal? I've found
integrating tests with cabal unintuitive and poorly documented--to the
point where I haven't really bothered! I've gotten it working before, but I
would have to look it up again in the future. (I also didn't use a
You can find an example here:
https://github.com/feuerbach/regex-applicative/blob/master/regex-applicative.cabal#L89
If you'd like to contribute a short README section based on that, please
go ahead! :)
Roman
* Tikhon Jelvis tik...@jelv.is [2013-08-06 09:29:21-0400]
Could you add some
On Tue, Aug 6, 2013 at 4:03 AM, J. Stutterheim j.stutterh...@me.com wrote:
I have to admit that I am a bit torn about using `pure`. On the one hand,
if you actually have a pure value, it feels pretty intuitive to me. But
what about
pure (putStrLn Hi)
`putStrLn Hi` is not a pure value...
Le 06/08/2013 14:47, Jake McArthur a écrit :
... But IO actions *are* pure values. What side effects do they have?
None! /You can do whatever you want with them/ with no harmful effects
in any Haskell expression. They only special thing about them is that
they have a run function
As I said,
On Tue, Aug 06, 2013 at 04:26:05PM +0200, Jerzy Karczmarczuk wrote:
1. First, it is not true that you can do with, say, (printStr Ho!
) whatever you want. In fact, you can do almost nothing with it. You
can transport it as such, and you can use it as the argument of
(=).
I don't think this
Awesome. Ill take a look at tasty sometime this month. Thanks for taking
the time to patiently answer all of our questions.
On Tuesday, August 6, 2013, Roman Cheplyaka wrote:
* Carter Schonwald carter.schonw...@gmail.com javascript:;
[2013-08-05 16:58:37-0400]
fair enough. I take it that
On 13-08-06 01:14 AM, J. Stutterheim wrote:
N.B. I am _not_ proposing that we actually change the name of `return`. I do
currently have the opportunity to pick names for common functions in a
non-Haskell related project, so I was wondering if there perhaps is a better
name for `return`.
I
Bikeshedding at its finest. I think if we are very lucky, then a long time
from now we will be able to deprecate return in favor of
Control.Applicative.pure
As for making it invisible, that's what idiom brackets and monad
comprehensions are for. But for those creating an *instance* of Monad,
Roman Cheplyaka r...@ro-che.info writes:
I am pleased to announce the first release of tasty, a new testing framework
for Haskell. It is meant to be a successor to test-framework (which is
unmaintained).
It would be nice to see a comparison of the various test frameworks and why
one might
Occasionally I have to explicitly add a type annotation, either for
clarity or to help choose a typeclass instance. Usually top-level
type annotations take care of this, but sometimes it's convenient to
only annotate a certain value, e.g. one argument of a lambda.
I've noticed that while vanilla
This is already a separate extension: PatternSignatures. However, that
extension is deprecated for some reason.
On Tue, Aug 6, 2013 at 2:46 PM, Evan Laforge qdun...@gmail.com wrote:
Occasionally I have to explicitly add a type annotation, either for
clarity or to help choose a typeclass
Evan Laforge qdun...@gmail.com writes:
Would it make sense to split it into a separate extension like
TypesOnArguments so I can more accurately express my deviation from
haskell2010 orthodoxy? Or is there some deeper tie between scoped
type variables and annotations on arguments?
I've also
* John Wiegley jo...@fpcomplete.com [2013-08-06 13:40:50-0500]
Roman Cheplyaka r...@ro-che.info writes:
I am pleased to announce the first release of tasty, a new testing framework
for Haskell. It is meant to be a successor to test-framework (which is
unmaintained).
It would be nice
On 6/08/2013, at 9:28 PM, J. Stutterheim wrote:
That argument makes sense, although I find it a bit counter-intuitive still.
In discussions like this, I have never been able to discover any meaning for
intuitive other than familiar. Applying pure to an IO operation doesn't
go against *my*
I bet you can find an abundance of C programmers who think that
strcmp is an intuitive name for string comparison (rather than
compression, say).
But at least, 'strcmp' is not a common English language term, to have
acquired some unintentional 'intuition' by being familiar with it even in
On Tue, Aug 6, 2013 at 9:10 PM, Richard A. O'Keefe o...@cs.otago.ac.nzwrote:
I bet you can find an abundance of C programmers who think that
strcmp is an intuitive name for string comparison (rather than
compression, say).
Them and a small and slowly shrinking group of folks who find it
Hello,
A friend of mine tried to install Haskell Platform and Leksah on
Windows and was troubled by the amount of problems he encountered as a
beginner in this. I've told him to ask over IRC and mailing list but
it seems he has some problems with registration.
Anyway, he blogged about his
35 matches
Mail list logo
