What is a type?

[jacob navia]

I would like to add at the beginning of the C tutorial I am writing
a short blurb about what "types" are. I came up with the following text.

Please can you comment?
Did I miss something?
Is there something wrong in there?
--------------------------------------------------------------------
Types
A type is a definition for a sequence of storage bits. It gives the
meaning of the data stored in memory. If we say that the object a is an
int, it means that the bits stored at that location are to be understood
as a natural number that is built by consecutive additions of powers of
two. If we say that the type of a is a double, it means that the bits
are to be understood as the IEEE 754 standard sequences of bits
representing a double precision floating point value.

Types can be primitive types (i.e. built-in types) or composite types,
i.e. types built from several primitive types.

Functions have a type too. The type of a function is determined by the
type of its return value, and all its arguments. The type of a function
is its interface with the outside world: its inputs (arguments) and its
outputs (return value).
Types in C can be incomplete, i.e. they can exist as types but nothing
is known about them, neither their size nor their bit-layout. They are
useful for encapsulating data into entities that are known only to
certain parts of the program.
Each type can have an associated pointer type: for int we have int
pointer, for double we have double pointer, etc. We can have also
pointers that point to an unspecified object. They are written as void
*, i.e. pointers to void.

The primitive types in lcc-win32 are:
Type Size in lcc-win32 Standard?
bool 1 Available in C99
char (signed/unsigned) 1 yes
short (signed/unsigned) 2 yes
int (signed/unsigned) 4 yes
long (signed/unsigned) 4 yes
long long 8 Available in C99
float 4 yes
double 8 yes
long double 12 Available in C99
complex types 16 May be absent in some

implementations
qfloat 56 Specific to lcc-win32
bignum variable Specific to lcc-win32

 

[pete]

I would like to add at the beginning of the C tutorial I am writing
a short blurb about what "types" are.
I came up with the following text.

Please can you comment?

"primitive types" and "composite types"
seem similar to the terms "basic types" and "aggregate types".
I think by "built-in types", you mean basic types.
It's not clear whether or not composite types include unions.

You mention object types, incomplete types and function types,
but I would emphasize that those three major catagories
are the top layer in the type hierarchy.

I would say that function types,
as well as being determined by the return type,
are determined by the "parameters" rather than the "arguments".
If a function has a parameter of type int,
you can call it with an argument of type char.

Did I miss something?

Alignment requirements are according to type.

Is there something wrong in there?

C doesn't mandate IEEE floating point.

 

[pete]

jacob navia wrote:

I think that's closer to the definition of "object type".

Object types also apply to constant expressions.

 

[jacob navia]

jacob navia wrote:




Alignment requirements are according to type.

I am not sure that this should be at the beginning of the tutorial. I
mention it when I speak about structures later.

C doesn't mandate IEEE floating point.

Right. Will add that.

 

[Chris Torek]

Did I miss something?
Is there something wrong in there?

long double 12 Available in C99
complex types 16 May be absent in some
implementations

complex types are "available in C99", in three flavors: complex
float, complex double, and complex long double. It sounds like
your "complex"es are only available in the "double" variety
(the size being 16 in lcc-win32 -- one should find 8, 16, and 24
given the sizes of float, double, and long double).

 

[jacob navia]

Did I miss something?
Is there something wrong in there?

In addition to what others wrote:

long double 12 Available in C99
complex types 16 May be absent in some
implementations

complex types are "available in C99", in three flavors: complex
float, complex double, and complex long double. It sounds like
your "complex"es are only available in the "double" variety
(the size being 16 in lcc-win32 -- one should find 8, 16, and 24
given the sizes of float, double, and long double).[/QUOTE]

Yes, in principle, but lcc-win32 implements (as of today) only
one kind of complex numbers.

As far as I understood the standard, complex types are not
mandatory for a conforming implementation and many small C
implementations do not provide them at all.

Now, in a tutorial, I can't say everything at once. I explain this
later when I speak about complex types.

 

[jacob navia]

Chris Torek wrote:

I re-read the complex number implementation and I have atypo
in the table. It should be 32, not 16. I implement complexes
only as long double _Complex, and I align them at 16 bytes.

Since this is the highest precision, the results should not be
affected. A problem could arise when reading say float _Complex
from a binary file written by other implementation.

Thanks for your answer.

jacob

 

[Tim Rentsch]

I would like to add at the beginning of the C tutorial I am writing
a short blurb about what "types" are. I came up with the following text.

Please can you comment?
Did I miss something?
Is there something wrong in there?
--------------------------------------------------------------------

Hi Jacob,

As a tutorial introduction I think what you wrote is pretty good. I'm
not sure what you're assuming about the backgrounds or experience of
your readers, so it's hard to assess whether it's too much or too
little.

There is an important piece that has been glossed over, namely the
distinction between program type and representation type. I wrote the
text below as another tack on how to explain what a type is. On
re-reading your text, I think I'm assuming a greater programming
background than your text was. In spite of that, you may find this
explanation helpful. Enjoy.

======================================================================

The word 'type' is used to mean one of two notions, related but
distinct, that have to do with how different kinds of values are
stored or operated on within a computer program.

The first notion has to do with the representation of a variable or
function in program memory. For variables: how many units of memory
does it occupy; what do different bit configurations mean in terms of
the set of values the bits are supposed to represent; which sets of
bits occupy which successive memory units; constraints on which sets
of memory units it can occupy (often called "alignment") - properties
like these define the representation ("type") of a variable or
intermediate value. For functions: what calling conventions need to
be observed when calling the function - where should its parameters
go, where will the return result go, what sort of register saving will
be done; what assumptions are made about the representations for the
arguments, and what representation can be expected for the result -
these properties, and perhaps a few other similar ones, define how a
function is to be represented in program memory (at least, from the
point of view of wanting to call the function, because the only thing
that can be "done" with a function is call it [1]).

The second notion has to do with compile time properties on some
syntactic program elements - declarators, variable names, expressions,
and function definitions are some examples - that specify or constrain
the representations of various run-time program elements - variable
values, intermediate values, or compiled functions. These "types" are
indicated in C by the familiar 'int', 'char', etc, and array, pointer
and function types that are used in C programs.

Historically these two notions were considered to be synonymous and
the word "type" was used for both. Further reflection will show that
they are different. For example, on a machine with eight bit bytes, a
variable of type 'char' may have an eight-bit signed representation,
or it may have an eight-bit unsigned representation. An external
variable declared 'extern int a[];' may be represented by 10 integers
or by 100 integers. A "program type" may also carry more information
than a "representation type": for example, a pointer declared 'const
int *p' will (on most machines) have exactly the same representation
as another pointer declared without the 'const'; or, in the case of
an 'enum' type, the representation will be exactly the same as one of
the integral types, yet the presence of the 'enum' type indicator in
the program text allows more thorough checking (of some programs) at
compile time, even though the (ANSI-standard) compiler itself allows
enum's and int's to be pretty much freely mixed.

It's important that the assumptions about what the correspondence is
between program types and representation types be made consistently
across an implementation. When compiling a program with a compiler
that represents 'int' as 32 bits, it usually will be disastrous to
call a library function that was compiled with a compiler that
represented 'int' with only 16 bits. The program type - int - is the
same in both cases, but the representation type differs between the
two compilers. But, different implementations can and do make
different choices for the mapping of program types to representation
types, sometimes even on the same machine architecture.

Because of these different choices that are made in different
implementations, experienced C developers try to minimize any
dependencies in their programs on the mapping between program types
and representation types. This goal is furthered by use of standardly
defined mechanisms like 'sizeof', 'CHAR_BIT', and so forth, so that
specific representation-type choices will not (insofar as is possible)
influence program behavior.

----------------

[1] In C, functions may also be "operated on" by taking their address
for a pointer-to-function. Depending on specifics of the particular
machine architecture, this requirements for this operation might also
be included in a function's representation.

 

[jacob navia]

I think that you have an important point what type *attributes* are
concerned.

In your example of the difference between int and const int, (the same
with volatile int) the volatile/const qualifiers are type attributes.
The same should be said for functions with _stdcall calling convention
for instance. The basic type of
int _stdcall foo(int);
is the same as
int foo(int);
but this two types differ in the attribute _stdcall.

For a beginner, it looks to me easier to understand the concept of
type attributes that exist only at compile time.

Did I understood you correctly?

jacob

 

[Tim Rentsch]

I think that you have an important point what type *attributes* are
concerned.

In your example of the difference between int and const int, (the same
with volatile int) the volatile/const qualifiers are type attributes.
The same should be said for functions with _stdcall calling convention
for instance. The basic type of
int _stdcall foo(int);
is the same as
int foo(int);
but this two types differ in the attribute _stdcall.

For a beginner, it looks to me easier to understand the concept of
type attributes that exist only at compile time.

Did I understood you correctly?

jacob

It's true that type qualifiers provide the most ready
examples of the program/represenation type distinction,
but not the only ones. Consider: on my platform (gcc
on x86 Linux), both 'int' and 'long' are four byte signed
quantities. The program types are clearly different,
yet the representation types are exactly the same. Also,
in some implementations, the two types

typedef int T1;
typedef struct { int x; } T2;

have exactly the same representation type (again, signed
integers of some length); passing one when the other is
expected wouldn't cause any runtime problems. Yet clearly
these different program types can be distinguished by the
compiler.

The reverse situation - where a single program type
corresponds to multiple representation types - normally
happens in C only for "incomplete [program] types". At
least, I can't think of other cases right off the top of my
head. But certainly it comes up at least in the case
of incomplete types.

So I see the "program type/representation type" distinction
as more fundamental than the distinction of qualified types
vs unqualified types.

How - and how much - one should weave all of these notions
into a tutorial intended for novices - that's not an easy
question to answer. On some machines, for example, pointers
to read-only areas have a different representation than
pointers that can be used for writing (often with a
"write-protected" or "write-enabled" bit); on such machines
the const/non-const distinction _does_ show up in the
representation type. This kind of fine point is almost
certainly too much for the tutorial that I think you're
writing. But I do think that the distinction between
program types and representation types is essential for
people, even novices, to have explained, and to understand
at least at some level.

I hope this explanation helps with your writing.

 

[Dan Pop]

As far as I understood the standard, complex types are not
mandatory for a conforming implementation and many small C
implementations do not provide them at all.

Complex types are optional *only* for freestanding C99 implementations.

For hosted implementations:

11 There are three complex types, designated as float _Complex,
double _Complex, and long double _Complex. The real floating
and complex types are collectively called the floating types.

12 For each floating type there is a corresponding real type,
which is always a real floating type. For real floating types,
it is the same type. For complex types, it is the type given by
deleting the keyword _Complex from the type name.

13 Each complex type has the same representation and alignment
requirements as an array type containing exactly two elements
of the corresponding real type; the first element is equal to
the real part, and the second element to the imaginary part,
of the complex number.

Then again, we know your compiler is not conforming to *any* C standard...

Dan

 

[Eric Sosman]

I would like to add at the beginning of the C tutorial I am writing
a short blurb about what "types" are. I came up with the following text.

Please can you comment?
Did I miss something?
Is there something wrong in there?
--------------------------------------------------------------------
Types
A type is a definition for a sequence of storage bits. It gives the
meaning of the data stored in memory. If we say that the object a is an
int, it means that the bits stored at that location are to be understood
as a natural number that is built by consecutive additions of powers of
two. If we say that the type of a is a double, it means that the bits
are to be understood as the IEEE 754 standard sequences of bits
representing a double precision floating point value. [...]

One problem with this explanation is that it relies
on the idea of "a sequence of storage bits," which would
seem to imply that a type exists only in connection with
memory. However, values have types even if they're not
memory-resident. For example, in `x * 2' the `2' has
type `int' even if the compiler uses "add x,x" or maybe
"shl x,1" to calculate the value, thus expunging all traces
of "two-ness" from the code.

To a beginner, a memory-centric explanation of "type"
may be helpful: it has a comforting solidity in what the
novice may perceive as a sea of abstraction. But I think
the approach has several drawbacks. It's inaccurate (as
shown above), it doesn't cover incomplete types (what's
the "sequence of storage bits" for a `void'?), and it takes
a bit of a stretch to get it to cover function types.

The worst feature of the memory-centric approach may be
that it encourages people to think about the representations
of values rather than about the values themselves. As a
class, C programmers seem all too susceptible to this
temptation (how often have you seen 0xFF referred to as a
negative value?), and anything one can do to *dis*courage
the practice is a blow for Truth, Justice, and the Amer--
er, Standard Way.

The challenge, of course, is to devise an explanation
that is both correct and comprehensible. IMHO, you've gone
for the short-term benefit of easy comprehension at the cost
of the long-term drawback of a mental model that's askew
from the truth of the language.

 

[jacob navia]

>
One problem with this explanation is that it relies
on the idea of "a sequence of storage bits," which would
seem to imply that a type exists only in connection with
memory.

Types are associated with objects, and objects must exist
in memory somewhere.

However, values have types even if they're not
memory-resident. For example, in `x * 2' the `2' has
type `int' even if the compiler uses "add x,x" or maybe
"shl x,1" to calculate the value, thus expunging all traces
of "two-ness" from the code.

A compiler that does constant folding (the general case)
doesn't destroy any types. It eliminates the objects (the
constants) and with the objects, their types disappear too.
I see no contradiction. The two in x*2 is eliminated and
with it its type. But until is eliminated the type exists
as a way of describing the bits in the machine representation
of two.

Note that types in this context are just descriptions of machine
representations, as I said in my proposal.

To a beginner, a memory-centric explanation of "type"
may be helpful: it has a comforting solidity in what the
novice may perceive as a sea of abstraction. But I think
the approach has several drawbacks. It's inaccurate (as
shown above), it doesn't cover incomplete types (what's
the "sequence of storage bits" for a `void'?),

void means "non", i.e. no type, and no corresponding object.
int fn(void)
means that fn has no objects declared as arguments.

and it takes
a bit of a stretch to get it to cover function types.

Why?

I define in my proposal the type of a function as the union
of the type of the return value (output) and arguments (inputs)
of the function.

This is clear and quite evident, at least in the lcc compiler
function types are treated that way.

The worst feature of the memory-centric approach may be
that it encourages people to think about the representations
of values rather than about the values themselves.

Types are descriptions of memory objects. Note that all we can
do in a machine is to abstract from a real number or from any
real world object *some* characteristics and *represent* it
in the machine.

When I write:

typedef struct tagPerson { char *name; int age; } Person;

I mean that I abstract from a real world person that has billions
of different characteristics, genetic code, eye color,
bank account level, number of fingers, etc. I make a machine
"type" where only two characteristics out of the billions
are considered: the name and the age.

As a
class, C programmers seem all too susceptible to this
temptation (how often have you seen 0xFF referred to as a
negative value?), and anything one can do to *dis*courage
the practice is a blow for Truth, Justice, and the Amer--
er, Standard Way.

It depends on the context where 0xff is used. It can be
a constant (255) or understood as negative because the highest
bit is set, or anything else...

The challenge, of course, is to devise an explanation
that is both correct and comprehensible. IMHO, you've gone
for the short-term benefit of easy comprehension at the cost
of the long-term drawback of a mental model that's askew
from the truth of the language.

Well please make a counter-proposal... How would you speak
about values without using some definition of type?


jacob

 

[Eric Sosman]

Types are associated with objects, and objects must exist
in memory somewhere.

No and no, I think. Consider

#include <stdio.h>
int main(void) {
struct nonsuch { double x; int y; };
printf ("sizeof(struct nonsuch) = %d\n",
(int)sizeof(struct nonsuch));
return 0;
}

I make two claims about this program: First, that it
defines and uses the type `struct nonsuch', and second,
that no `struct nonsuch' object exists in memory -- nor
anywhere else, for that matter.

A compiler that does constant folding (the general case)
doesn't destroy any types. It eliminates the objects (the
constants) and with the objects, their types disappear too.
I see no contradiction. The two in x*2 is eliminated and
with it its type. But until is eliminated the type exists
as a way of describing the bits in the machine representation
of two.

No, `2' doesn't lose its `int'-ness because of whatever
trickery the compiler employs in code generation. To
demonstrate this, let's try another toy program (I've
switched to `double' to make the demonstration clearer):

#include <stdio.h>
int main(void) {
char x;
printf ("%d ?= %d\n", (int)sizeof(x),
(int)sizeof(x*2.0));
return 0;
}

Most machines will print something like "1 ?= 8", showing
that the two `sizeof' operands have different sizes. Why
do they have different sizes? Because they have different
types. Why do they have different types? Because in the
second instance the presence of a `double' operand causes
the expression to have type `double' as well. Note that
the `2.0' need not exist in the generated code at all,
because it's never even evaluated -- yet it has a type
nonetheless, and the influence of that type is seen in
the output.

Note that types in this context are just descriptions of machine
representations, as I said in my proposal.

Yes, you said that. I've given some reasons why I
think it's an unwise claim.

void means "non", i.e. no type, and no corresponding object.
int fn(void)
means that fn has no objects declared as arguments.

`void' does *not* mean "no type," not ever. Like some
other C keywords and symbols (c.f. `static'), its meaning
is context-dependent:

- In the particular context you cite, it means "this
function takes no arguments."

- In all other contexts, it means "an incomplete type
that cannot be completed."

In neither case does it mean "no type" or "non."

Why?

All right, then, what's the "sequence of storage bits"
that represents the type-generic sqrt() function? What's
the "sequence of storage bits" that is the representation
of a function that's been inlined in five places and been
optimized differently in each of them? Or to go really
purist and ivory-tower on you, where does the C Standard
require that functions occupy memory at all?

> [...]

The worst feature of the memory-centric approach may be
that it encourages people to think about the representations
of values rather than about the values themselves.

Types are descriptions of memory objects.

"Are not!"

"Are so!"

"Are not!"

"Are so!"

.... all right, you win. My fingers are getting tired.

[...] As a
class, C programmers seem all too susceptible to this
temptation (how often have you seen 0xFF referred to as a
negative value?), and anything one can do to *dis*courage
the practice is a blow for Truth, Justice, and the Amer--
er, Standard Way.

It depends on the context where 0xff is used. It can be
a constant (255) or understood as negative because the highest
bit is set, or anything else...

If the context is "in C source code," 0xFF is a postive
value of type `int'. Period, end of sentence. Allow me to
suggest that if this isn't clear to you, you're not in a
position to be explaining types to anyone.

Well please make a counter-proposal... How would you speak
about values without using some definition of type?

You've turned it around, or maybe I've written less
clearly than I like to think I do. In C, every value has a
type and it would be folly to say otherwise, or to omit the
notion of a value's type when discussing its nature. But
it is *not* the case that every type has a value (c.f. `void')
or that every value of a type must exist in memory (c.f.
the eliminated constants, non-evaluated `sizeof' operands,
and so on). It's the latter that I think you're claiming and
that I beg to differ with.

As for making a counter-proposal -- well, I'm not an
accomplished author of textbooks. Good explanations sail
between Scylla and Charybdis: Perfect correctness may be
perfectly incomprehensible, while a facile exposition may
convey misinformation. That's why I admire and enjoy
K&R, Knuth, and the like: they're correct (usually) and
expressive (usually), and neither the correctness nor the
expression suffers on behalf of the other. It takes
artistry to steer such a boat, to stay clear of both the
rocks and the whirlpool. If you can manage to find the
right course, you'll have made a valuable contribution.

 

[Tim Rentsch]

I would like to add at the beginning of the C tutorial I am writing
a short blurb about what "types" are. I came up with the following text.

Please can you comment?
Did I miss something?
Is there something wrong in there?
--------------------------------------------------------------------
Types
A type is a definition for a sequence of storage bits. It gives the
meaning of the data stored in memory. If we say that the object a is an
int, it means that the bits stored at that location are to be understood
as a natural number that is built by consecutive additions of powers of
two. If we say that the type of a is a double, it means that the bits
are to be understood as the IEEE 754 standard sequences of bits
representing a double precision floating point value. [...]

One problem with this explanation is that it relies
on the idea of "a sequence of storage bits," which would
seem to imply that a type exists only in connection with
memory. However, values have types even if they're not
memory-resident. For example, in `x * 2' the `2' has
type `int' even if the compiler uses "add x,x" or maybe
"shl x,1" to calculate the value, thus expunging all traces
of "two-ness" from the code.

Syntactic elements have [program] types. It's the syntactic element
'2' that has type int, not some runtime value 2, which as you point
out may not exist. Values and other runtime entities have a
representation type impressed on them by the code accessing the value
or entity at that particular time. For linguistic convenience we
sometimes say "this object is of type int" but what's meant is that
the memory is being interpreted as having the representation type that
corresponds to the program type int for that implementation.

In case it isn't clear, I'm basically agreeing with what you're
saying, just trying to give more precise language to say it.

To a beginner, a memory-centric explanation of "type"
may be helpful: it has a comforting solidity in what the
novice may perceive as a sea of abstraction. But I think
the approach has several drawbacks. It's inaccurate (as
shown above), it doesn't cover incomplete types (what's
the "sequence of storage bits" for a `void'?), and it takes
a bit of a stretch to get it to cover function types.

The worst feature of the memory-centric approach may be
that it encourages people to think about the representations
of values rather than about the values themselves. As a
class, C programmers seem all too susceptible to this
temptation (how often have you seen 0xFF referred to as a
negative value?), and anything one can do to *dis*courage
the practice is a blow for Truth, Justice, and the Amer--
er, Standard Way.

It's important to understand both program types and representation
types. The problems mentioned above, and lots of others having
to do with the differences between different implemenations,
can be discussed and explained using the relationship between
program types and representation types. Incidentally, note
that program types are defined by the C standard, but representation
types are determined (sometimes with standard-imposed constraints)
by the machine architecture and compiler at hand.

The challenge, of course, is to devise an explanation
that is both correct and comprehensible.

Agreed. I'd be interested to see what suggestions some of
the regulars would write on this topic.

 

[Tim Rentsch]

Types are associated with objects, and objects must exist
in memory somewhere.

An object, or a function, is treated as though it has a certain
representation type at any particular point in (execution) time.
But the memory exists independently of the representation type
that is used to access it at any particular point. Also values
can come into existence that prior to coming into existence
weren't stored in any object - consider

int a[10];
* (char *) &a[3] = 0;

The address value &a[3] springs into existence having an address
representation type, but very likely wasn't previously stored in any
object.

A compiler that does constant folding (the general case)
doesn't destroy any types. It eliminates the objects (the
constants) and with the objects, their types disappear too.
I see no contradiction. The two in x*2 is eliminated and
with it its type. But until is eliminated the type exists
as a way of describing the bits in the machine representation
of two.

Objects are run-time entities; they don't exist during the
compilation process. Instead, the compiler manipulates syntactic and
tree elements that correspond to objects (and functions!) that might,
or might not, exist at run-time. Perhaps a small distinction, but a
significant one. Precise language is important.

Note that types in this context are just descriptions of machine
representations, as I said in my proposal.

There are program types and representation types, and it is
important to understand both. So, it is important to explain
both.

void means "non", i.e. no type, and no corresponding object.
int fn(void)
means that fn has no objects declared as arguments.

The type 'void' is not "no type", but an incomplete [program] type
that can't be completed. It's right that there is no representation
type corresponding to program type 'void'; but, the type 'void' is
still a [program] type.

Types are descriptions of memory objects. Note that all we can
do in a machine is to abstract from a real number or from any
real world object *some* characteristics and *represent* it
in the machine.

Program types are (sometimes somewhat abstract) specifications for how
various syntactic entities can be combined. On a particular
implementation, they also specify a mapping to a corresponding
representation type (or perhaps several representation types).

 

[pete]

Tim Rentsch wrote:

It's important to understand both program types and representation
types.

Does Dennis M. Ritchie understand the difference?
Aren't program types and representation types,
something that you just made up?

 

[Richard Harter]

Does Dennis M. Ritchie understand the difference?
Yes.

Aren't program types and representation types,
something that you just made up?

No.

HTH. HAND.

 

[jacob navia]

Syntactic elements have [program] types. It's the syntactic element
'2' that has type int, not some runtime value 2, which as you point
out may not exist. Values and other runtime entities have a
representation type impressed on them by the code accessing the value
or entity at that particular time. For linguistic convenience we
sometimes say "this object is of type int" but what's meant is that
the memory is being interpreted as having the representation type that
corresponds to the program type int for that implementation.

If I understand you correctly, you make a difference between program
types that correspond to the abstract types defined in the C standard,
and representation types that are the product of applying those abstract
types to a specific machine architecture.

You agree that types are definitions of how to interpret a sequence of
bits in memory:

> For linguistic convenience we
> sometimes say "this object is of type int" but what's meant is that
> the memory is being interpreted as having the representation type that
> corresponds to the program type int for that implementation.

Using your terminology, my type definition would correspond to the
representation types.

1) Abstract type: int, as defined by the C standard.

2) Concrete representation type: int as a sequence of 32 bits as
implemented by the lcc-win32 compiler.

The standard constraints the possible representations of int (it should
have at least 16 bits for instance), and lcc-win32 implements that
abstract type by choosing a machine word length for the "int" concrete
representation.

Did I understood you correctly?

Thanks for your contribution, you make an intersting point here.

I think a similar wording as above could be very well within the reach
of a beginner.

 

[Tim Rentsch]

Does Dennis M. Ritchie understand the difference?
Aren't program types and representation types,
something that you just made up?

I'm confident he understands the two ideas. I expect the names would
also make sense to him, perhaps without previous explanation, but
almost certainly after getting the descriptions posted recently in the
NG.

I admit to having chosen these particular names myself; the
concepts though have a much longer pedigree, appearing in the
literature starting in the early 1980's.

To be clear, the ideas are what's important (IMO) to understand. I
think the names are fairly good and reasonably evocative (if I do say
so myself), but the two distinct ideas are the important thing.