comp.lang.ada
 help / color / mirror / Atom feed
* String_Access in unbounded string handling?
@ 2024-01-14 11:05 Blady
  2024-01-14 11:17 ` Jeffrey R.Carter
  2024-01-17 13:34 ` Tucker Taft
  0 siblings, 2 replies; 9+ messages in thread
From: Blady @ 2024-01-14 11:05 UTC (permalink / raw)


Hello,

String_Access is defined in A.4.5 Unbounded-Length String Handling:
7          type String_Access is access all String;

and note:
75  The type String_Access provides a (nonprivate) access type for 
explicit processing of unbounded-length strings.

I wonder what String_Access is for and what could be "explicit processing"?

Thanks, Pascal.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: String_Access in unbounded string handling?
  2024-01-14 11:05 String_Access in unbounded string handling? Blady
@ 2024-01-14 11:17 ` Jeffrey R.Carter
  2024-01-14 15:12   ` Dmitry A. Kazakov
  2024-01-17  1:24   ` Randy Brukardt
  2024-01-17 13:34 ` Tucker Taft
  1 sibling, 2 replies; 9+ messages in thread
From: Jeffrey R.Carter @ 2024-01-14 11:17 UTC (permalink / raw)


On 2024-01-14 12:05, Blady wrote:
> 
> String_Access is defined in A.4.5 Unbounded-Length String Handling:
> 7          type String_Access is access all String;
> 
> and note:
> 75  The type String_Access provides a (nonprivate) access type for explicit 
> processing of unbounded-length strings.
> 
> I wonder what String_Access is for and what could be "explicit processing"?

String_Access is a mistake that should not exist.

-- 
Jeff Carter
"If you think you got a nasty taunting this time,
you ain't heard nothing yet!"
Monty Python and the Holy Grail
23

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: String_Access in unbounded string handling?
  2024-01-14 11:17 ` Jeffrey R.Carter
@ 2024-01-14 15:12   ` Dmitry A. Kazakov
  2024-01-17  1:30     ` Randy Brukardt
  2024-01-17  1:24   ` Randy Brukardt
  1 sibling, 1 reply; 9+ messages in thread
From: Dmitry A. Kazakov @ 2024-01-14 15:12 UTC (permalink / raw)


On 2024-01-14 12:17, Jeffrey R.Carter wrote:
> On 2024-01-14 12:05, Blady wrote:
>>
>> String_Access is defined in A.4.5 Unbounded-Length String Handling:
>> 7          type String_Access is access all String;
>>
>> and note:
>> 75  The type String_Access provides a (nonprivate) access type for 
>> explicit processing of unbounded-length strings.
>>
>> I wonder what String_Access is for and what could be "explicit 
>> processing"?
> 
> String_Access is a mistake that should not exist.

Well, from one point of view, surely.

However I frequently need such a type because I in general refrain from 
using Unbounded_String. Now, would be no problem to declare it as 
needed, except for generics! If you have generic packages like:

generic
    type Object_Type (<>) is private;
    type Object_Access_Type is access all Object_Type;

You want all instances to share the same String_Access. So it is 
conflicting. One is true, it has no place there. It should have been the 
package Standard or none.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: String_Access in unbounded string handling?
  2024-01-14 11:17 ` Jeffrey R.Carter
  2024-01-14 15:12   ` Dmitry A. Kazakov
@ 2024-01-17  1:24   ` Randy Brukardt
  2024-01-17  9:54     ` Blady
  1 sibling, 1 reply; 9+ messages in thread
From: Randy Brukardt @ 2024-01-17  1:24 UTC (permalink / raw)


"Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> wrote in message 
news:uo0fs5$dja6$1@dont-email.me...
> On 2024-01-14 12:05, Blady wrote:
>>
>> String_Access is defined in A.4.5 Unbounded-Length String Handling:
>> 7 type String_Access is access all String;
>>
>> and note:
>> 75 The type String_Access provides a (nonprivate) access type for 
>> explicit processing of unbounded-length strings.
>>
>> I wonder what String_Access is for and what could be "explicit 
>> processing"?
>
> String_Access is a mistake that should not exist.

I agree with Jeffrey. Whatever reason it was initially put into the package 
has long since ceased to be relevant. And, as Dmitry notes, when you want 
such a type, it's usually because you didn't want to use 
Ada.Strings.Unbounded (or Bounded). So the placement is odd at best.

               Randy.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: String_Access in unbounded string handling?
  2024-01-14 15:12   ` Dmitry A. Kazakov
@ 2024-01-17  1:30     ` Randy Brukardt
  0 siblings, 0 replies; 9+ messages in thread
From: Randy Brukardt @ 2024-01-17  1:30 UTC (permalink / raw)


"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:uo0tkt$g6av$1@dont-email.me...
...

> ...  It should have been the package Standard or none.

None for me. ;-)

One really doesn't want to put anything in Standard that isn't widely 
needed, as those names become hard to use in other circumstances. In 
particular, declarations in Standard hide anything that is use-visible with 
the same name, so adding something to Standard can be rather incompatable.

One could mitigate use-visibility problems by allowing more extensive 
overloading (for instance, of objects), but that causes rare and subtle 
cases where a program could change meaning without any indication. (Where a 
different object would be used, for instance.) That makes that too risky a 
change for Ada.

                            Randy.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: String_Access in unbounded string handling?
  2024-01-17  1:24   ` Randy Brukardt
@ 2024-01-17  9:54     ` Blady
  0 siblings, 0 replies; 9+ messages in thread
From: Blady @ 2024-01-17  9:54 UTC (permalink / raw)


Le 17/01/2024 à 02:24, Randy Brukardt a écrit :
> "Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> wrote in message
> news:uo0fs5$dja6$1@dont-email.me...
>> On 2024-01-14 12:05, Blady wrote:
>>>
>>> String_Access is defined in A.4.5 Unbounded-Length String Handling:
>>> 7 type String_Access is access all String;
>>>
>>> and note:
>>> 75 The type String_Access provides a (nonprivate) access type for
>>> explicit processing of unbounded-length strings.
>>>
>>> I wonder what String_Access is for and what could be "explicit
>>> processing"?
>>
>> String_Access is a mistake that should not exist.
> 
> I agree with Jeffrey. Whatever reason it was initially put into the package
> has long since ceased to be relevant. And, as Dmitry notes, when you want
> such a type, it's usually because you didn't want to use
> Ada.Strings.Unbounded (or Bounded). So the placement is odd at best.
> 
>                 Randy.

Thanks for all your answers,

This is probably a very minor subject, however I submitted it:
https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/79

Pascal.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: String_Access in unbounded string handling?
  2024-01-14 11:05 String_Access in unbounded string handling? Blady
  2024-01-14 11:17 ` Jeffrey R.Carter
@ 2024-01-17 13:34 ` Tucker Taft
  2024-01-19  1:36   ` Randy Brukardt
  1 sibling, 1 reply; 9+ messages in thread
From: Tucker Taft @ 2024-01-17 13:34 UTC (permalink / raw)


On Sunday, January 14, 2024 at 6:05:45 AM UTC-5, Blady wrote:
> Hello, 
> 
> String_Access is defined in A.4.5 Unbounded-Length String Handling: 
> 7 type String_Access is access all String; 
> 
> and note: 
> 75 The type String_Access provides a (nonprivate) access type for 
> explicit processing of unbounded-length strings. 
> 
> I wonder what String_Access is for and what could be "explicit processing"? 

The idea was to support the explicit use of new String'(...), X.all, and Unchecked_Deallocation rather than the implicit use of the heap inherent in Unbounded strings.  It was recognized that you need a single global access type to avoid having to do conversions all over the place.  This predated the availability of stand-alone objects of an anonymous access type (aka "SAOOAAATs" ;-), but those are not universally loved either.  It certainly cannot be removed now without potentially very painful disruption of existing users.  It could be moved to a different package without too much disruption, but I haven't seen any groundswell of interest in doing that either.
> 
> Thanks, Pascal.

Take care,
-Tuck

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: String_Access in unbounded string handling?
  2024-01-17 13:34 ` Tucker Taft
@ 2024-01-19  1:36   ` Randy Brukardt
  2024-01-30 15:53     ` Blady
  0 siblings, 1 reply; 9+ messages in thread
From: Randy Brukardt @ 2024-01-19  1:36 UTC (permalink / raw)


"Tucker Taft" <tucker.taft@gmail.com> wrote in message 
news:afd791fa-853f-48fa-9223-759b12d4ed87n@googlegroups.com...
On Sunday, January 14, 2024 at 6:05:45?AM UTC-5, Blady wrote:
>> Hello,
>>
>> String_Access is defined in A.4.5 Unbounded-Length String Handling:
>> 7 type String_Access is access all String;
>>
>> and note:
>> 75 The type String_Access provides a (nonprivate) access type for
>> explicit processing of unbounded-length strings.
>>
>> I wonder what String_Access is for and what could be "explicit 
>> processing"?
>
>The idea was to support the explicit use of new String'(...), X.all, and 
>Unchecked_Deallocation
>rather than the implicit use of the heap inherent in Unbounded strings.  It 
>was recognized that you
>need a single global access type to avoid having to do conversions all over 
>the place.  This
>predated the availability of stand-alone objects of an anonymous access 
>type
>(aka "SAOOAAATs" ;-), but those are not universally loved either.  It 
>certainly cannot be
>removed now without potentially very painful disruption of existing users. 
>It could be moved
>to a different package without too much disruption, but I haven't seen any 
>groundswell of interest
>in doing that either.

I'm dubious that there are any such users. Certainly, in the handful of 
cases where I needed such a type, I just declared it (strong typing, you 
know?) and never thought of Ada.Strings.Unbounded as being a place to find 
such a type already defined. It is such an odd place I doubt anyone outside 
of perhaps the people who defined the type ever used it.

OTOH, I agree that the compatibility impact is non-zero (anyone who did use 
it would have to change their code), and the benefit of removing the type at 
this point is close to zero (junk declarations abound in long-term Ada 
packages, what's one more; and certainly there is a lot of unused stuff in 
any particular reusable package and any particular use), so the cost-benefit 
ratio doesn't seem to make a change here worth it. An Ada successor language 
would design Ada.Strings.Unbounded rather differently (so as to be able to 
use string literals directly with the type) and probably would include 
universal character support as well, so it's hard to find an important 
reason to change this.

Also, I'm pretty sure we're discussed this within the ARG several times in 
the past, so this is well-trodden ground.

                  Randy.




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: String_Access in unbounded string handling?
  2024-01-19  1:36   ` Randy Brukardt
@ 2024-01-30 15:53     ` Blady
  0 siblings, 0 replies; 9+ messages in thread
From: Blady @ 2024-01-30 15:53 UTC (permalink / raw)


Le 19/01/2024 à 02:36, Randy Brukardt a écrit :
> "Tucker Taft" <tucker.taft@gmail.com> wrote in message
> news:afd791fa-853f-48fa-9223-759b12d4ed87n@googlegroups.com...
> On Sunday, January 14, 2024 at 6:05:45?AM UTC-5, Blady wrote:
>>> Hello,
>>>
>>> String_Access is defined in A.4.5 Unbounded-Length String Handling:
>>> 7 type String_Access is access all String;
>>>
>>> and note:
>>> 75 The type String_Access provides a (nonprivate) access type for
>>> explicit processing of unbounded-length strings.
>>>
>>> I wonder what String_Access is for and what could be "explicit
>>> processing"?
>>
>> The idea was to support the explicit use of new String'(...), X.all, and
>> Unchecked_Deallocation
>> rather than the implicit use of the heap inherent in Unbounded strings.  It
>> was recognized that you
>> need a single global access type to avoid having to do conversions all over
>> the place.  This
>> predated the availability of stand-alone objects of an anonymous access
>> type
>> (aka "SAOOAAATs" ;-), but those are not universally loved either.  It
>> certainly cannot be
>> removed now without potentially very painful disruption of existing users.
>> It could be moved
>> to a different package without too much disruption, but I haven't seen any
>> groundswell of interest
>> in doing that either.
> 
> I'm dubious that there are any such users. Certainly, in the handful of
> cases where I needed such a type, I just declared it (strong typing, you
> know?) and never thought of Ada.Strings.Unbounded as being a place to find
> such a type already defined. It is such an odd place I doubt anyone outside
> of perhaps the people who defined the type ever used it.
> 
> OTOH, I agree that the compatibility impact is non-zero (anyone who did use
> it would have to change their code), and the benefit of removing the type at
> this point is close to zero (junk declarations abound in long-term Ada
> packages, what's one more; and certainly there is a lot of unused stuff in
> any particular reusable package and any particular use), so the cost-benefit
> ratio doesn't seem to make a change here worth it. An Ada successor language
> would design Ada.Strings.Unbounded rather differently (so as to be able to
> use string literals directly with the type) and probably would include
> universal character support as well, so it's hard to find an important
> reason to change this.

At least, the type String_Access could be tagged as obsolescent.

Pascal.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2024-01-30 15:53 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-14 11:05 String_Access in unbounded string handling? Blady
2024-01-14 11:17 ` Jeffrey R.Carter
2024-01-14 15:12   ` Dmitry A. Kazakov
2024-01-17  1:30     ` Randy Brukardt
2024-01-17  1:24   ` Randy Brukardt
2024-01-17  9:54     ` Blady
2024-01-17 13:34 ` Tucker Taft
2024-01-19  1:36   ` Randy Brukardt
2024-01-30 15:53     ` Blady

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox