Version 1.1 of acs/ac-00315.txt

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

!standard 4.5.2(7)          19-01-08 AC95-00315/00
!class Amendment 19-01-08
!status received no action 19-01-08
!status received 18-12-25
!subject AI12-0020 streams and text encodings
!summary
!appendix

From: Vadim Godunko
Sent: Tuesday, December 25, 2018  9:21 AM

I suppose you did next one mistake in nice new feature, and after life
discussion someone asked me to provide my point of view ;)

First of all, you are still suppose what is it Character/Wide and try to handle
issues with "missing" characters. I suggest to step outside of this issue and
define new kind of streams - text steams, like

type Input_Text_Stream is limited interface;

not overriding function Get
   (Self : in out Input_Text_Stream) return Wide_Wide_Character;

type Output_Text_Stream is limited interface;

not overriding procedure Put
   (Self : in out Output_Text_Stream;
    Item : Wide_Wide_Character);

Then "redefine" 'Image/etc attributes like:

procedure Image (Item : T; Stream : in out Output_Text_Stream'Class);

function Value (Stream : in out Output_Text_Stream'Class) return T;

All text encoding handling is hidden inside implementation of
Input_Text_Stream/Output_Text_Stream functions. Standard library can provide
concrete implementation of these streams with support of UTF8/16/32 and any
application can provide own specialized implementation.

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

From: Randy Brukardt
Sent: Thursday, January 3, 2019  8:23 PM

...
> I suppose you did next one mistake in nice new feature, and after life
> discussion someone asked me to provide my point of view ;)
>
> First of all, you are still suppose what is it Character/Wide and try
> to handle issues with "missing" characters.

That's how Image is defined. It's a problem with the basic definition of Ada,
one that we're stuck with unless we're willing to abandon all compatibility. A
String is not an array! No amount of hacks will fix that underlying problem.

> I suggest
> to step outside of this issue and define new kind of streams
> - text steams, like
>
> type Input_Text_Stream is limited interface;
>
> not overriding function Get
>    (Self : in out Input_Text_Stream) return Wide_Wide_Character;
>
> type Output_Text_Stream is limited interface;
>
> not overriding procedure Put
>    (Self : in out Output_Text_Stream;
>     Item : Wide_Wide_Character);
>
> Then "redefine" 'Image/etc attributes like:
>
> procedure Image (Item : T; Stream : in out Output_Text_Stream'Class);
>
> function Value (Stream : in out Output_Text_Stream'Class) return T;
>
> All text encoding handling is hidden inside implementation of
> Input_Text_Stream/Output_Text_Stream functions. Standard library can
> provide concrete implementation of these streams with support of
> UTF8/16/32 and any application can provide own specialized
> implementation.

This doesn't make a lot of sense:
(1) It only "fixes" the representation issue for Image/Value (and we're not even
defining any of this for Value in Ada 2020). That's such a tiny corner of the
problem - why fix it *just* for Image? There's no way to use such a mechanism
for other string operations (like indexing or slicing).

If one was going to make any attempt at fixing the encoding problem at all (that
is, abstracting away the concrete representation of a string), then one needs a
much more complex and powerful abstraction. (See the !discussion of AI12-0021-1
for the outline of one possible such solution.) But it seems unlikely that such
a solution will ever get adopted into Ada, there is just too much existing stuff
that would have to be abandoned (changing existing stuff is almost always too
incompatible). It probably would make more sense in the context of "Better Ada",
that is a reimagining of Ada where compatibility is not a concern. (Whether that
could ever exist is an interesting question of its own.)

(2) This "fix" doesn't seem to be usable at all. The primary purpose of Image is
to provide an easy debugging image for logs/debug output/etc. Adding another
parameter to deal with (and especially turning Image into a procedure)
complicates the use. And if one adds another pile of mechanism to make Image
look like a function returning a String, then getting any other format becomes
complex and painful.


The use of streams to implement Image is really a hack to avoid having to define
Image in terms of "&", which is typically quite expensive. The hope is that
hardly anyone ever has to deal with it; the only people who do is those that
want to redefine Image for their ADT. Your approach seems to put it
front-and-center. And people writing Put_Image have no reason to deal with
representation - conversion is expensive. Moreover, Images need to be relatively
short (and are short-lived), so there isn't a strong need to save space. But
this proposal doesn't fix any of the many problems with string representation
(for instance, for file names, for I/O, for exception messages, ...), so that
doesn't gain much. To fix those things properly has already been determined to
be too much for this revision (see AI12-0021-1 again); we've determined to just
add more hacks.

Procedurally, you're too late as well. We've been working on this AI for 6 years
and actively for a year; the final form was approved at the October 2018
meeting. Comments could have been made at any point up to the approval and they
would have been considered promptly. Now, you would need to find enough ARG
members to make a motion to reopen the AI -- this generally requires finding a
significant technical problem with the proposal. (We don't make reopening
approved AIs easy so that controversial topics don't keep coming back from the
dead; if that wasn't the case, we would have a hard time getting anything done.)
You could also try to get WG 9 to reject the Ada 2020 Standard (usually, you
could try to get the individual AI rejected, but the next thing that WG 9 will
be voting on is the entire Standard; WG 9 pre-approved the set of possible AIs
for Ada 2020 to save time). For obvious reasons, I don't recommend that.

And if that was done, with the last meeting to add anything to Ada 2020 only 10
days away (we need to deliver the completed draft in March, and we have to spend
most of the remaining time reviewing the Standard and fixing problems
uncovered), undertaking an complex addition from scratch is not happening.
Pretty much the only choices to meet the schedule are to go ahead as designed or
to abandon entirely the redefinition of Image AI. I could see delaying Ada 2020
for something critical (for instance, parallel operations), but not for a
nice-to-have feature like this one.

Do you find this issue important enough to drop redefinition of Image
completely??

P.S. You can keep track of updates to the Ada-Auth.org site (and thus ARG
work) by monitoring the site log: http://www.ada-auth.org/log.html.

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

Questions? Ask the ACAA Technical Agent