Language Lawyer question 
Author Message
 Language Lawyer question

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://www.*-*-*.com/ ~wgroleau



Tue, 19 Nov 2002 03:00:00 GMT  
 Language Lawyer question

Quote:

>    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



Tue, 19 Nov 2002 03:00:00 GMT  
 Language Lawyer question


Quote:
> 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?



Tue, 19 Nov 2002 03:00:00 GMT  
 Language Lawyer question

Quote:


> > 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.

Quote:
> 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.)

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

(Modular_Type'(0))'Pred

--

San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.



Tue, 19 Nov 2002 03:00:00 GMT  
 Language Lawyer question

Quote:

> 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.



Thu, 21 Nov 2002 03:00:00 GMT  
 Language Lawyer question

Quote:
> 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

Quote:
> 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.

Quote:
> 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



Fri, 22 Nov 2002 03:00:00 GMT  
 Language Lawyer question

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

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

- Bob



Fri, 22 Nov 2002 03:00:00 GMT  
 Language Lawyer question

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

> - Bob

    Once upon a time, before Ada 83, there was no "standard" way to do
overload
resolution in Ada.  Various people came up with approaches that worked
in a reasonable
amount of time, but the best was a three pass algorithm, a top-down pass
finding all the possible matches ignoring sub-expressions, a bottom-up
pass removing nodes where it was not possible to match all the
parameters, and then a top-down pass marking the correct interpretation
(and insuring that there were no ambiguities).  The FSU team came up
with a way to eliminate the first pass, and showed that the
combinatorial explosion issue was not as bad as had been thought.  They
published the algorithm in Ada Letters.

    From then on ANY change to the overload resolution rules was
measured against that algorithm.  If it made it easier to implement or
faster, fine.  If it made the rules harder to test or risked
combinatorial explosion, then that alternative rule was unlikely to be
adopted.

    In Ada 95, some of the alternatives that had been thrown out in
1980-1982 made it back into the language--computer memories were much
larger and processors faster and some of these "simplifications" to the
syntax were allowed in, such as the new preference rule, and widening
the context for aggregates in assignment statements.



Sat, 23 Nov 2002 03:00:00 GMT  
 Language Lawyer question

Quote:
> 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.

Sorry, the subtype explanation and the lexical explanation both made
sense.
But in the above, the context would still resolve any overloading.  (I
think)

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



Sat, 30 Nov 2002 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Dispatching and generics - language lawyer question

2. Dispatching and generics - language lawyer question

3. Language lawyer question - private packages.

4. language lawyer question, PURE subroutines again

5. language lawyer question

6. language lawyer question: TARGET, dummys, aliasing

7. Record aggregate question (language lawyer needed!)

8. Question for language lawyers

9. constraint error question for language lawyers

10. Lisp standard question (for language lawyers)

11. Be your own Language Lawyer: Reading a Language Manual -- TCSIGAda --

12. casecrash: language lawyers: C'mon!

 

 
Powered by phpBB® Forum Software