🚀 go-pugleaf

Expires: 
Sender: 
Reply-To: aplusl@bernina.UUCP (Albert Meier)
Followup-To: 
Distribution: comp.lang.modula2
Organization: ETH Zuerich, Switzerland
Keywords: 

Here is now the exact proposal from Pat Terry (SA) and me (CH). We have
been asked to post it. As mentioned before for Switzerland it is the
second choice (the third has been decided in Nice, the first choice is
reconsidering the BSI proposal voted against in Nice). Pat has no access
to Usenet but he kindly greets you all. Here it comes:

To:   Persons interested in type conversions in Modula-2
 
From: Pat Terry, Computer Science, Rhodes University, GRAHAMSTOWN 6140
 
_______________________________________________________________________________________________________________
 
 
 
The Nice ISO standardisation meeting adopted a proposal of mine
concerning
"safe" type conversions, I suspect reluctantly, and with good reason.
The
proposal was motivated mainly by a desire to clear a log-jam, and with
an
eye on what was about to follow (the discussion on the status of ORD,
TRUNC
and FLOAT). Albert Meier and I would like to make a compromise
suggestion.
 
It is of interest to review the various proposals made for safe
conversions.  The position in PIM, I believe, can be summarised in the
following table, which omits the potential complications from range
errors.
 
 
                         To convert an Expression of type
 
                Integer Cardinal    Real    Longreal    Char     Enum
      To a result
      of type
 
      Integer      -       VAL       *         *         *         *
 
      Cardinal    VAL/ORD   -      TRUNC       *        ORD       ORD
 
      Real         *      FLOAT      -         *         *         *
 
      Longreal     *        *        *         -         *         *
 
      Char         *     VAL/CHR     *         *         -         *
 
      Enum         *       VAL       *         *         *         -
 
 
Here the * entries represent "no direct one-step conversion" and the -
entries represent "no conversion needed".  "Enum" means any enumerated
type, including BOOLEAN.
 
In fact, I am not certain how one converts directly from an integer to a
cardinal.  A close reading of PIM suggests that ORD is used, but I have
seen VAL advocated, and I have seen compilers do strange things here
too.
Another viewpoint is that ORD(MIN(INTEGER)) should return 0, but this is
really rather ludicrous, and I do not think anyone would take this
seriously.
 
One is struck with the sparseness of the table.  Some conversions are
really horrible, for example from integer to real.  Presumably one
really
needs code like
 
     IF I > 0 THEN R := FLOAT(ORD(I)) ELSE R := - FLOAT(ORD(ABS(I)) END
 
which would be very tiresome if complicated compound expressions were
needed.
 
One gets the distinct impression that the implementors of the original
compilers never have any need for writing any number-crunching programs
-
or indeed, any that use REAL at all.  One could level the same criticism
at
their total disregard for COMPLEX, but that is a rather different issue.
When I teach students here they are completely amazed at the difficulty
which using REAL seems to present.
 
The BSI proposal for safe conversions, as I can see it (stripped of the
LONGCARD, LONGINT, SHORTINT etc baggage which I think we can agree is a
side issue here), can be summarised in the following table.
 
 
                         To convert an Expression of type
 
                Integer Cardinal    Real    Longreal    Char     Enum
      To a result
      of type
 
      Integer      -     INTEGER   INTEGER   INTEGER     *         *
 
      Cardinal  CARDINAL    -      CARDINAL  CARDINAL  CARDINAL CARDINAL

      Real        REAL     REAL      -        REAL       *         *
 
      Longreal  LONGREAL LONGREAL  LONGREAL    -         *         *
 
      Char         *      CHAR       *         *         -         *
 
      Enum         *      DAYS       *         *         *         -
 
 
 
 
 
The proposal adopted at the Nice meeting can be summarised as follows
 
                         To convert an Expression of type
 
                Integer Cardinal    Real    Longreal    Char     Enum
      To a result
      of type
 
      Integer      -    CONVERT    CONVERT   CONVERT     *         *
 
      Cardinal  CONVERT     -  CONVERT/TRUNC CONVERT  CONVERT/ORD
CONVERT/ORD
 
      Real      CONVERT CONVERT/FLOAT -      CONVERT     *         *
 
      Longreal  CONVERT CONVERT    CONVERT     -         *         *
 
      Char         *    CONVERT/CHR  *         *         -         *
 
      Enum         *    CONVERT      *         *         *         -
 
 
The objection to this is aesthetic - it is very clumsy to use
CONVERT(T,x)
when a nice simple function would look better.  The objections to the
BSI
proposal are really that they introduce new semantics into old syntax.
The
argument in favour of ORD, TRUNC and CHR is that they are familiar and
already part of the language.
 
The point need to be made that the "standard" functions in Modula-2 are
mostly highly non-standard, in that many of them are in fact generic.
Once
this is accepted, there seems no reason why similar functions should not
be
as generic as ORD (which maps "any" ordinal type to CARDINAL), for
example,
and why FLOAT should not be able to map "any" numerical value to REAL.
Admittedly, REAL would be a better name than FLOAT, but that's history
that
we cannot rewrite.
 
The suggestion Albert and I would like to make is summarised in the
following table.  It introduces three new pervasive identifiers INT,
CARD
and LFLOAT.
 
 
                         To convert an Expression of type
 
                Integer Cardinal    Real    Longreal    Char     Enum
      To a result
      of type
 
      Integer      -       INT      INT       INT       INT       INT
 
      Cardinal   CARD/ORD   -     CARD/TRUNC  CARD    CARD/ORD  CARD/ORD

      Real       FLOAT    FLOAT      -        FLOAT      *         *
 
      Longreal   LFLOAT   LFLOAT   LFLOAT      -         *         *
 
      Char       CHR       CHR       *         *         -         *
 
      Enum       CONVERT  CONVERT    *         *         *         -
 
 
CHR, TRUNC and ORD are retained for historical reasons.  The matrix is
now
symmetric, and the usage of CONVERT would probably be minimal in
practice.
CARD could be dispensed with, and ORD used throughout, but CARD and INT
would make a nice pair, with the intent fairly obvious.
 
There is a lurking problem in that if an implementation wants to have
SYSTEM.LONGCARD or SYSTEM.SHORTINT or whatever, this seems to require a
further plethora of names.  However, we could still demand that CARD,
INT,
FLOAT, LFLOAT apply to arguments of any of these types, and would need
only
to  introduce LCARD, LINT, SCARD, SINT and so on.
 
 
 SSS   N   N  V   V      SNV       SWISS STANDARDIZATION BODY
S      NN  N  V   V      149/UK2   Programming Languages
 SSS   N N N  V   V      Chairman  Albert Meier, CH-8906 Bonstetten
    S  N  NN   V V       . E-mail  aplusl@ifi.ethz.(ch/UUCP)
 SSS   N   N    V                  ...mcvax!cernvax!ethz!aplusl