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 co
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
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:
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: *p=*q;
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`
(r
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 h
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 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 co
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*
Hello Claus,
Saturday, August 4, 2007, 7:55:18 PM, you wrote:
>>> so, there could be a library defining
>>
>>> lhs ==: rhs = putMVar <$> lhs <*> rhs
> the lifted operations combine as the unlifted ones do. so there's
> one definition each for =, /, +, not one definition for each of
> their
so, there could be a library defining
lhs ==: rhs = putMVar <$> lhs <*> rhs
ouch! since putMVar is already impure, there's a join missing:
lhs ==: rhs = putMVar <$> lhs <*> rhs
and in your application code, you could write
newEmptyMVar ==: putStrLn "hi there"
.. rant deleted
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 abst
Hi Claus,
> but the point is that you have a standard set of operations
> when working at that level, including conditionals, assignments,
> pointer increments, read/write, etc. you only need to define
> lifted variants of each of those operations *once*, in a library.
I think that defining lift
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.
--
bran
Hello Claus,
Saturday, August 4, 2007, 6:57:13 PM, you wrote:
> so, there could be a library defining
> lhs ==: rhs = putMVar <$> lhs <*> rhs
> and in your application code, you could write
> newEmptyMVar ==: putStrLn "hi there"
> (not that this would be useful;-)
it's great! how fools
i know that it may be trsanslated to everything including pure
assembler. what i'm missing in current Haskell is USEFUL SYNTAX for
these expressions. adding tons of liftM and ap can't make me happy
but the point is that you have a standard set of operations
when working at that level, including
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 th
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 us
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]
__
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`
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 }
bac
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
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
>
> 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
mytransaction = foo `liftM` r xvar0 `ap` r xvar1 ..
where r = readTVar
I really find it difficult to articulate why this isn't acceptable,
because it seems so obvious to me! It's short yes, but I really don't
think it's very clear...
if it is any consolation, i don't use that style myself
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 a
On 03/08/07, Claus Reinke <[EMAIL PROTECTED]> wrote:
> > mytransaction = do {
> > x0 <- readTVar xvar0
> > x1 <- readTVar xvar1
> > :
> > xn <- readTVar xvarn
> > return $ foo x0 x1 .. xn
> > }
> >
> > Versus
> >
> > mytransaction = return $ foo $(readTVar xvar0) $(readTVar xvar1) ..
> > $(rea
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
com
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 afr
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 probabl
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
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: *
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 anythi
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
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
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.
>
> Thi
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 +
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
can you please rewrite *p++=*q++ in haskell?
do { w p =<< r q; i p; i q }
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 }
Hello Claus,
Friday, August 3, 2007, 5:12:26 PM, you wrote:
>> can you please rewrite *p++=*q++ in haskell?
> do { w p =<< r q; i p; i q }
how about *Object.File.Line.CurPtr++ = *AnotherObject.File.Line.CurPtr++ ? ;)
> but whatever line-noise one prefers, this still seems a call for
> bett
Hello Mirko,
Friday, August 3, 2007, 4:41:05 PM, you wrote:
>> result is that currently C code rewritten in Haskell becomes much
>> larger and less readable.
> Larger should not be that issue and readability depends on the reader as
> your C example shows. Some Haskellers would very quickly reco
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
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 isn
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.
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
>> 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
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
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
memcp
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 rewriti
* 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
http://www.hask
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]
___
| > 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
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 ha
c.
Simon
| -Original Message-
| 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 thi
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?
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 s
57 matches
Mail list logo