2 All in all we are quite happy with
\SPLC{}. Our added syntactic sugar and the
3 higher order functions make our implementation of
\SPL{} quite comfortable to
4 program in. Due to the UNIX style interface it is quite easy to combine
5 usage of the compiler with
\SSM{}.
7 There are however of course a lot of things to can be improved. We discuss
9 the most interesting and most pressing issues. First of all error handling in
10 \SPLC{} can be greatly improved. Currently a lot of error happen at position
11 (
0,
0), most notably all type errors happen at this position. It would be a great
12 improvement in usability if errors would always be reported at the correct
13 position. A second issue is that in
\SPLC{} it is not possible to spread a
14 program over multiple modules, when developing larger programs this would be an
15 absolute requirement. Thirdly
\SPLC{} currently does not allow for multiple
16 recursion, and all functions need to be declared before they are called. It
17 would be nice to have multiple recursion and to not be forced to structure your
18 program in the order in which functions are called.
20 \subsection{Work division
}
22 \item [Lexing \& parsing
] : \\
25 \item [Lexing
] Mart \& Pim
26 \item [Parsing
] Mostly Mart, some Pim
27 \item [Sugar
] literal string: Mart, literal lists: Pim, Variable
28 arguments printing: Mart, Let-expansion: Pim, Lambdas: Pim
30 \item [Semantical analysis
] : \\
32 \item [Sanity checks
] Mart
33 \item [Type inference
] Mostly Pim, some Mart
34 \item [Lambda lifting
] Pim
36 \item [Code generation
] : \\
38 \item [RWST monad
] Mart
39 \item [Basic Generation
] Mart \& Pim
40 \item [Higher order functions
] Mart
43 %thoughts about compiler