Re: A Compiler for Natural Language (transator that translates from natural language to C++)

DeltaOne wrote:
> I got very good response for the C++ intermediate representation. And
> thanks to all the experts. Now i need some help for one project I am
> doing as a part of my study. Well it may sound a bit off track but the
> idea is to desing a compiler that learns language like human learn. I
> am explaining my idea little bit. This compiler is a natural language
> system That is near to an expert system. The aim of the system is to
> convert natural language statements into C++ (or any other
> language,but we need to feed that language structure into this
> application). We train the compiler to the destination language to
> which it should compile. The input natural language will be a
> restricted NL. It will be a algorithmic language. Well its not
> possible to give the full design here. But the main aim of the
> language is to get a uniform interface for all kind of languages. The
> compiler learns the language to which it should translate and does the
> job. I am as of now planning to create and design a system that
> translates natural language to C++ form.
>
> Any help on this topic and ideas form all of the experts out there
> will be of great help for me. My first priority is to tranlate NL to
> C++ and I dont want any optimisation now.
...


Unlike your C++ IR question, I think you're not going to get as good a
response to this one. I'm not clear exactly what you're proposing,
but I think it's either pointless or hopeless.


If your target is a programming language, then it seems like your NL
input will be simply a one-to-one mapping of tokens into your C++
output. If so, that's just speech recognition. If your NL input is
much higher level, as in, "sort and collate the data, then print",
then the need to model semantics and plan recognition and plan
generation will open a rats nest of complexity. You do NOT want to go
there.


IMHO, our fearless moderator is right -- translation from high level
NL abstraction to meaningful C++ (or even native code) is hopeless
given today's state of the art in AI, and the translation from low
level NL to C++ such as "a equals b times c" is a job for a mere FSM
(e.g. Lex).


The history of a couple of relevant enterprises will illustrate the
difficulties inherent in high level NLP translation: Automatic
Programming and Machine Translation. Decades of effort have gone into
each, with precious little to show for it. MT has achieved some
practical success, but only because humans have laboriously and
manually edited the mapping of the source lexicon into the target in
order to build commercial MT applications (like SYSTRAN).
Unfortunately, the translation of programming directions into
instructions is harder still.


Finally, you will also find that there is no consensus that NL is even
context free, which has dire implications for implementing its
translation using an expert system. Yes, a context sensitive language
can be parsed/translated using a pushdown automaton as a CFG (since
real world grammars and sentences are finite), but the amount of work
involved in representing all possible NL grammatical constructions
using productions is WAY outside the bounds of practicality. Even
abstractions on productions like statistical parsing run into serious
limits, not to mention the inability to resolve ambiguity or achieve
real understanding of NL without employing a rich/deep knowledge base.


BTW, years ago I recall suggesting that the translation of natural and
programming languages might share technology. I was roundly disabused
of the notion by folks from both the compiler and NLP communities. It
wouldn't surprise me if never the twain shall meet.


        Randy
--
Randy Crawford http://www.ruf.rice.edu/~rand rand AT rice DOT edu
[I thought one of the few points of agreement in the NL community was
that natural languages are context sensitive. They gave up on CFGs,
which they call phrase structure grammars, around 1960. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.