pragma Pure (Ada)

pragma Pure (Ada)

[Yannick Duchêne (Hibou57)]

In “A Brief Introduction to Ada 2012” (a great paper from John Barnes) ->
http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_Rational_Introducion.pdf

On page 12, you may read

> Ada 95 introduced the package Ada thus
>    package Ada is
>       pragma Pure(Ada);
>    end Ada;
> However, a close reading of the RM revealed that poor Ada
> is illegal since the pragma Pure is not in one of the allowed
> places for a pragma.

Does that mean that this was really illegal from strict layers point of  
view ? So GNAT was hacked ?

Notice how John Barnes was pleasantly teasing with the wording, as he  
wrote “poor Ada is illegal” instead of “Pure(Ada) is illegal” :-D


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: pragma Pure (Ada)

[Yannick Duchêne (Hibou57)]

Le Sat, 01 Oct 2011 03:50:36 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> In “A Brief Introduction to Ada 2012” (a great paper from John Barnes) ->
> http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_Rational_Introducion.pdf

On page 13, there's something I don't feel to understand

> Programmers have always moaned about the need for many
> explicit conversions in Ada. Accordingly, implicit
> conversions from anonymous access types to named access
> types are now permitted provided the explicit conversion is
> legal. The idea is that the need for an explicit conversion
> with access types should only arise if the conversion could
> fail. A curious consequence of this change is that a
> preference rule is needed for the equality of anonymous
> access types.

“a preference rule is needed for the equality of anonymous access types” ?  
What does that mean ?


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: pragma Pure (Ada)

[Yannick Duchêne (Hibou57)]

Le Sat, 01 Oct 2011 03:50:36 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> In “A Brief Introduction to Ada 2012” (a great paper from John Barnes) ->
> http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_Rational_Introducion.pdf

On page 14

> However, the behaviour of components which are records
> is different in Ada 2005 according to whether they are
> tagged or not. If a component is tagged then the primitive
> operation is used (which might have been redefined),
> whereas for an untagged type, predefined equality is used
> even though it might have been overridden. This is a bit
> surprising and so has been changed in Ada 2012 so that all
> record types behave the same way and use the primitive
> operation.

Not talking for me, but potentially for others: this may possibly  
introduce surprising behaviors in ancient applications, isn't it ?

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: pragma Pure (Ada)

[Adam Beneschan]

On Sep 30, 6:50 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> In “A Brief Introduction to Ada 2012” (a great paper from John Barnes) ->http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_Rational_I...
>
> On page 12, you may read
>
> > Ada 95 introduced the package Ada thus
> >    package Ada is
> >       pragma Pure(Ada);
> >    end Ada;
> > However, a close reading of the RM revealed that poor Ada
> > is illegal since the pragma Pure is not in one of the allowed
> > places for a pragma.
>
> Does that mean that this was really illegal from strict layers point of  
> view ? So GNAT was hacked ?

It's not fair to say GNAT was hacked.  Everybody knew that this code
was supposed to be legal.  It's just it was illegal according to a
literal reading of the RM rules that nobody noticed until I think I
discovered it while I was trying to look over the rules carefully to
answer a different question.  So the RM rules were clearly worded
wrong and had to be changed.

                           -- Adam

Re: pragma Pure (Ada)

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.v2nigzdfule2fv@index.ici...
Le Sat, 01 Oct 2011 03:50:36 +0200, Yannick Duch�ne (Hibou57)
<yannick_duchene@yahoo.fr> a �crit:

>> In "A Brief Introduction to Ada 2012" (a great paper from John Barnes) ->
>> http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_Rational_Introducion.pdf
>
>On page 14
>
>> However, the behaviour of components which are records
>> is different in Ada 2005 according to whether they are
>> tagged or not. If a component is tagged then the primitive
>> operation is used (which might have been redefined),
>> whereas for an untagged type, predefined equality is used
>> even though it might have been overridden. This is a bit
>> surprising and so has been changed in Ada 2012 so that all
>> record types behave the same way and use the primitive
>> operation.
>
>Not talking for me, but potentially for others: this may possibly 
>introduce surprising behaviors in ancient applications, isn't it ?

Right, although in most cases the change will fix bugs rather than create 
them. [Someone at AdaCore ran a testing version of GNAT with added code to 
identify such cases -- all of the code that was found either was test 
programs created specifically to check for the Ada 83/95 behavior, or cases 
where the programmer expected "=" to compose (but it didn't). They found no 
examples of cases where code actually expected non-composition of "=".]

There also are some new legality rules, but those of course could only cause 
an old program to be rejected. (Which would easily be fixed by moving the 
offending "=" declaration to some visible place.) So these are much less 
concerning.

We spent a lot of effort trying to figure out a way to keep compatibility 
for old code, but in this case it always came back to the fact that 
composition of "=" is what is really intended, and any hack to support both 
makes little sense (no one would intentionally want "=" to not compose).

Thus we eventually decided that it was better to just make the change.

                             Randy.


-- 
"Syntactic sugar causes cancer of the semi-colons."  [Epigrams on
Programming - Alan J. - P. Yale University]
"Structured Programming supports the law of the excluded muddle." [Idem]
Java: Write once, Never revisit 

Re: pragma Pure (Ada)

[Adam Beneschan]

On Sep 30, 7:11 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Sat, 01 Oct 2011 03:50:36 +0200, Yannick Duchêne (Hibou57)  
> <yannick_duch...@yahoo.fr> a écrit:
>
> > In “A Brief Introduction to Ada 2012” (a great paper from John Barnes) ->
> >http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_Rational_I...
>
> On page 13, there's something I don't feel to understand
>
> > Programmers have always moaned about the need for many
> > explicit conversions in Ada. Accordingly, implicit
> > conversions from anonymous access types to named access
> > types are now permitted provided the explicit conversion is
> > legal. The idea is that the need for an explicit conversion
> > with access types should only arise if the conversion could
> > fail. A curious consequence of this change is that a
> > preference rule is needed for the equality of anonymous
> > access types.
>
> “a preference rule is needed for the equality of anonymous access types” ?  
> What does that mean ?

If you have two objects of an anonymous access type that point to the
same type, in Ada 2005 you can test them for equality:

   X : access My_Record;
   Y : access My_Record;

   if X = Y then ...

This calls a function "=" that is defined in the language and takes
"universal access types" as parameters.

If you define a named access type:

   type My_Record_Acc is access My_Record;

this defines an implicit "=" operator:

   function "=" (Left, Right : My_Record_Acc) return Boolean ...

[and you can override it with your own operator if you really want
to].  In Ada 2005, this didn't pose a problem.  But in Ada 2012, if an
anonymous access type (access My_Record) could be implicitly converted
to a named access type (My_Record_Acc), then in this:

   if X = Y then ...

the compiler couldn't tell whether "=" means the function on
"universal access", or the function on My_Record_Acc (since X and Y
can now be implicitly converted to My_Record_Acc).  This is ambiguous,
and ambiguous function calls are normally an error, but making it an
error would make some legal Ada 2005 programs illegal in Ada 2012.  So
a special rule had to be added to make the language *prefer* the
"universal access" equality function over any other function.

Hope this helps,

                       -- Adam

Re: pragma Pure (Ada)

[Yannick Duchêne (Hibou57)]

Le Sat, 08 Oct 2011 03:37:53 +0200, Adam Beneschan <adam@irvine.com> a  
écrit:
> So a special rule had to be added to make the language *prefer* the
> "universal access" equality function over any other function.
>
> Hope this helps,
Yes Adam, that help, but raise another question: the choice of the  
anonymous access type operator is surprising to me. Why was the choice of  
the more specific operator rejected ? I guess this may be because the  
anonymous access type may not always be a valid parameter for the more  
specific redefined operator of the named access type (ex. different  
storage pool), but the choice of the least specific operator, is  
counterintuitive, and unintuitive things may lead to bad surprised and  
unexpected behavior (an an error at compile time is always preferable to  
an unexpected behavior).

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: pragma Pure (Ada)

[Yannick Duchêne (Hibou57)]

Le Sat, 08 Oct 2011 03:08:40 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> We spent a lot of effort trying to figure out a way to keep compatibility
> for old code, but in this case it always came back to the fact that
> composition of "=" is what is really intended, and any hack to support  
> both
> makes little sense (no one would intentionally want "=" to not compose).
>
> Thus we eventually decided that it was better to just make the change.
>
>                              Randy.

Personally agree, that was better to change, as the new semantic is more  
intuitive (agree too with your arguing).

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: pragma Pure (Ada)

[Niklas Holsti]

On 11-10-09 00:54 , Yannick Duchêne (Hibou57) wrote:
> Le Sat, 08 Oct 2011 03:37:53 +0200, Adam Beneschan <adam@irvine.com> a
> écrit:
>> So a special rule had to be added to make the language *prefer* the
>> "universal access" equality function over any other function.
>>
>> Hope this helps,
> Yes Adam, that help, but raise another question: the choice of the
> anonymous access type operator is surprising to me. Why was the choice
> of the more specific operator rejected ?

There can be several different such "more specific" operators, when 
there are possible implicit conversions of the anonymous access type to 
several named access type. Which "more specific" operator should be chosen?

> ...the choice of the least specific operator, is
> counterintuitive, and unintuitive things may lead to bad surprised and
> unexpected behavior (an an error at compile time is always preferable to
> an unexpected behavior).

The choice of the least specific operator minimizes the number of 
implicit type conversions, which in my view is good. But I would, 
perhaps, like to have a compiler switch to warn me when this preference 
rule is applied, especially if the non-preferred implicit conversions 
could reach an operator that is not the predefined operator for its type.


-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: pragma Pure (Ada)

[Adam Beneschan]

On Oct 8, 3:54 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Sat, 08 Oct 2011 03:37:53 +0200, Adam Beneschan <a...@irvine.com> a  
> écrit:> So a special rule had to be added to make the language *prefer* the
> > "universal access" equality function over any other function.
>
> > Hope this helps,
>
> Yes Adam, that help, but raise another question: the choice of the  
> anonymous access type operator is surprising to me. Why was the choice of  
> the more specific operator rejected ?  I guess this may be because the  
> anonymous access type may not always be a valid parameter for the more  
> specific redefined operator of the named access type (ex. different  
> storage pool), but the choice of the least specific operator, is  
> counterintuitive,

Actually, I think the opposite is true.  Say you have a package that
defines a record type Rec1 which defines an element of a linked list,
and it has a Link field:

   Link : access Rec1;

Now, in another package P2, you have some reason for defining your own
access type that accesses Rec1.  Maybe it's declared as a private
type:

   type Employee is private;

but you decide to implement it as an access-to-Rec1, in the private
part:

   type Employee is access all Rec1;

If we followed the rule you say is "intuitive", then any time in the
body of P2, you wrote

   if A.Link = B.Link then ...

the Link fields would suddenly be treated as having type Employee
(because the "=" operator on Employee would be used), even though Link
wasn't declared as having type Employee and the Employee type wasn't
even visible at the point the Link was declared.  This, to me, is
counter-intuitive.  So I think you've gotten it backwards.

The example is somewhat contrived; it's hard for me to think of a good
real-life example.  In practice, "=" won't be redefined that often,
which means it really doesn't matter which one the compiler picks.
You're going to be comparing two addresses for equality, no matter
which one is picked.  But there have to be some rules to allow the
compiler to pick one.  And, as Niklas pointed out, if there are
multiple named access types visible that access the same designated
type, using the "more specific" operator would still produce ambiguous
errors, which is not desired.

                                  -- Adam