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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,76878622fd40c57
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-11-17 00:57:29 PST
Path: 
 nntp.gmd.de!xlink.net!sol.ctr.columbia.edu!newsxfer.itd.umich.edu!gatech!swrinde!pipex!uunet!newsgate.watson.ibm.com!watnews.watson.ibm.com!ncohen
From: ncohen@watson.ibm.com (Norman H. Cohen)
Newsgroups: comp.lang.ada
Subject: Re: GNAT-Problem  Set_Line(), Set_Col()
Date: 16 Nov 1994 00:04:41 GMT
Organization: IBM T.J. Watson Research Center
Distribution: world
Message-ID: <3abiaq$qn9@watnews1.watson.ibm.com>
References: <395jba$kbs@tucs6.rz.tu-cottbus.de>
 <3aad5q$qn9@watnews1.watson.ibm.com> <3aari4$jlc@felix.seas.gwu.edu>
Reply-To: ncohen@watson.ibm.com
NNTP-Posting-Host: rios8.watson.ibm.com
Date: 1994-11-16T00:04:41+00:00
List-Id: <comp.lang.ada>

In article <3aari4$jlc@felix.seas.gwu.edu>, mfeldman@seas.gwu.edu
(Michael Feldman) writes: 

|> I'd like to hear from Norm or another Ada Wise Person why it was thought
|> necessary to declare a new type for Text_IO.Count, instead of simply using
|> Positive.

In fact, in the Ada 80 RM, it was Positive.  By the July 1982 draft of
the revised RM, it had been changed to a new integer type.  I would guess
from the timing that the change was in response to a comment received
during the ANSI canvass.

It is easy to envision (and it was even easier to envision in 1980) a
16-bit machine for which the natural range for type Integer is
-32_768 .. 32_768, but for which files can easily exceed 32,768 lines (or
the single line of a file with only one line terminator can exceed 32,768
columns).  Then type Integer is not wide enough to serve in the role
played by Text_IO.Count.

|>           I know the usual arguments about portability and predefined types,
|> but of course Text_IO.Count is also a predefined type with implementation
|> defined range, so the advantage is not at all obvious.

It allows the implementation to define an efficient size for type
Integer, based on the width of a machine register, even if that type is
too small for numbering columns, lines, and pages in the target file
system.  Had a single type been used in the RM, the implementation would
have been forced to make type Integer wide enough to number columns,
lines, and pages, possibly imposing a substantial performance penalty
(doing all Integer arithmetic in terms of separate low-order and
high-order halves of a word) for a marginal purpose.  (How often do you
use Set_Line and its cousins?)

|> In my opinion, the use of a new type here causes exactly the kind of
|> confusion Andreas encountered; are the benefits of a distinct type in
|> this case worth it when balanced against the confusion?

I agree that a separate type here is a pain, but it appears to be a
decision made for pragmatic rather than aesthetic reasons.  (After all,
column numbers, line numbers, and page numbers are distinct abstractions,
so if the motivation were methodological, we would expect to see three
different types.  Note also that Text_IO.Field and Text_IO.Number_Base
ARE subtypes of Integer, because any realistic definition of type Integer
would be sufficient to accommodate the uses of those subtypes.)  I don't
think there was any other reasonable choice.

--
Norman H. Cohen    ncohen@watson.ibm.com