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