CAL/Multiverse STM Integration

7 views
Skip to first unread message

Tom Davies

unread,
Mar 7, 2010, 4:52:55 AM3/7/10
to CAL Language Discussion
I have recently integrated the Multiverse STM library with CAL,
providing a similar STM library to Haskell's.

I haven't written it up properly yet, but the code is here:
http://github.com/tgdavies/calverse for anyone who is interested.

Raoul Duke

unread,
Mar 8, 2010, 1:53:36 PM3/8/10
to cal_la...@googlegroups.com
On Sun, Mar 7, 2010 at 1:52 AM, Tom Davies <tgda...@gmail.com> wrote:
> I have recently integrated the Multiverse STM library with CAL,
> providing a similar STM library to Haskell's.

keen!

Luke

unread,
Mar 9, 2010, 7:42:37 PM3/9/10
to CAL Language Discussion
Thanks Tom.

STM has come up in conversation a bit here recently. I might take a
proper(!) look at this soon.

Tom Davies

unread,
Mar 9, 2010, 8:52:43 PM3/9/10
to CAL Language Discussion

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);

Luke

unread,
Mar 10, 2010, 5:18:05 PM3/10/10
to CAL Language Discussion
I probably won't get to this properly for a month or so, but we have
some documents for which we'd like to allow concurrent authoring
(think Google Docs).
Right now we're just looking at defining the document model itself and
getting the basics done, but when the time comes we'll see if STM will
be a useful tool for our purposes.

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.

Reply all
Reply to author
Forward
0 new messages