How to get started with a new backend?

[Jason Dagit]

On Jan 28, 2013, at 3:21 AM, Simon Peyton-Jones <simonpj at microsoft.com> wrote:

> I would like to explore making a backend for .NET. I've done a lot of background reading about previous .NET and JVM attempts for Haskell. It seems like several folks have made significant progress in the past and, with the exception of UHC, I can't find any code around the internet from the previous efforts. I realize that in total it's a huge undertaking and codegen is only one of several significant hurdles to success.
>  
> Someone should start a wiki page about this!  It comes up regularly.  (That doesn’t mean it’s a bad idea; just that we should share wisdom on it.)  Maybe there is one, in which case perhaps it could be updated?
>  
> Some thoughts (which, if someone would like to transfer these to the wiki page, perhaps in more coherent form):
> 
> ·        Check out Frege.  Maybe others.  I think several folk are working on .NET or JVM projects.
> 
> ·        Do you want to inter-operate with .NET, or compile to .NET bytecode.  These are very different?  I’ll assume the latter.
> 

Yes, the latter.

> ·        Do you want to compile to verifiable .NET bytecode?  This is hard.  GHC’s type system is more expressive than .NET’s in many ways (higher kinded type variables, kind polymorphism...).  And less expressive in others (sub-typing). Compiling to verifiable bytecode would require lots of run-time type-tests (which we know will succeed) to reassure .NET that it’s all kosher.  Figuring out how to minimise these tests would be a challenge in itself.
> 

I'm okay with slow code. That's something I can improve later. :)

> ·        And of course this affects whether you can go via C#, since that requires the program to be well typed in the .NET sense.
> 

I'm not sure yet about going via C# or directly to CIL.
> ·        Do you want simply to run Haskell programs on .NET or do you want Haskell programs to call .NET libraries?  I assume the latter.  But that means that .NET types must be manifested somehow as Haskell types.   A big issue is how much of .NET’s type system you want to suck into Haskell.  A stressful example: can you define in Haskell a type that sub-classes an imported .NET type.
> 
> Daan and Mark and Sigbjorn and I wrote papers about this stuff. Look at the papers under "Foreign language integration" on http://research.microsoft.com/en-us/um/people/simonpj/papers/papers.html.  Oh, and this: http://research.microsoft.com/en-us/um/people/simonpj/papers/oo-haskell/index.htm
> 

Thanks. I'll make sure to read over those.

> ·        I’d be inclined to start from Core rather than STG, perhaps the output of CorePrep.  STG is a bit encrusted (though we’re about to simplify it a bit).  But honestly they are pretty similar.
> 
> Cmm would be a bad choice. It’s far too low level.
> 

Good to know.

> ·        Another major issues is that of primops (prelude/primops.txt.pp).  Things like add Int# or Float# are fine, but what about forking a thread, or throwing an exception? 
> 
> o   One possibility is to try to emulate them all.  I have no idea how hard that would be, but GHC’s I/O libraries rely heavily on lightweight concurrency.
> 
> o   Another is to trim the list of PrimOps, and only support some of them.  That’s easier, but you’d have to dump a lot of the ‘base’ package (particularly I/O) and re-implement it using the .NET libraries instead.
> 
> 

I think I will do whatever gets Fibonacci working first, and then reevaluate.

Thanks for the pointers.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20130128/e2cdc7d0/attachment.htm>