|
|
Re: Comp. Sci. 101: Definition of Type
|
Posted: Dec 9, 2004 10:20 AM
|
|
> Not every semantic classification of values is a type, but
> every type is a semantic classification of values.
I agree with that statement, but doesn't that mean your definition requires further precision?
>I could
> easily design a positive number type, or a negative
>number
> type, so I don't see how it is irrelevant.
Well, yes, or a "Foo" or a "Bar". If the problem is "What subset of 'semantic classifications of values' is worth defining as the set of types we'll be using in our system," I would argue that the answer comes from determining what constraints / behavior / capacity are important.
In your reply you said both that two types can have identical behavior (I assume you include range of values) and a single type can have multiple underlying representations. I'd submit that you're shifting perspective to argue both sides of the coin. I argue that within a given language, a type is what a type does.
Yes, one can define two types that are identical but which have different type identifiers. C-style enums strike me as the closest common example to 'identical but usefully distinct,' but even enum directions { Left, Right } and enum political_leanings { Left, Right } have different behavior in that they can't be assigned interchangeably: that constraint is imposed by the type system, true, but that's the point -- types constrain behavior. If you create two identical types that have identical behavior (including range of values and assignment compatibility), surely it's fair to say that one of the two is erroneous?
My point about the von Neumann architecture echoes some of the concerns you had about Toby's response, although I think you are too quick to dismiss his perspective. The primacy of types in discussions of computer science is not coincidental to the primacy of the von Neumann architecture.
In your reply to Toby you say "types don't necessarily have bits," which I don't follow.
|
|
Previous Topic
