Issue 571:  Question about IDL grammar (orb_revision)
Source:  (, )
Nature:  Uncategorized
Severity: 
Summary: Summary: Is it a mistake, in IDL grammar as given in CORBA 2.0, revised July 1996, that <octet_type> is not one of <const_type>s?

Resolution:  subsumed by issue 725
Revised Text: 
Actions taken:
May 6, 1997: received issue
February 23, 1999: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <daemon>
Date: Tue, 6 May 1997 18:02:06 -0400
From: Richard Mark Soley <soley@omg.org>
cc: experts, issues, orb_revision, cindy
Subject: question about IDL grammar
Reply-to: soley@omg.org
Errors-to: soley_errors@omg.org
Errors-To: owner-orb_revision
Sender: owner-orb_revision
X-OMG: orb_revision
To: orb_revision

    Date: Mon, 5 May 1997 08:47:03 -0400
    Message-Id: <199705051247.IAA24447@emerald>
    To: soley@omg.org
    From: Dean Rosenzweig <dean@math.hr>
    Subject: question

    The question is: is it a mistake, in IDL grammar as given in Corba 2.0,
    revised July 1966, that <octet_type> is not one of <const_type>s?

    It seems to be used that way in IDL specification of module IOP, say

	const octet LOCATE_NEVER = 0;

    Thanks very much in advance.

Congratulations, you seem to have found a hole in the specification, which I
am forwarding with this note to the appropriate maintainers.

The solution I think is either to (1) fix the grammar to support octets in
constant declarations, as you say, or (2) clarify the constant declaration
coersion rules to allow (e.g.) the obvious 0->0.

Thaks very much for pointing out the problem.

	-- Richard Soley

Return-Path: <daemon>
X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs
Date: Wed, 7 May 1997 09:01:03 +1000 (EST)
From: Michi Henning <michi@dstc.edu.au>
cc: issues@omg.org, experts@omg.org, orb_revision@omg.org, cindy@omg.org
Subject: Re: question about IDL grammar
Errors-To: owner-issues
Sender: owner-issues
X-OMG: issues
To: issues

On Tue, 6 May 1997, Richard Mark Soley wrote:

>     It seems to be used that way in IDL specification of module IOP, say
> 
> 	const octet LOCATE_NEVER = 0;
> 
>     Thanks very much in advance.
> 
> Congratulations, you seem to have found a hole in the specification, which I
> am forwarding with this note to the appropriate maintainers.

On a related note, constant definitions of type enum are also illegal.
I can't really see a reason not to allow them. If we allow octets and
change the spec accordingly, why not allow enum constants as well?

							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: <daemon>
Date: Tue, 6 May 1997 17:46:38 PDT
From: Bill Janssen <janssen@parc.xerox.com>
Subject: Re: question about IDL grammar
CC: issues@omg.org, experts@omg.org, orb_revision@omg.org, cindy@omg.org
References: <Pine.OSF.3.95.970507085946.8138E-100000@foxtail.dstc.edu.au>
Errors-To: owner-orb_revision
Sender: owner-orb_revision
X-OMG: orb_revision
To: orb_revision

ILU allows constants for all kinds of integer types, all kinds of real
types, the octet type, the boolean type, any enumerated type, and `the'
string type.  It seems to work in practice (though enum constants are
troublesome).  I've got no problem with changing CORBA to be more like
ILU :-).

Bill

Return-Path: <daemon>
From: kukura@apollo.hp.com
Date: Wed, 7 May 1997 09:45:41 -0400
Cc: issues@omg.org, experts@omg.org, issues@omg.org, orb_revision@omg.org,
        cindy@omg.org
Subject: Re: question about IDL grammar
Errors-To: owner-orb_revision
Sender: owner-orb_revision
X-OMG: orb_revision
To: orb_revision

   Snarfer: $Revision: 1.1.2.9 $ $Date: 1992/11/13 23:40:23 $
   Date: Tue, 6 May 1997 18:02:06 -0400
   From: Richard Mark Soley <soley@omg.org>
   Cc: experts@omg.org, issues@omg.org, orb_revision@omg.org, cindy@omg.org
   Reply-To: soley@omg.org
   Errors-To: soley_errors@omg.org
   Errors-To: owner-issues@omg.org
   Sender: owner-issues@omg.org
   X-Omg: issues

       Date: Mon, 5 May 1997 08:47:03 -0400
       Message-Id: <199705051247.IAA24447@emerald>
       To: soley@omg.org
       From: Dean Rosenzweig <dean@math.hr>
       Subject: question

       The question is: is it a mistake, in IDL grammar as given in Corba 2.0,
       revised July 1966, that <octet_type> is not one of <const_type>s?

       It seems to be used that way in IDL specification of module IOP, say

	   const octet LOCATE_NEVER = 0;

       Thanks very much in advance.

   Congratulations, you seem to have found a hole in the specification, which I
   am forwarding with this note to the appropriate maintainers.

   The solution I think is either to (1) fix the grammar to support octets in
   constant declarations, as you say, or (2) clarify the constant declaration
   coersion rules to allow (e.g.) the obvious 0->0.

Interop revision 1.1 changed these const definitions to #defines, so
the IDL should now be legal.  I would cerainly support changing the
IDL grammer to allow const octets.

   Thaks very much for pointing out the problem.

	   -- Richard Soley

-Bob

-- 
Robert A. Kukura			Internet Technology Lab
email: kukura@apollo.hp.com		Hewlett-Packard Company
phone: 508-436-4512			300 Apollo Drive CHR-03-WR
fax:   508-436-5176			Chelmsford, MA 01824

Return-Path: <daemon>
Date: Wed, 07 May 1997 08:12:34 -0700
From: Paul H Kyzivat <noblent.noblenet.com!paulk@noblent.noblenet.com>
Organization: NobleNet
Cc: uunet!omg.org!issues@uunet.uu.net, uunet!omg.org!experts@uunet.uu.net,
        uunet!omg.org!orb_revision@uunet.uu.net
Subject: Re: question about IDL grammar
References: <Pine.OSF.3.95.970507085946.8138E-100000@foxtail.dstc.edu.au>
Errors-To: owner-orb_revision
Sender: owner-orb_revision
X-OMG: orb_revision
To: orb_revision

Michi Henning wrote:
> 
> On Tue, 6 May 1997, Richard Mark Soley wrote:
> 
> >     It seems to be used that way in IDL specification of module IOP, say
> >
> >       const octet LOCATE_NEVER = 0;
> >
> >     Thanks very much in advance.
> >
> > Congratulations, you seem to have found a hole in the specification, which I
> > am forwarding with this note to the appropriate maintainers.
> 
> On a related note, constant definitions of type enum are also illegal.
> I can't really see a reason not to allow them. If we allow octets and
> change the spec accordingly, why not allow enum constants as well?

And on yet another related note, octets are not currently allowed as a
switch type in unions. If it becomes possible to express constants of
type octet, then it makes sense to allow them as switch types too.

It is annoying that you can discriminate a union on a char but not on an
octet.
-- 
____________________________________________
Paul Kyzivat            508-460-8222 (Voice)
Software Architect      508-460-3456 (Fax)
NobleNet, Inc.          paulk@noblenet.com
http://www.noblenet.com


Return-Path: <michi@dstc.edu.au>
X-Authentication-Warning: tigger.dstc.edu.au: michi owned process
doing -bs
Date: Thu, 25 Jun 1998 09:31:26 +1000 (EST)
From: Michi Henning <michi@dstc.edu.au>
Reply-To: Michi Henning <michi@dstc.edu.au>
To: orb_revision@omg.org
Subject: Proposal for 571 and 725

On Wed, 24 Jun 1998, Jishnu Mukerji wrote:

> > > 571 and 725: Allowing octet type and enum values in const
declarations.
> > 
> > Would be nice, wouldn't it?  All we are missing is the proposal
text.
> 
> Any volunteers for this one?

The following changes add enum and octet constants to IDL:

Page 3-11, production 13:

Add

	<const_type> ::=
		     |   <octet_type>
		    
to the existing alternatives. There is no need to make a change
for enums here because <scoped_name> is already a legal alternative.
Similarly, we need not make a change to the productions for
<const_exp>,
because <primary_expr> already permits a <scoped_name> as the value
of a constant.

Page 3-18:

Add the same <octet_type> alternative to the production for
<const_type>.

Section 3.7.2, page 3-20:

Change the first sentence to read:

	The <scoped_name> in the <const_type> production must be a
	previously defined name of an <integer_type>, <char_type>,
	<wide_char_type>, <boolean_type>, <floating_pt_type>,
	<fixed_pt_const_type>, <string_type>, <wide_string_type>,
	<octet_type>, or <enum_type> constant.

[ While we are at it, there is a typo in <wide_ char_type> -- there is
  an extraneous space here that needs to be deleted. ]

End of section 3.7.2:

Add the following text to the end of the section:

	An octet constant can be defined using an integer literal
	or an integer constant expression, for example:

	const octet O1 = 0x1;
	const long L = 3;
	const octet O2 = 5 + L;

	Values for an octet constant outside the range 0 - 255 shall
	cause a compile-time error.

	An enum constant can be defined using a scoped name for the
	enumerator. The scoped name is resolved using the normal
	scope resolution rules (XREF). For example:

	enum Color { red, green, blue };
	const Color FAVOURITE_COLOR = red;

	module M {
		enum Size { small, medium, large };
	};
	const M::Size MYSIZE = M::medium;

If we accept this proposal, we also need to alert the language mapping
task forces to add the relevant mappings. I've checked the C++ mapping
(orbos/98-01-11) and it appears that no change is really required,
because
the mapping is obvious. The same may not be true for other languages
though.

							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: <javier@cnd.hp.com>
Date: Wed, 24 Jun 1998 18:23:10 -0600
From: Javier Lopez-Martin <javier@cnd.hp.com>
To: orb_revision@omg.org, michi@dstc.edu.au
Subject: Re: Proposal for 571 and 725
Content-Md5: b2kSiqQRwTYX1f6uHzLXRw==

Hi Michi, ORB-reviewers ...

I very much agree with this change.  I think it was about time ...

Anyhow, one small comment on your wording:

> Section 3.7.2, page 3-20:
> 
> Change the first sentence to read:
> 
>	The <scoped_name> in the <const_type> production must be a
>	previously defined name of an <integer_type>, <char_type>,
>	<wide_char_type>, <boolean_type>, <floating_pt_type>,
>	<fixed_pt_const_type>, <string_type>, <wide_string_type>,
>	<octet_type>, or <enum_type> constant.
> 
> End of section 3.7.2:

This, in my opinion, limits the use of <scoped_name> to that of
already
defined constants.  This should be expanded to allow for enum
literals,
that was the original intent.  I don't have the spec handy to craft
the appropriate wording, but could be something like (please modify as
needed):

	The <scoped_name> in the <const_type> production must be a
	previously defined name of an <integer_type>, <char_type>,
	<wide_char_type>, <boolean_type>, <floating_pt_type>,
	<fixed_pt_const_type>, <string_type>, <wide_string_type>,
	<octet_type>, or <enum_type> constant, or a previously
	defined name of an enum literal.

Javier Lopez-Martin
Hewlett-Packard Co
javier@cnd.hp.com

Return-Path: <michi@dstc.edu.au>
X-Authentication-Warning: tigger.dstc.edu.au: michi owned process
doing -bs
Date: Thu, 25 Jun 1998 11:06:35 +1000 (EST)
From: Michi Henning <michi@dstc.edu.au>
To: Javier Lopez-Martin <javier@cnd.hp.com>
cc: orb_revision@omg.org
Subject: Re: Proposal for 571 and 725

On Wed, 24 Jun 1998, Javier Lopez-Martin wrote:

> Hi Michi, ORB-reviewers ...
> 
> I very much agree with this change.  I think it was about time ...
> 
> Anyhow, one small comment on your wording:
> 
> > Section 3.7.2, page 3-20:
> > 
> > Change the first sentence to read:
> > 
> >	The <scoped_name> in the <const_type> production must be a
> >	previously defined name of an <integer_type>, <char_type>,
> >	<wide_char_type>, <boolean_type>, <floating_pt_type>,
> >	<fixed_pt_const_type>, <string_type>, <wide_string_type>,
> >	<octet_type>, or <enum_type> constant.
> > 
> > End of section 3.7.2:
> 
> This, in my opinion, limits the use of <scoped_name> to that of
> already
> defined constants.  This should be expanded to allow for enum
> literals,
> that was the original intent.  I don't have the spec handy to craft
> the appropriate wording, but could be something like (please modify
> as
> needed):
> 
>	The <scoped_name> in the <const_type> production must be a
>	previously defined name of an <integer_type>, <char_type>,
>	<wide_char_type>, <boolean_type>, <floating_pt_type>,
>	<fixed_pt_const_type>, <string_type>, <wide_string_type>,
>	<octet_type>, or <enum_type> constant, or a previously
>	defined name of an enum literal.

Javier, I don't think this is right. From the spec:

	(12)	<const_decl>  ::= "const" <const_type> <identifier>
"="
				  <const_exp>
	(13)	<const_type>  ::= <integer_type>
			      |   ...
			      |   <scoped_name>

With the wording you suggest, we would make the following legal:

	enum Color { red, green, blue };

	const red MYCOLOR = green;

The point is that <const_type> deals with the left-hand side of a
constant
declaration but the right-hand side is dealt with by <const_exp>. So
I think what I suggested is right.

							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: <javier@cnd.hp.com>
Date: Wed, 24 Jun 1998 19:44:04 -0600
From: Javier Lopez-Martin <javier@cnd.hp.com>
To: javier@cnd.hp.com, michi@dstc.edu.au
Subject: Re: Proposal for 571 and 725
Cc: orb_revision@omg.org
Content-Md5: gjoMnsHd33Ys0ebaTVcrdA==

Michi,

I hate it when you are right (specially if I am wrong) :-)

> On Wed, 24 Jun 1998, Javier Lopez-Martin wrote:
> 
> > Hi Michi, ORB-reviewers ...
> > 
> > I very much agree with this change.  I think it was about time ...
> > 
> > Anyhow, one small comment on your wording:
> > 
> > > Section 3.7.2, page 3-20:
> > > 
> > > Change the first sentence to read:
> > > 
> > >	The <scoped_name> in the <const_type> production must be a
> > >	previously defined name of an <integer_type>, <char_type>,
> > >	<wide_char_type>, <boolean_type>, <floating_pt_type>,
> > >	<fixed_pt_const_type>, <string_type>, <wide_string_type>,
> > >	<octet_type>, or <enum_type> constant.
> > > 
> > > End of section 3.7.2:
> > 
> > This, in my opinion, limits the use of <scoped_name> to that of
> already
> > defined constants.  This should be expanded to allow for enum
> literals,
> > that was the original intent.  I don't have the spec handy to
> craft
> > the appropriate wording, but could be something like (please
> modify as
> > needed):
> > 
> >	The <scoped_name> in the <const_type> production must be a
> >	previously defined name of an <integer_type>, <char_type>,
> >	<wide_char_type>, <boolean_type>, <floating_pt_type>,
> >	<fixed_pt_const_type>, <string_type>, <wide_string_type>,
> >	<octet_type>, or <enum_type> constant, or a previously
> >	defined name of an enum literal.
> 
> Javier, I don't think this is right. From the spec:
> 
>	(12)	<const_decl>  ::= "const" <const_type> <identifier>
> "="
>				  <const_exp>
>	(13)	<const_type>  ::= <integer_type>
>			      |   ...
>			      |   <scoped_name>
> 
> With the wording you suggest, we would make the following legal:
> 
>	enum Color { red, green, blue };
> 
>	const red MYCOLOR = green;
> 
> The point is that <const_type> deals with the left-hand side of a
> constant
> declaration but the right-hand side is dealt with by <const_exp>. So
> I think what I suggested is right.

Yeap, definitely my fault.  Your text was correct in the first place.

One question (I don't have the spec handy): does the production for
<const_exp> allow for <scoped_name>, and in case it does, is there any
wording restriction on it?  There is where my comment would apply.
Anyhow, in the example that Michi provides, it is clear how to do it,
but maybe there is some wording that needs updating ...

[You see, I'm just trying to save my face now ;-)]

Javier
Return-Path: <jis@fpk.hp.com>
Sender: jis@fpk.hp.com
Date: Mon, 29 Jun 1998 16:38:20 -0400
From: Jishnu Mukerji <jis@fpk.hp.com>
Organization: Hewlett-Packard New Jersey Laboratories
To: Michi Henning <michi@dstc.edu.au>
Cc: orb_revision@omg.org,
        Philippe Gautron <Philippe.Gautron@diapason.France.Sun.COM>
Subject: Re: Proposal for 571 and 725
References:
<Pine.OSF.3.96.980625085008.18939Q-100000@tigger.dstc.edu.au>

Michi Henning wrote:

> On Wed, 24 Jun 1998, Jishnu Mukerji wrote:
>
> > > > 571 and 725: Allowing octet type and enum values in const
declarations.
> > >
> > > Would be nice, wouldn't it?  All we are missing is the proposal
text.
> >
> > Any volunteers for this one?
>
> The following changes add enum and octet constants to IDL:
>
> Page 3-11, production 13:
>
> Add
>
>         <const_type> ::=
>                      |   <octet_type>
>
> to the existing alternatives. There is no need to make a change
> for enums here because <scoped_name> is already a legal alternative.
> Similarly, we need not make a change to the productions for
<const_exp>,
> because <primary_expr> already permits a <scoped_name> as the value
> of a constant.
>
> Page 3-18:
>
> Add the same <octet_type> alternative to the production for
> <const_type>.
>
> Section 3.7.2, page 3-20:
>
> Change the first sentence to read:
>
>         The <scoped_name> in the <const_type> production must be a
>         previously defined name of an <integer_type>, <char_type>,
>         <wide_char_type>, <boolean_type>, <floating_pt_type>,
>         <fixed_pt_const_type>, <string_type>, <wide_string_type>,
>         <octet_type>, or <enum_type> constant.
>
> [ While we are at it, there is a typo in <wide_ char_type> -- there
is
>   an extraneous space here that needs to be deleted. ]
>
> End of section 3.7.2:
>
> Add the following text to the end of the section:
>
>         An octet constant can be defined using an integer literal
>         or an integer constant expression, for example:
>
>         const octet O1 = 0x1;
>         const long L = 3;
>         const octet O2 = 5 + L;
>
>         Values for an octet constant outside the range 0 - 255 shall
>         cause a compile-time error.
>
>         An enum constant can be defined using a scoped name for the
>         enumerator. The scoped name is resolved using the normal
>         scope resolution rules (XREF). For example:
>
>         enum Color { red, green, blue };
>         const Color FAVOURITE_COLOR = red;
>
>         module M {
>                 enum Size { small, medium, large };
>         };
>         const M::Size MYSIZE = M::medium;
>
> If we accept this proposal, we also need to alert the language
mapping
> task forces to add the relevant mappings. I've checked the C++
mapping
> (orbos/98-01-11) and it appears that no change is really required,
because
> the mapping is obvious. The same may not be true for other languages
though.

Michi,

There appears to be a a couple of minor problems with this proposal as
Philippe
just pointed out to me. They are:

1. The grammar allows a <const_expr> as the right hand side in a
<const_decl>
which would seemingly allow things like:

    const M::Color FAV_COLOR = red & green; // 1

not a good thing since the coercion of the result to something of type
M::Color
is not at all obvious. Fixing this by tweaking the grammar seems like
a very
painful thing, since it is hard to distinguish an <expr> from a free
standing
<scoped_name>. So everything other than a single <scoped_name> will
have to be
disallowed on the RHS of (1) above using some other clever ploy?

2. We need to state a rule that the constant identifier on the RHS is
one of
those that are valid for the constant type on the LHS. So in>

    enum Color {red, green, blue};
    enum Taste {sweet, sour, bitter};

    const Color c = red;    // is OK but
    const Color d = bitter; // is not OKPlease let me know what your
thoughts are
on resolving this issue.

Thanks,

Jishnu.

Return-Path: <michi@dstc.edu.au>
X-Authentication-Warning: tigger.dstc.edu.au: michi owned process
doing -bs
Date: Tue, 30 Jun 1998 07:30:09 +1000 (EST)
From: Michi Henning <michi@dstc.edu.au>
To: Jishnu Mukerji <jis@fpk.hp.com>
cc: orb_revision@omg.org,
        Philippe Gautron <Philippe.Gautron@diapason.France.Sun.COM>
Subject: Re: Proposal for 571 and 725

On Mon, 29 Jun 1998, Jishnu Mukerji wrote:

> Michi Henning wrote:
> 
> > On Wed, 24 Jun 1998, Jishnu Mukerji wrote:
> >
> > > > > 571 and 725: Allowing octet type and enum values in const
> declarations.
> > > >
> > > > Would be nice, wouldn't it?  All we are missing is the
> proposal text.
> > >
> > > Any volunteers for this one?
> >
> > The following changes add enum and octet constants to IDL:
> >
> > Page 3-11, production 13:
> >
> > Add
> >
> >         <const_type> ::=
> >                      |   <octet_type>
> >
> > to the existing alternatives. There is no need to make a change
> > for enums here because <scoped_name> is already a legal
> alternative.
> > Similarly, we need not make a change to the productions for
> <const_exp>,
> > because <primary_expr> already permits a <scoped_name> as the
> value
> > of a constant.
> >
> > Page 3-18:
> >
> > Add the same <octet_type> alternative to the production for
> > <const_type>.
> >
> > Section 3.7.2, page 3-20:
> >
> > Change the first sentence to read:
> >
> >         The <scoped_name> in the <const_type> production must be a
> >         previously defined name of an <integer_type>, <char_type>,
> >         <wide_char_type>, <boolean_type>, <floating_pt_type>,
> >         <fixed_pt_const_type>, <string_type>, <wide_string_type>,
> >         <octet_type>, or <enum_type> constant.
> >
> > [ While we are at it, there is a typo in <wide_ char_type> --
> there is
> >   an extraneous space here that needs to be deleted. ]
> >
> > End of section 3.7.2:
> >
> > Add the following text to the end of the section:
> >
> >         An octet constant can be defined using an integer literal
> >         or an integer constant expression, for example:
> >
> >         const octet O1 = 0x1;
> >         const long L = 3;
> >         const octet O2 = 5 + L;
> >
> >         Values for an octet constant outside the range 0 - 255
> shall
> >         cause a compile-time error.
> >
> >         An enum constant can be defined using a scoped name for
> the
> >         enumerator. The scoped name is resolved using the normal
> >         scope resolution rules (XREF). For example:
> >
> >         enum Color { red, green, blue };
> >         const Color FAVOURITE_COLOR = red;
> >
> >         module M {
> >                 enum Size { small, medium, large };
> >         };
> >         const M::Size MYSIZE = M::medium;
> >
> > If we accept this proposal, we also need to alert the language
> mapping
> > task forces to add the relevant mappings. I've checked the C++
> mapping
> > (orbos/98-01-11) and it appears that no change is really required,
> because
> > the mapping is obvious. The same may not be true for other
> languages though.
> 
> Michi,
> 
> There appears to be a a couple of minor problems with this proposal
> as Philippe
> just pointed out to me. They are:
> 
> 1. The grammar allows a <const_expr> as the right hand side in a
> <const_decl>
> which would seemingly allow things like:
> 
>     const M::Color FAV_COLOR = red & green; // 1
> 
> not a good thing since the coercion of the result to something of
> type M::Color
> is not at all obvious. Fixing this by tweaking the grammar seems
> like a very
> painful thing, since it is hard to distinguish an <expr> from a free
> standing
> <scoped_name>. So everything other than a single <scoped_name> will
> have to be
> disallowed on the RHS of (1) above using some other clever ploy?

This is actually the case for all the other constant types as
well. For
example, the grammar allows non-sensical things like

	const float X = f1 & ~f2 / 5;

I simply followed the existing convention of restricting the
definition
as a semantic constraint:

> >         An enum constant can be defined using a scoped name for
the
> >         enumerator. The scoped name is resolved using the normal
> >         scope resolution rules (XREF). For example:

So, the above should make it clear that you have to have a scoped name
on the RHS. Although, we should tighten the above words more:

	"... can *only* be defined using a scoped name ..."

> 2. We need to state a rule that the constant identifier on the RHS
is one of
> those that are valid for the constant type on the LHS. So in>
> 
>     enum Color {red, green, blue};
>     enum Taste {sweet, sour, bitter};
> 
>     const Color c = red;    // is OK but
>     const Color d = bitter; // is not OKPlease let me know what your
thoughts are
> on resolving this issue.

Yes, you are right. I was slack here. How about appending the
following
to the words above:

	The constant name for the RHS of an enumerated constant
definition
	must denote one of the enumerators defined for the enumerated 
	type of the constant.

							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: <jis@fpk.hp.com>
Sender: jis@fpk.hp.com
Date: Wed, 01 Jul 1998 10:44:05 -0400
From: Jishnu Mukerji <jis@fpk.hp.com>
Organization: Hewlett-Packard New Jersey Laboratories
To: orb_revision@omg.org
Subject: [Fwd: Proposal for 571 and 725]

Attached below forwarded to the orb_revision list. Everybody, if you
want your comments to be taken into consideration in the discussion,
please send them to the orb_revision list, and not personally to me. I
just tabulate, consolidate and do final edits to produce documents
that
can be voted on.:-) The technical expretise (including mine) sits in
the
orb_revision list.:-)

Cheers,

Jishnu.

Received: from sneezy.fpk.hp.com by sleepy.fpk.hp.com with ESMTP
	(1.39.111.2/16.2+CNS 4.0 ) id AA026147368; Wed, 1 Jul 1998
08:49:28 -0400
Return-Path: <N.P.Sharman@man0506.wins.icl.co.uk>
Received: from atlrel1.hp.com by sneezy.fpk.hp.com with ESMTP
	(1.39.111.2/16.2+CNS 4.0 ) id AA250347367; Wed, 1 Jul 1998
08:49:27 -0400
Received: from bath.mail.pipex.net (bath.mail.pipex.net
[158.43.192.4])
	by atlrel1.hp.com (8.8.6/8.8.5tis) with SMTP id IAA14612
	for <jis@fpk.hp.com>; Wed, 1 Jul 1998 08:49:03 -0400 (EDT)
From: N.P.Sharman@man0506.wins.icl.co.uk
X400-Received: by mta bath.mail.pipex.net in
/PRMD=pipex/ADMD=pipex/C=gb/;
               Relayed; Wed, 1 Jul 1998 13:29:00 +0100
X400-Received: by mta fel01m2 in /PRMD=pipex/ADMD=pipex/C=gb/;
Relayed;
               Wed, 1 Jul 1998 13:28:04 +0100
X400-Received: by mta hls03 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed;
               Wed, 1 Jul 1998 13:35:21 +0100
X400-Received: by mta MAN05C1 in /PRMD=pipex/ADMD=pipex/C=gb/;
Relayed;
               Wed, 1 Jul 1998 13:27:13 +0100
X400-Received: by /PRMD=ICL/ADMD=GOLD 400/C=GB/; converted (ia5-text);
Relayed;
               Wed, 1 Jul 1998 13:27:32 +0100
Date: Wed, 1 Jul 1998 13:27:32 +0100
X400-Originator: N.P.Sharman@man0506.wins.icl.co.uk
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506
0000026100001077]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 1077
Alternate-Recipient: Allowed
Message-Id: <"1077*/I=NP/S=Sharman/OU=man0506/O=icl/PRMD=icl/ADMD=gold
400/C=GB/"@MHS>
To: jis@sleepy.fpk.hp.com
In-Reply-To: <3597FB3C.9C6D728F@fpk.hp.com>
References: <3597FB3C.9C6D728F@fpk.hp.com>
Subject: RE(2): Proposal for 571 and 725







Jishnu Mukerji wrote:

> Michi Henning wrote:
> 
> > On Wed, 24 Jun 1998, Jishnu Mukerji wrote:
> >
> > > > > 571 and 725: Allowing octet type and enum values in const 
declarations.
> > > >
> > > > Would be nice, wouldn't it?  All we are missing is the
> proposal text.
> > >
> > > Any volunteers for this one?
> >
> > The following changes add enum and octet constants to IDL:
> >
> > Page 3-11, production 13:
> >
> > Add
> >
> >         <const_type> ::=
> >                      |   <octet_type>
> >
> > to the existing alternatives. There is no need to make a change
> > for enums here because <scoped_name> is already a legal
> alternative.
> > Similarly, we need not make a change to the productions for
> <const_exp>,
> > because <primary_expr> already permits a <scoped_name> as the
> value
> > of a constant.
> >
> > Page 3-18:
> >
> > Add the same <octet_type> alternative to the production for
> > <const_type>.
> >
> > Section 3.7.2, page 3-20:
> >
> > Change the first sentence to read:
> >
> >         The <scoped_name> in the <const_type> production must be a
> >         previously defined name of an <integer_type>, <char_type>,
> >         <wide_char_type>, <boolean_type>, <floating_pt_type>,
> >         <fixed_pt_const_type>, <string_type>, <wide_string_type>,
> >         <octet_type>, or <enum_type> constant.
> >
> > [ While we are at it, there is a typo in <wide_ char_type> --
> there is
> >   an extraneous space here that needs to be deleted. ]
> >
> > End of section 3.7.2:
> >
> > Add the following text to the end of the section:
> >
> >         An octet constant can be defined using an integer literal
> >         or an integer constant expression, for example:
> >
> >         const octet O1 = 0x1;
> >         const long L = 3;
> >         const octet O2 = 5 + L;
> >
> >         Values for an octet constant outside the range 0 - 255
> shall
> >         cause a compile-time error.
> >
> >         An enum constant can be defined using a scoped name for
> the
> >         enumerator. The scoped name is resolved using the normal
> >         scope resolution rules (XREF). For example:
> >
> >         enum Color { red, green, blue };
> >         const Color FAVOURITE_COLOR = red;
> >
> >         module M {
> >                 enum Size { small, medium, large };
> >         };
> >         const M::Size MYSIZE = M::medium;
> >
> > If we accept this proposal, we also need to alert the language
> mapping
> > task forces to add the relevant mappings. I've checked the C++
> mapping
> > (orbos/98-01-11) and it appears that no change is really required,
> because
> > the mapping is obvious. The same may not be true for other
> languages 
though.
> 
> Michi,
> 
> There appears to be a a couple of minor problems with this proposal
> as 
Philippe
> just pointed out to me. They are:
> 
> 1. The grammar allows a <const_expr> as the right hand side in a 
<const_decl>
> which would seemingly allow things like:
> 
>     const M::Color FAV_COLOR = red & green; // 1
> 
> not a good thing since the coercion of the result to something of
> type 
M::Color
> is not at all obvious. Fixing this by tweaking the grammar seems
> like a very
> painful thing, since it is hard to distinguish an <expr> from a free
> 
standing
> <scoped_name>. So everything other than a single <scoped_name> will
> have to 
be
> disallowed on the RHS of (1) above using some other clever ploy?
>
A syntactic restriction on scoped names in expresssions would be a bad
> idea, 
since it would forbid things like:

    const unsigned long MAX_SEQ_LENGTH = 100;
    const unsigned long MAX_SEQ_INDEX = MAX_SEQ_LENGTH - 1;

I suggest that we extend the typing rules for constant expressions, to
regard 
each enumeration type as distinct from other enumeration types and
from the 
built-in integer types.  Then the rules could EITHER forbid
conversions 
between enumeration types and integer types altogether, OR allow
"widening" 
from an enumeration type to an integer type, but not vice-versa.

Adopting the stricter rule would mean that the expression "red &
green" would 
be illegal altogether; the weaker rule would give it an integer value
(zero, 
given the definition of Color below) but disallow the conversion back
to Color 
in the assignment.
  
> 2. We need to state a rule that the constant identifier on the RHS
is one of
> those that are valid for the constant type on the LHS. So in>
> 
>     enum Color {red, green, blue};
>     enum Taste {sweet, sour, bitter};
> 
>     const Color c = red;    // is OK but
>     const Color d = bitter; // is not OK
>
> Please let me know what your thoughts are on resolving this issue.
>
Either typing rule would allow the definition of "c" but forbid that
of "d",
because Color and Taste are distinct (even if bitter could be widened
to 2, it
could not be narrowed to Color).

To choose between the stricter and weaker rules, decide whether you
want to
tolerate things like:

    unsigned long NUMBER_OF_COLORS = blue + 1;

(goes wrong if I add another color!) 

> Thanks,
> 
> Jishnu.

Nick Sharman
ICL Object Software Laboratories