Language Lawyer question

Language Lawyer question

[Wes Groleau]

One of my coworkers just asked an interesting question:

   Why do we have to write

      Some_Type'Pred (Some_Value)

   when

      Some_Value'Pred

   is more natural/intuitive and
   carries just as much type info?

I pointed out that there is no type info in a literal (like
Orange'Pred) but he said that the type info would be somewhere 
else in the statement.  I could not quickly come up with a
counter-example.  Plus, how often would we use a literal as
parameter to 'Pred ?  Might as well just use the literal value 
of the Predecessor.


-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: Language Lawyer question

[Paul Graham]

Wes Groleau wrote: 
>    Why do we have to write
>       Some_Type'Pred (Some_Value)
>    when
>       Some_Value'Pred
>    is more natural/intuitive and
>    carries just as much type info?
> 
> I pointed out that there is no type info in a literal (like
> Orange'Pred) but he said that the type info would be somewhere
> else in the statement.  I could not quickly come up with a
> counter-example. Plus, how often would we use a literal as
> parameter to 'Pred ?  Might as well just use the literal value 
> of the Predecessor.

It could be Some_Type'Pred(f(x)) for an arbitrary function f (this has
the same problem as your example using a literal, but is more realistic.

Or you might want to say Integer'Pred(1+1), which is easier to parse
than (1+1)'Pred.

An attribute like 'Pred has a kind of qualified expression syntax, if
you think of Pred as an overloaded function predefined on all discrete
types.  Then the type qualifier Some_Type' resolves the overloading.

Paul

Re: Language Lawyer question

[Keith Thompson]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
> Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote in message
> news:39380CEB.2CC4682E@ftw.rsc.raytheon.com...
> > One of my coworkers just asked an interesting question:
> >
> >    Why do we have to write
> >       Some_Type'Pred (Some_Value)
> >    when
> >       Some_Value'Pred
> >    is more natural/intuitive and
> >    carries just as much type info?

The grammar for an attribute reference is
     attribute_reference ::= prefix'attribute_designator
where
     prefix ::= name | implicit_dereference

Of course, that doesn't really answer the question; the grammar could
have been defined to allow an arbitrary expression as a prefix.  I
suppose it was defined that way for the sake of clarity, to prevent
expressions from becoming overly complex.

> What is 0'Pred?

If it were legal, it should be the same as 0 - 1 -- which means the
resolution would depend on the context.  (Note that the equivalence
between Foo'Pred and Foo - 1 wouldn't apply to enumeration types.)

> But, how would you do the equivalent of Modular_Type'Pred (0)
> with your syntax?

(Modular_Type'(0))'Pred

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Language Lawyer question

[David C. Hoos, Sr.]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote in message
news:39380CEB.2CC4682E@ftw.rsc.raytheon.com...
> One of my coworkers just asked an interesting question:
>
>    Why do we have to write
>
>       Some_Type'Pred (Some_Value)
>
>    when
>
>       Some_Value'Pred
>
>    is more natural/intuitive and
>    carries just as much type info?
>
> I pointed out that there is no type info in a literal (like
> Orange'Pred) but he said that the type info would be somewhere
> else in the statement.  I could not quickly come up with a
> counter-example.  Plus, how often would we use a literal as
> parameter to 'Pred ?  Might as well just use the literal value
> of the Predecessor.
>
What is 0'Pred?

1.  Illegal if Natural
2.  -1 if Integer
3,  2 ** modulus - 1 if modular

Now if you meant Some_Object'Pred -- that's possible

But, how would you do the equivalent of Modular_Type'Pred (0)
with your syntax?

Re: Language Lawyer question

[Robert I. Eachus]

Keith Thompson wrote:

> The grammar for an attribute reference is
>      attribute_reference ::= prefix'attribute_designator
> where
>      prefix ::= name | implicit_dereference
> 
> Of course, that doesn't really answer the question; the grammar could
> have been defined to allow an arbitrary expression as a prefix.  I
> suppose it was defined that way for the sake of clarity, to prevent
> expressions from becoming overly complex.

   Actually, it is a lexical problem, not a parsing issue.  In Ada 80,
the  rule for distinguishing character literals, strings, and the
apostrophes in attributes was unnecessarily complex.  It wasn't
ambiguous, but looking at  fragments like Character''''&''''Last or
A'('a','b','c')'Range should show you the problem.  The lexical analyzer
can figure it out, but trying to do sensible error correction is a
horror.  (Again, it has been a long time since I was working with Ada
definitions before Ada 83, so that first example may be preliminary
Ada.  You can see why the parentheses are now required around qualified
expressions.)  During the ANSI standardization process, someone
suggested the following rule:  If the token before the apostrophe is not
an identifier or right parenthesis, the apostrophe is the beginning of a
literal.  If the next token is a left parenthesis, you have a qualified
expression.  Otherwise, it had better be an attribute.  (I think Ted
Baker may have been the first to propose this, but it ws one of those
rules that gelled.  Once there were no exceptions, no one was going to
allow any back in the language.  The two pass overload resolution
algorithm, definitely from Ted, was another similar case.)

   So in Ada 80, we all basically agreed that any implementor who
defined a single character attribute name--especially if it could be
used as the prefix oof another attribute--had to be nuts, and left it at
that.  In what became Ada 83, the rules were tightened up so that there
were no violations of the technique possible.  Allowing attributes of
arbitrary expressions would just take us back to the bad old days, but
if you allow attributes of an expression in parentheses, it wouldn't
break existing lexical analyzers.

Re: Language Lawyer question

[Robert Dewar]

In article <yec1z2fr6zs.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> > What is 0'Pred?
>
> If it were legal, it should be the same as 0 - 1 -- which
means the
> resolution would depend on the context.


Truly ugly! Currently, pred has nothing whatsoever to do with
the "-" operator. Creating such a linkage would be really
nasty!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Language Lawyer question

[Robert A Duff]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

> What is 0'Pred?

It depends on context, just like any other overload resolution
question.  If that were legal, then we could write:

    X: Integer;
    type Modular is mod 123;
    Y: Modular;

    X := (0)'Pred;
    Y := (0)'Pred;

and they would resolve to the appropriate type, just as if you had
written something like "X := -(0);"  Or, for that matter, "X := 0;".

In the rare cases where context doesn't determine the type already, you
use a qualified expression:

    if 0'Pred = -1 then -- Ambiguous; illegal.
    
    if Integer'((0)'Pred) = -1 then -- OK

    if (Integer'(0)'Pred) = -1 then -- OK
    
    if (0)'Pred = Integer'(-1) then -- OK

> 1.  Illegal if Natural
> 2.  -1 if Integer

Well, Natural and Integer are the same *type*, which is all overload
resolution cares about.  Also, Integer'Pred and Natural'Pred are the
same -- Natural'Pred(0) is legal, and does not raise any exception -- it
returns -1.  So, presumably if (0)'Pred were legal syntax, it would do
the same thing.

> 3,  2 ** modulus - 1 if modular
> 
> Now if you meant Some_Object'Pred -- that's possible
> 
> But, how would you do the equivalent of Modular_Type'Pred (0)
> with your syntax?

See above -- the same way you deal with overloaded operators applied to
literals.

To answer the original question: There is no very good reason why it's
T'Pred(X) rather than X'Pred.  The syntax could be redesigned to allow
attributes applied to expressions (although as Robert Eachus pointed out
in another note, it's tricky to get that right), and overload resolution
could be used in the normal way to resolve these things.  I suspect the
real reason is simply that the original language designers didn't like
that style -- a matter of taste.

Here's a related question:  Why can't I say:

    subtype Digit is range 0..9;

    function To_Character(X: Digit) return Character is
    begin
        return (String'("0123456789"))(X+1); -- Illegal.
    end To_Character;

?

- Bob

Re: Language Lawyer question

[Robert A Duff]

"Robert I. Eachus" <rieachus@earthlink.net> writes:

>...  The two pass overload resolution
> algorithm, definitely from Ted, was another similar case.)

I'm curious -- what do you mean by that?

- Bob