Bulat Ziganshin wrote:
apfelmus wrote:
avoid the small layer of imperative code, of course. But the more you
treat imperative code as somewhat pure, the greater the danger that the
purely functional logic will be buried inside a mess of imperative code.
In other words, the goal is exactly to
Hello apfelmus,
Wednesday, August 8, 2007, 11:33:41 AM, you wrote:
it's point of view of theoretical purist. i consider Haskell as
language for real world apps and need to write imperative code appears
independently of our wishes. in paricular, it's required to write very
efficient code, to
Bulat Ziganshin wrote:
Hello apfelmus,
Saturday, August 4, 2007, 12:18:33 PM, you wrote:
Then, mytransaction reads
mytransaction = return foo `apT` xvar0 `apT` xvar1 `apT` ...
how about a+b*(c+d)?
That follows the same pattern,
return (+) `apT` a `apT`
(return (*)
On 4 Aug 2007, at 12:41 am, Mirko Rahn wrote:
rewrite *p++=*q++ in haskell?
it's one of C idioms. probably, you don't have enough C experience to
understand it :)
Maybe, but how can *you* understand it, when the standard is vague
about it?
It could be
A: *p=*q; p+=1; q+=1;
B:
On Fri Aug 3 06:06:31 EDT Neil Mitchell wrote:
What are the semantics of
do b f (- a)
where does the evaluation of a get lifted to?
I suggest the execution of (a) should be done immediately before the
action obtained by applying the monadic function whose argument it is
part of:
Sebastian Sylvan wrote:
Claus Reinke wrote:
mytransaction = do {
x0 - readTVar xvar0
x1 - readTVar xvar1
:
xn - readTVar xvarn
return $ foo x0 x1 .. xn
}
ah, a concrete example. but isn't that the typical use case for ap?
mytransaction = foo `liftM` r xvar0 `ap` r xvar1 ..
Hello apfelmus,
Saturday, August 4, 2007, 12:18:33 PM, you wrote:
Then, mytransaction reads
mytransaction = return foo `apT` xvar0 `apT` xvar1 `apT` ...
how about a+b*(c+d)?
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
can you give translation you mean? i don't have anything against
combinators, they just need to be easy to use, don't forcing me to
think where i should put one, as i don't think with lazy code and C
imperative code. and they shouldn't clatter the code, too. just try to
write complex expression
Hello Claus,
Saturday, August 4, 2007, 3:06:11 PM, you wrote:
can you give translation you mean? i don't have anything against
combinators, they just need to be easy to use, don't forcing me to
think where i should put one, as i don't think with lazy code and C
imperative code. and they
On Aug 4, 2007, at 11:19 , Bulat Ziganshin wrote:
and use it. want to assign a=b/(c+d)? nothing can be easier! just
define one more macro!
And? Everything above machine code is just macros at various
levels of abstraction, including all our favorite higher-level
abstractions.
--
Hello Brandon,
Saturday, August 4, 2007, 7:27:16 PM, you wrote:
On Aug 4, 2007, at 11:19 , Bulat Ziganshin wrote:
and use it. want to assign a=b/(c+d)? nothing can be easier! just
define one more macro!
And? Everything above machine code is just macros at various
levels of abstraction,
I think that defining lifted versions of every function is dangerous,
especially in a widely-used library. Monadic code will start to look
pure, and before long someone will be using let expressions and where
blocks to share monadic computations rather than using do blocks to
share the *results*
On Aug 4, 2007, at 11:48 , Bulat Ziganshin wrote:
Hello Brandon,
Saturday, August 4, 2007, 7:27:16 PM, you wrote:
On Aug 4, 2007, at 11:19 , Bulat Ziganshin wrote:
and use it. want to assign a=b/(c+d)? nothing can be easier! just
define one more macro!
And? Everything above machine
Hello Brandon,
Saturday, August 4, 2007, 8:44:46 PM, you wrote:
That would be why I'm using a language which lets me compose things
in complex ways. And just once, abstracting it away into a library,
which you seem to be missing.
and you hate 'do' syntax sugar?
--
Best regards,
Bulat
On Aug 4, 2007, at 14:51 , Bulat Ziganshin wrote:
Hello Brandon,
Saturday, August 4, 2007, 8:44:46 PM, you wrote:
That would be why I'm using a language which lets me compose things
in complex ways. And just once, abstracting it away into a library,
which you seem to be missing.
and you
| I've heard Simon (Peyton-Jones) twice now mention the desire to be able
| to embed a monadic subexpression into a monad. That would be
| http://article.gmane.org/gmane.comp.lang.haskell.prime/2267 and in the
| recent OSCON video.
|
| I still think that this syntax extension has profound
-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris
| Smith
| Sent: 03 August 2007 04:30
| To: haskell-cafe@haskell.org
| Subject: [Haskell-cafe] Re: monad subexpressions
|
| Neil Mitchell [EMAIL PROTECTED] wrote:
| I think this is a fantastic idea, please do so!
|
|
| Okay
Chris Smith wrote:
I've heard Simon (Peyton-Jones) twice now mention the desire to be able
to embed a monadic subexpression into a monad. That would be
http://article.gmane.org/gmane.comp.lang.haskell.prime/2267 and in the
recent OSCON video.
I still think that this syntax extension has
Hi
Perhaps we need to cool this thread down a little bit, and refocus. I
personally choose never to use ++ as anything but a statement, since
my brain works that way. Other people find different things natural,
so can pick what they choose. The one thing you can guarantee is that
discussing it
can you please rewrite *p++=*q++ in haskell?
assuming these operations
i :: V a - IO (V a) -- incr var addr, return old addr
r :: V a - IO a -- read var
w :: V a - a - IO () -- write var value
and this unfolded translation
do { qv - r q; w p qv; i p; i q }
assuming
Hi
Thinking on the semantic issue for the moment:
Can you use (-) outside of a do block?
b f (- a)
What are the semantics of
do b f (- a)
where does the evaluation of a get lifted to?
Given:
if (- a) then f (- b) else g (- c)
Do b and c both get monadic bindings regardless of a?
if (-
rewrite *p++=*q++ in haskell?
it's one of C idioms. probably, you don't have enough C experience to
understand it :)
Maybe, but how can *you* understand it, when the standard is vague about it?
It could be
A: *p=*q; p+=1; q+=1;
B: *p=*q; q+=1; p+=1;
C: tp=p; tq=q; p+=1; q+=1; *tp=*tq;
rewrite *p++=*q++ in haskell?
MR I always reject such codes when produced by my students. It is just
MR unreadable. I even do not understand what you are trying to achieve.
MR However, gcc seems it to compile to something like
MR *p = *(p+1) ; *q = *(q+1)
MR But for what is the '=' good for?
Hello Mirko,
Friday, August 3, 2007, 3:32:57 PM, you wrote:
rewrite *p++=*q++ in haskell?
I always reject such codes when produced by my students. It is just
unreadable.
it's one of C idioms. probably, you don't have enough C experience to
understand it :)
So rewriting it in Haskell (of
rewrite *p++=*q++ in haskell?
*p = *(p+1) ; *q = *(q+1)
If that's true then GCC has gone insane, because they are completely different.
Of course you are right, I just observed at the wrong place..., sorry
for that.
Though, as any C programmer knows, you really should be using
apfelmus [EMAIL PROTECTED] wrote:
I still think that this syntax extension has profound impact and is a
bad idea. Simon's and Neill's use case was the dreaded name-supply monad
where the order of effects really doesn't matter up to alpha-conversion.
The objection to that use case is that
Hello apfelmus,
Friday, August 3, 2007, 12:05:22 PM, you wrote:
I still think that this syntax extension has profound impact and is a
bad idea.
can you please rewrite *p++=*q++ in haskell?
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
rewrite *p++=*q++ in haskell?
I always reject such codes when produced by my students. It is just
unreadable. I even do not understand what you are trying to achieve.
However, gcc seems it to compile to something like
*p = *(p+1) ; *q = *(q+1)
But for what is the '=' good for?
So
* Bulat Ziganshin wrote:
Hello apfelmus,
I still think that this syntax extension has profound impact and is a
bad idea.
can you please rewrite *p++=*q++ in haskell?
p = q
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
rewrite *p++=*q++ in haskell?
MR I always reject such codes when produced by my students.
I don't think it's a good idea to reject working code.
MR I even do not understand what you are trying to achieve.
Well, that just means that your students are a bit smarter than you.
And I'd like to
Simon Peyton-Jones [EMAIL PROTECTED] wrote:
Furthermore there must be no lambda between the monadic splice and the do.
I'm curious about this.
One could sugar:
do tax - getTax
return $ map (\price - price * (1 + tax)) bill
into:
do return $ map (\price - price * (1 + (-
On 03/08/07, apfelmus [EMAIL PROTECTED] wrote:
Chris Smith wrote:
Also, I got so frustrated that I ended up abandoning some code
recently because STM is, in the end, so darn hard to use as a
result of this issue. I'd love to see this solved, and I'm quite
eager to do it.
This sounds
Claus Reinke [EMAIL PROTECTED] wrote:
to illustrate why some of us are concerned about this extension,
a few examples might help.
Claus, I've been saving your message in order to respond to it when I
have the time to look over it in detail. I don't think there will be
forthcoming answers
Hi
do { do { a; b}; c }
is still the same as
do { a; do { b; c } }
yes? no? perhaps? sometimes? how long did it take you?
I'm not entirely sure I understand the point here. The monad laws are
defined in terms of = and return. They have never had anything to do
with do,
mytransaction = do {
x0 - readTVar xvar0
x1 - readTVar xvar1
:
xn - readTVar xvarn
return $ foo x0 x1 .. xn
}
Versus
mytransaction = return $ foo $(readTVar xvar0) $(readTVar xvar1) ..
$(readTVar xvarn)
ah, a concrete example. but isn't that the typical use case for ap?
mytransaction =
On Fri, Aug 03, 2007 at 02:41:05PM +0200, Mirko Rahn wrote:
rewrite *p++=*q++ in haskell?
it's one of C idioms. probably, you don't have enough C experience to
understand it :)
Maybe, but how can *you* understand it, when the standard is vague about it?
It could be
A: *p=*q; p+=1;
On 8/3/07, Neil Mitchell [EMAIL PROTECTED] wrote:
This is how I understand it:
Can you use (-) outside of a do block?
b f (- a)
b do { ta -a; f ta }
or
b a = \ta - f ta
What are the semantics of
do b f (- a)
do b a = \ta - f ta
Given:
if (- a) then f (- b) else g (- c)
a = \ta -
Hello Chris,
Friday, August 3, 2007, 8:09:49 PM, you wrote:
foo = do b' - readTVar b
c' - readTVar c
d' - readTvar d
return (b' + c' / d')
It's true that order of effects *can* be important in monads like IO and
STM. It's also true, though, that probably 50% of
Chris Smith wrote:
I'm primarily interested in the two cases where one simply has no
choice about the use of monads: and those are IO and STM.
No, this is not purely functional programming then; but it has
some very compelling advantages to Haskell's implementation of
these, that I'm afraid
I'll dig for it later if you like. The essence of the matter was a
bunch of functions that looked something like this:
foo = do b' - readTVar b
c' - readTVar c
d' - readTvar d
return (b' + c' / d')
In other words, a string of readTVar statements, followed by one
On Friday 03 August 2007, Sebastian Sylvan wrote:
On 03/08/07, Claus Reinke [EMAIL PROTECTED] wrote:
ah, a concrete example. but isn't that the typical use case for ap?
mytransaction = foo `liftM` r xvar0 `ap` r xvar1 ..
where r = readTVar
I really find it difficult to articulate
much snipping
Also, note, if you use the operators in Control.Applicative, then:
return $ foo $(bar1) $(bar2) $(bar3) ...
can be:
return foo * bar1 * bar2 * bar3 ...
or:
foo $ bar1 * bar2 * bar3
I don't (personally) see how that's any more cryptic than placing brackets
On Fri, Aug 03, 2007 at 05:48:18PM -0700, Brandon Michael Moore wrote:
General purpose brackets are overkill here. I would really like a simple
monadic case. What's so bad about
caseM mexpr of
p1 - branch1
p2 - branch2
(mexpr = \e - case e of
p1 - branch1
p2 - branch2)
Hello apfelmus,
Saturday, August 4, 2007, 12:22:53 AM, you wrote:
avoid the small layer of imperative code, of course. But the more you
treat imperative code as somewhat pure, the greater the danger that the
purely functional logic will be buried inside a mess of imperative code.
In other
Hello Claus,
Friday, August 3, 2007, 7:29:32 PM, you wrote:
how about *Object.File.Line.CurPtr++ = *AnotherObject.File.Line.CurPtr++ ?
;)
what's the difference?-)
let p = Object.File.Line.CurPtr
let q = AnotherObject.File.Line.CurPtr
do { w p = r q; i p; i q }
back to the
On Thu, 2007-08-02 at 21:29 -0600, Chris Smith wrote:
Neil Mitchell [EMAIL PROTECTED] wrote:
I think this is a fantastic idea, please do so!
Okay, I'll do it then. If I have a good weekend, perhaps I'll volunteer
a talk at AngloHaskell after all! :)
So what about syntax? I agree
Neil Mitchell [EMAIL PROTECTED] wrote:
I think this is a fantastic idea, please do so!
Okay, I'll do it then. If I have a good weekend, perhaps I'll volunteer
a talk at AngloHaskell after all! :)
So what about syntax? I agree with your objections, so we've got
( - expr ) -- makes
47 matches
Mail list logo
