[capidl] Bug (?) in current grammar
Jonathan S. Shapiro
shap@eros-os.org
Tue, 18 Sep 2001 14:16:48 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_0185_01C1404C.8DCA44A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In addition to some minor semicolonic (sic) fixes that I haven't checked =
in yet, there is some behavior permitted by the current grammar that I =
think is ill-advised. Under the current grammar, it is legal to say
struct outer {
struct inner {
integer a;
};
};
That is, no distinction is made by the grammar between type declarations =
and member declarations. My concern is that in several languages =
(including C++), the declaration above is effectively:
struct foo { /* no members */ };
which creates problems -- especially w.r.t. inheritance -- because of =
the fact that it has zero size.
Unless there is a compelling reason to retain structs with no members, I =
would like to disallow this, either by a restriction in the grammar or a =
semantics check that the struct has child members after the closing =
curly.
If this is enforced in the grammar, which I would prefer, I propose we =
do so by requiring in the grammar that the *last* item in the struct be =
a member declaration. I am aware of no semantic rationale for permitting =
trailing nested structs, as these go out of scope immediately and can =
therefore never be used.
Oddly, the same issue does *not* arise in discriminated unions, because =
the discriminator itself takes space, and there are real cases in which =
the discriminator value is the totality of what needs to be transferred. =
Therefore, discriminated unions should not be required to have members =
for a given discriminator. For parallelism, however, a discriminated =
union case lacking members should likewise lack type definitions, as =
these cannot possibly be referenced in the absence of a member =
declaration.
Objections? Comments?
shap
------=_NextPart_000_0185_01C1404C.8DCA44A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>In addition to some minor semicolonic =
(sic) fixes=20
that I haven't checked in yet, there is some behavior permitted by the =
current=20
grammar that I think is ill-advised. Under the current grammar, it is =
legal to=20
say</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> struct outer =
{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
struct inner=20
{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
integer a;</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2> =20
};</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> };</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>That is, no distinction is made by the =
grammar=20
between type declarations and member declarations. My concern is that in =
several=20
languages (including C++), the declaration above is =
effectively:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> struct foo { /* no =
members */=20
};</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>which creates problems -- especially =
w.r.t.=20
inheritance -- because of the fact that it has zero size.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Unless there is a compelling reason to =
retain=20
structs with no members, I would like to disallow this, either by a =
restriction=20
in the grammar or a semantics check that the struct has child members =
after the=20
closing curly.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>If this is enforced in the grammar, =
which I would=20
prefer, I propose we do so by requiring in the grammar that the *last* =
item in=20
the struct be a member declaration. I am aware of no semantic rationale =
for=20
permitting trailing nested structs, as these go out of scope immediately =
and can=20
therefore never be used.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Oddly, the same issue does *not* arise =
in=20
discriminated unions, because the discriminator itself takes space, and =
there=20
are real cases in which the discriminator value is the totality of what =
needs to=20
be transferred. Therefore, discriminated unions should not be required =
to have=20
members for a given discriminator. </FONT><FONT face=3DArial =
size=3D2>For=20
parallelism, however, a discriminated union case lacking members should =
likewise=20
lack type definitions, as these cannot possibly be referenced in the =
absence of=20
a member declaration.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Objections? Comments?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>shap</FONT></DIV></BODY></HTML>
------=_NextPart_000_0185_01C1404C.8DCA44A0--