Issue 1310:  Keyword identifiers (01) (obv-rtf)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: 
 The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
 the concept of "keyword identifiers" in an effort to avoid breaking
 existing IDL specifications.
 1) First and foremost, the addition of keyword identifiers changes
 the IDL grammar into a context-sensitive grammar, which are known to
 be notoriously difficult to parse.

Resolution: 
Revised Text: 
Actions taken:
May 8, 1998: received issue
July 30, 1998: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <vinoski@iona.com>
X-Sender: vinoski@mail.boston.iona.ie
Date: Thu, 07 May 1998 17:44:17 -0400
To: obv-rtf@omg.org, issues@omg.org
From: Steve Vinoski <vinoski@iona.com>
Subject: let's lose keyword identifiers

The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications. It specifies that a keyword identifier
is a word that is treated as a keyword only when used in a keyword
context, and is otherwise treated as a regular identifier.

As a solution, keyword identifiers create a significant long-term
penalty in order to correct a short-term problem. They raise more
issues than they solve:

1) First and foremost, the addition of keyword identifiers changes
the IDL grammar into a context-sensitive grammar, which are known to
be notoriously difficult to parse. In fact, keyword identifiers
require any IDL compiler written using the yacc and lex
parser-generation tools to at best be significantly rewritten, and at
worst to be completely redesigned and reimplemented using recursive
descent or other parsing techniques. Given the common use of tools
like yacc and lex for parsing simple grammars like that of pre-OBV
IDL, requiring significant rework of all IDL compilers built on those
tools is an extremely high price to pay for an attempt to avoid
breaking a few existing IDL specifications in the short term.

A previous message to the obv-rtf list from Jeff Mischkinsky alluded
in several places to yacc and lex being "more powerful" than
recursive descent:

>We added these extensions to our parser quite easily. We actually use
a
>system that theoretically should be somewhat less powerfull than
>yacc/bison/lex because it is based upon a recursive descent parser
>generator. But it does let us annoate productions to say use a
lookahead
>of 2 instead of having to hand write production code that does this.
>
>Since yacc is theoretically more powerful, this may not be necessary.
>It is however not very difficult to add a small amount of action
>code to lex in order for it to tell if it is in a context where it
>should return the keyword, rather than an identifier for identifier
>keywords.

This hints that there shouldn't be any problem building parsers using
the "more powerful" yacc that can handle keyword identifiers, but
this is at best misleading. Yacc is designed to parse LALR(1)
grammars, but I believe that some of the examples shown below are
LALR(2) or worse, which yacc can't handle. The fact that the
designers of keyword identifiers do not know what types of grammars
yacc can handle is an indication of how poorly thought out this
design really is.