🚀 go-pugleaf

In article 728031611@risken, hansg@risken.vd.volvo.se (Hans Granqvist) writes:
>This may be a strange question, but having read in the latest issue of
>BYTE about Machine Translation, I thought, why not express the source
>language in yacc to resolve all ambiguities like "the can can be filled"
>where "can" is noun or verb?

YACC, which stands for "Yet Another Compiler Compiler", can be used with LEX to
create simple natural language front ends for programs, but it is extremely 
limited when it comes to resolving ambiguities.  The reason that it works well
for implementing artificial language compilers is that such languages, by design,
contain ambiguities that can be resolved locally.  That is, you don't need to 
resort to context or pragmatic knowledge to figure out which of the possible
meanings are optimal.  For example, the Lisp expression (list list) uses the
ambiguous symbol "list", but the compiler sees the first instance as a function
name and the second as a variable name.  Word order alone resolves the ambiguity.
Your example "the can can be filled" happens to contain an ambiguity of this sort,
and that is why it looks like YACC can resolve it.  Unfortunately, natural language
tends to prefer ambiguity of the following sort, which cannot be resolved by looking
at local conditions in the sentence:  
		"Mary saw that gas can explode."
		                   ^^^--verb or noun?

>I realise the enormity of such a scheme, but I would
>very much like to know if anybody has produced such a front end for
>an MT device.

Not for an MT device, but for a natural language command language.  At Boeing, we
have a need to write machine-interpretable tests in English.  Implementations of
such "English Test Languages" have been written in BASIC and YACC/LEX.  Our natural
language group also converted our NL parser to read simple BNF rules, and I wrote
a simple "semantic grammar" front end with just context free rules.  The reason that
this works is that the test language is designed to be unambiguous.  It looks like
English, but its expressions are as unambiguous as a programming language.  

MT is too difficult a problem for this kind of solution because the input text tends
to be far less constrained.  One of the reasons that NLP researchers like to work
with MT is that it forces you to do everything--language understanding and language
generation.  Therefore, it is less tractable than activities such as NL front ends
to data bases, grammar checking, etc.  YACC and LEX are not really suitable for MT
applications.

-----
Disclaimer:  Opinions expressed above are not those of my employer.

    Rick Wojcik   (rwojcik@boeing.com)   Seattle, WA