1 / 20

Haskell.NET

Haskell.NET. The Art of Avoiding Work. Oliver Hunt & Nigel Perry University of Canterbury, New Zealand. Summary. Introduction Background Prior Art Challenges & Solutions Results The Future Questions. Introduction: What?. Implementation of Haskell 98 on Rotor/.NET

normandy-robin
Download Presentation

Haskell.NET

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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” benefit:cost?

  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…

  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 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

More Related