🚀 go-pugleaf

In article <s37hvINN1j1@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
   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' 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.

Logically this is true for most languages.  It is only in the
implementation of certain languages that _static_ information from the
program text can allow the "hidden value" to be optimised away.


  In other words, a "value" by any other name.

Yes, the "type" value.


   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?

Again yes, the "type" 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.

Yes to all this, though I'm not keen on the "special hidden value"
stuff, just call it a "type" :-)


   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?

Depends on the language your writing in.


   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.

I agree.


   Fancy global analysis inherently can figure out less than what I
   can.

Ah, but it's nice :-)


   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.

I thought I was, I call it a "type".  I use "type" to encompass the
the _static_ type as seen in the program text, and the _dynamic_ type
as seen in some programming languages, and I make these distinctions
clear if it isn't from the context.  JLG's original definition equated
type with the former and didn't allow it to cover the latter.  That is
what I object to.  I have similar problems with some (well known) OO
promoters who equate "strong typing" with "static typing" when IMHO
they are orthogonal.


   Perhaps this duality ought to be made explicit.

I thought it already was, that is why I was puzzled by JLG's
definition of "type".

bevan