On 26/04/2012 04:36 AM, Darren New wrote:
> On 4/25/2012 1:12, Invisible wrote:
>> You do all of that stuff from /outside/ your transactions, that's all.
>
> Except that .NET is about components, so that doesn't work out too well.
>
> And if you're talking about putting Haskell on .NET, then your entire
> program becomes one "transaction".

How so?

> (Note we've moved to talking about
> STM from talking about Haskell, which was not my intention. It was an
> analogy.)

OK. And I was just saying that Haskell /already/ lets you use libraries 
written in C, which aren't functional at all. I don't see why using the 
.NET libraries would be any harder. [Assuming you solve the problem of 
how to make your program run on the CLR in the first place, obviously.]

>> Remember, transactions are only for thread communication. You start a
>> transaction, fetch the next work item from the shared work queue, and the
>> transaction. Then you process the work item, calling whatever
>> libraries you need.
>
> And if the work item is in a class written that does I/O to obtain it,
> or to log a message, or etc etc etc?

I am really bad at typing, aren't I? :-S

What I /meant/ to write was that you start a transaction, fetch the next 
work item, and then end the transaction. Once the transaction is over, 
you can do as much I/O as you like.

The problem (I assume) that you're talking about is that all the 
existing .NET stuff is structured under the assumption that you can do 
I/O whenever you feel like it. I can see a few ways to approach that. 
(Perhaps the simplest possibility being "only Haskell is allows to use 
STM". :-P )

Post a reply to this message