I would think that it is generally impossible to automatically extract intentions from code. I run into this wall every day at work, I know _what_ the code is doing. But there is often little information as to _why_ it does what it does. It's not only due to the fact that the program is shaped by the idioms and constraints by the host language it is also the fact that the host language in general is a machine description language not a general problem statment language.
I guess you are referring to the first problem when you talk about expressibility. To address the second problem I'm thinking that you have to seperate the problem description, and solution from machine specifications. That is have a programming model where you create languages specifically to encode the problem, and then create an intepreter for the language to create machines solving it. BR, John On Sat, Apr 9, 2011 at 6:19 AM, Alan Kay <[email protected]> wrote: > In some of the other correspondence, the loss of expressibility through > translation is mentioned. UNCOL also had this problem. I think quite a bit > of work by an expert system has to be added to something like OMeta in order > to both retain expressibility, recover it, and generate it (when the target > is more expressive than the source). _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
