Follow-up to my original posting (Re: RM question concerning types)

Follow-up to my original posting (Re: RM question concerning types)

[Steven Holtsberg]

I believe that if the following slight change were made to the reference
manual, it would be OK.

RM 3.5

For any scalar type T or for any subtype T of a scalar type, the
following attributes are defined:                                              7

T' FIRST	Yields the lower bound of T.  The value of this attribute
                has the same base type as T.
                             ^^^^
T' LAST		Yields the upper bound of T.  The value of this attribute
                has the same base type as T.
                             ^^^^

Re: Follow-up to my original posting (R

[stt]

A scalar value doesn't *have* a "subtype"; it belongs to
each subtype of its type which includes the value in its range.

The only difference between
"base type" and "type" has to do with subtype issues, where
"base type" is really "base subtype," which is the subtype
with the maximal range supported by the type.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

2nd follow-up to my previous posting (Re: RM question concerning types)

[Steven Holtsberg]

In article <22@dim.sm.unisys.com> steve@dim.sm.unisys.com (I) write:
>I believe that if the following slight change were made to the reference
>manual, it would be OK.
>
>RM 3.5
>
>For any scalar type T or for any subtype T of a scalar type, the
>following attributes are defined:                                              7
>
>T' FIRST	Yields the lower bound of T.  The value of this attribute
>                has the same base type as T.
>                             ^^^^
>T' LAST		Yields the upper bound of T.  The value of this attribute
>                has the same base type as T.
>                             ^^^^

I was wrong.  In (RM) 3.3, it is stated that the base type
of a type is the type itself.  So, changing "type" to "base type"
does not change the above sentences.  Therefore, T, declared by

type T is range l..r

must be a subtype, not a type.  If T is taken as a subtype, then
the description in RM 3.5 is OK.

Now, the only question is why do they allow declaration of such static subtypes?
(E.g., type T is range l..r instead of subtype T is integer_type range l..r).
The only reason I can think of is to allow the particular implementation to
choose which base type to use--which of course, leads to non-portable code.

Re: 2nd follow-up to my previous posting (Re: RM question concerning types)

[Robert Firth]

In article <23@dim.sm.unisys.com> steve@dim.sm.unisys.com (Steven Holtsberg) writes:

>Now, the only question is why do they allow declaration of such static subtypes?
>(E.g., type T is range l..r instead of subtype T is integer_type range l..r).
>The only reason I can think of is to allow the particular implementation to
>choose which base type to use--which of course, leads to non-portable code.

Sorry if the above was a typo, Steven, but the intent of a declaration such
as

	type INDEX is range 0 .. 100_000;

is to allow PORTABLE code.  The compiler is required to map this onto an
intrinsic type that has at least the required range.  For example, on a
VAX-11 the base type will be "longword", on an MC68020 it will be "long",
and so on.

The declaration can therefore be moved unchanged from one machine to
another.  Contrast this with the trouible the C folks in the nearby
newsgroup have with their "int" of who knows what size.