>> OK. And I was just saying that Haskell /already/ lets you use libraries
>> written in C, which aren't functional at all.
>
> And can the C call back into the Haskell?

Yes. I demonstrated using the C sort() function to sort Haskell data, 
remember?

> And if so, are all the Haskell invariants and such maintained?

You have to tell the compiler whether or not you consider the C function 
to be "pure" or not. Obviously, you can lie. Don't do that.

> And can you do that without telling the
> caller whether they're calling C or compiled Haskell?

Does sort() know what it's calling?

>> 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.
>
> Right. But if "fetch the transaction" means "obtain it from the server
> over there using TCP/IP", then you're kind of screwed, aren't you?

Yeah. STM only works for stuff local to one machine.

Or rather, the implementations I've seen only work local to one machine. 
It's quite plausible you could extend it so that the transactional data 
you're mutating might be remote - but them it would be the STM engine 
sending network traffic, not you.

> Heck, even a regular expression match isn't functional in .NET.

Probably. In fact, I doubt much of the .NET libraries are. So you would 
probably end up using existing Haskell libraries for anything except 
actual I/O - the thing that .NET is good at.

>> 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 )
>
> And that's the kind of incompatibility I'm saying makes .NET much less
> useful.

Certainly it makes it less useful, yes. Whether it makes it "not worth 
it at all" is more open to debate.

Post a reply to this message