What is a type?

[Tim Rentsch]

Re: What is a type?

jacob navia <jacob@jacob.re mcomp.fr> writes:
[color=blue]
> Eric Sosman wrote:[color=green]
> >
> > 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.[/color]
>
> Types are associated with objects, and objects must exist
> in memory somewhere.[/color]

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.

[color=blue][color=green]
> > 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.
> >[/color]
>
> 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.[/color]

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.

[color=blue]
> Note that types in this context are just descriptions of machine
> representations , as I said in my proposal.[/color]

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

[color=blue][color=green]
> > 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'?),[/color]
>
> void means "non", i.e. no type, and no corresponding object.
> int fn(void)
> means that fn has no objects declared as arguments.[/color]

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.

[color=blue][color=green]
> > 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.[/color]
>
> 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.[/color]

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]

Re: What is a type?

Tim Rentsch wrote:
[color=blue]
> It's important to understand both program types and representation
> types.[/color]

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

--
pete

[Richard Harter]

Re: What is a type?

On Tue, 05 Oct 2004 10:58:41 GMT, pete <pfiland@mindsp ring.com> wrote:
[color=blue]
>Tim Rentsch wrote:
>[color=green]
>> It's important to understand both program types and representation
>> types.[/color]
>
>Does Dennis M. Ritchie understand the difference?[/color]

Yes.
[color=blue]
>Aren't program types and representation types,
>something that you just made up?[/color]

No.

HTH. HAND.

[jacob navia]

Re: What is a type?

Tim Rentsch wrote:[color=blue]
> 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.
>[/color]

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:

You wrote:[color=blue]
> 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.[/color]

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]

Re: What is a type?

pete <pfiland@mindsp ring.com> writes:
[color=blue]
> Tim Rentsch wrote:
>[color=green]
> > It's important to understand both program types and representation
> > types.[/color]
>
> Does Dennis M. Ritchie understand the difference?
> Aren't program types and representation types,
> something that you just made up?[/color]

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.

[Tim Rentsch]

Re: What is a type?

jacob navia <jacob@jacob.re mcomp.fr> writes:
[color=blue]
> Tim Rentsch wrote:[color=green]
> > 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.
> >[/color]
>
> 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.[/color]

Yes, with two minor corrections. The term "abstract type" is generally
used to mean a different concept; any of the terms "program type", "C type",
or "standard C type" would be more appropriate. Also, representation types
exist independently; they aren't the "product of applying" the C types.
A more accurate way of saying it would be that, on a particular machine,
a compiler chooses a representation type that will correspond to each
C program type. There are also representation types that don't correspond
to any C program type (although most of these won't ever be used by
the compiler).

[color=blue]
> You agree that types are definitions of how to interpret a sequence of
> bits in memory:[/color]

You left out "representation " in that sentence. Representation types
do determine how to interpret memory values, in the case of data
objects; it's a little dangerous to call memory values "a sequence
of bits", since part of the representation type would determine
in what order the memory units are processed. And, functions also
have a representation type, but in the case of functions the representation
type determines how they should be called, not how the memory storing
the function object code will be interpreted.
[color=blue]
> You wrote:[color=green]
> > 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.[/color]
>
> Using your terminology, my type definition would correspond to the
> representation types.[/color]

I think that's right. That's a little bit dangerous, since it
encourages people to think in terms of the representations , which
will change from machine to machine, or from compiler to compiler.
Or even, in some cases, from compilation to compilation. That's why
it's also important to explain program types.
[color=blue]
> 1) Abstract type: int, as defined by the C standard.[/color]

Again, the term "abstract type" shouldn't be used, since it's
standardly used in the literature to mean something very different.

[color=blue]
> 2) Concrete representation type: int as a sequence of 32 bits as
> implemented by the lcc-win32 compiler.[/color]

Similarly, the word "concrete" here should not be used, since it
means something different in the literature. The type 'int' is
a concrete type, as the term is standardly used. You might try
"architectu re/compiler specific representation" .

[color=blue]
> 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?[/color]

I believe so (reiterating my comments about not using "abstract" and
"concrete" for these purposes).

[color=blue]
> 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.[/color]

You are most welcome. I think so too.

[Keith Thompson]

Re: What is a type?

Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=blue]
> pete <pfiland@mindsp ring.com> writes:[color=green]
>> Tim Rentsch wrote:
>>[color=darkred]
>> > It's important to understand both program types and representation
>> > types.[/color]
>>
>> Does Dennis M. Ritchie understand the difference?
>> Aren't program types and representation types,
>> something that you just made up?[/color]
>
> 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.[/color]

Personally, I find the term "representa tion type" confusing. It's
certainly important to distinguish between a "type" (as used in the
standard and in the abstract machine) and "representation " (as spplied
to the hardware), but I don't find it useful to apply the term "type"
to the latter. FWIW, YMMV.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Tim Rentsch]

Re: What is a type?

Keith Thompson <kst-u@mib.org> writes:
[color=blue]
> Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=green]
> > pete <pfiland@mindsp ring.com> writes:[color=darkred]
> >> 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?[/color]
> >
> > 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.[/color]
>
> Personally, I find the term "representa tion type" confusing. It's
> certainly important to distinguish between a "type" (as used in the
> standard and in the abstract machine) and "representation " (as spplied
> to the hardware), but I don't find it useful to apply the term "type"
> to the latter. FWIW, YMMV.[/color]

I chose the term "representa tion type" because historically the word
"type" was used to mean both concepts, and I thought it might help
people who are used to thinking the two concepts are synonymous.
I agree though that a different term might be better. Anyone
have any suggestions?

[Keith Thompson]

Re: What is a type?

Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=blue]
> Keith Thompson <kst-u@mib.org> writes:[/color]
[...][color=blue][color=green]
>> Personally, I find the term "representa tion type" confusing. It's
>> certainly important to distinguish between a "type" (as used in the
>> standard and in the abstract machine) and "representation " (as spplied
>> to the hardware), but I don't find it useful to apply the term "type"
>> to the latter. FWIW, YMMV.[/color]
>
> I chose the term "representa tion type" because historically the word
> "type" was used to mean both concepts, and I thought it might help
> people who are used to thinking the two concepts are synonymous.
> I agree though that a different term might be better. Anyone
> have any suggestions?[/color]

What about just "representation "?

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

Re: What is a type?

Tim Rentsch wrote:[color=blue]
> So I see the "program type/representation type" distinction
> as more fundamental than the distinction of qualified types
> vs unqualified types.[/color]

You are right. I think the best example are enumeration types
that only exist at run time, and where the "underlying " type
is int. The types are different but the underlying representation
is the same.

The same holds for
int a;
and
struct { int a;} a;

Two types with exactly the same representation.

It will be a challenge to explain all this subtetlies
in a tutorial, but somehow I find it necessary.

I think it can be done by proposing a rough approach
at the beginning, and refining it later.

But I am against writing yet another C for dummies. I
want to try to explain the complexity of C without
making believe people that they are learning yet another
version of BASIC or other beginner's language.

C programmers have to know more details of the actual
hardware because C allows you to use directly that
hardware.

Hardware is represented in C as a sequential space of
addreses, where are stored the data and the preprogrammed
(compiled) instructions sequences, that act with those
data and maybe further inputs.

Building types and procedures is called "programmin g".

A type can be several things, starting with the simple
ones, passive data. This data is stored in integers,
the only thing that machines understand: bits.

A *type* for this kind of data means a coded algorithm
description for the usage of the data. Text is stored
using an alphabet, the most common alphabet being the
"ASCII" format. An alphabet is a common convention for
writing letters as integers. We say that 'A' will be 65
and be done with it. Other alphabets can (and are) used
of course, C is not tied to ASCII.

The type char means then, that the data stored in
consecutive addresses is to be understood as a sentence
like:
"Please enter the amount"
that should be shown at default centered coordinates
with some button underneath and an edit field.

Integers can be used to store text, or colors if you
like: you make an alphabet and assign integers to the whole
color spectrum. The integers are interpreted by the screen
hardware as colors to be shown. Images can be stored as
integers that encode intensity levels and direct the
hardware to display the image.

Integers can store audio, as the many files floating
around will prove... Bach, Ravel, and many others can be
encoded in integers that represent a waveform at an
implicit frequency.

Integers can be used to encode other integers, so you
get formats like mp3 that take the voluminous sequence
of integers produced by the sampler and spit integers
again, but much less.

The type of the integers changes. It will be of no use
to the mp3 decoder to try to understand a photograph as
a song. Or maybe, we should hear what comes out of it
who knows...

In any case the type of the mp3 data is a song, not
a photograph, and if you display it as text (you can
do that one day to "see" a song) it will not be
meaningful either, the type is wrong.

All machines handle basically nothing else but bits.
To find our way we define types of data, i.e. we
ascribe a specific meaning to each bit of what we are
processing: a song, a photograph, some text, a number,
whatever.

Integers aren't all, as everyone knows, 0.5 exists,
and it is not an integer. Well, that doesn't hold.

We can approximate real numbers by using two integers,
the mantissa and the exponent, and we can figure out
clever ways of adding those integer pairs (or floating
point numbers, see later in this tutorial).

Integers can be arbitrarily big, with today's hard disk
capacity storing an integer of 200 GB is possible.

Smaller integers can be handled with a lot less problems
however, and for most applications, double precision is
already quite good.

Note that we "approximat e" real numbers, never really
touching them. There is a quantization loss in the encoding,
and a whole seri'es of problems implicit in the digital
nature of the encoding.

Some integers of 1 units are called "chars" and they are
used to encode the alphabet, making the machine store text.

In C you can at any moment change your mind and start
interpreting the same bits in another way. You make a
cast operation, i.e. you apply to some address a new
type.

Several simple types can be combined into aggregates,
i.e. a related bunch of data like integers, character
strings, real numbers, etc. This aggregates can have
relationships between them, represented by pointers to
other aggregates. This are composite types (structures
or unions)

The data is handled in procedures, i.e. a sequences of
instructions that receive some inputs, and produce some
output or modification of the program state. The type
of a procedure is strictly defined by the type of its
inputs and the type of the output (return value).

There are yet another kind of types, where you make
a distinction between two objects that have the same
representation. You can build, for instance, an "enumerated "
type, that is in fact an integer, but encodes special
meaning.

There are even types that you can't figure out at all:
opaque types. This type is, for instance:

struct unknown *bn;

and struct "unknown" is nowhere defined. Or even worst:

void *bn;

A pointer that points to an unknown object.
You can do only one thing with this pointer:
pass it around.

Usually you receive an opaque pointer from a library
that wants to hide the details of how they do their
stuff from you. This is good for you, since you are
using the library precisely because you do not want to
know a lot about it and just use it.

This allows the library writers too, to change all their
internal stuff without needing a change in all the
customer base. Opaque types are like firewalls. They limit the
growth of the interdependency between the several
parts that make a whole program.


Well it will be something around this lines. Thanks for
the feedback.

[jacob navia]

Re: What is a type?

jacob navia wrote:
[color=blue]
> You are right. I think the best example are enumeration types
> that only exist at run time, and where the "underlying " type
> is int. The types are different but the underlying representation
> is the same.
>[/color]

Should be obviously compile time, not run-time what a blunder.
Enumerations exist only at compile time. At run time the
underlying type is used. The circuit doesn't have any
idea of enumerations.

I pressed the send button too soon.

[Tim Rentsch]

Re: What is a type?

Keith Thompson <kst-u@mib.org> writes:
[color=blue]
> Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=green]
> > Keith Thompson <kst-u@mib.org> writes:[/color]
> [...][color=green][color=darkred]
> >> Personally, I find the term "representa tion type" confusing. It's
> >> certainly important to distinguish between a "type" (as used in the
> >> standard and in the abstract machine) and "representation " (as spplied
> >> to the hardware), but I don't find it useful to apply the term "type"
> >> to the latter. FWIW, YMMV.[/color]
> >
> > I chose the term "representa tion type" because historically the word
> > "type" was used to mean both concepts, and I thought it might help
> > people who are used to thinking the two concepts are synonymous.
> > I agree though that a different term might be better. Anyone
> > have any suggestions?[/color]
>
> What about just "representation "?[/color]

If we use the term "representation " by itself, there's an ambiguity
about whether the notion under discussion is generic or specific.
Individual values have a 'representation '; storage that holds any of
a set of values has (or is accessed using) a 'representation type'.
("What's the representation for a NULL pointer?") Also, using
"representation " by itself doesn't work very well for functions; we
aren't interested in the particular bits that make up a function's
object code, but we are interested in what calling conventions are
necessary to call it. An unadorned "representation " tends to evoke
bit patterns more than it does calling sequences.

Certainly there is some precedent for using "representation " in these
kinds of discussions - "two's complement representation" , for example.
For informal discussions it's probably fine. For more precise
descriptions, however, talking about the relationship between "types"
at compile-time and at run-time, "representa tion type" seems more
both more accurate and more evocative.

[Still good to have gotten the suggestion - thank you.]

Other ideas? Surely there must be some...

[Keith Thompson]

Re: What is a type?

jacob navia <jacob@jacob.re mcomp.fr> writes:[color=blue]
> Tim Rentsch wrote:[color=green]
>> So I see the "program type/representation type" distinction
>> as more fundamental than the distinction of qualified types
>> vs unqualified types.[/color]
>
> You are right. I think the best example are enumeration types
> that only exist at run time, and where the "underlying " type
> is int. The types are different but the underlying representation
> is the same.[/color]

(As you acknowledged later, that should be "only exist at compilation
time".)

This makes it sound like an enumeration type and type "int" are
fundamentally different things, that an enumeration type exists at
compilation time, but type "int" exists at run time. This is
misleading. The type "int", like an enumeration type, exists only at
compilation time. Rather than saying that the underlying type of an
enumeration type is int, it's more accurate to say that the
enumeration type and int have the same representation. (That
representation might be a machine word, for example.)

And, of course, the representation of an enumeration type may or may
not be the same as the representation of type int; it's up to the
implementation to choose an underlying representation that can hold
all the specified values.

As a rule of thumb, anything having to do with the C language exists
only in your source program or at compilation time, not at run time.
(That's not completely true, since a lot of the names overlap.)

In my opinion, it's best to use the term "type" only for things that
are types in C, not for entities like machine words that exist at run
time.

[...]
[color=blue]
> Hardware is represented in C as a sequential space of
> addreses, where are stored the data and the preprogrammed
> (compiled) instructions sequences, that act with those
> data and maybe further inputs.[/color]

That assumes a particular runtime model, one not required by the C
standard. There isn't necessarily a single sequential address space.
Data and code could be in separate address spaces; for that matter,
each object (declared or created by malloc()) could be in a distinct
address space. The existence of pointer arithmetic implies a
sequential address space within a single object, but not across
objects. A function address could be anything that allows the
function to be called; it could easily be an index into a system table
rather than a machine-level address.

[...]
[color=blue]
> In C you can at any moment change your mind and start
> interpreting the same bits in another way. You make a
> cast operation, i.e. you apply to some address a new
> type.[/color]

A cast operator specifies a type conversion. Not all such conversions
are simple reinterpretatio ns of the bits. Conversions between integer
and floating-point types almost certainly do more than just copying
the bits; conversions between pointer types may or may not do so.
What you're talking about is type punning; converting addresses is one
of several ways to achieve that.

[...]
[color=blue]
> There are even types that you can't figure out at all:
> opaque types. This type is, for instance:
>
> struct unknown *bn;
>
> and struct "unknown" is nowhere defined. Or even worst:
>
> void *bn;
>
> A pointer that points to an unknown object.
> You can do only one thing with this pointer:
> pass it around.[/color]

These are called incomplete types; it's best to keep your terminology
consistent with standard usage.

Incomplete types and opaque types are two different things, and an
opaque type needn't be an incomplete type. For example, the type FILE
in <stdio.h> is opaque as far as the programmer is concerned (the
standard says nothing about its contents), but I can see what's in it
(in many implementations ) by viewing the appropriate header file.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Re: What is a type?

Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=blue]
> Keith Thompson <kst-u@mib.org> writes:
>[color=green]
>> Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=darkred]
>> > Keith Thompson <kst-u@mib.org> writes:[/color]
>> [...][color=darkred]
>> >> Personally, I find the term "representa tion type" confusing. It's
>> >> certainly important to distinguish between a "type" (as used in the
>> >> standard and in the abstract machine) and "representation " (as spplied
>> >> to the hardware), but I don't find it useful to apply the term "type"
>> >> to the latter. FWIW, YMMV.
>> >
>> > I chose the term "representa tion type" because historically the word
>> > "type" was used to mean both concepts, and I thought it might help
>> > people who are used to thinking the two concepts are synonymous.
>> > I agree though that a different term might be better. Anyone
>> > have any suggestions?[/color]
>>
>> What about just "representation "?[/color]
>
> If we use the term "representation " by itself, there's an ambiguity
> about whether the notion under discussion is generic or specific.
> Individual values have a 'representation '; storage that holds any of
> a set of values has (or is accessed using) a 'representation type'.
> ("What's the representation for a NULL pointer?")[/color]

In my opinion, what you're calling a "representa tion type" isn't a
type at all. You can talk about the representation of a type (32-bit
two's-complement), or the representation of a particular value
(hexadecimal DEADBEEF); as long as you're careful, I don't see much of
a problem using the same word for both. If you want to distinguish,
you might consider using a term like "type representation" .
[color=blue]
> Also, using
> "representation " by itself doesn't work very well for functions; we
> aren't interested in the particular bits that make up a function's
> object code, but we are interested in what calling conventions are
> necessary to call it. An unadorned "representation " tends to evoke
> bit patterns more than it does calling sequences.[/color]

I wouldn't talk about the "representation " of a function at all,
either of its object code or of its calling convention. Data items
have representations .

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Tim Rentsch]

Re: What is a type?

Keith Thompson <kst-u@mib.org> writes:
[color=blue]
> Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=green]
> > Keith Thompson <kst-u@mib.org> writes:
> >[color=darkred]
> >> Tim Rentsch <txr@alumnus.ca ltech.edu> writes:
> >> > Keith Thompson <kst-u@mib.org> writes:
> >> [...]
> >> >> Personally, I find the term "representa tion type" confusing. It's
> >> >> certainly important to distinguish between a "type" (as used in the
> >> >> standard and in the abstract machine) and "representation " (as spplied
> >> >> to the hardware), but I don't find it useful to apply the term "type"
> >> >> to the latter. FWIW, YMMV.
> >> >
> >> > I chose the term "representa tion type" because historically the word
> >> > "type" was used to mean both concepts, and I thought it might help
> >> > people who are used to thinking the two concepts are synonymous.
> >> > I agree though that a different term might be better. Anyone
> >> > have any suggestions?
> >>
> >> What about just "representation "?[/color]
> >
> > If we use the term "representation " by itself, there's an ambiguity
> > about whether the notion under discussion is generic or specific.
> > Individual values have a 'representation '; storage that holds any of
> > a set of values has (or is accessed using) a 'representation type'.
> > ("What's the representation for a NULL pointer?")[/color]
>
> In my opinion, what you're calling a "representa tion type" isn't a
> type at all.[/color]

Wouldn't you say pointers that store just an address and pointers that
store an address and a length are different types of pointers?
Wouldn't you say that a 'cdecl' function and a 'stdcall' function are
different types of functions? Wouldn't you say a number stored in
host order and a number stored in network order are different types of
numbers (even if on the host in question values in the two orderings
always had the same representations )? It makes just as much sense to
say that there are different types of representations as it does to
say that there are different types of variables.

[color=blue]
> You can talk about the representation of a type (32-bit
> two's-complement), or the representation of a particular value
> (hexadecimal DEADBEEF); as long as you're careful, I don't see much of
> a problem using the same word for both.[/color]

It's applicable to one but not the other. The word representation
means "likeness or image"; unless there is something stored somewhere
in the running program, such a byte with a '4' in it and a rule like
"'4' means int", the phrase "the representation of a type" is a misuse
of language. That's a pretty good indicator that this path isn't
the right one to go down.

[color=blue]
> If you want to distinguish,
> you might consider using a term like "type representation" .[/color]

I don't mean "the representation of a type"; what I mean is "the type
of representation" . It seems like "representa tion type" is a better
term for that.

Suggestions from other quarters have been "machine type",
"representation al type", "implementa tion type", and "representa tion
schema". Are any of those less confusing or less misleading
than "representa tion type"?

[color=blue][color=green]
> > Also, using
> > "representation " by itself doesn't work very well for functions; we
> > aren't interested in the particular bits that make up a function's
> > object code, but we are interested in what calling conventions are
> > necessary to call it. An unadorned "representation " tends to evoke
> > bit patterns more than it does calling sequences.[/color]
>
> I wouldn't talk about the "representation " of a function at all,
> either of its object code or of its calling convention. Data items
> have representations .[/color]

That you wouldn't use the same word for functions is a good indication
that it's not really the right term here. Both "data values" and
"function values" have differing patterns of implementation. What
we're trying to find is a term that captures and expresses the idea of
an "implementation al pattern" - the same term should apply equally to
differences in function implementation as it does to differences in
data implementation.