From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,388fc53f584bd695
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news1.google.com!news.glorb.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: "Vinzent Hoefler" <nntp-2010-09@t-domaingrabbing.de>
Newsgroups: comp.lang.ada
Subject: Re: Fixed point constants issue
Date: Tue, 14 Sep 2010 20:28:51 +0200
Message-ID: <op.vi1cadcjd20q5n@jellix.jlfencey.com>
References: <op.vizer4qnd20q5n@jellix.jlfencey.com>
 <1f0l0baynq1x7$.phl9cqpwcr37.dlg@40tude.net>
 <op.vizhg5ygd20q5n@jellix.jlfencey.com>
 <fq489oqf49fo$.2yo8f4fno57$.dlg@40tude.net>
 <op.vizozumhd20q5n@jellix.jlfencey.com>
 <i6n66u$3rg$1@news.eternal-september.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
X-Trace: individual.net HYG3DXmdsyF/vbf+J0obOAWhDpLy8ZqOGK6ctzFknQUVylZ9Hm
Cancel-Lock: sha1:8qQ59z0LEhl/EYNGeeM5CnT44+0=
User-Agent: Opera Mail/10.62 (Win32)
Xref: g2news1.google.com comp.lang.ada:14080
Date: 2010-09-14T20:28:51+02:00
List-Id: <comp.lang.ada>

On Tue, 14 Sep 2010 08:54:20 +0200, J-P. Rosen <rosen@adalog.fr> wrote:

> Every language with overloading has to decide whether resolution goes
> from the outside to the inside, or the other way round. In the case of
> Ada, it is the "enclosing context" that determines the type of what's in
> it. If the enclosing context is a type conversion, it tells nothing
> about the expected type of its argument, hence the fall back to
> universal types. If the enclosing context is typed, it determines the
> type of the "*" operator.

I understand that. What I don't understand is that two different compilers  
do
seem to handle it differently. Actually, I just wanted to know which one  
does
it wrong. ;)

Now, to make matters worse:

ARM 3.5(9):
"[...] the evaluation of the range evaluates these simple_expressions
in an arbitrary order, and converts them to the type of the range."

which I read as "_first_ evaluate and _then_ convert". But this only  
applies to
the dynamic case, right?

Then:

ARM 3.5(5):
"For a subtype_indication containing a range_constraint, [...], the type  
of the
range shall resolve to that of the type determined by the subtype_mark of  
the
subtype_indication. For a range of a given type, the simple_expressions of  
the range
(likewise, the simple_expressions of the equivalent range for a
range_attribute_reference) are expected to be of the type of the range."

Which is quite specific and seems to happen here.

Yet, this is not the end:

ARM 3.5.9(3) defines a fixed point definition to have a  
"real_range_specification",
which according to ARM 3.5.7(5) "is expected to be of any real type; the  
types
need not be the same".

Now, I suspect that in

type    Fixed_1 is         delta 0.5 range 0.0 .. 50.0 * 0.1;
subtype Fixed_2 is Fixed_1           range 0.0 .. 50.0 * 0.1;

(where "One_Tenth" shall be a non-static function).

Fixed_1 and Fixed_4 have a range of 0.0 .. 5.0 then, whilst Fixed_2's  
range suddenly
is 0.0 .. 0.0 again, right?


Vinzent.

-- 
There is no signature.