CVS difference for ais/ai-00161.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-00161.txt

--- ais/ai-00161.txt	1999/02/28 01:42:58	1.5
+++ ais/ai-00161.txt	1999/03/01 19:15:23	1.6
@@ -283,3 +283,168 @@
 				Randy.
 
 ****************************************************************
+
+From: 	Pascal Leroy
+Sent: 	Monday, March 01, 1999 4:16 AM
+
+Yeah, I know someone would notice...
+
+The reason why I didn't structure the AI in this way is that I was under the
+impression that the stuff in !discussion was insufficiently rigorous for a
+!wording section.  But then you're right: having the wording depend on an
+undefined term is not too good.
+
+Pascal
+
+****************************************************************
+
+From: 	Pascal Leroy
+Sent: 	Monday, March 01, 1999 4:14 AM
+
+> In AI 161, you have proposed that entry-less protected
+> objects are not preelaborable.  This is a troublesome
+> change, as Shared_Passive packages are required to
+> be preelaborable, and entry-less protected objects are
+> the only means of synchronization available via a
+> Shared_Passive partition.
+
+This was a mistake.  My intent was _not_ to make them non-preelaborable.
+
+However, now that you have drawn my attention to this topic, I believe there
+is a specific problem with protected objects.  The private part of a protected
+object may include default expressions for components, and these default
+expressions may or may not be preelaborable.  We need to decide if we want to
+respect the privacy of the private part of protected objects.  If we do, it
+seems that the pragma should apply in this case too: i.e., in the absence of a
+pragma, the declaration of a protected object should be non-preelaborable; if
+on the other hand you use the pragma, then the private part must have
+preelaborable initialization.
+
+What do you think?
+
+> There seem to be two solutions.  One
+> is to allow stream attributes to be specified before the
+> type is fully defined.  The other is to allow them to be specified
+> in the private part.
+
+I hate to open private parts.  In our compiler, this is a real nightmare (we
+have to do that for pragma Convention, and that's already a big pain in the
+neck).
+
+So my preference would be to allow the specification of stream attributes
+before the type is fully defined.  Remember that we already have an AI that
+says that 13.1(10) does not apply to stream attributes.  This would just be
+another oddity with stream-oriented attributes.  (In fact I believe the
+stream-oriented attributes should not be considered a representation item,
+since they do not affect the physical representation of the type; they should
+be "something else", with much more relaxed rules; but we are not going to
+rewrite chapter 13...)
+
+> I suppose another option is to have some
+> kind of "incomplete" stream attribute specification,
+> such as "for Lim_Type'Read use <>;" in the visible part,
+> and then complete the definition in the private part.  This is
+> rampant invention, of course, but it solves another problem.
+
+This would have been a nice idea in '93, but at this point I think the
+language is insufficiently broken to invent new syntax.
+
+> Types like Exception_Occurrence are required to have stream attributes,
+> but not have any other primitive operations declared in the
+> visible part.  However stream attributes can only be defined
+> in terms of some "normal" subprogram, which must necessarily also
+> be visible at the point of the stream attribute definition.
+> Another contradiction...
+
+If there is a problem with this package, then I'd rather see the ARG modify
+the specification of Ada.Exceptions to include the additional stuff needed for
+streaming, rather than adding new syntax for this cornercase.
+
+Pascal
+
+****************************************************************
+
+From: 	Tucker Taft
+Sent: 	Monday, March 01, 1999 8:18 AM
+
+> > In AI 161, you have proposed that entry-less protected
+> > objects are not preelaborable.  This is a troublesome
+> > change, as Shared_Passive packages are required to
+> > be preelaborable, and entry-less protected objects are
+> > the only means of synchronization available via a
+> > Shared_Passive partition.
+>
+> This was a mistake.  My intent was _not_ to make them non-preelaborable.
+>
+> However, now that you have drawn my attention to this topic, I believe there
+> is a specific problem with protected objects.  The private part of a protected
+> object may include default expressions for components, and these default
+> expressions may or may not be preelaborable.  We need to decide if we want to
+> respect the privacy of the private part of protected objects.  If we do, it
+> seems that the pragma should apply in this case too: i.e., in the absence of a
+> pragma, the declaration of a protected object should be non-preelaborable; if
+> on the other hand you use the pragma, then the private part must have
+> preelaborable initialization.
+>
+> What do you think?
+
+Yes, I suppose the pragma ought to apply to entry-less protected
+types in the same way it applies to private types.  On the other
+hand, there seems no need for the pragma for a singleton protected
+object, since the only use of the type is for that object, and
+if that object is in a preelaborated package, clearly the
+default initialization needs to be preelaborable.
+
+> ...
+
+> > There seem to be two solutions.  One
+> > is to allow stream attributes to be specified before the
+> > type is fully defined.  The other is to allow them to be specified
+> > in the private part.
+>
+> I hate to open private parts.  In our compiler, this is a real nightmare (we
+> have to do that for pragma Convention, and that's already a big pain in the
+> neck).
+>
+> So my preference would be to allow the specification of stream attributes
+> before the type is fully defined.  Remember that we already have an AI that
+> says that 13.1(10) does not apply to stream attributes.  This would just be
+> another oddity with stream-oriented attributes.  (In fact I believe the
+> stream-oriented attributes should not be considered a representation item,
+> since they do not affect the physical representation of the type; they should
+> be "something else", with much more relaxed rules; but we are not going to
+> rewrite chapter 13...)
+
+Yes, I agree, since 13.1(10) does not apply to stream attributes, we
+should view them as a special category of attribute, and allow them
+to be specified on private types and other not-yet-completely-defined
+types.
+
+> > I suppose another option is to have some
+> > kind of "incomplete" stream attribute specification,
+> > such as "for Lim_Type'Read use <>;" in the visible part,
+> > and then complete the definition in the private part.  This is
+> > rampant invention, of course, but it solves another problem.
+>
+> This would have been a nice idea in '93, but at this point I think the
+> language is insufficiently broken to invent new syntax.
+>
+> > Types like Exception_Occurrence are required to have stream attributes,
+> > but not have any other primitive operations declared in the
+> > visible part.  However stream attributes can only be defined
+> > in terms of some "normal" subprogram, which must necessarily also
+> > be visible at the point of the stream attribute definition.
+> > Another contradiction...
+>
+> If there is a problem with this package, then I'd rather see the ARG modify
+> the specification of Ada.Exceptions to include the additional stuff needed for
+> streaming, rather than adding new syntax for this cornercase.
+
+If we allow specification of stream attributes on private types, that
+will probably simplify the solution enough to not justify adding any
+declarations to Ada.Exceptions.
+
+-Tuck
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent