Issue 1055: Can value type inherit from Value Box type (obv-rtf) Source: (, ) Nature: Severity: Summary: Summary: 1) Can a Value type inherit from a Value Box type (the Value Box is described as been syntactic sugar for a Value type)? If so, what is the implicit name of the Value Box"s single data member? Resolution: Revised Text: Actions taken: March 13, 1998: received issue April 28, 1998: closed issue Discussion: End of Annotations:===== Return-Path: X-Sender: jeffm@visigenic.com Date: Fri, 13 Mar 1998 11:30:45 -0800 To: jeffm@visigenic.com From: "Jeff Mischkinsky" Subject: Re: More questions, cmments and clarifications on OMG Objects by Value spec Cc: , The following are some additional items concerning the 'Objects byValue' spec that I have accumulated while working on making the appropriate changes to our IDL compiler... Questions: ------------- 1) Can a Value type inherit from a Value Box type (the Value Box is described as been syntactic sugar for a Value type)? If so, what is the implicit name of the Value Box's single data member? Comments and/or requests for clarification: ----------------------------------------------------- 1) Section 5.4.2 'New lexical type - Keyword Identifier' the statement is made that "new keyword identifiers should only be added such that the resulting grammar is still easily parsable, e.g. is LALR(1).". It seems to me that is not true even for the newly introduced keyword identifiers in many cases. Consider the following: module foo { interface public { ... }; // The following are legal since the new keyword identifiers occur in a context interface custom { ... }; // which expects an identifier. interface custom { ... }; // which expects an identifier. value safe { ... }; value foo2: safe { ... }; // Is this legal or an error? value foo3: safe safe { ... }; // What about this? value foo4 { public x; // Is this legal or an error? public public y; // What about this? custom value(); // Is this a valid operation or a syntax error? }; }; There is room for several possible interpretations of these cases (and the many others like them), including ones that require the grammar to be non-LALR(1). I would appreciate further clarification as to how these cases are to be handled. 2) The new grammar rule: ::=3D ";" | ";" seems to open up another large hole for making the grammar non-LALR(1), which may or may not have been intentional. This becomes clear as you work your way back through the set of grammar rules. For example, according to the way I read the rules, the following is legal "new" IDL: module foo { value foo2 { struct foo3 { ...arbitrarilly long definition... }; =20 // The ';' finally tells us its a simple struct dcl=20 // (i.e. part of the -> -> -> rule) struct foo4 { ...arbitrarilly long definition... } x; // The identifier 'x' finally tells us its a state member // (i.e. part of the -> -> -> -> rule). }; }; There are quite a few similar (though different) cases like this. This is particularly messy for us, because our current parser uses recursive descent, and the inability to determine which rule to apply based on the next token makes the code extremely messy (prior to OBV, there were no such problems). My comment on this is that this problem could have been easily averted by changing the rule to: ::=3D ";" | ";" ::=3D "private" This (or similar rule change) would have made the grammar much simpler to parse. I hope I am do not seem to be too nitpicky, but these are real concerns and problems I've encountered while attempting to integrate the OBV syntax changes into our existing compiler. Any feedback and/or clarifications are appreciated. Jeff Mischkinsky email: jeffm@visigenic.com Senior Software Architect voice: +1(650)312-5158 Visigenic Software, Inc. fax: +1(650)286-2475 951 Mariner's Island Blvd. web: http://www.visigenic.com San Mateo, CA 94404 Return-Path: Date: Mon, 16 Mar 1998 15:08:12 +0000 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: "David C. Morrill" Cc: randyfox@austin.ibm.com, Jeff Mischkinsky , krochat@austin.ibm.com, issues@omg.org Subject: Re: More questions, cmments and clarifications on OMG Objects by Value spec References: <01bd4eaf$418dd760$1aa63509@dmorrill.austin.ibm.com> Dave, The intention was that value boxes have no inheritance (see section 5.3.3). This would mean there is no need to define an IDL name for the data member. We may have to tighten up the words in 5.3.3 to make this unambiguous. On keyword recognition, the "best" rule is to recognize a keyword identifier as its keyword whenever this is valid syntactically, and failing this, to recognize it as identifier wherever this is valid syntactically. One problem with this might be the amount of lookahead needed to decide. This rule would lead to the following: > value foo2: safe { ... }; // Is this legal or an error? legal syntactically, "safe" is identifier > value foo3: safe safe { ... }; // What about this? legal syntactically, second "safe" is identifier > value foo4 { > public x; // Is this legal or an error? legal syntactically, "public" is type name > public public y; // What about this? legal syntactically, second "public" is type name > custom value(); // Is this a valid operation or a syntax > error? valid operation returning type "custom" > }; If this is too hard to implement, a simpler rule would be to resolve the ambiguity with a fixed amount of lookahead. For example, with one token maximum lookahead, > custom value(); would be a syntax error because "custom" would be recognized as a keyword by looking ahead to "value" (only). Do you think the "best" rule is implementable? On your proposed change to require explicit private or public keywords, I think this is OK. It makes it easy for humans as well as compilers to see where the state members are, and it prevents people getting the wrong visibility because they did not realize which was the default. I will defer to Jeff on whether this change is appropriate for an RTF. These are good questions, and definitely not too nitpicky. We appreciate this thorough review from someone who has to implement our spec. Simon > David C. Morrill wrote: > > Gentlemen: > > The following are some additional items concerning the 'Objects by > Value' spec that I have accumulated while working on making the > appropriate changes to our IDL compiler... > > Questions: > ------------- > 1) Can a Value type inherit from a Value Box type (the Value Box is > described as been syntactic sugar for a Value type)? If so, what is > the implicit name of the Value Box's single data member? > > Comments and/or requests for clarification: > ----------------------------------------------------- > 1) Section 5.4.2 'New lexical type - Keyword Identifier' the > statement is made that "new keyword identifiers should only be added > such that the resulting grammar is still easily parsable, e.g. is > LALR(1).". It seems to me that is not true even for the > newly introduced keyword identifiers in many cases. Consider the > following: > > module foo { > interface public { ... }; // The following are legal since > the new keyword identifiers occur in a context > interface custom { ... }; // which expects an identifier. > value safe { ... }; > > value foo2: safe { ... }; // Is this legal or an error? > value foo3: safe safe { ... }; // What about this? > value foo4 { > public x; // Is this legal or an error? > public public y; // What about this? > custom value(); // Is this a valid operation or a syntax > error? > }; > }; > > There is room for several possible interpretations of these cases > (and the many others like them), including ones that require the > grammar to be non-LALR(1). I would appreciate further clarification > as to how these cases are to be handled. > > 2) The new grammar rule: > ::= > ";" > | ";" > seems to open up another large hole for making the grammar > non-LALR(1), which may or may not have been intentional. This > becomes clear as you work your way back through the set of grammar > rules. For example, according to the way I read the rules, the > following is legal "new" IDL: > > module foo { > value foo2 { > struct foo3 { ...arbitrarilly long definition... }; > // The ';' finally tells us its a simple struct dcl > // (i.e. part of the -> -> > -> rule) > struct foo4 { ...arbitrarilly long definition... } x; > // The identifier 'x' finally tells us its a state member > // (i.e. part of the -> -> > -> -> rule). > }; > }; > > There are quite a few similar (though different) cases like > this. This is particularly messy for us, because our current parser > uses recursive descent, and the inability to determine which rule to > apply based on the next token makes the code extremely > messy (prior to OBV, there were no such problems). > > My comment on this is that this problem could have been easily > averted by changing the rule to: > ::= > ";" > | ";" > ::= "private" > This (or similar rule change) would have made the grammar much > simpler to parse. > > I hope I am do not seem to be too nitpicky, but these are real > concerns and problems I've encountered while attempting to integrate > the OBV syntax changes into our existing compiler. > > Any feedback and/or clarifications are appreciated. > > David Morrill > Senior Software Engineer > IBM Corporation -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: To: nash@hursley.ibm.com cc: "David C. Morrill" , randyfox@austin.ibm.com, Jeff Mischkinsky , krochat@austin.ibm.com, issues@omg.org, crawley@dstc.edu.au Subject: Re: More questions, cmments and clarifications on OMG Objects by Value spec Date: Tue, 17 Mar 1998 10:51:46 +1000 From: Stephen Crawley On the subject of grammar Simon Nash wrote: > On keyword recognition, the "best" rule is to recognize a keyword > identifier as its keyword whenever this is valid syntactically, and > failing this, to recognize it as identifier wherever this is valid > syntactically. One problem with this might be the amount of > lookahead > needed to decide. [...] > If this is too hard to implement, a simpler rule would be to resolve > the ambiguity with a fixed amount of lookahead. [...] > Do you think the "best" rule is implementable? IMO, that is the wrong question. [If you can rigourously specify the syntax rules, then yes it is implementable. The implementation could be ugly ... ] The real question is would such a complex approach really be a good idea? In my opinion, the answer is clearly no: 1) They would be hard to implement correctly. There are already too many places where IDL compilers diverge from the standard. 2) They would result in confusion for the average writer / reader of IDL. The current CORBA IDL syntax is expressible as an LALR(1) grammar. I think that any IDL extensions should retain this property. I certainly don't want a grammar where "safe" can be either a keyword or an identifier depending on context! -- Steve Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 17 Mar 1998 11:05:22 +1000 (EST) From: Michi Henning To: Stephen Crawley cc: nash@hursley.ibm.com, "David C. Morrill" , randyfox@austin.ibm.com, Jeff Mischkinsky , krochat@austin.ibm.com, issues@omg.org Subject: Re: More questions, cmments and clarifications on OMG Objects by Value spec On Tue, 17 Mar 1998, Stephen Crawley wrote: > The current CORBA IDL syntax is expressible as an LALR(1) grammar. I think > that any IDL extensions should retain this property. I certainly don't > want a grammar where "safe" can be either a keyword or an identifier > depending on context! I agree completely. There is a precedent for that with PL/1, which allowed you to use keywords as identifiers, and then worked out from the context whether a keyword or an identifier was meant. People learned over time that the feature was a misfeature, because it could lead to extremely confusing code. In addition, as Steve points out, parsers get substantially more difficult to implement because they need to disambiguate the language. The upshot is that it doesn't make sense to put a lot more effort into implementing a parser just to support a feature that makes the language worse instead of better. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Mon, 16 Mar 1998 17:40:18 -0800 From: Jonathan Biggar To: Stephen Crawley CC: nash@hursley.ibm.com, "David C. Morrill" , randyfox@austin.ibm.com, Jeff Mischkinsky , krochat@austin.ibm.com, issues@omg.org Subject: Re: More questions, cmments and clarifications on OMG Objects by Value spec References: <199803170051.KAA00372@piglet.dstc.edu.au> Stephen Crawley wrote: > The current CORBA IDL syntax is expressible as an LALR(1) grammar. > I think > that any IDL extensions should retain this property. I certainly > don't > want a grammar where "safe" can be either a keyword or an identifier > depending on context! Perhaps it would be better to reverse the proposal? Instead, provide an "escape" sequence so that any keyword can be used as an identifier. This would provide a little less security for IDL being invalidated due to new keywords (because the IDL would have to be updated to add the escapes) but would not involve complicating the parser much at all. Even though you might have to fix the IDL to add an escape, you would only have to do it on rare occasions, and the application code would remain completely unchanged. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 16 Mar 1998 18:49:16 PST Sender: Bill Janssen From: Bill Janssen To: Stephen Crawley , Jonathan Biggar Subject: Re: More questions, cmments and clarifications on OMG Objects by Value spec CC: nash@hursley.ibm.com, "David C. Morrill" , randyfox@austin.ibm.com, Jeff Mischkinsky , krochat@austin.ibm.com, issues@omg.org References: <199803170051.KAA00372@piglet.dstc.edu.au> <350DD482.7673E505@floorboard.com> Excerpts from local.omg: 16-Mar-98 Re: More questions, cmments.. Jonathan Biggar@floorboa (862*) > Perhaps it would be better to reverse the proposal? Instead, provide an > "escape" sequence so that any keyword can be used as an identifier. This is what we do with ILU's ISL. The `escape sequence' is to quote the identifier. Bill Return-Path: X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: omg/issues To: Jonathan Biggar cc: Stephen Crawley , nash@hursley.ibm.com, "David C. Morrill" , randyfox@austin.ibm.com, Jeff Mischkinsky , krochat@austin.ibm.com, issues@omg.org Subject: Re: More questions, cmments and clarifications on OMG Objects by Value spec Date: Tue, 17 Mar 1998 13:23:22 +1000 From: Stephen Crawley > Stephen Crawley wrote: > > The current CORBA IDL syntax is expressible as an LALR(1) > grammar. I think > > that any IDL extensions should retain this property. I certainly > don't > > want a grammar where "safe" can be either a keyword or an > identifier > > depending on context! > > Perhaps it would be better to reverse the proposal? Instead, > provide an > "escape" sequence so that any keyword can be used as an identifier. > This would provide a little less security for IDL being invalidated > due > to new keywords (because the IDL would have to be updated to add the > escapes) but would not involve complicating the parser much at all. > > Even though you might have to fix the IDL to add an escape, you > would > only have to do it on rare occasions, and the application code would > remain completely unchanged. You could do that. Indeed, that's what the MODL language does. [MODL is DSTC's textual language for specifying MOF meta-models.] For example, if I want to declare a (meta-)attribute called "attribute" I can write: ... attribute long QUOTE "attribute"; ... The reason we decided to do this was that we could not restrict the names of MOF model elements to exclude keywords in a (non-standard!) meta-modeling language. [Furthermore, the adopted interpretation of the RFP requirement for alignment of MOF with UML meant that there had to be elements in the meta-model and the meta-meta-model with the same name!] --- However, IMO it would be a bad idea to implement this "hack" in IDL: 1) there is no precedent for this. After all the user is not currently not allowed to (say) define an interface called "Interface". 2) providing such a feature could conceivably make life complicated for language mappings and stubs generation. 3) it does not avoid the need for (a small number of) IDL files to be editted. All it means is that you have to change instances of ''safe'' used as an identifier to ''QUOTE "safe"'' instead of to ''something_else''. -- Steve Return-Path: Sender: jon@floorboard.com Date: Mon, 16 Mar 1998 19:30:48 -0800 From: Jonathan Biggar To: Stephen Crawley CC: nash@hursley.ibm.com, "David C. Morrill" , randyfox@austin.ibm.com, Jeff Mischkinsky , krochat@austin.ibm.com, issues@omg.org Subject: Re: More questions, cmments and clarifications on OMG Objects by Value spec References: <199803170323.NAA01692@piglet.dstc.edu.au> Stephen Crawley wrote: > 3) it does not avoid the need for (a small number of) IDL files to > be > editted. All it means is that you have to change instances of > ''safe'' used as an identifier to ''QUOTE "safe"'' instead of to > ''something_else''. Yes, but only the IDL would change, and none of the application code that depends on the IDL would have to change, because in the language mapping, the same identifier symbol would continue to be used. That is where the current pain of adding a new keywork to IDL is most visible. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org