!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. ***************************************************************