Dag Odenhall writes:
> I particularly like she's (her?) syntax for Alternative. Not sure
> whether or not Idris has that. Applicative tuples would be nice too,
> something like (|a,b,c|) translating to liftA3 (,,) a b c. And
> operators too, liftA2 (+) a b as (| a + b |)?
>
I patched she and did
If we're adding applicative brackets, it would be nice to have something
like ⦇⦈ as options via UnicodeSyntax. When playing around with She, I found
it much easier to read than the ASCII version, especially when I needed to
combine them:
(|(|a + b|) + (|c * d|)|)
⦇⦇a + b⦈ + ⦇c * d⦈⦈
Coinc
Simon Peyton-Jones writes:
> | Indeed, I wished the 0-ary case would be more alike to the unary
> | and binary case, cf.
> |
> | return f0
> | f1 <$> a1
> | f2 <$> a1 <*> a2
> |
> | What is needed is a nice syntax for "idiom brackets".
>
> Indeed. I'm quite open to adding idio
I particularly like she's (her?) syntax for Alternative. Not sure whether
or not Idris has that. Applicative tuples would be nice too, something like
(|a,b,c|) translating to liftA3 (,,) a b c. And operators too, liftA2 (+) a
b as (| a + b |)?
On Thu, Aug 15, 2013 at 11:08 AM, Erik Hesselink wrot
On Thu, Aug 15, 2013 at 5:39 AM, Jason Dagit wrote:
> Also, if anyone wants to look at prior art first, Idris supports applicative
> brackets.
As does she [0].
Erik
[0] https://personal.cis.strath.ac.uk/conor.mcbride/pub/she/idiom.html
___
Haskell-Ca
On Wed, Aug 14, 2013 at 7:54 PM, Simon Peyton-Jones
wrote:
> | Indeed, I wished the 0-ary case would be more alike to the unary and
> | binary case, cf.
> |
> | return f0
> | f1 <$> a1
> | f2 <$> a1 <*> a2
> |
> | What is needed is a nice syntax for "idiom brackets".
>
> Indeed. I'
| Indeed, I wished the 0-ary case would be more alike to the unary and
| binary case, cf.
|
| return f0
| f1 <$> a1
| f2 <$> a1 <*> a2
|
| What is needed is a nice syntax for "idiom brackets".
Indeed. I'm quite open to adding idiom brackets to GHC, if everyone can agree
on the
On 13/08/13 17:38, Andreas Abel wrote:
Indeed, I wished the 0-ary case would be more alike to the unary and binary
case, cf.
return f0
f1 <$> a1
f2 <$> a1 <*> a2
You could always write the above as
pure f0
pure f1 <*> a1
pure f2 <*> a1 <*> a2
Twan
_
On 06.08.2013 10:46, Adam Gundry wrote:
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
On Thu, Aug 8, 2013 at 7:40 AM, Timon Gehr wrote:
> You make the distinction between "evaluate",
>>
>
> Which essentially means applying reduction rules to an expression until
> the result is a value.
>
> and "execute" or "run", etc. This is not functional.
>>
>
> How would you know?
>
I thin
On Thu, Aug 08, 2013 at 01:19:27AM +0200, Jerzy Karczmarczuk wrote:
> Bardur Arantsson comments the comment of Joe Quinn:
> >>>On 8/7/2013 11:00 AM, David Thomas wrote:
> >twice :: IO () -> IO ()
> >twice x = x >> x
> >
> >I would call that evaluating x twice (incidentally creating
quoth Richard A. O'Keefe
> Check the OED. Most of its meaning are about _turning back_,
> _resuming_, _reverting_. Yielding or making a profit is not at
> all about "providing a value", but about money going out AND
> COMING BACK. It's the coming back part that makes it a "return".
Yes. Retur
On 8/08/2013, at 2:56 AM, Donn Cave wrote:
> The RFC822 headers of your email suggest that you use a Macintosh computer,
> so apart from the apparently disputable question of whether you're familiar
> with English, you have the same online dictionary as mine.
My department has an electronic subsc
On 08/08/2013 01:19 AM, Jerzy Karczmarczuk wrote:
Bardur Arantsson comments the comment of Joe Quinn:
>On 8/7/2013 11:00 AM, David Thomas wrote:
>>twice :: IO () -> IO ()
>>twice x = x >> x
>>
>>I would call that evaluating x twice (incidentally creating two
>>separate evaluations of one pure a
On 8/08/2013, at 2:09 AM, damodar kulkarni wrote:
> Thanks for pointing this out, I was not able to point my thoughts in this
> direction.
>
> But I still have a doubt: if my familiarity doesn't come in the form of some
> "analogy", then my acquired intuition about "it" would be of little use.
On 7/08/2013, at 9:17 PM, Jerzy Karczmarczuk wrote:
> I am the last here who would quarrel with Richard O'K., but I firmly believe
> that such reasoning is a Pandora box.
>
> The King, the government, the Pope, etc. have no power, only the
> interpretation of their decrees by "outer agents" _d
Bardur Arantsson comments the comment of Joe Quinn:
>On 8/7/2013 11:00 AM, David Thomas wrote:
>>twice :: IO () -> IO ()
>>twice x = x >> x
>>
>>I would call that evaluating x twice (incidentally creating two
>>separate evaluations of one pure action description), but I'd like to
>>better see yo
On 2013-08-07 22:38, Joe Quinn wrote:
> On 8/7/2013 11:00 AM, David Thomas wrote:
>> twice :: IO () -> IO ()
>> twice x = x >> x
>>
>> I would call that evaluating x twice (incidentally creating two
>> separate evaluations of one pure action description), but I'd like to
>> better see your perspect
On 8/7/2013 11:00 AM, David Thomas wrote:
twice :: IO () -> IO ()
twice x = x >> x
I would call that evaluating x twice (incidentally creating two
separate evaluations of one pure action description), but I'd like to
better see your perspective here.
x is only evaluated once, but /executed/
Return is all about providing a value *when used transitively*. When used
intransitively, it's about moving yourself. There's nothing about the
latter sense that implies providing a value.
Which is not to say Richard did not overstate the case - "return needn't
necessarily (in English) suggest p
> 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.
>
I'm sure there is a sense in which this is true, but I'm not seeing it.
How would you describe what's going on here?
twice :: IO () -> IO ()
quoth Richard A. O'Keefe,
...
> If you're familiar with *English* rather than, say, the C family of
> programming languages, "return" isn't _that_ bad, there is certainly
> nothing about the word that suggests providing a value.
The RFC822 headers of your email suggest that you use a Macintosh com
> "It is intuitive" has no other discernable meaning than "*I* am familiar
> with it, or something very much like it."
>
Thanks for pointing this out, I was not able to point my thoughts in this
direction.
But I still have a doubt: if my familiarity doesn't come in the form of
some "analogy", the
Fine reasoning.
Pure means incorruptible. It means that a pure result can be reused again
and again -like the gold or silver- while an impure result must be
re-created whenever it must be used. The metaphor is natural and I guess
that the use of pure (rather than referential transparent) is inform
One of the surprising things of Haskell is how little effort is done in
order to confer meaning to the names. That happens also in the case of the
mathematical language. Often they have a single letter. The reason is that
their meaning is completely defined by their signature and their
properties.
Richard A. O'Keefe :
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
On 7/08/2013, at 2:10 PM, damodar kulkarni wrote:
> 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
On Tue, Aug 6, 2013 at 9:10 PM, Richard A. O'Keefe wrote:
> 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
>
> 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
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 *m
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,
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 su
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 thi
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 6, 2013 at 4:03 AM, J. Stutterheim 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 ther
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
)
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"
> An: haskell-cafe@haskell.or
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 dis
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 g
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"
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 qu
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 Haskel
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 p
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
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?
>
> ___
> H
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
What about 'inject'?
On 6 August 2013 09:09, Karol Samborski wrote:
> What about 'pack'?
>
> Best,
> Karol
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
__
What about 'pack'?
Best,
Karol
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
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 `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,
Hi Tarik,
Could you motivate the choice for these names? Thanks!
On 6 Aug 2013, at 08:14, Tarik ÖZKANLI wrote:
> next, carry, feed, roll
>
>
>
> On 6 August 2013 08:37, KC wrote:
> I thought a pure value was being returned from the monad. :)
>
>
> On Mon, Aug 5, 2013 at 10:32 PM, Christia
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 p
next, carry, feed, roll
On 6 August 2013 08:37, KC 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 o
I thought a pure value was being returned from the monad. :)
On Mon, Aug 5, 2013 at 10:32 PM, Christian Sternagel
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 sometime
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 t
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
56 matches
Mail list logo
