|
![](/i/fill.gif) |
On 8/26/2012 1:01, Orchid Win7 v1 wrote:
> On 26/08/2012 04:30 AM, Darren New wrote:
>> On 8/20/2012 1:31, Invisible wrote:
>>> You said C# lets you call arbitrary machine code as easily as calling
>>> another C# function. I said it doesn't.
>>
>> Assuming it uses one of the calling conventions that C# understands,
>> then yes, it does.
>
> And if some machine code has the same calling convention as Haskell, then
> it's trivial to call. Admittedly, no such code exists anywhere, because the
> Haskell calling convention is insanely complicated and changes every few
> years, but you see my point. :-P
I see your point. But you seem to be missing mine.
>
>>> 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.
>>
>> So it's hard to call across the boundaries there.
>
> Not so much "hard" as "non-trivial".
Well, yes. You have to restructure your Haskell code and basically re-write
it in C style in order to call it from C.
>>> 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.
>>
>> OK. Still a bit clunkier than C#. :-)
>
> What? C# doesn't ask you to write explicit upcasts and downcasts sometimes?
Not for dynamic variables. And almost never for regular C# values either.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
![](/i/fill.gif) |