63 lines
3.4 KiB
TeX
63 lines
3.4 KiB
TeX
\chapter{Future Work}
|
|
\label{chap:future_work}
|
|
\epigraph{Follow! But! follow only if ye be men of valor, for the entrance
|
|
to this cave is guarded by a creature so foul, so cruel that no man
|
|
yet has fought with it and lived! Bones of four fifty men lie strewn
|
|
about its lair. So, brave knights, if you do doubt your courage or
|
|
your strength, come no further, for death awaits you all with nasty
|
|
big pointy teeth.}{Monty Python}
|
|
|
|
This is going to look like a brain dump, despite any effort to make it
|
|
understandable by the Outside World.
|
|
|
|
\begin{description}
|
|
\item[Module import clean-up:] for historical reasons, some imports
|
|
might be completely useless now. Similarly, imports such as
|
|
|Debug.Trace| should disappear too ;
|
|
\item[Paka terms with real holes:] in Section~\ref{sec:il_paka_paka},
|
|
we have seen that Paka terms are ignoring most of their holes by
|
|
using hard-coded values ;
|
|
\item[More efficient redundant assignment optimizer:] in
|
|
Chapter~\ref{sec:il_paka_optimizer}, we have seen that the optimizer
|
|
is quite conservative, making it quite useless in practice ;
|
|
\item[Supporting function pointers:] preventing Filet-o-Fish users to
|
|
abuse function pointers is a violation to Geneva convention. I do
|
|
not think that there is some deep technical difficulty to get
|
|
that. But printing the type of such pointer was a first trouble, if
|
|
I remember correctly ;
|
|
\item[Implementing the interpreter in the Agda language:] this was
|
|
already one of my goal initially, but the NICTA people insisted that
|
|
without an in-theorem-prover semantics, the dependability argument is just
|
|
bullsh*t. Ha, these Australians\ldots ;
|
|
\item[Code generator back-back-end:] following the steps of FoF and
|
|
Paka, we need a more principled back-back-end, generating (correct)
|
|
out of |FoFCode| ;
|
|
\item[Hoopl-based optimization framework:] the
|
|
Hoopl~\cite{ramsey-hoopl} framework is a promising tool to implement
|
|
any kind of data-flow analysis and optimization. Instead of
|
|
developing our own crappy optimizer, we should use that stuff, when
|
|
the source is released. This is the reason why @IL.Paka.Optimizer@
|
|
is such a joke: it \emph{must} be dropped asap ;
|
|
\item[Translation validation infrastructure:] because we claim
|
|
dependability but our compiler is such a tricky mess, we need a good
|
|
bodyguard. Translation validation~\cite{necula-tvi} is an affordable
|
|
technique that tells you, when you run your compiler, if it has
|
|
barfed (and where), or not. If it has not failed, then you know for
|
|
sure that the generated code is correct ;
|
|
\item[More stringent syntactic tests:] it is very easy to build
|
|
ill-formed Filet-o-Fish terms, because the types of constructs have
|
|
not been engineered to ensure their invariants, and there is little
|
|
or no run-time checks. It is just a matter of putting more run-time
|
|
checks, a lot more ;
|
|
\item[Compiling to macros:] that's an interesting topic: we are able
|
|
to generate C code. We might need to generate C macro at some
|
|
point. How would that fit into Filet-o-Fish?
|
|
\item[Compiling with assertions:] assuming that Filet-o-Fish-generated
|
|
C code is correct, we are ensured that it must never failed at
|
|
run-time, except if it is provided with bogus input data. Being able
|
|
to specify what is a valid input data and translating that into
|
|
assertions might be useful. Similarly, when reading in an array, for
|
|
example, we probably want to ensure that we are not going out of
|
|
bounds, and an assert should fail if this is the case.
|
|
\end{description}
|