Literals for Private Types

Literals for Private Types

[Alexandre E. Kopilovitch]

Near 3 weeks ago I sent to Ada-Comment mailing list my proposal for literals
for private types. As no reaction followed there, I concluded that the proposal
sank in silence. Therefore I decided to post a brief and informal exposition
of that proposal here in comp.land.ada (I suppose that those people who might
be interested in full and more formal version are subscribed to Ada-Comment
and therefore already saw it). Here it is:

-----

1. Both String and numeric literals become possible for any user-defined type,
including private types.

2. Two new attributes is all that needed for that: Literal_Conversion attribute,
defines a family of conversion functions for a type, while With_Literals
attribute, being attached to a subprogram's formal parameter permits implicit
conversion of literal actual argument for the parameter.

The With_Literal attribute provides necessary control over ambiguity, which
always was a major obstacle for the issue of literals for user-defined types.

Appropriate parameters of all predefined operations of the type are considered
as equipped with the With_Literals attribute, so implicit conversions of
literal actual arguments is always permitted for them.

3. The Literal_Conversion attribute should be defined within the type's specs
by usual method:

  type T is ...;
  for T'Literal_Conversion use F; 

(function F must take single String or numeric argument and return T).

The With_Literals attribute need not be defined at all - actually it acts more
like a pragma, but an attribute form it is simply more natural and convenient
for the case:

  procedure P (Arg : in T'With_Literals);

4. With that proposal, the String literals for Unbounded_String type can be
introduced by adding exactly one statement to Ada.Strings.Unbounded specs:

  for Unbounded_String use To_Unbounded_String;

The direct effect of this addition will be an opportunity to assign String
literals to Unbounded_Strings without explicit conversion.

The subprograms defined in Ada.Strings.Unbounded package will not be affected
because they have no With_Literals attribute attached to their parameters.

Then, if we wish to allow implicit conversion from string literals for our
user-defined function Compare, we must use With_Literal attributes for its
parameters:

  function Compare (Source : in Unbounded_String'With_Literals;
                    Target : in Unbounded_String'With_Literals)
    return Boolean;

-----



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Literals for Private Types

[Alexander Kopilovitch]

It appears that my previous posting on this subject had a slip inside the code
line proposed for inclusion in Ada.Strings.Unbounded (which teaches that even
a brief and informal text should be reviewed by another person if it contains
some code -;) in paragraph 4 - there must be

  for Unbounded_String'Literal_Conversion use To_Unbounded_String;

So, here is the corrected text:

-----

1. Both String and numeric literals become possible for any user-defined type,
including private types.

2. Two new attributes is all that needed for that: Literal_Conversion attribute,
defines a family of conversion functions for a type, while With_Literals
attribute, being attached to a subprogram's formal parameter permits implicit
conversion of literal actual argument for the parameter.

The With_Literal attribute provides necessary control over ambiguity, which
always was a major obstacle for the issue of literals for user-defined types.

Appropriate parameters of all predefined operations of the type are considered
as equipped with the With_Literals attribute, so implicit conversions of
literal actual arguments is always permitted for them.

3. The Literal_Conversion attribute should be defined within the type's specs
by usual method:

  type T is ...;
  for T'Literal_Conversion use F; 

(function F must take single String or numeric argument and return T).

The With_Literals attribute need not be defined at all - actually it acts more
like a pragma, but an attribute form it is simply more natural and convenient
for the case:

  procedure P (Arg : in T'With_Literals);

4. With that proposal, the String literals for Unbounded_String type can be
introduced by adding exactly one statement to Ada.Strings.Unbounded specs:

  for Unbounded_String'Literal_Conversion use To_Unbounded_String;

The direct effect of this addition will be an opportunity to assign String
literals to Unbounded_Strings without explicit conversion.

The subprograms defined in Ada.Strings.Unbounded package will not be affected
because they have no With_Literals attribute attached to their parameters.

Then, if we wish to allow implicit conversion from string literals for our
user-defined function Compare, we must use With_Literal attributes for its
parameters:

  function Compare (Source : in Unbounded_String'With_Literals;
                    Target : in Unbounded_String'With_Literals)
    return Boolean;

-----



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Literals for Private Types

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:
> Near 3 weeks ago I sent to Ada-Comment mailing list my proposal for literals
> for private types. As no reaction followed there, I concluded that the proposal
> sank in silence. Therefore I decided to post a brief and informal exposition
> of that proposal here in comp.land.ada (I suppose that those people who might
> be interested in full and more formal version are subscribed to Ada-Comment
> and therefore already saw it). Here it is:

Actually, quite the opposite, there has been a huge discussion on the 
ARG list about AI-318 (Returning [limited] objects without copying) and 
AI-325 (Anonymous access types as function result types).  What we are 
converging on will probably be by far the biggest change in Ada 0Y from 
current Ada.  (And IMHO a very big improvement.)

The net result, assuming that we do get all the loose ends tied up and 
reach consensus, will be that it will be possible to initialize limited 
objects either with an aggregate, or something similar to a function. 
(The 'something similar to part' means that we think that these special 
constructors need a flag in the syntax, since the calling sequence 
generated needs to be different, but haven't agreed on what the new 
syntax should look like.)

But any action on something else involving functions of limited types 
(literals are notationally a function in Ada, as are some attributes) 
will only occur after we get the ground rules for initializing limited 
objects nailed down.  I think that for some reason some of the 
discussion is in AI-325 not AI-318 on the website.  If you want to look 
at the current discussion be sure to allocate a couple of days.  The 
many of the issues go deep into compiler internals, and there are a lot 
of pages of discussion there.  There have been days where I had trouble 
keeping up in real-time, and as you can see, Randy, Tucker and I are the 
main posters.

-- 
                                           Robert I. Eachus

100% Ada, no bugs--the only way to create software.