PageRenderTime 26ms CodeModel.GetById 19ms RepoModel.GetById 0ms app.codeStats 0ms

/report/future.tex

https://github.com/khskrede/mehh
LaTeX | 74 lines | 54 code | 20 blank | 0 comment | 0 complexity | 729d2fd59c8742b571de25c31f34a1ee MD5 | raw file
  1. \section{Future work}
  2. \subsection{Rewrite the deserializer to proper RPython}
  3. The deserializer is currently not written in proper RPython.
  4. Converting the code to RPython will allow it to be compiled to a JIT interpreter by
  5. the RPython toolchain. This should not be a very big task, but it requires understanding
  6. of the RPython coding style. There are also restrictions on how one may use the PyPy parser
  7. tools.
  8. \subsection{Implement basic Haskell libraries}
  9. Implementing Haskell libraries is necessary to run any Haskell program passed
  10. through GHC. One option may be to implement (or automatically generate from GHC code) Haskell
  11. primitive types, and to convert the Haskell base libraries to JSCore. Compiling GHC with the
  12. $-fext-core$ flag should be possible, and should generate
  13. External-core files for all library modules.
  14. \subsection{Linking functionality}
  15. Currently no thought has been given to the linking between multiple modules. This
  16. must be implemented for any non-trivial Haskell programs to function.
  17. \subsection{Test suite and benchmarking}
  18. A framework for testing and benchmarking should be set up. Allowing us to compare
  19. speed to other implementations, and progress of development. GHC uses a test framework
  20. relying on Python and GNU Make that should be looked into.
  21. \subsection{Optimize JIT compiler for Haskell-Python}
  22. Further optimization of the JIT compiler for the Haskell-Python interpreter will be
  23. necessary to achieve good speed.
  24. \begin{comment}
  25. \subsection{Map GHC encoded Types to Haskell-Python}
  26. Figure out how to create encoded types for Haskell-Python. It may be possible to
  27. autogenerate these from GHC files.
  28. "2.) understanding how GHC encodes types. The Core Haskell of the previous steps encodes the types of all functions in slightly low-level
  29. ways. This needs to be understood and a mapping of these types to what
  30. the Python Haskell interpreter provides needs to be written."
  31. \subsection{Set up GHC test environment for Haskell-Python}
  32. Setting up the GHC test environment for Haskell-Python would be very valuable
  33. for development and bug fixing.
  34. "3.) the actual interpretation of the Core language is mostly
  35. implemented. There are probably some things missing, which will be
  36. discovered by running some Haskell programs. For that end, it would be
  37. good to find out whether there is a Haskell implementation test suite
  38. and get it to run."
  39. \subsection{Add built in Haskell types to run some Haskell benchmarks}
  40. "4.) what is missing to run more non-pure Haskell programs are all the
  41. built-in functions (e.g. those that perform arithmetic, I/O, call C
  42. functions, etc) and built-in types (e.g. integers, floats, C-level types
  43. like arrays and structs). These should be added step by step. This is an
  44. essentially open-ended task. It would be good to add as many built-ins
  45. so that some of the Haskell benchmarks can run."
  46. \subsection{Optimize PyPy JIT for Haskell-Python}
  47. "5.) JIT work: While the JIT of PyPy can mostly be automatically applied,
  48. in practice a lot of careful work is needed to make sure that the
  49. generated code is optimal (or at least good). To do that, a test suite
  50. of Haskell snippets that explicitly compares the generated machine code
  51. with what it should look like is needed, and then the careful adding of
  52. some tests to this suite, together with the better placement of JIT
  53. hints. This is both the hardest step, as well as the most exciting one."
  54. \end{comment}