John, It is true you can't know exact intention but that hasn't stopped computer scientists from trying to answer the question. For example, Joe Goguen's work on algebraic semiotics resulted in Joe developing a few basic rules for mapping information from one medium to another. Joe's first rule was "Wherever possible, preserve the structure of the content."
I could think of... and have thought of... a lot of techniques for automatically porting code (an extremely difficult problem, considering it covers correct live migration from an Intel to an adversarial AMD processor with possibly deliberately incompatible Instruction Set Architecture), including ways to automatically trade-off structure with other goals in a controlled fashion. One that Goguen was interested in was "content mixing" or "predictive modeling" - hot buzzwords before the AI Winter came and dried up lots of interesting funding. It is starting to re-emerge because of the multi-core kerfluffle, since it can achieve the sorts of "parallel-busyness" chipmaker's crave. I'd recommend Mark Turner's paper Forging Connections, which suggests some meaning belong to the mapping itself, rather the source-target approaches. In other words, we tend to construct meaning in a blend between the source and target. We don't just have mappings-as-meanings , but "forge" meaning *from* mapping. (I hope I explained that well.) On 4/9/11, John Nilsson <j...@milsson.nu> wrote: > 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 <alan.n...@yahoo.com> 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 > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
