[M3devel] The role INTEGER and subranges in Modula-3

[mika at async.caltech.edu]

Very clear explanation.  I might even have been sold on LONGINT.

Well, almost. 

Thanks for the explanation, anyhow!

     Mika

"Rodney M. Bates" writes:
>I am suspecting there is some misunderstanding about Modula-3's approach
>to integer sizes.
>
>The original idea is to use subrange types, (which are
>programmer-defined,) not different builtin types, to match the value
>range you need.  The safety rules of the language ensure that values
>stored in variables are in the type's range.  But all arithmetic is
>done in the full native word size of the machine.
>
>Types are more abstract than most languages, in that different machine
>representations (particularly, bit count) need not be different base
>types in the language.
>
>There are no implicit type conversions.  Instead, this need is met by
>the concept of assignability.  If the abstract value is in a
>variable's range, it can be assigned to the variable.  Size changes,
>if needed, are the code generator's problem.
>
>All this drastically simplifies the language, while also allowing the
>programmer to define an exact match between type-imposed value ranges
>and what the application needs, rather than just a few powers of two.
>Having implied type conversions, which also interact with sizes of
>intermediate arithmetic results, requires many pages of language
>definition that we avoid.
>
>LONGINT, which I have advocated, flies in the face of this tidy
>scheme.  If we could do all arithmetic efficiently in the biggest size
>likely to be commonly needed, LONGINT would have no place.  But native
>sized arithmetic is always the most efficient.  In today's world,
>there are two very common classes of use cases: 1) 32-bit arithmetic
>is wide enough, 2) 32-bit is not wide enough, but 64-bit is.  In both
>cases, on machines of either native arithmetic size, we want the best
>efficiency.  LONGINT is for case 2, and when you further need to be
>able to run on either size of machine.  INTEGER is for otherwise.
>
>Whether you believe in LONGINT or not, there is certainly no
>justification for more base integer types than two: one the native
>size of the machine and one bigger.
>
>Note that, as defined in Modula-3 today, INTEGER and LONGINT are
>always distinct types (distinct, regardless of either their value
>ranges or of the machine's native word size), with no subtype relation
>between them, no assignability between them, no implied conversions
>between them, no mixed arithmetic operators, no questions about
>intermediate result range, and literals of unambiguous type.  Thus we
>stay out of the semantic tar pit most languages fall into with
>multiple integer sizes, while giving the programmer drastically more
>choices on range limits.
>
>Note that original Modula-3, in contrast to the single integer type,
>has three floating point types, no doubt motivated by the messy
>realities of taking full advantage of hardware-provided arithmetics.
>These three have the same type isolation properties as INTEGER and
>LONGINT, with the same consequences.  In fact, the integer type
>isolation is directly modeled after the floating type isolation.
>
>-- 
>Rodney Bates
>rodney.m.bates at acm.org