🚀 go-pugleaf

In article <id.OCVO.D6A@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
|If the two objects have the same operations with the same meanings they
|have the same type.

What is the comparison criterion for the operations? What is a
"meaning" for you, here?

|If the two objects have the same operations with the same meanings over
|some range of values, and different meanings over other ranges of values,
|then you can't say they have the same operations nor that they are the
|same type.

I surely can over the restricted domain. But the idea I was trying to
capture was this: suppose you have two representations of a "point",
one cartesian and one polar. Both are IMPLEMENTED as pairs of floats,
and so they have the same CONCRETE representation. Both represent
points on a plane, so they have the same intensional type. The same
list of operators is provided for both variants. Question: do they
have the same "type" or not?

This example SHOULD demonstrate that there's a third crucial
component, beyond the intension and the extension: there's the nature
of the mapping betwixt. And it's a parameter of language design how
visible that is, and a parameter of personality how visible you think
it OUGHT to be.

|In C, the type is bound to the identifier, so you can set up an alias
|for a collection of data that treats it as a different type. But the
|type can still be defined as the set of operations you can perform on
|that data. This is referred to in C as "type punning" and is considered
|as bad thing.

There are actually cases where it is fully legitimate. Consider a
routine that compares strings. In general one wishes to maintain the
opacity of the character type - which character code is in use is an
implementation-private affair - but the string comparison routine may
LEGITIMATELY happen to know that chars are stored as 8 bit unsigneds
with an alphabetically compatible order (let's say). From an external
perspective, you'd say that the routine was punning. Internally,
presumably, it is just in a scope where character and 8bit unsigned
are identified.

There are better ones than this. Consider a language that does smart
data representation. I have a type of error codes, with values like
DIDNT_WORK and YOU_MUST_BE_KIDDING. The compiler has assigned these
physical representations of 0, 1, .... I have another type of, oh, C
strings, represented by pointers in the usual way. Now, I write a
routine that returns:

	[ success: Boolean
	; if success
	  then result: String
	  else problem: ErrorCode
	  end
	]

The representation selector does a good job, and chooses a one-word
representation, packing all those fields together: "success" is
represented by that word being > 1, in which case that word as a whole
encodes the string value; otherwise the word as a whole is the error
value (the compiler is making use of special knowledge that no string
is stored at addresses below a certain number, of course. It's allowed
to.).

It is actually algorithmically CORRECT, now, to refer to an object of
my record type as a value of ANY of the types String (under the normal
representation), ErrorCode (under the normal representation), Boolean
(under the peculiar notation that you compare against some small whole
number) or the structure type as a whole. (Of course, use of the
component types needs to be underneath the discriminant guard, but
there's still a "live" pun between the struct, the discriminant and
the active branch).

There's a fundamentally different flavour to good tagless
implementations :-).
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------