Hello John,

Thanks for the pointers, I will indeed have a look at this.

I have a pet project of mine trying to create a platform and
prgramming model to handle this kind of problem. Such a simple thing
as keeping referential integritey between static Java code, the
embedded SQL and over to the dynamic databas is one of those
irritating problems I intend to address with this approach.

I enviosion a system with a meta-language and some standard
transformation to editor views, compilation stages and type-systems,
implemented in terms of this meta-language.

BR,
John

On Sun, Apr 10, 2011 at 4:38 AM, John Zabroski <[email protected]> wrote:
> 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 <[email protected]> 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 <[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
>>
>
> _______________________________________________
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
>

_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Reply via email to