On Sun, Jul 11, 2010 at 4:06 PM, Brandon S Allbery KF8NH <
allb...@ece.cmu.edu> wrote:

> The whole point of the .net CLR is that the implementation (Windows
> COM, Mono, etc.) is hidden; you work with the CLR directly, *not* the
> implementation behind it.


True. At least for CLR code that only deals with more CLR code.


> hs-dotnet is binding to the
> CLR interfaces, *not* the implementation details that the CLR is designed
> to
> hide.


I trust you understand for haskell to access CLR it must make use of the FFI
native layer and that when I create a new C# class no haskell modules are
automatically created.

The CLR itself, of course, needs to link to other libraries supplying
> its implementation details,


Each implementation of the CLR is providing an API for calling into the CLR
from the outside. While calling out via p/invoke is platform independent
(the p/invoke api itself, there's no guarantee of a specific lib existing),
calling in is implementation specific. If a new CLR implementation was
written in javascript I wouldn't be too surprised if they didn't provide the
same header files as mono.


> but if that ever becomes visible at the level
> hs-dotnet is using then the CLR is completely useless.
>

Completely useless? The CLR was not created for interop but interop was
created because some of us don't target the CLR. C#, VB.Net, F#, P#,
IronPython, etc... can call each others code uniformly no matter who's
implementation/platform is be used. This is what the CLR is there for,
guaranteeing seem-less integration within not seem-less interop. The idea is
that with modern hardware it became practical to stop writing native code
and target either CLR or JVM but it was also solving previous language
integration issues of the 90's. COM was messy and verbose but it kinda
worked for getting OO code to work between any native language that
supported COM.

If there was a IronHaskell for example we too would benefit platform
independent code that just worked anywhere. Most of us are using GHC
however, which produces native code instead of common intermediate language
but we can access CLR through either hs-dotnet or Salsa. One of 2 things
must happen to use these with mono. Ideally each library would have a stage
in configuration that checked whether .Net exists or Mono exists and use the
appropriate headers and libs accordingly during the build stage. The other
option is less than ideal but it's advantage is that it requires no changes
to be applied to hs-dotnet: Provide the
libcom<http://linux.lsdev.sil.org/wiki/index.php/Libcom>to all non
windows machines that you intend to use hs-dotnet on.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to