[Haskell-cafe] Learning Haskell

Sebastian Sylvan sebastian.sylvan at gmail.com
Wed Dec 7 14:53:48 EST 2005

On 12/7/05, Robin Green <greenrd at greenrd.org> wrote:
> 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


-- 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...


Sebastian Sylvan
UIN: 44640862

More information about the Haskell-Cafe mailing list