[M3devel] INTEGER vice INT32

[Peter Eiserloh]

Hi Tony,

Both Jay, and yourself have valid points.

One can classify the two kinds of types, as implicit, and 
explicit.  

More specifically, INTEGER is implicit, and is useful for
in-memory representation.  This was especially important 
when machine registers were very different between machines.
Very few remember the days of 18-bit words, with 9-bit 
bytes (thank you!).  An implicit type is very useful, 
when you are not worried about external representation
and all one needs is the logical behavior of the type,
independent of the particular machine on which one may
currently be.

Explicit types are much more useful, if not imperative, 
when defining data types for external storage (in files, 
or network protocols).

For binary file IO many people take a naive approach, and
simply overlay a data structure onto the file stream.  
This ignores the potential difference in sizes of implicit
types, and their endianess.   A more careful method of
doing binary files, is to distinguish the external from
the internal representation, and have procedures to do
the IO a field at a time.  See binIO.

Back in the late 1980's, and early 1990s, I had an Amiga 
computer, and had two different "C" compilers: Aztec, C
and SAS/C.  The Aztec compiler int was 16-bits, whereas 
the SAS/C int was 32 bits.  As you can imagine this caused 
all sorts of havoc.  The Amiga system includes were 
rewritten with somewhat more explicit types. These were 
macros such as ULONG, SLONG, USHORT, SSHORT, UBYTE, and 
SBYTE. 

This illustrates the importance of explicit types.
Both implicit and explicit types have their place.


Peter



Date: Wed, 16 Dec 2009 20:10:14 -0500
From: Tony Hosking <hosking at cs.purdue.edu>
Subject: Re: [M3devel] Oops, forgot to ask
To: Jay K <jay.krell at cornell.edu>
Cc: m3devel <m3devel at elegosoft.com>
Message-ID: <EF60618E-7AE3-4FF9-A805-5B8B83B369E2 at cs.purdue.edu>
Content-Type: text/plain; charset="us-ascii"

>On 16 Dec 2009, at 19:52, Jay K wrote:
>
>> "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 
>bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER?
>> 
>> 
>> See..LONGINT is only useful in this brief period where we still have 32bit INTEGER.
>> (Actually it would have been useful long ago.)
>
>LONGINT could be 128 bits for all its definition cares.  It is just 
>something usually (not always) bigger than an INTEGER.
>
>>  I really think "long" is a dumb name..
>> There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, 
>UINT64, and unsigned and signed integers the same size of a pointer, 
>possibly called INT and UINT, or size_t and ptrdiff_t..
>
>Now these are dumb names because they wire in the size of the value.
>
>In Modula-3 INTEGER is a natural (i.e., word-size) value.


+--------------------------------------------------------+
| Peter P. Eiserloh                                      |
+--------------------------------------------------------+