prefix of dereference must be a name?

prefix of dereference must be a name?

[Stephen Leake]

I'd like to be able to do the following:

type T is record ... end record;
type T_Access is access all T;

function "+" (Left, Right in : ...) return T_Access;

A : T_Access := new T;
B : T_Access := new T;
C : T_Access := A + B;

A.all := (C + B).all;

but GNAT complains that "prefix for selection is not a name", pointing
to (C + B).all.

So then I tried:

function "-" (Token : in T_Access) return T_Access
is begin
    return Token;
end;

A.all := -(C + B).all;

and got the same error. Finally I tried:

function Copy (Token : in T_Access) return T_Access
is begin
    return Token;
end;

A.all := Copy (C + B).all;

And the compiler was happy.

What's the rationale for this? 

I assume one issue here is that "-" might be an intrinsic, but since
the type involved is not a numeric type, I don't see how that could be
a problem.

Similarly for ().all; when could that be a problem?

-- 
-- Stephe

Re: prefix of dereference must be a name?

[Yannick Duchêne Hibou57]

On 30 juil, 09:09, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> [...]
> A.all := (C + B).all;
>
> [...]
> So then I tried:
> [...]
> A.all := -(C + B).all;
>
> and got the same error. Finally I tried:
>
> [...]
> A.all := Copy (C + B).all;
>
> And the compiler was happy.
>
> What's the rationale for this?
>
> [...]
> Similarly for ().all; when could that be a problem?
>
> --
> -- Stephe

Hi Stephe,

The reason behind this is in the language reference.

Let's go step by step.

First of all ARM 4.1.3 says:
(2) selected_component ::= prefix . selector_name
(3) selector_name ::= identifier | character_literal | operator_symbol

No special point with “ selector_name ” and any way, you did not get
into trouble with it.

Next, is the “ prefix ” part which is of big interest to you.

About it, ARM 4.1 says:
(2) name ::=
     direct_name | explicit_dereference
   | indexed_component | slice
   | selected_component | attribute_reference
   | type_conversion | function_call
   | character_literal


You may open you ARM reference or you may browse it at
http://www.adaic.com/standards/05rm/html/RM-TTL.html is you haven't
got one off-line on computer and then go to ARM 4.1 and follow each
links to know in detail about what the “ name ” part can be.

But you can see in the latter excerpt, that “ function_call ” appears,
but not “ expression ”.

Now about the rationale behind (previously given, was the direct
reason), I do not know, but I guess this may be to avoid any kind of
invisible temporaly variable (the result of a function is mostly an
initializer, not a returned variable).

If I find more about the rational, I will tell you, or perhaps some
one else will tell before ;)

Have a nice time

Yannick

Re: prefix of dereference must be a name?

[John B. Matthews]

In article <u4osuzlxw.fsf@stephe-leake.org>,
 Stephen Leake <stephen_leake@stephe-leake.org> wrote:

> I'd like to be able to do the following:
> 
> type T is record ... end record;
> type T_Access is access all T;
> 
> function "+" (Left, Right in : ...) return T_Access;
> 
> A : T_Access := new T;
> B : T_Access := new T;
> C : T_Access := A + B;
> 
> A.all := (C + B).all;
> 
> but GNAT complains that "prefix for selection is not a name", pointing
> to (C + B).all.
> 
> So then I tried:
> 
> function "-" (Token : in T_Access) return T_Access
> is begin
>     return Token;
> end;
> 
> A.all := -(C + B).all;
> 
> and got the same error. Finally I tried:
> 
> function Copy (Token : in T_Access) return T_Access
> is begin
>     return Token;
> end;
> 
> A.all := Copy (C + B).all;
> 
> And the compiler was happy.

Interesting. The compiler was happy with a function call:

A.all := "+"(C, B).all;

but a use_type_clause didn't seem to help.

> What's the rationale for this? 
> 
> I assume one issue here is that "-" might be an intrinsic, but since
> the type involved is not a numeric type, I don't see how that could be
> a problem.
> 
> Similarly for ().all; when could that be a problem?

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: prefix of dereference must be a name?

[Stephen Leake]

Yannick Duchêne Hibou57 <yannick_duchene@yahoo.fr> writes:

> On 30 juil, 09:09, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>> [...]
>> A.all := (C + B).all;
>>
>> What's the rationale for this?
>>
> About it, ARM 4.1 says:
> (2) name ::=
>      direct_name | explicit_dereference
>    | indexed_component | slice
>    | selected_component | attribute_reference
>    | type_conversion | function_call
>    | character_literal
>
> But you can see in the latter excerpt, that “ function_call ” appears,
> but not “ expression ”.

Looking in the annotated language reference manual, I find this in
4.1, about what could be allowed as the prefix for .all:

17.f
          Discussion: Actually, it would be reasonable to allow any
          primary in front of .all, since only the value is needed, but
          that would be a bit radical.

I guess that makes me a radical, which is nothing new :).

And yesterday's "radical" is today's "progressive". That note is from
the Ada 95 changes; time to move on!

But as you say, I want more than a primary, I want an expression. Hmm.
"primary" includes "qualified_expression". That would save me from
declaring Copy above. Although when things are class-wide the necessary
type qualifier can be quite long.

I still don't see the fundamental problem.

-- 
-- Stephe

Re: prefix of dereference must be a name?

[Dmitry A. Kazakov]

On Fri, 31 Jul 2009 08:04:56 -0400, Stephen Leake wrote:

> Looking in the annotated language reference manual, I find this in
> 4.1, about what could be allowed as the prefix for .all:
> 
> 17.f
>           Discussion: Actually, it would be reasonable to allow any
>           primary in front of .all, since only the value is needed, but
>           that would be a bit radical.
> 
> I guess that makes me a radical, which is nothing new :).
>
> And yesterday's "radical" is today's "progressive". That note is from
> the Ada 95 changes; time to move on!

Talking  about radicalism it would be much better to remove ".all" where an
object of target type is expected.

   A.all := C + B;  -- Unambiguous

> But as you say, I want more than a primary, I want an expression. Hmm.
> "primary" includes "qualified_expression". That would save me from
> declaring Copy above. Although when things are class-wide the necessary
> type qualifier can be quite long.
> 
> I still don't see the fundamental problem.

Huh, it is the same problem as here:

   Two := ("A" & "B")'Length; -- Illegal

too RADICAL ! (:-))

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

Re: prefix of dereference must be a name?

[Robert A Duff]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> I still don't see the fundamental problem.

There is no fundamental problem.  I agree with you 100% -- things like
"(A + B).all" and "(A & B)'Length" ought to be legal.  They're not,
and that's probably because nobody thought it important enough to
go against "tradition".  Traditionally, Ada 83 made a big distinction
between expressions and names (and likewise, between values and
(constant) objects).  Ada 95 eroded that distinction somewhat, but
not entirely.

- Bob

Re: prefix of dereference must be a name?

[Adam Beneschan]

On Jul 30, 12:35 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:

> Interesting. The compiler was happy with a function call:
>
> A.all := "+"(C, B).all;
>
> but a use_type_clause didn't seem to help.

Right, because (C + B).all just doesn't fit into the syntax.  USE TYPE
makes certain functions visible that wouldn't otherwise be directly
visible, but it doesn't change the syntax rules.  (If "+" weren't
visible at all, then you'd get an error with

   "+"(C,B).all

but it wouldn't be a syntax error; the error would be that the
compiler didn't know what "+" meant.  This could be hypothetically
fixed with something like

   Some_Package."+"(C, B).all

USE TYPE can also fix that problem by making "+" directly visible,
i.e. visible without needing a package name.  But it still can't make
illegal syntax illegal.)

                                -- Adam

Re: prefix of dereference must be a name?

[John B. Matthews]

In article 
<dfef89b8-7821-4852-bff7-9dac1bafa2a8@t11g2000prh.googlegroups.com>,
 Adam Beneschan <adam@irvine.com> wrote:

> On Jul 30, 12:35 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> 
> > Interesting. The compiler was happy with a function call:
> >
> > A.all := "+"(C, B).all;
> >
> > but a use_type_clause didn't seem to help.
> 
> Right, because (C + B).all just doesn't fit into the syntax.  USE TYPE
> makes certain functions visible that wouldn't otherwise be directly
> visible, but it doesn't change the syntax rules.  (If "+" weren't
> visible at all, then you'd get an error with
> 
>    "+"(C,B).all
> 
> but it wouldn't be a syntax error; the error would be that the
> compiler didn't know what "+" meant.  This could be hypothetically
> fixed with something like
> 
>    Some_Package."+"(C, B).all
> 
> USE TYPE can also fix that problem by making "+" directly visible,
> i.e. visible without needing a package name.  But it still can't make
> illegal syntax illegal.)

Ah, that makes sense. Thanks. The problem wasn't visibility; it was 
legality. Yannick's reference to the definition of names was 
dispositive:

<http://www.adaic.com/standards/05rm/html/RM-4-1.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: prefix of dereference must be a name?

[Adam Beneschan]

On Jul 30, 12:09 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> I'd like to be able to do the following:
>
> type T is record ... end record;
> type T_Access is access all T;
>
> function "+" (Left, Right in : ...) return T_Access;
>
> A : T_Access := new T;
> B : T_Access := new T;
> C : T_Access := A + B;
>
> A.all := (C + B).all;
>
> but GNAT complains that "prefix for selection is not a name", pointing
> to (C + B).all.
>
> So then I tried:
>
> function "-" (Token : in T_Access) return T_Access
> is begin
>     return Token;
> end;
>
> A.all := -(C + B).all;
>
> and got the same error. Finally I tried:
>
> function Copy (Token : in T_Access) return T_Access
> is begin
>     return Token;
> end;
>
> A.all := Copy (C + B).all;
>
> And the compiler was happy.
>
> What's the rationale for this?
>
> I assume one issue here is that "-" might be an intrinsic, but since
> the type involved is not a numeric type, I don't see how that could be
> a problem.
>
> Similarly for ().all; when could that be a problem?

You should look over AI05-0003.  I think there's a fair amount of
sympathy for your position; I agree that it would have been better to
have less distinction between "names" and "expressions", but the
problem just never made it high enough on the priority list.  It's
simple to say "You should be able to use an expression with an
operator wherever you could use the equivalent function call", but not
at all simple to change the language rules consistently and make sure
the change doesn't cause any other problems, and probably not at all
simple for all the compiler vendors to make the necessary changes.

AI05-0003 will fix one related issue, I think, to allow qualified
expressions [Type'(Function_Call(...))] to be used where they
currently can't.  I felt this one was important, because using
qualified expressions is sometimes the only reasonable way to
eliminate ambiguities in overloading cases---or at least the only non-
clunky way.  In your examples, you *could* always replace (A+B) with
"+"(A,B) to get around the problem, so it's not as important to have
this fixed, and a decision has to be made about whether it's worth the
effort.  But I agree that it would have been nice if the language had
been designed "right" at the beginning.

                                         -- Adam

Re: prefix of dereference must be a name?

[Yannick Duchêne Hibou57]

On 4 août, 03:45, Adam Beneschan <a...@irvine.com> wrote:
> You should look over AI05-0003.  I think there's a fair amount of
> sympathy for your position; I agree that it would have been better to
> have less distinction between "names" and "expressions", but the
> problem just never made it high enough on the priority list.  It's
> simple to say "You should be able to use an expression with an
> operator wherever you could use the equivalent function call", but not
> at all simple to change the language rules consistently and make sure
> the change doesn't cause any other problems, and probably not at all
> simple for all the compiler vendors to make the necessary changes.
>
> AI05-0003 will fix one related issue, I think, to allow qualified
> expressions [Type'(Function_Call(...))] to be used where they
> currently can't.  I felt this one was important, because using
> qualified expressions is sometimes the only reasonable way to
> eliminate ambiguities in overloading cases---or at least the only non-
> clunky way.  In your examples, you *could* always replace (A+B) with
> "+"(A,B) to get around the problem, so it's not as important to have
> this fixed, and a decision has to be made about whether it's worth the
> effort.  But I agree that it would have been nice if the language had
> been designed "right" at the beginning.
>
>                                          -- Adam

Although I agree about your arguments for a more intuitive and less
badly-restrictive syntax, I still try to understand why it is like it
is, and I suppose there were some good reasons, like avoiding too
much deep expressions. Perhaps it was in the hope it would help
readability and maintenance, forcing the decomposition of some
expressions in intermediate steps.

While for the simple example you gave, “ Type'(Function_Call(...)) ”,
this hypothetical reason would surely not apply.