But now you are adding some side conditions :)
For example, if you want comparable or even better abstractions in the target
language, then there is a lot more work that has to be done (and I don't know
of
a great system that has ever been able to do this well e.g. to go from an
understandable low level meaning to really nice code using the best
abstractions
of the target language). Maybe John Z knows?
Most schemes retain meaning but lose expressibility through translation, and it
is hard to get this back.
The FFI library problem is actually one of the problems discussed in the STEPS
proposal and project. Some possible solutions have been suggested (I think
several have real merit -- "semantic typing", matching of needs and resources,
etc.), but nothing substantive has been done). The larger problems will require
something like "negotiation" between modules (this idea goes back to some of
the
agent ideas at PARC, and was partially catalyzed by the AM and Eurisko work by
Doug Lenat).
I think it's time to revisit some of these ideas.
Cheers,
Alan
________________________________
From: Casey Ransberger <[email protected]>
To: Fundamentals of New Computing <[email protected]>
Sent: Fri, April 8, 2011 5:10:29 PM
Subject: Re: [fonc] Question about OMeta
So if I wanted to translate a Java application to C# (which ought to be pretty
trivial, given the similarity,) what would I do about the libraries? Or the
native interfaces?
It seems like a lot of the semantics of modern (read: industrial 60s/70s tech)
programs really live in libraries written in lower modes of abstraction, over
FFI interfaces, etc. I doubt it's as easy to translate this stuff as it is core
application code (plumbing, usually, which usually delivers the various
electronic effluvia between the libraries in use.)
I wonder what the folks here might suggest? Is there a fifth corner in the room
that I'm not turning?
I'd really like to be able to look at a program in the language of my
choosing... I just don't know how useful that is when I find out that #foo
happens to use an FFI over to something written in assembler and running on an
emulator. It sounds ridiculous, but I never run out of ridiculous in my way
doing this stuff for a living:)
I think about "rebuilding the world" in a way that keeps algorithms in a repo,
a
la Mathematica. Pure algorithms/functions, math really, seem to be easier in
some cases to compose than classes/inheritance/etc (am I wrong? I could be
wrong
here.)
I don't see a way to do anything like this without first burning the disk
packs,
which is a bummer, because if there was a really workable way to translate
large
applications, I know some folks with COBOL apps who might have interesting work
for me (I'm a sucker for old systems. It's like digging up an odd ceramic pot
in
the back yard and wondering who left it there, when, why. Technological
archeology and such. I'm also a sucker for shiny new technology like OMeta, so
I
picture gobs of fun.)
Fortunately I have some of the best people in the world hard at work on burning
my disk packs! Thanks VPRI:) Can't wait to dig into Frank and see what's there.
Huge fan of HyperCard, so I'm really pleased to see the direction it's taking.
On Apr 8, 2011, at 2:46 PM, Alan Kay <[email protected]> wrote:
It does that all the time. An easy way to do it is to make up a universal
semantics, perhaps in AST form, then write translators into and out of.
>
>Cheers,
>
>Alan
>
>
>
>
________________________________
From: Julian Leviston <[email protected]>
>To: Fundamentals of New Computing <[email protected]>
>Sent: Fri, April 8, 2011 7:24:28 AM
>Subject: [fonc] Question about OMeta
>
>I have a question about OMeta.
>
>Could it be used in any way to efficiently translate programs between
>languages?
>I've been thinking about this for a number of months now... and it strikes me
>that it should be possible...?
>
>Julian.
>_______________________________________________
>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
