Difference between revisions of "Yhc/TMR"

From HaskellWiki
< Yhc
Jump to navigation Jump to search
m (May not be intended as a wiki page, but it's here and may as well follow the guidelines with respect to headings.)
Line 3: Line 3:
 
This is a draft of the Yhc TMR article, deadline April 13th. It isn't intended as a wiki article beyond the listed authors (although if you want to fix some spelling, we don't mind!). If you are interested in helping email the Yhc list.
 
This is a draft of the Yhc TMR article, deadline April 13th. It isn't intended as a wiki article beyond the listed authors (although if you want to fix some spelling, we don't mind!). If you are interested in helping email the Yhc list.
   
= The Beginning =
+
== The beginning ==
   
 
In the beginning there was the nhc compiler, which had a number of issues. We fixed some of them.
 
In the beginning there was the nhc compiler, which had a number of issues. We fixed some of them.
Line 13: Line 13:
 
Include the transition from CVS -> york Darcs -> haskell.org Darcs
 
Include the transition from CVS -> york Darcs -> haskell.org Darcs
   
= Portability Concerns =
+
== Portability concerns ==
   
 
From the beginning portability was a prime concern, while the original nhc was only running on Linux v old.old, and never Windows, Yhc was fully portable by design.
 
From the beginning portability was a prime concern, while the original nhc was only running on Linux v old.old, and never Windows, Yhc was fully portable by design.
Line 21: Line 21:
 
Why portability is such a concern, details of our ports system. Include our scons architecture, buildbot system etc. Mention that Yhc runs under Hugs, and indeed some of the developers use Hugs.
 
Why portability is such a concern, details of our ports system. Include our scons architecture, buildbot system etc. Mention that Yhc runs under Hugs, and indeed some of the developers use Hugs.
   
= Why the front end must die, Libraries for All =
+
= Why the front end must die: Libraries for All =
   
 
Lots of the nhc features are pure evil. We should rewrite them to move forward, making the compiler more compliant and more friendly for all. Libraries would be a good strategy.
 
Lots of the nhc features are pure evil. We should rewrite them to move forward, making the compiler more compliant and more friendly for all. Libraries would be a good strategy.
Line 29: Line 29:
 
Our thoughts on the future, kill the front end and turn everything into a library. Keep the compiler light weight,
 
Our thoughts on the future, kill the front end and turn everything into a library. Keep the compiler light weight,
   
= Yhc.Core =
+
== Yhc.Core ==
   
 
Yhc.Core is one area we have already moved into the library field, and its getting used quite a lot.
 
Yhc.Core is one area we have already moved into the library field, and its getting used quite a lot.
Line 92: Line 92:
   
   
= Javascript Backend =
+
== Javascript backend ==
   
 
The Javascript backend is a unique feature of Yhc, something which our light weight approach makes easier.
 
The Javascript backend is a unique feature of Yhc, something which our light weight approach makes easier.
Line 100: Line 100:
 
the ideas behind it, the Javascript FFI, browser compatability, the approach
 
the ideas behind it, the Javascript FFI, browser compatability, the approach
   
= Wacky Features =
+
== Wacky features ==
   
 
Yhc is going in many interesting directions. Some of these directions are likely to become very important in the future, some are likely to fade away. Yhc is a genuine research bed for brand new ideas.
 
Yhc is going in many interesting directions. Some of these directions are likely to become very important in the future, some are likely to fade away. Yhc is a genuine research bed for brand new ideas.
Line 108: Line 108:
 
When you don't spend all the time on wacky type systems, you get a lot more time left to work on Wacky other stuff. Include Java interpetter, .NET back end, Javascript back end, Python interpretter, Hat debugging, yhi-stack, whole program optimisation. Lots of these things are breeding grounds for various useful technologies, and most are marching towards genuine usefulness.
 
When you don't spend all the time on wacky type systems, you get a lot more time left to work on Wacky other stuff. Include Java interpetter, .NET back end, Javascript back end, Python interpretter, Hat debugging, yhi-stack, whole program optimisation. Lots of these things are breeding grounds for various useful technologies, and most are marching towards genuine usefulness.
   
= Acknowledgements =
+
== Acknowledgements ==
   
 
Thanks to everyone who has submitted a patch, become a buildbot, reported bugs or done anything else to benefit the Yhc project. We've put together a list of most of the people (if we've missed you, please shout, and we'll add your name in future versions of this document!)
 
Thanks to everyone who has submitted a patch, become a buildbot, reported bugs or done anything else to benefit the Yhc project. We've put together a list of most of the people (if we've missed you, please shout, and we'll add your name in future versions of this document!)

Revision as of 21:58, 23 February 2007

Authors: Neil Mitchell, Tom Shackell, Matt Naylor, Dimitry Golubovsky, Andrew Wilkinson

This is a draft of the Yhc TMR article, deadline April 13th. It isn't intended as a wiki article beyond the listed authors (although if you want to fix some spelling, we don't mind!). If you are interested in helping email the Yhc list.

The beginning

In the beginning there was the nhc compiler, which had a number of issues. We fixed some of them.

Author: Tom/Neil/Andrew

How we started up Yhc, this is the section that would have been in the History of Haskell paper if they had done a Yhc section :)

Include the transition from CVS -> york Darcs -> haskell.org Darcs

Portability concerns

From the beginning portability was a prime concern, while the original nhc was only running on Linux v old.old, and never Windows, Yhc was fully portable by design.

Author: Tom, Andrew

Why portability is such a concern, details of our ports system. Include our scons architecture, buildbot system etc. Mention that Yhc runs under Hugs, and indeed some of the developers use Hugs.

Why the front end must die: Libraries for All

Lots of the nhc features are pure evil. We should rewrite them to move forward, making the compiler more compliant and more friendly for all. Libraries would be a good strategy.

Author: Neil/Tom

Our thoughts on the future, kill the front end and turn everything into a library. Keep the compiler light weight,

Yhc.Core

Yhc.Core is one area we have already moved into the library field, and its getting used quite a lot.

Author: Neil (with bits from Matt, Dimitry)

Why Yhc.Core is so very important, a list of the projects that use it. Why Yhc Core is better than GHC Core - i.e. the only option left around.

Here is a simple Yhc.Core evaluator:

import System
import Yhc.Core

norm               :: CoreExpr -> CoreExpr
norm (CoreCon c)   =  CoreApp (CoreCon c) []
norm x             =  x

try              :: CoreExpr -> (CoreExpr, CoreExpr) -> [CoreExpr]
try e (pat, rhs) =  case (norm e, norm pat) of
                       (CoreApp (CoreCon f) as, CoreApp (CoreCon g) bs)
                         | f == g     -> [CoreLet (zip (vars bs) as) rhs]
                       (e, CoreVar v) -> [CoreLet [(v,e)] rhs]
                       (a,b)
                         | isCoreConst a && a == b -> [rhs]
                       _              -> []
  where
    vars         =  map fromCoreVar

match      :: CoreExpr -> [(CoreExpr, CoreExpr)] -> CoreExpr
match e as =  head (concatMap (try (norm e)) as)

hnf                             :: Core -> CoreExpr -> CoreExpr
hnf p (CoreCase e as)           =  hnf p (match (hnf p e) as)
hnf p (CoreLet ds e)            =  hnf p (replaceFreeVars ds e)
hnf p (CoreCon c)               =  CoreCon c
hnf p (CoreFun f)               =  hnf p (CoreLam bs body)
  where
    CoreFunc _ bs body          =  coreFunc p f
hnf p (CoreLam [] e)            =  hnf p e
hnf p (CoreApp (CoreCon c) as)  =  CoreApp (CoreCon c) as
hnf p (CoreApp f [])            =  hnf p f
hnf p (CoreApp f (a:as))        =
  case hnf p f of
    CoreLam [] e                -> hnf p (CoreApp e (a:as))
    CoreLam (b:bs) e            -> hnf p (CoreLet [(b,a)] (CoreApp
                                              (CoreLam bs e) as))
hnf p (CorePos _ e)             =  hnf p e
hnf p e                         =  e

nf     :: Core -> CoreExpr -> CoreExpr
nf p e =  case hnf p e of
            CoreCon c -> CoreCon c
            CoreApp (CoreCon c) es -> CoreApp (CoreCon c) (map (nf p) es)
            e -> e

main = do [filename] <- getArgs
          core <- loadCore filename
          let core' = removeRecursiveLet core
          print (nf core' (CoreFun "main"))


Javascript backend

The Javascript backend is a unique feature of Yhc, something which our light weight approach makes easier.

Author: Dimitry

the ideas behind it, the Javascript FFI, browser compatability, the approach

Wacky features

Yhc is going in many interesting directions. Some of these directions are likely to become very important in the future, some are likely to fade away. Yhc is a genuine research bed for brand new ideas.

Author: All

When you don't spend all the time on wacky type systems, you get a lot more time left to work on Wacky other stuff. Include Java interpetter, .NET back end, Javascript back end, Python interpretter, Hat debugging, yhi-stack, whole program optimisation. Lots of these things are breeding grounds for various useful technologies, and most are marching towards genuine usefulness.

Acknowledgements

Thanks to everyone who has submitted a patch, become a buildbot, reported bugs or done anything else to benefit the Yhc project. We've put together a list of most of the people (if we've missed you, please shout, and we'll add your name in future versions of this document!)

Andrew Wilkinson, Bernie Pope, Bob Davie, Brian Alliet, Christopher Lane Hinson, Dimitry Golubovsky, Gabor Greif, Goetz Isenmann, Isaac Dupree, Kartik Vaddadi, Krasimir Angelov, Malcolm Wallace, Michal Palka, Mike Dodds, Neil Mitchell, Robert Dockins, Samuel Bronson, Stefan O'Rear, Thorkil Naur, Tom Shackell