Haskell.NET

1
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
  benefitcost?

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
• Doesnt support disjoint union types well
• Disjoint union types central to Haskell 98

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
• 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 MltXgt 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 benefitcost
• Benefit other languages

19
Demo

• It really does work

20
Q (maybe) A