🚀 go-pugleaf

bevan@cs.man.ac.uk (Stephen J Bevan) writes:
: In article <1992Apr8.180420.9294@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
:    The word `type' means any static attribute which is associated with
:    an identifier in such a way that _every_ occurrence of the identifier
:    in a given scope has that attribute.
: 
: Is this is a JLG definition or do others share this view?  It
: certainly doesn't match with what my idea of a "type" is.
: 
: 
:    The word `type' has no meaning at all if all attributes are
:    dynamically alterable.
: 
: I would have thought it did, the "type" is just the "type" at the
: particular time you look at it.  I'd consider this "dynamic typing".

Well in that case all you mean by "type" is some sort of "hidden value" that
hangs on with the object that affects what it means in any given
expression.  In other words, a "value" by any other name. In a real live
implementation do I have to store some variable that says what the "type" is
at any given time?  If so, then isn't it just another sort of value?  The
identifier, of course, is effectively a compound type, where one of the
subparts is some thing that specifies what type it is, and then the other
part is of course the conventional value of that object.  The "type" of that
object is the "value" of the type specifier.

A "type declaration" is then an assertion about the "special hidden value" of
the object.

Either something changes, or it doesn't.  When I write an identifier
is there _anything_ that I know "for sure" in a static sense that can
be computed at compile time?  In this way, "type declarations" are
assertions about correct program behavior that the programmer can
specify if desired.  I, along with JLG, believe that this is a good
idea in most circumstances.  Fancy global analysis inherently can
figure out less than what I can.  

For practical use, this 'special hidden value' might be a useful
do things that matches most problem domains, but please call a spade
a spade.

Perhaps this duality ought to be made explicit.

: Stephen J. Bevan				bevan@cs.man.ac.uk


Matt Kennel
mbk@inls1.ucsd.edu