Version 1.1 of acs/ac-00114.txt

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

!standard 6.7(00)          05-10-21 AC95-00114/01
!class Amendment 05-10-21
!status received no action 05-10-21
!status received 05-01-31
!subject Generic versions of Ada.Strings packages
!summary
!appendix

From: Robert Dewar
Date: Monday, January 31, 2005  7:29 AM

with the addition of wide_wide, there is a lot of code duplication
between normal/wide/wide_wide versions. I am considering introducing
a single generic in some cases, with three instantiations:

1. Less code duplication
2. Interesting capability for user to instantiate with other than
      Character, Wide_Character or Wide_Wide_Character

Unbounded_Integer_Lists seem like an interesting thing to me

Was this possibility ever discussed?

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

From: Pascal Leroy
Date: Monday, January 31, 2005  7:53 AM

> with the addition of wide_wide, there is a lot of code
> duplication between normal/wide/wide_wide versions. I am
> considering introducing a single generic in some cases, with
> three instantiations:
>
> 1. Less code duplication
> 2. Interesting capability for user to instantiate with other than
>       Character, Wide_Character or Wide_Wide_Character

Interestingly enough, that's how our current implementation of the
Character and Wide_Character works internally, and we will build on top of
that for Wide_Wide_Character.  As I recall (I didn't look at the code
recently) this is all generic, except for two special cases:

1 - I/O on wide files typically involves some kind encoding (UTF, UCS,
JIS, etc.) while I/O on normal character files doesn't.
2 - Character sets and maps are represented as arrays, while
Wide_Character sets use some more fancy data structures with indirections
(gosh, I can't for the life of me remember how that works).

> Unbounded_Integer_Lists seem like an interesting thing to me
>
> Was this possibility ever discussed?

No, I don't think so.  And given past experience, it's way too late to add
predefined units at this point.  However, this could be introduced as part
of an extension to the predefined library, outside of the Amendment
process (we gave a lot of thought to leaving the door opened to extensions
when we designed the containers).

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

From: Robert Dewar
Date: Monday, January 31, 2005  11:22 AM

> No, I don't think so.  And given past experience, it's way too late to add
> predefined units at this point.  However, this could be introduced as part
> of an extension to the predefined library, outside of the Amendment
> process (we gave a lot of thought to leaving the door opened to extensions
> when we designed the containers).

There is no limitation on adding grandchildren anyway, so you
could certainly add Ada.Strings.Generic_Unbounded. I think I
will go ahead and do it, no reason not to!

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

From: Randy Brukardt
Date: Monday, January 31, 2005  4:53 PM

> Unbounded_Integer_Lists seem like an interesting thing to me

Ada 2005 has that, it's called Containers.Vectors (Integer).

Matt tried as much as made sense to copy the design of Ada.Strings.Unbounded
when he designed Containers.Vectors -- it doesn't have every possible
operation, but it has the ones you are most likely to use. You could even
use it as better abstracted version of Ada.Strings.Unbounded if you wanted
to (the "&" operators and constructor functions are supported).

As far as a generic version of Unbounded_Strings goes, Dr. Leif suggested
that years ago. Probably other people have, too.

I would be very opposed to a generic being the only thing supported. It
would be unnecessarily hard to use and unnecessarily expensive in our
implementation (each character would have take up maximum size, which would
require a shape conversion and thunk access to them). Assuming appropriate
nongeneric equivalents are defined, I would grudgingly agree to it.

But I do think it is a bit late to do so, and I'm pretty sure you'd find
it's not quite right to do (certainly not for Wide_Text_IO, and probably not
in a number of other cases as well) - at least without adjustment of the
semantics and wording.

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

From: Robert Dewar
Date: Wednesday, February 2, 2005  9:18 AM

> I would be very opposed to a generic being the only thing supported. It
> would be unnecessarily hard to use and unnecessarily expensive in our
> implementation (each character would have take up maximum size, which would
> require a shape conversion and thunk access to them). Assuming appropriate
> nongeneric equivalents are defined, I would grudgingly agree to it.

Yes, of course nongeneric equivalents are defined, that has to be the
case for back compatibility.
>
> But I do think it is a bit late to do so, and I'm pretty sure you'd find
> it's not quite right to do (certainly not for Wide_Text_IO, and probably not
> in a number of other cases as well) - at least without adjustment of the
> semantics and wording.

It's useless in the Text_IO case, but it is useful for the string packages
case, and I have noted it down as an enhancement we will implement for
GNAT (we don't need it to be in the standard for that :-)

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


Questions? Ask the ACAA Technical Agent