gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gm2] INTEGER CARDINAL compatibility


From: Andreas Fischlin
Subject: Re: [Gm2] INTEGER CARDINAL compatibility
Date: Sat, 23 Feb 2008 12:16:13 +0100
User-agent: Thunderbird 2.0.0.9 (Macintosh/20071031)

Dear Gaius,

Yes it does include any relational comparisons. The basic M2 rule for expressions being that within an expression all terms must be compatible, this means of the same type (note the subtlety that i: INTEGER; myi: MYINT; with TYPE MYINT=INTEGER makes i and myi compatible => compatible type means NOT same type identifier. This property being exploited by compilers by mapping all types to a unique LONGINT number and reducing type checking to a simple integer comparison). From this follows comparisons are not allowed by comparing between any pair of INTEGER, CARDINAL, SHORTINT, LONGINT, SHORTCARD, and LONGCARD. Reason being that a comparison is an expression as given by M2 EBNF:

   expression = SimpleExpression [relation SimpleExpression].

Concerning DEC(c,i) or DEC(i,c) they are both legal. The result of DEC or INC is given by the context, i.e. the type of the first argument determines what it is. Many standard functions are overloaded (OOP, Ada), that's why they are there in the first place.

Moreover, please note, that in general DEC and INC should also operate on any scalar type, this includes also enumeration types, and accepts in the forms INC(v,n) or DEC(v,n) as n any simple expression of the following integer types (independent of the scalar type v):

si: SHORTINT; sc: SHORTCARD; i: INTEGER; c: CARDINAL; li: LONGINT; lc: LONGCARD;

In particular note that the following is legal:
 ...
 VAR e: (blue, red, green); i: INTEGER;
BEGIN
 e := blue; i := 1; DEC(e,2*i);
 ...

However, being syntactically legal has nothing to do with the values. The latter is only a run-time issue and if the result of the DEC operation (or INC operation) does cause a range error for the target scalar type (above example will), that exception depends on the current handling of such errors (typically compiler option dependent). Yet, no compiler error is expected to be issued in above example. Only humans know that above example causes inevitably a run time error.

Regards,
Andreas


Gaius Mulley wrote:
Hi,

I'm in the middle of correcting the compatibility between INTEGERs
and CARDINALs during assignment, expression, parameter passing
and INC and DEC.  (With appropriate runtime range checking).

I see from PIM4 and ISO that mixed expressions using an INTEGER
and CARDINAL variable are disallowed.  But I couldn't find whether
this also includes:

MODULE foo ;
VAR
   i: INTEGER ;
   c: CARDINAL ;
BEGIN
   IF i>c
   THEN

   END
END foo.

from my reading is that this is illegal according to ISO and PIM, but
this does seem restrictive..  I was just wondering whether I'd missed
something, or misinterpreted something?

Conversely its my understanding that:

DEC(c, i)    (* legal providing 0 <= i <= MAX(CARDINAL)
                (* the later always true for i *) *)

and
DEC(i, c)    (* legal providing 0 <= c <= MAX(INTEGER) *)


regards,
Gaius


_______________________________________________
gm2 mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/gm2

--

________________________________________________________________________
Andreas Fischlin, Ph.D., Group Director

Terrestrial Systems Ecology
Institute of Integrative Biology: Ecology, Evolution, Infectious Disease
Department of Environmental Sciences, ETH Zurich

Address:
ETH Zurich, CHN E35.1
8092 Zurich, Switzerland

Phone: +41 44 633-6090 / Fax: +41 44 633-1031
http://www.sysecol.ethz.ch/Staff/af/
http://www.sysecol.ethz.ch/

    _/_/_/ _/_/_/ _/  _/
   _/       _/   _/  _/   Eidgenoessische Technische Hochschule Zuerich
  _/_/_/   _/   _/_/_/   Swiss Federal Institute of Technology Zurich
 _/       _/   _/  _/   Ecole polytechnique federale de Zurich
_/_/_/   _/   _/  _/   Politecnico federale de Zurigo

            Make it as simple as possible, but distrust it!
________________________________________________________________________





reply via email to

[Prev in Thread] Current Thread [Next in Thread]