On Saturday 12 January 2002 07:31, Ashley Yakeley wrote:
> At 2002-01-11 06:18, Jorge Adriano wrote:
> >The whole problem is with passing the 'r' as a parameter, which is
> > precisly what I'm trying to avoid.
>
> You could always pass it implicitly (using -fglasgow-exts):
Thanks, at first it see
At 2002-01-19 08:16, Marcin 'Qrczak' Kowalczyk wrote:
>Here is mine. The same code can work with MVars too, as long as the
>order of operations is consistent with the empty/full state. The
>empty/full state is real for MVars and imagined for IORef/STRef.
Could you simply the interface if you con
11 Jan 2002 17:10:16 -0500, Albert Lai <[EMAIL PROTECTED]> pisze:
> Now my grief is that I cannot write a subprogram with state
> variables and have it reused in ST and IO. Fortunately I can write
> a subprogram with mutable arrays and have it reused in ST and IO,
> so I can write "sort a given
> DIY? what does that means?
Do It Yourself. I.e. as in my tutorial.
> What if you want both and keep nice clean(*) programming style... :-)
You can compose monads. I've done something like the following in
the past (only with IO):
data StateTrans s a = StateTrans (s -> ST (s,a))
Here s is
At 2002-01-11 06:18, Jorge Adriano wrote:
>The whole problem is with passing the 'r' as a parameter, which is precisly
>what I'm trying to avoid.
You could always pass it implicitly (using -fglasgow-exts):
--
testfunc = do
r <- newSTRef ('x',0)
(do
foo
On Friday 11 January 2002 19:39, Jan-Willem Maessen wrote:
> The ST monad provides safer encapsulation of mutable references. We
> can prove that references which escape a particular instance of ST are
> never side effected. See the paper "Lazy Functional State Threads":
>
> http://www.cse.ogi
> DIY monads are good when: you fix the state variables, you don't want
> to mention them in subprogram parameters.
I've taken this solution for a fairly large piece of software.
One word of warning about DIY state monads, you have to be very carefull
about strictness and lazyness. If your monad
> I agree with you. My work-around is then to define foo and bar locally
> to testfunc, in the scope of r:
>
> testfunc = do
>r <- newSTRef ('x',0)
>let foo = do
> (c,n) <- readSTRef r
> writeSTRef r ('a', n+1)
>ba
> If I understand you correctly, you want global mutable variables, right?
> This is, I believe, only possible using IORef's and unsafePerformIO.
Kind of, I'm searching for the best approach to keep track of data in my
algorithms without constantly changing signatures.
State monad as defined in
Theodore Norvell <[EMAIL PROTECTED]> writes:
> Jorge's question raised a question in my mind. The IOExts
> module has many of the same features as the ST module, why
> are there two ways to do the same thing? Is the ST module
> only there for legacy purposes?
My user view is that I appreciate
> > testfunc = do
> >r <- newSTRef ('x',0)
> >foo r
> >bar r
> >(c,n) <- readSTRef r
> >return n
Jorge Adriano <[EMAIL PROTECTED]> writes:
> Yeap, I could do it like this myself :)
> The whole problem is with passing the 'r' as a parame
Hi,
> > testfunc = do
> >r <- newSTRef ('x',0)
> >foo r
> >bar r
> >(c,n) <- readSTRef r
> >return n
>
> Yeap, I could do it like this myself :)
> The whole problem is with passing the 'r' as a parameter, which is
precisly
> what I'm try
Theodore Norvell <[EMAIL PROTECTED]> asks:
> Jorge's question raised a question in my mind. The IOExts
> module has many of the same features as the ST module, why
> are there two ways to do the same thing? Is the ST module
> only there for legacy purposes?
The ST monad provides safer encapsula
Jorge's question raised a question in my mind. The IOExts
module has many of the same features as the ST module, why
are there two ways to do the same thing? Is the ST module
only there for legacy purposes?
Cheers,
Theo Norvell
___
Glasgow-haskell-
> Your example uses two state variables: a Char and an Int, paired up as
> a tuple. Below, I use one state variable of type (Char,Int) for that,
> as hinted by your first attempt at the translation. foo and bar will
> each need to take a parameter --- the reference to the state variable,
> due
Jorge Adriano <[EMAIL PROTECTED]> writes:
> Anyway, I was coding some simple GA, and as you probably know I need to use
> random values. The most elegant way I could think of was to generate some
[...]
> Monads! (right?)
Well, I suppose so. Generally speaking.
But, you might want to consid
I will just translate your example from Norvell's DIY state monad to
GHC's ST monad. As you noticed, GHC's ST monad begins with an "empty"
state and you use some commands to add state variables as you go.
This means the translation is not straightforward. I hope you still
get the gist of it.
Yo
ead what I needed to be able to use the IO Monad.
Seems to me like having a State Transformer monad its the best way to do it.
Now I've read a great deal of Richard Birds Book chap 10 (Monads), as well as
the "Monads for the Haskell Working Programmer"[1] by Theodore Norvell.
I was
18 matches
Mail list logo
