🚀 go-pugleaf

David Gudeman
Norman Diamond
Raul Rockwell

dg>>>... static typing implies ... all expressions can be assigned types
dg>>>from a restricted set ... such that machine representations can be
dg>>>decided on at compile time 
nd>>Yes.
dg>>>                           and such that no type information has to
dg>>>be associated with a value at runtime.
nd>>No.

rr>No, "type information has to be associated with a value at runtime" ?

Type information might or might not be needed at runtime, depending on
the type.  Actually did not distinguish between static typing and static
classing, since no one else seems to be interested in distinguishing
these.

rr>Then what is dynamic typing?

From what I've seen in this argument, dynamic typing is the absence of
programmer specification of types.

rr>Or, was this a statement that "constant type tags can be assiciated
rr>with a value at runtime"?  If so, it is far from a clear statement.

Why would type tags have to be constant?

nd>>Why not both [dynamic and static typing] ?

rr>"Both" is, by definition, not static typing -- such a language would
rr>allow you to express statements which can not be statically typed.

Indeed, "both" means that the language would allow you to express
statements which cannot be statically typed, and also statements which
can be statically typed, and also statements which are constrained to
static types by administrative fiat.

rr>On the other hand, it is often a simple matter (of strength reduction) to
rr>extract static typing information from statements in a dynamically
rr>typed language.

"Often" is the key word in that sentence.  It is often possible to write
C programs without the use of "void *", but someone decided that "often"
isn't "often enough."

>One distinction is that in a dynamically typed language type
>assertions are "just another operator" and most likely will use the
>same syntactic conventions as other language operators.

Oh, this sounds like a "both" ... haven't seen one of those yet.

>In statically
>typed language this does not have to be the case, and usually is not.

Once upon a time, "uniformity of reference" was a buzz-phrase.  People
liked Fortran and PL/I better than Algol because array element selection
looked like function calls, and they would have liked structure selection
to look like function calls too, so that the client would not have to
"know" the kind (I don't want to say "type" this time) of structuring
involved to retrieve the data.  However, the Pascal and C style of square
brackets for arrays and dot for structures (and parentheses for function
calls) seems to have won.  I like it too.  It seems to reduce confusion.

I think that to use different syntax to distinguish static properties
of an entity from its dynamic properties also might reduce confusion.

>This was hashed out in comp.lang.misc about a month ago, though it
>might not have been expressed fully in any one article.

Sorry, I wasn't reading comp.lang.misc then.
--
Norman Diamond       diamond@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.