Re: What is a type?
From: Eric Sosman (eric.sosman_at_sun.com)
Date: 10/04/04
- Next message: Merrill & Michele: "Re: arrays and K&R §5.10"
- Previous message: Mike Wahler: "Re: Clearly, it is too late to fix c99 - C is dead"
- In reply to: jacob navia: "Re: What is a type?"
- Next in thread: Tim Rentsch: "Re: What is a type?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 04 Oct 2004 14:48:14 -0400
jacob navia wrote:
> Eric Sosman wrote:
>
>> 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.
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.
>> 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.
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.
>> 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.
`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."
>> and it takes
>> a bit of a stretch to get it to cover function types.
>
> 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.
>> 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?
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.
-- Eric.Sosman@sun.com
- Next message: Merrill & Michele: "Re: arrays and K&R §5.10"
- Previous message: Mike Wahler: "Re: Clearly, it is too late to fix c99 - C is dead"
- In reply to: jacob navia: "Re: What is a type?"
- Next in thread: Tim Rentsch: "Re: What is a type?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
