Yhc/TMR: Difference between revisions
No edit summary |
Started putting a Javascript section |
||
Line 97: | Line 97: | ||
Author: Dimitry | Author: Dimitry | ||
<small>the ideas behind it, the Javascript FFI, browser compatability, the approach</small> | |||
The idea to write a converter from Haskell to Javascript has been floating around for a while [add links]. Many people expressed interest in such feature, but no practical implementation was visible. | The idea to write a converter from Haskell to Javascript has been floating around for a while [add links]. Many people expressed interest in such feature, but no practical implementation was visible. | ||
=== General concepts === | === General concepts === | ||
The Javascript backend converts a linked and optimized Yhc Core file into a piece of Javascript code to be embedded in a XHTML document. The Javascript code generator attempts to translate Core expressions to Javascript expressions one-to-one with minor optimizations on its own, taking advantage of Javascript capability to pass functions around as values. | |||
=== Integration with DOM === | === Integration with DOM === | ||
The Web Consortium provides OMG IDL files to describe the API to use with the Document Object Model (DOM). An utility was designed, based on HaskellDirect, to parse these files and convert them to set of Haskell modules. The way interface inheritance is reflected differs from the original HaskellDirect way: in HaskellDirect this was achieved by declaration of "nested" algebraic data types, while the Javascript backend utility takes advantage of Haskell typeclasses, representing DOM types with fantom types, and declaring them instances of appropriate class(es). | |||
=== Unicode support === | |||
Despite the fact that all modern Web browsers support Unicode, this is not the case with Javascript: no access to Unicode characters' properties is provided. In the same time it is impossible for a Haskell application running in a browser not to have access to such information. The approach used is the same as used in Hugs and GHC: the Unicode characters database file from Unicode Consortium was converted into a set of Javascript arrays, each array entry representing a range of character code values, or a case conversion rule for a range (for this implementation, Unicode support was limited to character category, and simple case conversions). First, a range is found by character code using binary search; then character category and case conversion distances (values to add to character core to convert between upper and lower cases) are retrieved from the range entry. The whole set of arrays adds about 70 kilobytes to the web page size, if embedded inside a <script> tag. | |||
Using the Core overlay technique, Haskell character functions (like <tt>toUpper</tt>, <tt>isAlpha</tt>, etc.) were hooked up to the Javascript implementations supporting Unicode. This did not result in considerable slowdowns, rather, some browsers even showed minor speedup in heavy functions like <tt>read::String -> Int</tt>. | |||
=== Browsers compatibility === | |||
Compatibility with major browsers such as Netscape/Mozilla/Firefox and Microsoft Internet Explorer, and also Opera was observed. Compatibility with Safari has not been reached so far. | |||
=== Future plan: Fudgets === | === Future plan: Fudgets === | ||
the | It is planned to port some portion of Fudgets, so it becomes possible to write Web applications using this library. Several experiments showed that the Stream Processors (SP), and some parts of Fudget Kernel layers worked within a Javascript application. More problems are expected with porting the toplevel widgets due to differences in many concepts between Web browser and X Window, for which the Fudgets library was originally developed. | ||
== Wacky features == | == Wacky features == |
Revision as of 16:12, 21 March 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
The idea to write a converter from Haskell to Javascript has been floating around for a while [add links]. Many people expressed interest in such feature, but no practical implementation was visible.
General concepts
The Javascript backend converts a linked and optimized Yhc Core file into a piece of Javascript code to be embedded in a XHTML document. The Javascript code generator attempts to translate Core expressions to Javascript expressions one-to-one with minor optimizations on its own, taking advantage of Javascript capability to pass functions around as values.
Integration with DOM
The Web Consortium provides OMG IDL files to describe the API to use with the Document Object Model (DOM). An utility was designed, based on HaskellDirect, to parse these files and convert them to set of Haskell modules. The way interface inheritance is reflected differs from the original HaskellDirect way: in HaskellDirect this was achieved by declaration of "nested" algebraic data types, while the Javascript backend utility takes advantage of Haskell typeclasses, representing DOM types with fantom types, and declaring them instances of appropriate class(es).
Unicode support
Despite the fact that all modern Web browsers support Unicode, this is not the case with Javascript: no access to Unicode characters' properties is provided. In the same time it is impossible for a Haskell application running in a browser not to have access to such information. The approach used is the same as used in Hugs and GHC: the Unicode characters database file from Unicode Consortium was converted into a set of Javascript arrays, each array entry representing a range of character code values, or a case conversion rule for a range (for this implementation, Unicode support was limited to character category, and simple case conversions). First, a range is found by character code using binary search; then character category and case conversion distances (values to add to character core to convert between upper and lower cases) are retrieved from the range entry. The whole set of arrays adds about 70 kilobytes to the web page size, if embedded inside a <script> tag.
Using the Core overlay technique, Haskell character functions (like toUpper, isAlpha, etc.) were hooked up to the Javascript implementations supporting Unicode. This did not result in considerable slowdowns, rather, some browsers even showed minor speedup in heavy functions like read::String -> Int.
Browsers compatibility
Compatibility with major browsers such as Netscape/Mozilla/Firefox and Microsoft Internet Explorer, and also Opera was observed. Compatibility with Safari has not been reached so far.
Future plan: Fudgets
It is planned to port some portion of Fudgets, so it becomes possible to write Web applications using this library. Several experiments showed that the Stream Processors (SP), and some parts of Fudget Kernel layers worked within a Javascript application. More problems are expected with porting the toplevel widgets due to differences in many concepts between Web browser and X Window, for which the Fudgets library was originally developed.
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