1. The Art of Avoiding Work
Haskell.NET
The Art of Avoiding Work
Oliver Hunt & Nigel Perry
University of Canterbury, New Zealand

2. Summary Introduction Background Prior Art Challenges & Solutions
Results
The Future
Questions

3. Introduction: What? Implementation of Haskell 98 on Rotor/.NET
Haskell is one of the worlds most popular functional programming languages.
How to compile Haskell for .NET is still a research problem
Can it be done “reasonably”?
Would IL changes provide “worthwhile” benefit:cost?
Reasonably = at appropriate performance/loss of functionality – interpretation would work for all of Glasgow Haskell but wouldn’t be reasonable. Worthwhile = is the cost of IL changes warranted, or do you just take a hit – B:C. IL changes of course require Rotor.

4. Introduction: Haskell
Well known
Used in industry and academia
Non-strict
Glasgow Haskell Compiler (GHC)
Provides intermediate-level output to support new backends
Extends Haskell 98 – providing future avenues of research

5. Introduction: Why?
Different language families are suited to different tasks
This adds a non-strict functional language to the languages available on .NET
To test the extent to which .NET can run many languages.
Primarily used by object oriented imperative languages.

6. Prior Art: Bridges
The functional language runs natively on the real machine
A software bridge is provided to the VM
Examples:
Lambada (Haskell for JVM)
Hugs.Net (Haskell for .NET)

7. Prior Art: New Languages
Designed to work on the VMs
Reduced features
Mixed compile/interpretive approaches
More OO-like type systems
Examples:
Pizza (JVM)
Strict
Introduced parametric polymorphism to JVM
Mondrian (.NET)
OO-like type system
Used a mixed compiled/interpretive approach
Targeted at scripting applications

8. Haskell 98 on .NET: Challenges
Non-strict evaluation
Functions as values
Partial evaluation/“currying”
Type switches

9. Challenge: Non-strict Evaluation
Mondrian: “External” non-strictness
Client must know
Manual evaluation
Interpretive-like
JIT Objects: “Internal” non-strictness
Non-strictness hidden from client
Automatic evaluation
Doesn’t support disjoint union types well
Disjoint union types central to Haskell 98…
JIT Objects was an earlier project that produced “non-strict C#” – actually a non-strict framework for any language to use but demonstrated using C#

10. Haskell.NET: Non-strict Evaluation
Use “Internal” non-strictness
Best for interworking
Primitive types
Follow JIT Objects
Optimise to use single class, rather than type/subtype combination
Auto conversion to/from values & boxed values
Function types
Use hidden nested subtype

11. Non-strict Evaluation (cont)
Disjoint union types
Type: abstract class
Alternatives: sub-classes
Discrimination:
use tag fields
Resolution:
“asX” methods rather than casting
Non-strictness
Hidden sub-class
Internal: evaluation hidden by tag/asX
Issues:
Casting only works for evaluated values
Not totally transparent
But disjoint unions not “standard” OO

12. Non-strict types
data List a = Cons a (List a) : Nil

13. Challenge: Functions as values
.NET provides delegates, which are “OO function pointers”
Unfortunately:
Relatively inefficient given the high usage in Haskell
Difficult to combine with non-strictness
Replace using a parametric function type
Provide conversions to/from delegates for inter-language working
Extends to support partial application
Might extend to support higher-rank types (Glasgow extension)

14. Challenge: Partial Evaluation
Calling a function omitting arguments, to create a new function, e.g.
Inc x = x+
Calling (inc 3) returns a function that adds 3 to its argument
We extend our previous function type
Instance fields used to store pre-supplied arguments

15. Challenge: Type Switches
Very slow in .NET
Must use a series of type checks/casts
These checks take account of subtypes
Addressed by the addition of an explicit tag enumerand to each type. I.e:
Effectively duplicate the hidden VM tag
Do exact, as opposed to subtype, matching

16. Status Compiler functional Performance? But incomplete…
Large %age of Haskell 98 language
Smaller %age of Haskell 98 libraries
Largely engineering, not research, left
Performance?
Primes Sieve (first 1000 primes)
GHC Native: 0.9s
GHC .NET: 1.5s

17. Future Work: Glasgow Haskell
Higher Rank Types
Passing generic functions as values
Partly supported now:
Wrap inside interface
Higher Kind Types
E.g. allow M<X> where both M & X are variable
How to do reasonably efficiently in .NET?
Fallback is reflection/runtime code generation…
Currently by-passed (e.g. hardwire Monad to IO)

18. Future Work: IL Changes?
Compared to “native” implementation:
More classes – adds VM load
Some extra indirections – a runtime cost
Virtual dispatch for tag checking
Etc.
Investigate if IL changes would:
Provide Haskell a good benefit:cost
Benefit other languages

19. Demo
It really does work…

20. Q & (maybe) A