[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
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
More information about the Haskell-Cafe
mailing list