On 12/7/05, Robin Green
On Wednesday 07 December 2005 19:35, Tomasz Zielonka wrote:
On Tue, Dec 06, 2005 at 10:58:45PM +0300, Bulat Ziganshin wrote:
the third-priority problem is language itself. in particular, i hate Haskell school of imperative manipulations:
x' <- readIORef x y' <- readIORef y writeIORef z (x'*y')
Some day you may thank for this verbosity, because it encourages you do program in a purely functional way making your program more friendly for SMP execution.
You are mistaken. The verbosity is necessary if you want "visual" referential transparency, but not necessary if you only want pure functional programming. Only the latter is helpful for optimisability. I am hoping to write a paper on this topic.
I probably wouldn't mind some syntax along the lines of -- x,y :: IOref a x := y translated to v <- readIORef y writeIORef x y and -- x :: IOref a , y :: a x := y translated to writeIORef x y Of course it should carry over to STM (TVar) and ST etc. Maybe even allow the right-hand-side to have type "IO a" and make "Num a => IORef a" instances in Num to allow expressions like x := y + z Where x, y and z are IORefs or regular values. As long as the result of := (or any numeric operators involving IORefs) is always an IO computation it's still safe. It may make it harder for people to grasp the difference between an IORef and a regular value though... /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862