|
Self modifying code, yeah!
Heh. Languages like Lisp and Forth are not only good
at generating code, from one angle, its the only way
to program them. The simple term structures that allow
for easy code generation also fail to provide enough
redundancy for human readers and static type checking.
More complex languages can be multi-staged, for example
MetaOcaml, but the result would seem to be that
such languages aren't useful: the annotation is just
too much to cope with.
Partial evaluators look much better to me: its basically
a multi-stage compiler where the 'staging' is detected automatically,
without annotations .. but all compilers do this anyhow,
under the name 'optimisation'. The big problem is you
have no idea what optimisations were actually done.
The two approaches (explicit annotation and no annotation) might
admit a useful middle ground. The idea is that you don't
tell the compiler how to optimise, nor what to optimise,
but you do provide annotations which specify *complexity*
requirements.
As an example, consider matrix multiplication which is O(N^3)
for unknown matrices. If one of the matricies is known to be
diagonal, its O(N^2). So if you could annotate:
matrix x = A * B : O(dim(A) ^ 2)
a partial evaluator could either optimise to O(N^2) or
report an error .. leaving you to figure out why its automated
reasoning failed to detect the optimisation.
This is a really crude idea as stated: more generically I guess
one might like to see a more 'type like' notion to write
the complexity notion with, since both are abstractions used
as constraints.
| 
Udell: Programs that write programs
