Re: [Haskell-cafe] Alternative name for return
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 occupied in Haskell), since an arbitrary value is lifted into a monad. (The literature sometimes uses unit.) cheers chris On 08/06/2013 02:14 PM, J. Stutterheim wrote: Dear Cafe, 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) 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`. - Jurriën __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe -- -- Regards, KC ___ 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] Alternative name for return
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 perhaps explain the intuition behind `unit` as an alternative to `return` in the context of monads? - Jurriën On 6 Aug 2013, at 07:32, Christian Sternagel c.sterna...@gmail.com wrote: Dear Jurriën. personally, I like lift (which is of course already occupied in Haskell), since an arbitrary value is lifted into a monad. (The literature sometimes uses unit.) cheers chris On 08/06/2013 02:14 PM, J. Stutterheim wrote: Dear Cafe, 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) 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`. - Jurriën ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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 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 occupied in Haskell), since an arbitrary value is lifted into a monad. (The literature sometimes uses unit.) cheers chris On 08/06/2013 02:14 PM, J. Stutterheim wrote: Dear Cafe, 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) 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`. - Jurriën ___ 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 -- -- Regards, KC ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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, 2013 at 7:14 AM, J. Stutterheim j.stutterh...@me.com wrote: Dear Cafe, 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) 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`. - Jurriën ___ 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] Alternative name for return
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 Applicative, I can add (and have added) the Applicative constraint in the Monad definition for my project, so I will also have to write an Applicative instance for my monads. - Jurriën On 6 Aug 2013, at 09:50, Erik Hesselink hessel...@gmail.com wrote: 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, 2013 at 7:14 AM, J. Stutterheim j.stutterh...@me.com wrote: Dear Cafe, 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) 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`. - Jurriën ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc Description: Message signed with OpenPGP using GPGMail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
What about 'pack'? Best, Karol ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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
Re: [Haskell-cafe] Alternative name for return
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 value... Why not? ___ 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] Alternative name for return
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 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] Alternative name for return
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 programming, not so much about monads. Can you perhaps explain the intuition behind `unit` as an alternative to `return` in the context of monads? Probably because of the monad laws, where `return` is a unit (in the mathematical sense) for the `bind` operation. - chris - Jurriën On 6 Aug 2013, at 07:32, Christian Sternagel c.sterna...@gmail.com wrote: Dear Jurriën. personally, I like lift (which is of course already occupied in Haskell), since an arbitrary value is lifted into a monad. (The literature sometimes uses unit.) cheers chris On 08/06/2013 02:14 PM, J. Stutterheim wrote: Dear Cafe, 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) 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`. - Jurriën ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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 reached finally the Noble Domain of Philosophy. I mean, instead of discussing concepts, people begin to discuss names. And since for some, even IO () is a pure value, I suspect that the next round will rekindle the discussion on the word pure... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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 question. Perhaps it would be better if `return` had no
name at all. Consider the following:
return f `ap` s `ap` t
f $ s * t
do { sv - s
; tv - t
; return (f sv tv) }
These are all different ways of spelling
f s t
plus the necessary applicative or monadic bureaucracy. But why couldn't
we write just the plain application, and let the type system deal with
the plumbing of effects?
I realise that this may be too open a research area for your project...
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 don't think the choice of name matters. I do think it should be short.
Preferably invisible.
Adam
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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 (i.e. someone without a post-bachelor degree) look at the
code and get an intuitive feel of what is going on. 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
(I am working with another language altogether), so don't fear ;)
- Jurriën
On 6 Aug 2013, at 10:46, Adam Gundry adam.gun...@strath.ac.uk wrote:
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 question. Perhaps it would be better if `return` had no
name at all. Consider the following:
return f `ap` s `ap` t
f $ s * t
do { sv - s
; tv - t
; return (f sv tv) }
These are all different ways of spelling
f s t
plus the necessary applicative or monadic bureaucracy. But why couldn't
we write just the plain application, and let the type system deal with
the plumbing of effects?
I realise that this may be too open a research area for your project...
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 don't think the choice of name matters. I do think it should be short.
Preferably invisible.
Adam
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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 goes against that intuition. Looking at the type of `return :: a - m a, there are several slightly more intuitive (to me) options in this discussion already: lift: the value `a` is lifted into the monad `m` pack: the value `a` is packed into the monad `m` wrap: the value `a` is wrapped in the monad `m` inject: the value `a` is injected into the monad `m` promote: the value `a` is promoted to a monad `m a` On 6 Aug 2013, at 10:16, Tobias Dammers tdamm...@gmail.com wrote: 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 value... Why not? ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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 disgraceful confusion in heads of my students whose previous programming experience was based on Python, and who learned Haskell and Java in parallel. So, I won't claim that names are irrelevant. And return in particular. However, my personal philosophy is the following: accept the fact that words in one language -- formal or natural -- mean something different than in another one. [[In French the word file in computerese is queue in English; this is in fact a French word meaning tail in English, and I have several dozens of such examples... And so what?...]] It is good to choose consciously some good names while elaborating a standard. But getting back to it after several years, is -- for me -- a waste of time. This, unfortunately, pollutes the true philosophy as well. I believe that at least 80% of the progress in the philosophy of religions belongs to the linguistic domain. The anglosaxons corupted the word semantics, used in a pejorative sense: discussion about superficialities, the words, not the concepts, while the true semantics is about the true sense. So, sorry for being sarcastic, or even cynical in my previous post, but I sincerely think that oldies are oldies, let them be, and work more on issues that are still evolving. All the best. Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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 nor suggest its utility, while the other words probably tend to cause a very false sense of understanding. so, long talk few suggestions if it should be about Monads as a concept, i'd suggest 1) unit and counit for Monads and Comonads. (this is my personal favorite choice, probably because i did learn to understand Monads by reading a paper about Comonads.) if it should be more selfexplaining for the average coder, then 2) let,set,put,be,:= or return allowed only at end of script - use let anywhere else for ScriptLike (aka Monad) as a strict version of return, i'd suggest something that may somehow fit into 1 and 2: 3) eval = Control.Exception.evaluate :: a - IO a regards - marc Gesendet: Dienstag, 06. August 2013 um 11:43 Uhr Von: Jerzy Karczmarczuk jerzy.karczmarc...@unicaen.fr An: haskell-cafe@haskell.org Betreff: Re: [Haskell-cafe] Alternative name for return 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 disgraceful confusion in heads of my students whose previous programming experience was based on Python, and who learned Haskell and Java in parallel. So, I won't claim that names are irrelevant. And return in particular. However, my personal philosophy is the following: accept the fact that words in one language -- formal or natural -- mean something different than in another one. [[In French the word file in computerese is queue in English; this is in fact a French word meaning tail in English, and I have several dozens of such examples... And so what?...]] It is good to choose consciously some good names while elaborating a standard. But getting back to it after several years, is -- for me -- a waste of time. This, unfortunately, pollutes the true philosophy as well. I believe that at least 80% of the progress in the philosophy of religions belongs to the linguistic domain. The anglosaxons corupted the word semantics, used in a pejorative sense: discussion about superficialities, the words, not the concepts, while the true semantics is about the true sense. So, sorry for being sarcastic, or even cynical in my previous post, but I sincerely think that oldies are oldies, let them be, and work more on issues that are still evolving. All the best. Jerzy ___ 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] Alternative name for return
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 not legal to expose in pure Haskell. Even if it were exposed, *that function* would be the impure thing, not the IO actions you apply it to. (This is why GHC has unsafePerformIO and not UnsafeIO). - Jake On Aug 6, 2013 5:29 AM, J. Stutterheim j.stutterh...@me.com wrote: 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 goes against that intuition. Looking at the type of `return :: a - m a, there are several slightly more intuitive (to me) options in this discussion already: lift: the value `a` is lifted into the monad `m` pack: the value `a` is packed into the monad `m` wrap: the value `a` is wrapped in the monad `m` inject: the value `a` is injected into the monad `m` promote: the value `a` is promoted to a monad `m a` On 6 Aug 2013, at 10:16, Tobias Dammers tdamm...@gmail.com wrote: 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 value... Why not? ___ 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 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] ANNOUNCE: tasty, a new testing framework
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 framework.) It would be awesome to see an example .cabal file along with your example test cases. thanks, -tikhon On Tue, Aug 6, 2013 at 1:53 AM, Roman Cheplyaka r...@ro-che.info wrote: * Carter Schonwald carter.schonw...@gmail.com [2013-08-05 16:58:37-0400] fair enough. I take it that you're also (implicitly) committing to maintaining this for the next few years? :) That's correct. Roman ___ 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] ANNOUNCE: tasty, a new testing framework
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 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 framework.) It would be awesome to see an example .cabal file along with your example test cases. thanks, -tikhon On Tue, Aug 6, 2013 at 1:53 AM, Roman Cheplyaka r...@ro-che.info wrote: * Carter Schonwald carter.schonw...@gmail.com [2013-08-05 16:58:37-0400] fair enough. I take it that you're also (implicitly) committing to maintaining this for the next few years? :) That's correct. Roman ___ 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] Alternative name for return
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... Or is there another way to interpret the word pure in this context? I actually have the opposite problem: what's impure about lifting 5 into Maybe or []? `pure` feels IO-targeted. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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, -- *Now Is The Time* -- [[choose your reference of this Original Expression; perhaps the albums of Alanis Morissette or that of Jeff Lorber...]] ... to discuss the Purity. Go ahead and good luck. Unfortunately I belong to a Cretacean generation, for whom the Referential Transparency means something, so I don't believe you, Jake. I am not saying that you are wrong. I say that calling an action a pure /value/ is almost meaningless. 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 (=). 2. This is the only way you can evaluate your pure value, and because of the monadic chaining, you cannot do it twice, you cannot re-evaluate it. You know all this as well as I do, perhaps better. That's why the purity here is dubious (although, unless I am mistaken, all functional constructs are considered pure by Wadler...). 3. Brandon Albery is (in my eyes) right: what's impure about lifting 5 into Maybe or []? `pure` feels IO-targeted. A list, such as (return 5) in the List/Nondet Monad may be treated as a normal data item. But a IO action, or a IoRef mutable reference -- not really, they are Magic. If you claim that Magic is Pure, I abandon the ring. For me the Magical entities (i.e., the entities which are controlled by some layers UNDER the one YOU control) are impure, since there is no operational definition of purity for them. No side effects? Sure, if you don't do anything with it. Even the most horrible Devil is pure. Unless you call it... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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 argument holds much water. You can do even less with (). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tasty, a new testing framework
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 you're also (implicitly) committing to maintaining this for the next few years? :) That's correct. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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 suggest simply. Having said that, I like all the other names too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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, well, we obviously need to be able to refer to which operation we are implementing. I like the idea of using lift, because this is the word used for MonadTrans, which is the same operation, but in the category of Haskell Monads instead of the category of Hask. However, it is convenient to have both in scope unqualified, so maybe lift would not be the best choice. -- Dan Burton On Aug 6, 2013 7:38 AM, Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: 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 argument holds much water. You can do even less with (). ___ 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] ANNOUNCE: tasty, a new testing framework
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 select one over another. I use hspec currently (which also integrates with HUnit, QuickCheck, etc.), and couldn't tell at a glance what tasty might offer. And I particularly dislike writing tests inside of a gigantic list; I much prefer the monadic style of hspec. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ScopedTypeVariables
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 haskell is happy to allow me to put type annotations on variables where they are used (e.g. '\x - f (x :: T)'), if I put it on the variable where it is bound (e.g. '\(x :: T) - f x'), it wants me to turn on ScopedTypeVariables. I think ScopedTypeVariables is a nice extension and I'm sure it comes from a perfectly respectable family and all, but it feels like annotations on arguments comes in as a side-effect. 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? Now that I think of it, it seems inconsistent that 'x :: A - B; x a = ...' is valid, but 'x = \(a :: A) - (...) :: B' is not. Doesn't the former desugar to the latter? And what about getting ScopedTypeVariables into haskell prime? As far as I know everyone loves it, or at least no one actually hates it :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ScopedTypeVariables
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 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 haskell is happy to allow me to put type annotations on variables where they are used (e.g. '\x - f (x :: T)'), if I put it on the variable where it is bound (e.g. '\(x :: T) - f x'), it wants me to turn on ScopedTypeVariables. I think ScopedTypeVariables is a nice extension and I'm sure it comes from a perfectly respectable family and all, but it feels like annotations on arguments comes in as a side-effect. 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? Now that I think of it, it seems inconsistent that 'x :: A - B; x a = ...' is valid, but 'x = \(a :: A) - (...) :: B' is not. Doesn't the former desugar to the latter? And what about getting ScopedTypeVariables into haskell prime? As far as I know everyone loves it, or at least no one actually hates it :) ___ 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] ScopedTypeVariables
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 wondered why I have to enable ScopedTypeVariables in those cases -- when I'm not turning it on to scope any type variables, but just to make annotations possible in more places. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tasty, a new testing framework
* 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 to see a comparison of the various test frameworks and why one might select one over another. I use hspec currently (which also integrates with HUnit, QuickCheck, etc.), and couldn't tell at a glance what tasty might offer. And I particularly dislike writing tests inside of a gigantic list; I much prefer the monadic style of hspec. This has been discussed on reddit here: http://www.reddit.com/r/haskell/comments/1jr8lb/tasty_a_new_testing_framework_successor_to/cbhiz40 Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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* intuition because Haskell has *trained* my intuition to see 'putStrLn Hi' as a pure value; it's not the thing itself that has effects, but its interpretation by an outer engine, just as my magnetic card key has by itself no power to open doors, but the magnetic reader that looks at the card _does_. I don't attribute agency to the card! I'm not arguing that my intuition is _right_, only that it is _different_. In particular, for anyone who has much experience with Haskell, return is almost the only name that could possibly be intuitive because that _is_ the name that is familiar. Haskell programmers who've got used to Applicative will also find pure intuitive, *because it is familiar*. 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). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
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 our daily life. The Haskell terms, say, 'return' and 'lift', on the other hand, do have usage in common English, so even a person with _no_ programming background would have acquired some unintentional 'intuition' by being familiar with them. And in that light, _for_me_, 'lift' is more _intuitive_ than 'return' or 'pure'. It seems, to me, like the thing being 'lifted' from a given world into a more 'abstract' world. Of course, I recall reading somewhere: a poet is a person who uses the different words to mean the same thing, while a mathematician is a person who ascribes more meanings to the same word. Haskell, being originated from _mathy_ people, we do get to _enjoy_ this effect. Having said this, it has actually helped me build a different type of 'intuition' for words and I do enjoy it. Thanks and regards, -Damodar Kulkarni On Wed, Aug 7, 2013 at 6:40 AM, Richard A. O'Keefe o...@cs.otago.ac.nzwrote: 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* intuition because Haskell has *trained* my intuition to see 'putStrLn Hi' as a pure value; it's not the thing itself that has effects, but its interpretation by an outer engine, just as my magnetic card key has by itself no power to open doors, but the magnetic reader that looks at the card _does_. I don't attribute agency to the card! I'm not arguing that my intuition is _right_, only that it is _different_. In particular, for anyone who has much experience with Haskell, return is almost the only name that could possibly be intuitive because that _is_ the name that is familiar. Haskell programmers who've got used to Applicative will also find pure intuitive, *because it is familiar*. 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). ___ 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] Alternative name for return
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 intuitive because obviously only the first 6 characters of an imported function are significant :) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Platform and Leksah on Windows
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 problems at http://dorinlazar.ro/haskell-platform-windows-crippled/ and I'm sure that we can work on fixing some of them. -- MM All we have to decide is what we do with the time that is given to us ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
