Unary operator after binary operator: legal or not?

Unary operator after binary operator: legal or not?

[Jeffrey R. Carter]

Here's something confusing I encountered:

with Ada.Strings.Unbounded;

function Xyz (Left, Right : in Ada.Strings.Unbounded.Unbounded_String)
return String is
    function "+" (Right : in Ada.Strings.Unbounded.Unbounded_String)
    return String renames Ada.Strings.Unbounded.To_String;
begin -- Xyz
    if +Left <= +Right then
       return +Left & +Right;
       --            ^ Error reported here.
    end if;
end Xyz;

A compiler reports "missing operand", referencing the space after the "&".

Why then does it accept the comparison in the previous line? Both are

+Left [binary operator] +Right

-- 
Jeff Carter
"Have you gone berserk? Can't you see that that man is a ni?"
Blazing Saddles
38

Re: Unary operator after binary operator: legal or not?

[Markus E.L.]

> Here's something confusing I encountered:
>
> with Ada.Strings.Unbounded;
>
> function Xyz (Left, Right : in Ada.Strings.Unbounded.Unbounded_String)
> return String is
>     function "+" (Right : in Ada.Strings.Unbounded.Unbounded_String)
>     return String renames Ada.Strings.Unbounded.To_String;
> begin -- Xyz
>     if +Left <= +Right then
>        return +Left & +Right;
>        --            ^ Error reported here.
>     end if;
> end Xyz;
>
> A compiler reports "missing operand", referencing the space after the "&".
>
> Why then does it accept the comparison in the previous line? Both are
>
> +Left [binary operator] +Right

Precedence?

Regards -- Markus

Re: Unary operator after binary operator: legal or not?

[Adam Beneschan]

On Jul 30, 3:52 pm, "Jeffrey R. Carter"
<spam.jrcarter....@acm.nospam.org> wrote:
> Here's something confusing I encountered:
>
> with Ada.Strings.Unbounded;
>
> function Xyz (Left, Right : in Ada.Strings.Unbounded.Unbounded_String)
> return String is
>     function "+" (Right : in Ada.Strings.Unbounded.Unbounded_String)
>     return String renames Ada.Strings.Unbounded.To_String;
> begin -- Xyz
>     if +Left <= +Right then
>        return +Left & +Right;
>        --            ^ Error reported here.
>     end if;
> end Xyz;
>
> A compiler reports "missing operand", referencing the space after the "&".
>
> Why then does it accept the comparison in the previous line? Both are
>
> +Left [binary operator] +Right

I think that was a deliberate decision.  See the BNF in 4.4.  The
operands of "and", "and then", "or", "or else", "xor", "in", or
relational operators are <simple_expression>.  The definition of a
<simple_expression> is

  [unary_adding_operator] term {binary_adding_operator term}

A unary_adding_operator is part of the syntax of <simple_expression>
but not of <term>, so the consequences is that the right operator of a
binary_adding_operator (or a multiplying_operator, or "**" or "abs" or
"not") can't start with a unary adding operator, unless you
parenthesize it.  But the right operand of a relational operator or
one of the logical operators I listed above *can* start with a unary
adding operator.

                         -- Adam

Re: Unary operator after binary operator: legal or not?

[Jeffrey R. Carter]

Adam Beneschan wrote:
> 
> I think that was a deliberate decision.  See the BNF in 4.4.  The
> operands of "and", "and then", "or", "or else", "xor", "in", or
> relational operators are <simple_expression>.  The definition of a
> <simple_expression> is
> 
>   [unary_adding_operator] term {binary_adding_operator term}
> 
> A unary_adding_operator is part of the syntax of <simple_expression>
> but not of <term>, so the consequences is that the right operator of a
> binary_adding_operator (or a multiplying_operator, or "**" or "abs" or
> "not") can't start with a unary adding operator, unless you
> parenthesize it.  But the right operand of a relational operator or
> one of the logical operators I listed above *can* start with a unary
> adding operator.

I missed that. I knew logical and relational operators were separated 
from other binary operators to get reasonable precedence behavior, but 
didn't remember they had special syntax rules to allow this.

And "abs" and "not" ARE permitted after binary adding and multiplying 
operators, further confusing the issue.

I'd think being consistent would be be preferable.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29

Re: Unary operator after binary operator: legal or not?

[anon]

This maybe a compiler error.  It seams that my GNAT 2.1 from (NYC) as 
well as my GNAT 4.3 (GNU) and my Adacore GNAT 2005 (GPL) all state 
the same that it there is a "missing operand". But if you use the 
following:
       return "+"(Left) & "+"(Right);
or 
       return (+Left) & (+Right);
they both work

From LRM 4.4 .. 4.5 and LRM 6.6 states that the unary functions can be 
redefined.  The reason I say this may be an compiler error is because 
the following will still give the same error: 

Compiling: xyz.adb (source file time stamp: 2007-07-30 03:00:04)

     1. 
     2. function Xyz (Left, Right : in integer) return integer is
     3. 
     4. begin -- Xyz
     5.     if +Left <= +Right then
     6.        return +Left * +Right;
                             |
        >>> missing operand

     7.     end if;
     8. end Xyz;




In <KYtri.46105$Fc.35820@attbi_s21>, "Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes:
>Here's something confusing I encountered:
>
>with Ada.Strings.Unbounded;
>
>function Xyz (Left, Right : in Ada.Strings.Unbounded.Unbounded_String)
>return String is
>    function "+" (Right : in Ada.Strings.Unbounded.Unbounded_String)
>    return String renames Ada.Strings.Unbounded.To_String;
>begin -- Xyz
>    if +Left <= +Right then
>       return +Left & +Right;
>       --            ^ Error reported here.
>    end if;
>end Xyz;
>
>A compiler reports "missing operand", referencing the space after the "&".
>
>Why then does it accept the comparison in the previous line? Both are
>
>+Left [binary operator] +Right
>
>-- 
>Jeff Carter
>"Have you gone berserk? Can't you see that that man is a ni?"
>Blazing Saddles
>38

Re: Unary operator after binary operator: legal or not? => Compiler Error

[anon]

In <h%Bri.384485$p47.369566@bgtnsc04-news.ops.worldnet.att.net>, anon@anon.org (anon) writes:
>This maybe a compiler error.  It seams that my GNAT 2.1 from (NYC) as 
>well as my GNAT 4.3 (GNU) and my Adacore GNAT 2005 (GPL) all state 
>the same that it there is a "missing operand". But if you use the 
>following:
>       return "+"(Left) & "+"(Right);
>or 
>       return (+Left) & (+Right);
>they both work
>
>From LRM 4.4 .. 4.5 and LRM 6.6 states that the unary functions can be 
>redefined.  The reason I say this may be an compiler error is because 
>the following will still give the same error: 
>
>Compiling: xyz.adb (source file time stamp: 2007-07-30 03:00:04)
>
>     1. 
>     2. function Xyz (Left, Right : in integer) return integer is
>     3. 
>     4. begin -- Xyz
>     5.     if +Left <= +Right then
>     6.        return +Left * +Right;
>                             |
>        >>> missing operand
>
>     7.     end if;
>     8. end Xyz;
>

Forgot to add, in my modified math version, if you replace the "+Right" 
with "+7" which is a simple_expression it still will give an error. And 
because you could replace the "+7" with "-7", for negative numbers, 
which is also a simple_expression you still get an error. This means you 
have found a compiler error!

This needs to be reported!


>In <KYtri.46105$Fc.35820@attbi_s21>, "Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes:
>>Here's something confusing I encountered:
>>
>>with Ada.Strings.Unbounded;
>>
>>function Xyz (Left, Right : in Ada.Strings.Unbounded.Unbounded_String)
>>return String is
>>    function "+" (Right : in Ada.Strings.Unbounded.Unbounded_String)
>>    return String renames Ada.Strings.Unbounded.To_String;
>>begin -- Xyz
>>    if +Left <= +Right then
>>       return +Left & +Right;
>>       --            ^ Error reported here.
>>    end if;
>>end Xyz;
>>
>>A compiler reports "missing operand", referencing the space after the "&".
>>
>>Why then does it accept the comparison in the previous line? Both are
>>
>>+Left [binary operator] +Right
>>
>>-- 
>>Jeff Carter
>>"Have you gone berserk? Can't you see that that man is a ni?"
>>Blazing Saddles
>>38
>

AW: Unary operator after binary operator: legal or not? => CompilerError

[Grein, Christoph (Fa. ESG)]

>     1. 
>     2. function Xyz (Left, Right : in integer) return integer is
>     3. 
>     4. begin -- Xyz
>     5.     if +Left <= +Right then
>     6.        return +Left * +Right;
>                             |
>        >>> missing operand
>
>     7.     end if;
>     8. end Xyz;
>

> Forgot to add, in my modified math version, if you replace the
"+Right" 
> with "+7" which is a simple_expression it still will give an error.
And 
> because you could replace the "+7" with "-7", for negative numbers, 
> which is also a simple_expression you still get an error. This means
you 
> have found a compiler error!
>
>This needs to be reported!

Nonsense! The compiler is correct. See the syntax RM 4.4 (4-6). (This
has been properly answered already by someone else.)

A factor (6) is a primary, not a simple_expression (4).


Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Robert A Duff]

anon@anon.org (anon) writes:

> In <h%Bri.384485$p47.369566@bgtnsc04-news.ops.worldnet.att.net>, anon@anon.org (anon) writes:
>>This maybe a compiler error.  It seams that my GNAT 2.1 from (NYC) as 
>>well as my GNAT 4.3 (GNU) and my Adacore GNAT 2005 (GPL) all state 
>>the same that it there is a "missing operand". But if you use the 
>>following:
>>       return "+"(Left) & "+"(Right);
>>or 
>>       return (+Left) & (+Right);
>>they both work
>>
>>From LRM 4.4 .. 4.5 and LRM 6.6 states that the unary functions can be 
>>redefined.  The reason I say this may be an compiler error is because 
>>the following will still give the same error: 
>>
>>Compiling: xyz.adb (source file time stamp: 2007-07-30 03:00:04)
>>
>>     1. 
>>     2. function Xyz (Left, Right : in integer) return integer is
>>     3. 
>>     4. begin -- Xyz
>>     5.     if +Left <= +Right then
>>     6.        return +Left * +Right;
>>                             |
>>        >>> missing operand
>>
>>     7.     end if;
>>     8. end Xyz;
>>
>
> Forgot to add, in my modified math version, if you replace the "+Right" 
> with "+7" which is a simple_expression it still will give an error. And 
> because you could replace the "+7" with "-7", for negative numbers, 
> which is also a simple_expression you still get an error. This means you 
> have found a compiler error!
>
> This needs to be reported!

If there's a bug, it's a bug in the language definition.  ;-)

GNAT is correctly implementing the syntax rules, here.
"X * +7" and "X * -7" and "X * -Y" and so forth are
all illegal.  See RM-4.4.

There is a similar example in RM-4.5(17), with the comment
"-- parentheses are necessary".

This has nothing to do with user-defined operators.
It's just the syntax rules -- defining your own
operators doesn't change the syntax.

- Bob

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Dmitry A. Kazakov]

On Tue, 31 Jul 2007 11:05:05 -0400, Robert A Duff wrote:

> If there's a bug, it's a bug in the language definition.  ;-)

But not in this place. There should be user-defined subtypes, which would
eliminate any need in tricks like defining nonsensical "+", just in order
to have a shortest possible name for the conversion, which otherwise should
be automatic.

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

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 31 Jul 2007 11:05:05 -0400, Robert A Duff wrote:
>
>> If there's a bug, it's a bug in the language definition.  ;-)
>
> But not in this place. There should be user-defined subtypes, which would
> eliminate any need in tricks like defining nonsensical "+", just in order
> to have a shortest possible name for the conversion, which otherwise should
> be automatic.

Agreed.

But don't you think:

    X * -3

ought to be legal (no user-defined operators in sight)?

- Bob

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Georg Bauhaus]

On Tue, 2007-07-31 at 11:53 -0400, Robert A Duff wrote:

> But don't you think:
> 
>     X * -3
> 
> ought to be legal (no user-defined operators in sight)?

You'r kidding, aren't you? Next thing would be

   X *- 3;

Or, can't we have X + -3, please?

Why is --3 not positive? I get a strange compiler error.

  --Georg

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Adam Beneschan]

On Jul 31, 10:02 am, Georg Bauhaus <rm.tsoh
+bauh...@maps.futureapps.de> wrote:
> On Tue, 2007-07-31 at 11:53 -0400, Robert A Duff wrote:
> > But don't you think:
>
> >     X * -3
>
> > ought to be legal (no user-defined operators in sight)?
>
> You'r kidding, aren't you? Next thing would be
>
>    X *- 3;
>
> Or, can't we have X + -3, please?

I want to be able to say "c = a+++b" like I can in C.

What I can't figure out is, my C compiler accepts "c = a+++b" but it
doesn't
seem to accept "c = a+++++b", which should clearly be equivalent to
c = (a++) + (++b).  Is this a bug in the language, or in my C
compiler?

                 -- Adam

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Maciej Sobczak]

On 31 Lip, 21:17, Adam Beneschan <a...@irvine.com> wrote:

> What I can't figure out is, my C compiler accepts "c = a+++b"

Yes.

> but it
> doesn't
> seem to accept "c = a+++++b"

Right.

> which should clearly be equivalent to
> c = (a++) + (++b).

Why do you think so? On what basis?

The C (and C++) parser is greedy, which means that it tries to eat as
much as it can to get the valid token. The first two pluses in 'a++++
+b' give a single token '++'. The next two pluses give another *valid*
token, which is again '++'. And so on. The only problem is that two
such tokens one after another, while still being *valid* tokens, do
not form a valid expression (cannot post-increment the r-value that
results from the first post-increment).

Note that you can/should write:

c = a++ + ++b;

which does what you expect (except that post-increment has no benefits
over pre-increment here).

Hint: keep the formatting of your code readable. Your compiler just
refuses the code that would be hard to read by a human being - why do
you consider it to be a bug in the language? :-)

--
Maciej Sobczak
http://www.msobczak.com/

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Adam Beneschan]

On Aug 1, 12:16 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 31 Lip, 21:17, Adam Beneschan <a...@irvine.com> wrote:
>
> > What I can't figure out is, my C compiler accepts "c = a+++b"
>
> Yes.
>
> > but it
> > doesn't
> > seem to accept "c = a+++++b"
>
> Right.
>
> > which should clearly be equivalent to
> > c = (a++) + (++b).
>
> Why do you think so? On what basis?

Sorry, I guess I should have used a smiley.  I thought it was obvious
that I was being silly.

                        -- Adam

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Robert A Duff]

Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de> writes:

> On Tue, 2007-07-31 at 11:53 -0400, Robert A Duff wrote:
>
>> But don't you think:
>> 
>>     X * -3
>> 
>> ought to be legal (no user-defined operators in sight)?
>
> You'r kidding, aren't you?

I wasn't...

>...Next thing would be
>
>    X *- 3;

OK, you make a good point.

But what's the general principle?  Can't write two operators in a row?
Then why is "X=-3" legal?  (Of course I would normally write "X = -3".)

And why does -11 mod 5 = -1?

> Or, can't we have X + -3, please?
>
> Why is --3 not positive? I get a strange compiler error.

;-)

- Bob

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Georg Bauhaus]

Robert A Duff wrote:

> 
> But what's the general principle?

My guess is,  "logical and relational operators were separated
from other binary operators to get reasonable precedence behavior",
as per Jeff Carter. And likely an architect would not want
to build on top of chains of punctuation symbols condensing
meaning into character sequences that look more like molecules
rather than text.

IIRC, ML and APL have no overloadings of '-' for negation
and subtration. Will users still see a readability problem
once there are more satisfactory solutions of the two cases:

 -X

and

 +"Y"

Or perhaps Robert Dewar's suggestion to reserve one punctuation
symbol not currently in the language for user defined operator
overloading might help, like "$"? Or, since $ is used in some
preprocessors, one symbol that is wisely picked from the set
of symbols available in ISO 10646. Just one.

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Dmitry A. Kazakov]

On Wed, 01 Aug 2007 09:24:33 +0200, Georg Bauhaus wrote:

> Or perhaps Robert Dewar's suggestion to reserve one punctuation
> symbol not currently in the language for user defined operator
> overloading might help, like "$"? Or, since $ is used in some
> preprocessors, one symbol that is wisely picked from the set
> of symbols available in ISO 10646. Just one.

Huh, Georg, you were so happy about Unicode. Now you miss such an excellent
opportunity to use the "advantages" of! There are whole lotta code
positions to grab. I vote for "voiceless central-plus-lateral alveolar
fricative" (U+02AA) for that purpose. Such operators qualify as a speech
pathology, I think. (:-))

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

AW: Unary operator after binary operator: legal or not? => CompilerError

[Grein, Christoph (Fa. ESG)]

> "voiceless central-plus-lateral alveolar fricative" (U+02AA)

Or Miriam Makeba's famous click sound :-)


Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 

Re: AW: Unary operator after binary operator: legal or not? => CompilerError

[Ian Clifton]

Grein, Christoph (Fa ESG) <Christoph.Grein@eurocopter.com> writes:

    >> "voiceless central-plus-lateral alveolar fricative" (U+02AA)

> Or Miriam Makeba's famous click sound
> :-)

Wow, what a wonderful page of Unicode! I've found my
all-time-favourite character (U+02AD). Whoever thought an abstruse
discussion of Ada syntax would lead there!

-- 
Ian Clifton                   Phone: +44 1865 275677
Chemistry Research Laboratory Fax:   +44 1865 285002
Oxford University             ian.clifton@chem.ox.ac.uk
Mansfield Road   Oxford OX1 3TA   UK

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Georg Bauhaus]

On Wed, 2007-08-01 at 10:02 +0200, Dmitry A. Kazakov wrote:
> On Wed, 01 Aug 2007 09:24:33 +0200, Georg Bauhaus wrote:
> 
> > Or perhaps Robert Dewar's suggestion to reserve one punctuation
> > symbol not currently in the language for user defined operator
> > overloading might help, like "$"? Or, since $ is used in some
> > preprocessors, one symbol that is wisely picked from the set
> > of symbols available in ISO 10646. Just one.
> 
> Huh, Georg, you were so happy about Unicode. Now you miss such an excellent
> opportunity to use the "advantages" of! There are whole lotta code
> positions to grab. I vote for "voiceless central-plus-lateral alveolar
> fricative" (U+02AA) for that purpose.

A better choice might be something neutral,

- A symbol that stands out and is easier to distinguish
  from other characters than ASCII '0' is from 'O'.

- is not a currency symbol.

- In a pinch, can be produced by a 9pin needle printer,
  and be distinguishable.

- A symbol that is not mistaken for a display problem.

- Also, it should be readily available on most contemporary
  workstations, terminals, or PCs. 

- Other important qualities might be the amount of symmetry,

- a lack of conventional meaning to avoid presumptions.

- Perhaps the operator symbol should also be free from potential
  political issues deriving from symbolic associations.

- The glyphs should have reasonably few "relatives" (we can
  live with 0 and O, 1 and l, so no silly pseudo-arguments
  about glyphs of character sets, please)

- It will need to be stressed that everything that looks new will
  create well known reactions in stereotypical machine
  programmers just like in the stereotypical peasants. Both are
  always skeptical of the unknown almost by definition (Useless!
  Have been working without it for generations! -- Well, why Ada
  then, why generics, and why O-O? ;-)

Examples:

"◆"	Black Diamond
"⚫"	Medium black circle
"⊡"	Squared dot operator
"⊚"	Circled ring operator

Note that none of these have been chosen from the set of
widely used mathematical symbols. (Of course, someone _is_
using these symbols, would they exist otherwise.)
A few example uses:

  X := Y ◆ 4;

  X := ◆"Allô !";

Black, bold, standing out, simple.
(Unlike a white diamond, a black diamond does not look like
anything else, even with reduced eye sight: In X := Y ◇ 4;
the white diamond maybe does look like some other character.)

  X := Y ⚫ 4;

  X := ⚫"Allô !";

Similar.
Needless to say, we already have '0' and 'O' and 'o' in
Ada 83, so please avoid adding another white, empty circle.
Instead, use two:

  X := Y ◎ 4;

  X := ◎"Allô !";

I prefer squares over circles because squares don't look like
any other symbol of Ada (Ada does not have '[' and ']' brackets,
so misunderstandings are unlikely):

  X := Y ⊡ 4;

  X := ⊡"Allô !";

Here is a counterexample that in my view doesn't seem to work well
on all computers: "⌘", the Place of interest sign. It might
be displayed like a blurred 'x' or like a blurred multiplication
symbol.

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Jeffrey R. Carter]

Georg Bauhaus wrote:
> 
> Or perhaps Robert Dewar's suggestion to reserve one punctuation
> symbol not currently in the language for user defined operator
> overloading might help, like "$"? Or, since $ is used in some
> preprocessors, one symbol that is wisely picked from the set
> of symbols available in ISO 10646. Just one.

Personally, I like unary function "\".

-- 
Jeff Carter
"Mr. President, we must not allow a mine-shaft gap!"
Dr. Strangelove
33

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Dmitry A. Kazakov]

On Tue, 31 Jul 2007 11:53:50 -0400, Robert A Duff wrote:

> But don't you think:
> 
>     X * -3
> 
> ought to be legal (no user-defined operators in sight)?

Maybe it was a typing error of:

    X * Y - 3

If not, then probably it is a style error:

   - X * 3

I find Ada's association restrictions a god idea. In earlier days C/C++
liberal policy of handling associations was a real problem. Nowadays, one
gets a warning in some cases, but Ada is far stricter and for all I think
that the idea of warning is itself not OK. Ideally, any program should be
either legal or not. Nothing in between. Any warning is a kind of defeat in
language design.

Of course if we considered -3 being a literal, that would change a lot. But
that would be IMO a bad idea.

BTW, following the reductionist's path, what about eliminating decimal
literals, introducing "." and "E" operators instead?

function "." (Numerator, Denominator : Universal_Integer)
   return Universal_Real;

 (:-))

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

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Charles Lindsey]

In <wccy7gwa7sh.fsf@shell01.TheWorld.com> Robert A Duff <bobduff@shell01.TheWorld.com> writes:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> On Tue, 31 Jul 2007 11:05:05 -0400, Robert A Duff wrote:
>>
>>> If there's a bug, it's a bug in the language definition.  ;-)
>>
>> But not in this place. There should be user-defined subtypes, which would
>> eliminate any need in tricks like defining nonsensical "+", just in order
>> to have a shortest possible name for the conversion, which otherwise should
>> be automatic.

>Agreed.

>But don't you think:

>    X * -3

>ought to be legal (no user-defined operators in sight)?

Interestingly, that example works in ALGOL 68, which generally speaking is
as pernickety a language as you are likely to get.

--x works too. Essentially, all the monadic operators have a higher
preference than the dyadic ones.

The only case where this turns out to be a little odd is

   -2^2
which is to be contrasted with the effect of
   x-2^2
and even there it is only the method of parsing that changes. The result
is actually the same.

(INT x = 2
;print((x*-3, --x,-2^2,x-2^2))
)
 

which prints

STARTING ...
         -6          +2          +4          -2
 ... AND YET ANOTHER ALGOL68 PROGRAM RUNS TO COMPLETION
 CPU  0.17



>- Bob
-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Stuart]

"Charles Lindsey" <chl@clerew.man.ac.uk> wrote in message 
news:JM5yyp.Azp@clerew.man.ac.uk...

<snip>

> Interestingly, that example works in ALGOL 68, which generally speaking is
> as pernickety a language as you are likely to get.
>
> --x works too. Essentially, all the monadic operators have a higher
> preference than the dyadic ones.

It can also work in Ada - just not as an arithmetic operation ;-)
      MyLongNameResult := MyLongNameInput--2
                                          +MyLongNameAddend;

I have never really been enamoured with the Ada choice of comment marker, 
especially when there were many other unused/lesser used characters 
available.

-- 
Stuart 

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Dmitry A. Kazakov]

On Thu, 2 Aug 2007 20:44:49 GMT, Charles Lindsey wrote:

> In <wccy7gwa7sh.fsf@shell01.TheWorld.com> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 
>>But don't you think:
> 
>>    X * -3
> 
>>ought to be legal (no user-defined operators in sight)?
> 
> Interestingly, that example works in ALGOL 68, which generally speaking is
> as pernickety a language as you are likely to get.
> 
> --x works too. Essentially, all the monadic operators have a higher
> preference than the dyadic ones.

The Ada's rule is not about precedence it is about association. Unary minus
does not associate with itself in Ada. This was a deliberate decision.

> The only case where this turns out to be a little odd is
> 
>    -2^2
>
> which is to be contrasted with the effect of
>    x-2^2

No problem, if you wanted -2**2 |= -(2**2), but 2**-2 |= 2**(-2), you would
just extend the precedence model, see

http://www.dmitry-kazakov.de/ada/components.htm#Parsers_etc

(chapter 8.2.2)

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

Re: Unary operator after binary operator: legal or not? => Compiler Error

[anon]

PROOF!

Using the three statements
 
  return +Left & +Right;
  return +Left * +Right;
  return +Left * -7;

we get the following three Expressions 

  +Left & +Right;
  +Left * +Right
  +Left * -7

Ada LRM 4.4 ( 2 ) =>  expression ::= relation 

  +Left & +Right;
  +Left * +Right
  +Left * -7

Ada LRM 4.4 ( 3 ) =>  relation ::= simple_expression 

  +Left & +Right;
  +Left * +Right
  +Left * -7

Ada LRM 4.4 ( 4 ) =>  simple_expression ::= [unary_adding_operator] 
                                            term 
                                            {binary_adding_operator term}

  ::=  +Left & +Right
       +      => is the unary, 
       Left   => is a Term,
       &      => binary_adding_operator 
       +Right => is second term 

  ::=  +Left * +Right
       +      => is the unary, 
       Left   => is a Term,
       *      => binary_adding_operator 
       +Right => is second term 

  ::=  +Left * -7
       +      => is the unary, 
       Left   => is a Term,
       *      => binary_adding_operator 
       -7     => is second term

For now, skiping Left as a Term, because no compiler error and to save 
time.

Using the second Term!
Ada LRM 4.4 ( 5 ) =>   term ::= factor 

  +Right
  -7

Ada LRM 4.4 ( 6 ) =>   factor ::= primary 

  +Right
  -7

Ada LRM 4.4 ( 7 ) =>   primary ::= numeric_literal | .. | (expression)

  +Right  => is defined as an expression
  -7      => is defined as an expression

Back to Ada LRM 4.4 ( 2 ) => expression ::= relation 

  +Right
  -7

Ada LRM 4.4 ( 3 ) =>  relation ::= simple_expression 

  +Right
  -7

Ada LRM 4.4 ( 4 ) =>  simple_expression ::= [unary_adding_operator] 
                                            term 
                                            {binary_adding_operator term}

  ::=   +Right
        +     => is the unary, 
        Right => term 
 
  ::=  -7
       -  => is the unary, 
       7  => term


Ada LRM 4.4 ( 5 ) =>   term ::= factor 

  Right
  7

Ada LRM 4.4 ( 6 ) =>   factor ::= primary 

  Right
  7

Ada LRM 4.4 ( 7 ) =>   primary ::= numeric_literal | string_literal 

  Right  => string_literal 
  7      => numeric_literal

All three  expressions are valid Ada expressions

  +Left & +Right
  +Left * +Right
  +Left * -7

Which means that the following three statement are valid!

  return +Left & +Right;
  return +Left * +Right;
  return +Left * -7;

Since GNAT gives an error!
That Denote This is a GNAT COMPILER ERROR!

And No Parenthesize Are Required!

GNAT COMPILER ERROR!



In <KdCri.384503$p47.38112@bgtnsc04-news.ops.worldnet.att.net>, anon@anon.org (anon) writes:
>In <h%Bri.384485$p47.369566@bgtnsc04-news.ops.worldnet.att.net>, anon@anon.org (anon) writes:
>>This maybe a compiler error.  It seams that my GNAT 2.1 from (NYC) as 
>>well as my GNAT 4.3 (GNU) and my Adacore GNAT 2005 (GPL) all state 
>>the same that it there is a "missing operand". But if you use the 
>>following:
>>       return "+"(Left) & "+"(Right);
>>or 
>>       return (+Left) & (+Right);
>>they both work
>>
>>From LRM 4.4 .. 4.5 and LRM 6.6 states that the unary functions can be 
>>redefined.  The reason I say this may be an compiler error is because 
>>the following will still give the same error: 
>>
>>Compiling: xyz.adb (source file time stamp: 2007-07-30 03:00:04)
>>
>>     1. 
>>     2. function Xyz (Left, Right : in integer) return integer is
>>     3. 
>>     4. begin -- Xyz
>>     5.     if +Left <= +Right then
>>     6.        return +Left * +Right;
>>                             |
>>        >>> missing operand
>>
>>     7.     end if;
>>     8. end Xyz;
>>
>
>Forgot to add, in my modified math version, if you replace the "+Right" 
>with "+7" which is a simple_expression it still will give an error. And 
>because you could replace the "+7" with "-7", for negative numbers, 
>which is also a simple_expression you still get an error. This means you 
>have found a compiler error!
>
>This needs to be reported!
>
>
>>In <KYtri.46105$Fc.35820@attbi_s21>, "Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes:
>>>Here's something confusing I encountered:
>>>
>>>with Ada.Strings.Unbounded;
>>>
>>>function Xyz (Left, Right : in Ada.Strings.Unbounded.Unbounded_String)
>>>return String is
>>>    function "+" (Right : in Ada.Strings.Unbounded.Unbounded_String)
>>>    return String renames Ada.Strings.Unbounded.To_String;
>>>begin -- Xyz
>>>    if +Left <= +Right then
>>>       return +Left & +Right;
>>>       --            ^ Error reported here.
>>>    end if;
>>>end Xyz;
>>>
>>>A compiler reports "missing operand", referencing the space after the "&".
>>>
>>>Why then does it accept the comparison in the previous line? Both are
>>>
>>>+Left [binary operator] +Right
>>>
>>>-- 
>>>Jeff Carter
>>>"Have you gone berserk? Can't you see that that man is a ni?"
>>>Blazing Saddles
>>>38
>>
>

Re: Unary operator after binary operator: legal or not? => Compiler Error

[Adam Beneschan]

On Jul 31, 4:22 pm, a...@anon.org (anon) wrote:

> Ada LRM 4.4 ( 6 ) =>   factor ::= primary
>
>   +Right
>   -7
>
> Ada LRM 4.4 ( 7 ) =>   primary ::= numeric_literal | .. | (expression)
>
>   +Right  => is defined as an expression
>   -7      => is defined as an expression

What happened to those nice parentheses around "expression" that the
above syntax rule requires?  Did you think they were there in the RM
just for decoration?

No wonder you won't post using your real name.

                      -- Adam

Re: Unary operator after binary operator: legal or not? => Illegal

[anon]

My Typo! Or was I too tied and hungry to see them!

The Final word comes from Ada LRM 4.5.1 ( 17 ). Examples that 
the Ada Committee gave us.

    Y**(-3)              --  parentheses are necessary

This is defined in 83, 95 and 2005 LRM. Which makes it LAW!


To most languages the parentheses are not required.  Actually some 
languages even define the -3 as a numeric_literal. But this difference 
is what makes Ada a pain for some and a delight for others.


But since the expression option is define as "(expression)"
instead of "( expression )" I chose to define the parentheses to 
denote to use the BNF expression instead of the definition found 
in LRM 4.4 ( 1 ).  

Now, If the clause was "( expression )" which this clearly denotes 
that you must have a left parenthese followed by the expression 
which is followed by a right parenthese. And I would have agree 
with you earlier!

But with the example stated in the LRM I can not argue. 

So, I Stand corrected!

As for why I go by "Anon" that my business!


In <1185927237.362545.195380@d30g2000prg.googlegroups.com>,  Adam Beneschan <adam@irvine.com> writes:
>On Jul 31, 4:22 pm, a...@anon.org (anon) wrote:
>
>> Ada LRM 4.4 ( 6 ) =>   factor ::= primary
>>
>>   +Right
>>   -7
>>
>> Ada LRM 4.4 ( 7 ) =>   primary ::= numeric_literal | .. | (expression)
>>
>>   +Right  => is defined as an expression
>>   -7      => is defined as an expression
>
>What happened to those nice parentheses around "expression" that the
>above syntax rule requires?  Did you think they were there in the RM
>just for decoration?
>
>No wonder you won't post using your real name.
>
>                      -- Adam
>

AW: Unary operator after binary operator: legal or not? => CompilerError

[Grein, Christoph (Fa. ESG)]

Oh anon boy, no need to shout! Better learn to read BNF.

> That Denote This is a GNAT COMPILER ERROR!

  +Left & +Right;

simple_expression ::= [unary_adding_operator]
                      term 
                      {binary_adding_operator term}

       +      => is the unary, 
       Left   => is a Term,
       &      => binary_adding_operator 
       +Right => So this must be a term to make the thing legal

term ::= factor {multiplying_operator factor}

So +Right must be a factor

factor ::= primary

So +Right must be a primary

primary ::= numeric_literal | (expression)

So you claim +Right is a numeric literal - interesting


Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 

To := Grein, Christoph (Fa. ESG)

[anon]

Even though I made a mistake about the parentheses. My BNF reading 
was correct. I did cut the BNF definitions to valid statements and 
opions only. So, you need to reread my post. 

I said:

Ada LRM 4.4 ( 7 ) =>   primary ::= numeric_literal | .. | (expression)

  +Right  => is defined as an expression
  -7      => is defined as an expression

-- ---------------------------- --
-- For other statements see other post --
-- ---------------------------- --

Ada LRM 4.4 ( 7 ) =>   primary ::= numeric_literal | string_literal 

  Right  => string_literal 
  7      => numeric_literal


So, where did I claim that "+Right" was a numeric literal?  I do not 
see that.  I define the "+Right" as an expression and then later 
define "Right" as a string_literal.  which is correct except that the
expression definition requires parentheses.




In <mailman.15.1185946484.3834.comp.lang.ada@ada-france.org>, "Grein, Christoph (Fa. ESG)" <Christoph.Grein@eurocopter.com> writes:
>Oh anon boy, no need to shout! Better learn to read BNF.
>
>> That Denote This is a GNAT COMPILER ERROR!
>
>  +Left & +Right;
>
>simple_expression ::= [unary_adding_operator]
>                      term 
>                      {binary_adding_operator term}
>
>       +      => is the unary, 
>       Left   => is a Term,
>       &      => binary_adding_operator 
>       +Right => So this must be a term to make the thing legal
>
>term ::= factor {multiplying_operator factor}
>
>So +Right must be a factor
>
>factor ::= primary
>
>So +Right must be a primary
>
>primary ::= numeric_literal | (expression)
>
>So you claim +Right is a numeric literal - interesting
>
>
>Eurocopter Deutschland GmbH
>Sitz der Gesellschaft/Registered Office: Donauwoerth
>Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
>Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
>Geschaeftsfuehrung/Board of Management:
>Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt
>
>CONFIDENTIALITY NOTICE 
>
>This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
>If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
>It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 
>

AW: To := Grein, Christoph (Fa. ESG)

[Grein, Christoph (Fa. ESG)]

Anon,

You seem to have a dogmatic attitude. You *did* make a mistake in
reading BNF - you omitted the (). So since +Right has no opening par.,
this cannot be an expression, as you've learned by now.

There were several posts correcting your claim that there is a compiler
bug, but you insisted.

> Even though I made a mistake about the parentheses. My BNF reading 
> was correct. I did cut the BNF definitions to valid statements and 
> opions only. So, you need to reread my post.


Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 

Re: AW: To := Grein, Christoph (Fa. ESG)

[anon]

In <mailman.16.1185952313.3834.comp.lang.ada@ada-france.org>, "Grein, Christoph (Fa. ESG)" <Christoph.Grein@eurocopter.com> writes:
>Anon,
>
>You seem to have a dogmatic attitude. 

        -- --------------------------- --
        --  True programmers are that way!  --
        -- --------------------------- --

>
>There were several posts correcting your claim that there is a compiler
>bug, but you insisted.
>

Did they, now! What I saw was opions with a few agumenting that it 
should be legal or others trying to alter the Ada definitions. The post 
about have "++++++" or something in c/c++ like that.  Not looking at 
the posting at the movement. They did this instead of giving the 
correct answer which is not very constructive to others is it.

        -- ---------------------------------------- --
        --  I did not see the True RM rule aka RM 4.4 ( 7 )  --
        --  with it example RM 4.5 ( 17 ) until I happen to  --
        -- see it.  Looking for something else.                --
        -- ---------------------------------------- --

And for you!  You tried to alter my definition to "+Right was 
defined as a numeric_literal".  Which shows that you can make 
mistakes as well. But have you owned up it it?



>> Even though I made a mistake about the parentheses. My BNF reading 
>> was correct. I did cut the BNF definitions to valid statements and 
>> opions only. So, you need to reread my post.
>
>
>Eurocopter Deutschland GmbH
>Sitz der Gesellschaft/Registered Office: Donauwoerth
>Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
>Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
>Geschaeftsfuehrung/Board of Management:
>Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt
>
>CONFIDENTIALITY NOTICE 
>
>This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
>If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
>It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 
>

AW: AW: To := Grein, Christoph (Fa. ESG)

[Grein, Christoph (Fa. ESG)]

>>You seem to have a dogmatic attitude. 
>
>       -- --------------------------- --
>        --  True programmers are that way!  --
>        -- --------------------------- --

True programmers don't use Ada.


Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 

Re: AW: AW: To := Grein, Christoph (Fa. ESG)

[Markus E.L. 2]

"Grein, Christoph (Fa. ESG)" wrote:

>>>You seem to have a dogmatic attitude. 
>>
>>       -- --------------------------- --
>>        --  True programmers are that way!  --
>>        -- --------------------------- --
>
> True programmers don't use Ada.

True programmers use which language then? :-),

Regards -- Markus

Re: AW: AW: To := Grein, Christoph (Fa. ESG)

[tmoran]

> True programmers use which language then? :-),

Why Fortran, assembly, octal, toggling switches, or whatever's the best for
the job at hand, of course.

Re: AW: AW: To := Grein, Christoph (Fa. ESG)

[Ed Falis]

On Thu, 02 Aug 2007 19:02:56 -0400, <tmoran@acm.org> wrote:

>> True programmers use which language then? :-),
>
> Why Fortran, assembly, octal, toggling switches, or whatever's the best  
> for
> the job at hand, of course.


Well, for the job at hand, I always prefer switch-toggling.  You can feel  
it under your fingers, you know?

Re: AW: AW: To := Grein, Christoph (Fa. ESG)

[Markus E.L. 2]

'tmoran AT acm DOT org' wrote:

>> True programmers use which language then? :-),
>
> Why Fortran, assembly, octal, toggling switches, or whatever's the best for
      -------

Oh d*mn, I forgot that. :-). And of course true programmers TALK IN
CAPITAL LETTERS - that explains some things in Anon's writing style
and also explains why Ada is not a TRUE PROGRAMMERS language: It's
written Ada, not ...

Regards - Markus

AW: AW: AW: To := Grein, Christoph (Fa. ESG)

[Grein, Christoph (Fa. ESG)]

>>>>>You seem to have a dogmatic attitude. 
>>>
>>>       -- --------------------------- --
>>>        --  True programmers are that way!  --
>>>        -- --------------------------- --
>>
>> True programmers don't use Ada.
>
> True programmers use which language then? :-),

Dunno, but real porgrammers don't use Pascal either ;-)


Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 

Re: AW: To := Grein, Christoph (Fa. ESG)

[Markus E.L. 2]

'Colossus DOT Pike AT worldnet DOT att DOT net (anon)' wrote:

> In <mailman.16.1185952313.3834.comp.lang.ada@ada-france.org>, "Grein, Christoph (Fa. ESG)" <Christoph.Grein@eurocopter.com> writes:
>>Anon,
>>
>>You seem to have a dogmatic attitude. 
>
>         -- --------------------------- --
>         --  True programmers are that way!  --
>         -- --------------------------- --

True programmers aren't that way. True programmers go with the flow.


>>There were several posts correcting your claim that there is a compiler
>>bug, but you insisted.
>>
>
> Did they, now! What I saw was opions with a few agumenting that it 
> should be legal or others trying to alter the Ada definitions. The post 

Actually you saw at least two references to the ARM with proof that
your assertions where wrong.

>         --  I did not see the True RM rule aka RM 4.4 ( 7 )  --
>         --  with it example RM 4.5 ( 17 ) until I happen to  --

The examples are certainly instructive, but my idea is that they
aren't normative. So I wouldn't rely on the examples (without
understanding which rule apply to them).

Regards -- Markus