home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / sci / lang / 9028 < prev    next >
Encoding:
Text File  |  1993-01-28  |  3.0 KB  |  59 lines
  1. Newsgroups: sci.lang
  2. Path: sparky!uunet!bcstec!bronte!snake!rwojcik
  3. From: rwojcik@atc.boeing.com (Richard Wojcik,snake)
  4. Subject: Re: yacc like grammar of natural languages?
  5. Message-ID: <1993Jan26.173504.8147@atc.boeing.com>
  6. Sender: usenet@atc.boeing.com (For news)
  7. Reply-To: rwojcik@atc.boeing.com
  8. Organization: Research & Technology
  9. References: <hansg.728031611@risken>
  10. Date: Tue, 26 Jan 1993 17:35:04 GMT
  11. Lines: 46
  12.  
  13. In article 728031611@risken, hansg@risken.vd.volvo.se (Hans Granqvist) writes:
  14. >This may be a strange question, but having read in the latest issue of
  15. >BYTE about Machine Translation, I thought, why not express the source
  16. >language in yacc to resolve all ambiguities like "the can can be filled"
  17. >where "can" is noun or verb?
  18.  
  19. YACC, which stands for "Yet Another Compiler Compiler", can be used with LEX to
  20. create simple natural language front ends for programs, but it is extremely 
  21. limited when it comes to resolving ambiguities.  The reason that it works well
  22. for implementing artificial language compilers is that such languages, by design,
  23. contain ambiguities that can be resolved locally.  That is, you don't need to 
  24. resort to context or pragmatic knowledge to figure out which of the possible
  25. meanings are optimal.  For example, the Lisp expression (list list) uses the
  26. ambiguous symbol "list", but the compiler sees the first instance as a function
  27. name and the second as a variable name.  Word order alone resolves the ambiguity.
  28. Your example "the can can be filled" happens to contain an ambiguity of this sort,
  29. and that is why it looks like YACC can resolve it.  Unfortunately, natural language
  30. tends to prefer ambiguity of the following sort, which cannot be resolved by looking
  31. at local conditions in the sentence:  
  32.         "Mary saw that gas can explode."
  33.                            ^^^--verb or noun?
  34.  
  35. >I realise the enormity of such a scheme, but I would
  36. >very much like to know if anybody has produced such a front end for
  37. >an MT device.
  38.  
  39. Not for an MT device, but for a natural language command language.  At Boeing, we
  40. have a need to write machine-interpretable tests in English.  Implementations of
  41. such "English Test Languages" have been written in BASIC and YACC/LEX.  Our natural
  42. language group also converted our NL parser to read simple BNF rules, and I wrote
  43. a simple "semantic grammar" front end with just context free rules.  The reason that
  44. this works is that the test language is designed to be unambiguous.  It looks like
  45. English, but its expressions are as unambiguous as a programming language.  
  46.  
  47. MT is too difficult a problem for this kind of solution because the input text tends
  48. to be far less constrained.  One of the reasons that NLP researchers like to work
  49. with MT is that it forces you to do everything--language understanding and language
  50. generation.  Therefore, it is less tractable than activities such as NL front ends
  51. to data bases, grammar checking, etc.  YACC and LEX are not really suitable for MT
  52. applications.
  53.  
  54. -----
  55. Disclaimer:  Opinions expressed above are not those of my employer.
  56.  
  57.     Rick Wojcik   (rwojcik@boeing.com)   Seattle, WA
  58.  
  59.