Isn't "transitive" the wrong word?

[Scott S. McCoy]

On Fri, 2008-04-04 at 11:17 -0700, Walter Bright wrote:
> BCS wrote:
> > Walter Bright wrote:
> >> Janice Caron wrote:
> >>
> >>> Sorry to go all grammar/mathematics nit-picky, but isn't "transitive"
> >>> completely the wrong word?
> >>
> >>
> >> No, it is used in this sense in academic papers on the subject.
> > 
> > That might not answer the question.
> > 
> > One question that should be asked (but it might be to late to ask) is; 
> > is transitive the word that /should/ be used? Note that this is distinct 
> > from the question of transitive being the world that /is/ used.
> 
> We should only invent new jargon if we're forced to. I don't see any 
> compelling reason not to use transitive in the same form that academics 
> use it to write papers about.

It's dubious, but not "wrong".

given const(int) a;
and a is typeof(b)
and b is typeof(c)
then c is const(int).

This is generally true with all type classes and other attributes of a
type system, with the exception of storage classes such as static,
final, and const.  Transitive const would imply that const storage
class is now transitive, where previously only the type was
transitive.  Naturally, this has another implication of making const an
attribute of the value, as opposed to an attribute of the identifier,
which interestingly subsequently enough revokes it's previous
definition of being a storage class.  This means const is no longer a
storage class, but an attribute of the value type.

That is, const(int) is not the value type int with the storage class
const.  const is now an attribute of the value type system and int is
no longer the type of a int marked "const", it's now simply
const(int).  It might be possible that it could be demoted into an int
by copy-on-reference, or promoted into an invariant(int).  It might
also be that const(int) is a descendant of int.  But const(int) is now
the type.

Naturally this opens the door for other terms which could be used to
define the concept: the const value type attribute.  Or, const as a
part of the value type system, or whatever.

So now that we're all talking about this, how about normalizing the
syntax of const?

private const int foo;

The above example is inconsistent for a number of reasons.  The first,
that const is listed as a storage class as opposed to an attribute of
the value type.  And again it's inconsistent in a context I previously
brought up:

private const int foo;
public const const(int) bar () { return foo; }

In the above example, the behavior of the keyword "const" is relatively
schizophrenic.  const is listed as a part of the storage class for foo,
and then as an access qualifier for bar(), with the same syntax.  It
would seem more consistent with the essence of const if const was
always an attribute of the type, when associated with a value.

private const(int) foo;

This would also mean that:

private const int foo;

could maintain it's previous definition, which is a part of what's
making people so frustrated about const.  Since const is listed in the
storage-class part of the declaration, const as a storage class could
be possible.  Alternatively, const as a storage class could be a syntax
error.

Cheerio,
	Scott S. McCoy