>>>> I very much doubt that C# lets you trivially call arbitrary machine
>>>> code.
>>>
>>> You would be mistaken. It's no harder in C# to call COM or C code than
>>> it is to do so from C++. Machine code? Well, you have to know the
>>> calling convention, but sure, you can do that.
>>
>> It's no harder to call C than to call Haskell, once you define where the
>> hell the function is and what arguments it's expecting. Your point?
>
> I'm not following. You said C# doesn't let you call machine code. I said
> it did.

No.

You said C# lets you call arbitrary machine code as easily as calling 
another C# function. I said it doesn't.

> And if Haskell tends to use things like lists extensively, or options,
> or something like that, then yeah, it can be hard to pass such things
> across computation boundaries, let alone lazy expressions.

You cannot pass arbitrary Haskell expressions to C. You can only pass 
primitive data types that C understands. (Things like int or long or 
void*.) If C needs to access Haskell stuff, you write Haskell functions 
that inspect the Haskell stuff and return something that C understands, 
and then have C call that.

> And of course
> if the C isn't actually a function in the functional sense, I'm not sure
> how Haskell handles it.

If the code you're trying to call has no observable side effects (e.g., 
sinh() or something) then you mark it as a pure function. If it /does/ 
have observable side-effects, then you mark it as an I/O action, and 
handle it the same way as any other I/O action. Really, it's not hard.

> For example, it's really not obvious how easy it
> would be to invoke a C function that takes as one of its arguments a
> pointer to a function.

Do you remember that time I used the C sort() function to work a Haskell 
data structure? Do you remember how I don't even know all that much 
about C, and yet it only took me about 20 minutes to figure it out?

Seriously, it's not "trivial". But it's pretty damned simple.

> Note I'm not bashing Haskell. I'm simply pointing out the assertion that
> Haskell does everything as well as every other language doesn't sound
> right to me.

And, as I keep pointing out, that isn't what I said. I said the core 
language design is simple and clean. I didn't say it has a library for 
every possible task. However, the language design itself doesn't rule 
out any particularly large possibilities, as far as I can tell.

>> JavaScript is a language invented for controlling web browsers. I
>> don't know of anything else that runs it.
>
> There are lots of other applications that have incorporated javascript.

Really?

> For example, MongoDB interprets javascript to decide how to do queries
> and build indexes.
>
> And have you not heard of node.js?

I've /heard of/ node.js; I have no idea what it /is/ though.

>>> Except that JS is dynamically-typed.
>> And Haskell can't manage dynamically-typed code.
>> Oh, wait. Yes it can.
>
> OK. Again, I didn't know that. I thought Haskell is statically typed.

Haskell is statically typed. But there's a library for doing stuff with 
dynamic types. Basically, it lets you convert any suitable value to a 
special "Dynamic" type. You can then later try to cast it back to 
something else, which succeeds iff that is actually the correct type. 
You know, the usual deal.

At worst, if you wanted to talk to something dynamic, you could just 
mark every single thing it touches is "type unknown" until you try to do 
something with it. It isn't that hard.

Post a reply to this message