Version 1.1 of acs/ac-00161.txt

Unformatted version of acs/ac-00161.txt version 1.1
Other versions for file acs/ac-00161.txt

!standard 11.4.1(6.1/2)          08-05-10 AC95-00161/01
!standard 11.4.1(6.2/2)
!class confirmation 08-05-10
!status received no action 08-05-10
!status received 08-03-02
!subject Query on stream routines in Ada.Exceptions
!summary
!appendix

From: Robert Dewar
Date: Sunday, March  2, 2008  6:09 PM

It seems fine to insist that Ada.Exceptions provide stream routines for
Exception_Occurrence, but it is a pity that the explicit routines
Read/Write_Exception_Occurrence are in the spec, meaning that they have to be
implemented as shown.

We have a nice mechanism for providing stream routines in a case like this
(pragma Stream_Convert) without dragging in all the streams stuff, but it can't
accomodate the explicit procedures, was it *really* necessary to make these
procedures visible?

****************************************************************

From: Robert Dewar
Date: Sunday, March  2, 2008  6:26 PM

By the way, you do not need to worry about backward compatibility when looking
at this, I can promise that there are no existing Ada 2005 programs using these
procedures :-)

We could possibly implement a giant kludge in which these routines become
implicit child subprograms in a transparent manner, but it's a lot of work for
no gain (we do have a template for that kind of implementation, in GNAT, generic
packages like Text_IO.Integer_IO are implicit child packages, so that if you
with Text_IO you don't get all the junk loaded if you don't use it :-)

****************************************************************

From: Tucker Taft
Date: Monday, March  3, 2008  7:09 AM

It is necessary to make these procedures visible for limited types.  For
non-limited types, we can simply add an implementation requirement that the
stream routines do something reasonable.   But for a limited type, the stream
attributes need to be "available" and for a limited type that means a visible
attribute specification.  I don't believe the language designers should get to
"cheat" for something like this unless we give the same capability to users.

****************************************************************

From: Robert Dewar
Date: Monday, March  3, 2008  8:18 AM

OK, If that is the case I agree, but I thought that it was good enough to have
stream attributes defined in the private part. What disallows that?

****************************************************************

From: Robert Dewar
Date: Monday, March  3, 2008  8:20 AM

> I don't
> believe the language designers should get to "cheat" for something
> like this unless we give the same capability to users.

Of course in GNAT, we *do* give the same capability to users, Stream_Convert is
generally usable, here for interest is the documentation:

Probably what we can do is to make pragma Stream_Convert manufacture the
corresponding routines automatically (and we can choose the convention so that
it just happens to work for Ada.Exceptions :-))

> Syntax:
>
> @smallexample @c ada
> pragma Stream_Convert (
>   [Entity =>] type_LOCAL_NAME,
>   [Read   =>] function_NAME,
>   [Write  =>] function_NAME);
> @end smallexample
>
> @noindent
> This pragma provides an efficient way of providing stream functions
> for types defined in packages.  Not only is it simpler to use than
> declaring the necessary functions with attribute representation
> clauses, but more significantly, it allows the declaration to made in
> such a way that the stream packages are not loaded unless they are
> needed.  The use of the Stream_Convert pragma adds no overhead at all,
> unless the stream attributes are actually used on the designated type.
>
> The first argument specifies the type for which stream functions are
> provided.  The second parameter provides a function used to read
> values of this type.  It must name a function whose argument type may
> be any subtype, and whose returned type must be the type given as the
> first argument to the pragma.
>
> The meaning of the @var{Read}
> parameter is that if a stream attribute directly or indirectly
> specifies reading of the type given as the first parameter, then a
> value of the type given as the argument to the Read function is read
> from the stream, and then the Read function is used to convert this to
> the required target type.
>
> Similarly the @var{Write} parameter specifies how to treat write
> attributes that directly or indirectly apply to the type given as the first parameter.
> It must have an input parameter of the type specified by the first
> parameter, and the return type must be the same as the input type of the Read function.
> The effect is to first call the Write function to convert to the given
> stream type, and then write the result type to the stream.
>
> The Read and Write functions must not be overloaded subprograms.  If
> necessary renamings can be supplied to meet this requirement.
> The usage of this attribute is best illustrated by a simple example,
> taken from the GNAT implementation of package Ada.Strings.Unbounded:
>
> @smallexample @c ada
> function To_Unbounded (S : String)
>            return Unbounded_String
>   renames To_Unbounded_String;
>
> pragma Stream_Convert
>   (Unbounded_String, To_Unbounded, To_String); @end smallexample
>
> @noindent
> The specifications of the referenced functions, as given in the Ada
> Reference Manual are:
>
> @smallexample @c ada
> function To_Unbounded_String (Source : String)
>   return Unbounded_String;
>
> function To_String (Source : Unbounded_String)
>   return String;
> @end smallexample
>
> @noindent
> The effect is that if the value of an unbounded string is written to a
> stream, then the representation of the item in the stream is in the
> same format used for @code{Standard.String}, and this same
> representation is expected when a value of this type is read from the stream.

****************************************************************

From: Pascal Leroy
Date: Monday, March  3, 2008  3:08 AM

> We have a nice mechanism for providing stream routines in a case
> like this (pragma Stream_Convert) without dragging in all the
> streams stuff, but it can't accomodate the explicit procedures,
> was it *really* necessary to make these procedures visible?

This was discussed during the design, and we explicitly decided against compiler
magic.  See the !discussion of AI 438.

One (arguably marginal) advantage of having Read/Write_Exception_Occurrence
visible is that they don't have convention Intrinsic and therefore can be used
as the prefix of Access, while the stream attributes can't.

****************************************************************

From: Robert Dewar
Date: Monday, March  3, 2008  2:15 PM

True, or instantiated

Fine, I will enhance our compiler magic to cover this case :-)

****************************************************************

From: Pascal Leroy
Date: Monday, March  3, 2008  9:34 AM

> OK, If that is the case I agree, but I thought that it was good
> enough to have stream attributes defined in the private part.
> What disallows that?

If the stream attributes are specified in the private part they are not
"available" to the outside world, see 13.13.2(44/2).

****************************************************************

From: Robert Dewar
Date: Monday, March  3, 2008  2:16 PM

OK, understood

Part of the trouble here is that a lot of junk has crept into Ada.Exceptions
which is a unit likely to be included with virtually all programs,

Well, off to work on the required magic!

****************************************************************


Questions? Ask the ACAA Technical Agent