Hello,
the following idea has been circulating in my mind quite
a bit. I'll put this to discussion on the sprint but you
may want to comment here on the list, too.
I think that we should generally use our (unit-) tests
in combination with our flexible upcoming interpreter
to gather type and other information at *runtime*. This
dynamically gathered information can later be used to
generate C, ObjC or other source code. Or for optimizations
debugging and whatnot.
So we wouldn't generate from a static Parse-Tree only
but almost always in combination with the runtime information
we gather during executing the tests. Thus we can use
the tests not only for producing a robust code base but for
generating code, specializations and optimizations
of all kinds. I hope that with this approach we can
avoid many "hints" which we might otherwise be inclined
to hardcode. Better invest the time in good tests.
For this to work we should have a scheme which makes
it easy to get from a unittests to its correlating
function/method/class/module and vice versa. Although
not strictly neccessary i'd like to be able to navigate
in both directions at runtime, also.
and-how-do-we-test-the-tests-ly y'rs,
holger