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 assembler future? :) so-called high-level languages started with the idea that you don't need to give explicit names to intermediate results
the problem with Haskell is that we need to split C expression into several statements and explicitly specify execution order even when we know that it doesn't matter. ideally, it should be possible to define
++x = modifyIORef x (+1) >> readIORef x *x = readIORef x
apart from the prefix symbols (i used one-letter prefix names), you can (as i'm sure you know). and the point of my little exercise was to show that instead of doing the splitting by hand at each usage site, we can write lifting combinators that do the splitting behind the scenes. what gives haskell aspirations to be a fine imperative language is that its abstraction mechanisms work as well for imperative code as for functional code.
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 using C and these combinators -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com