I haven't written it up properly yet, but the code is here:
http://github.com/tgdavies/calverse for anyone who is interested.
keen!
STM has come up in conversation a bit here recently. I might take a
proper(!) look at this soon.
On Mar 10, 11:42 am, Luke <luke.ev...@gmail.com> wrote:
> Thanks Tom.
>
> STM has come up in conversation a bit here recently. I might take a
> proper(!) look at this soon.
I'd be interested in your comments, Luke.
In particular, I've implemented an IO Monad -- which is not really the
CAL way.
And I wonder whether wrapSTM needs to be as complex as I've made it:
wrapSTM :: STM a -> CalFunction;
private wrapSTM !stm =
makeCalFunction
(\!tx -> let (_, a) = stm.STM.f $ unsafeCoerce tx;
in toStrictJObject a);
toStrictJObject :: a -> JObject;
toStrictJObject v = (outputCalValueStrict # toCalValue) (deepStrict id
v);
On the subject on monads, I've been using them rather more recently.
We have ported a larger cross section of Haskell libraries (including
monads) and of course they are a rather nice encapsulation device for
one's own code anyway. The basic set of monads defined in the current
CAL libraries can (currently) create a little bit of extra runtime
overhead if you care about super-fast runtime efficiency (and in a lot
of stuff we're doing we are so concerned), but there are other areas
where monads really work well.
Incidentally, I also have a port of arrows to CAL, but so far unlike
monads I have not really ventured to create new arrows. While
desugared 'do notation' works pretty well in CAL, the special arrows
comprehensions in Haskell don't unpack quite so nicely.