On Sat, Jan 29, 2000 at 02:21:04PM -0500, David N. Smith IBM" wrote:
[deletia]
> Mark (and others):
> 
> I agree that types lead to better compiler output, but SELF showed
>that that doesn't mean the programmer has to *write* those types (nor
>actually write those classes either).

Hmmm.  I somewhat disagree with your assertion that types lead to
better compiled code.  It may be true in object-oriented languages but
with low-level procedural languages (e.g. C), types mean that the
compiler often has to generate extra code to preserve the type
restrictions.  For example, if a processor has 32-bit registers and a
the compiler implements a 16-bit short type, the compiler has to make
sure that the results of short arithmetic are truncated down to 16
bits after each arithmetic operation.  If C didn't have types--just
had register-sized variables that you could treat however you
wanted--the code generated would be more efficient, at least on a
mediocre compiler.

Types are a big win in C because they help the compiler catch stupid
but fatal errors (e.g. "foo = NULL;" vs. "*foo=NULL;").

Errors like the above are quite serious in C and tend to either a)
crash the program or machine, b) alter some arbitrary piece of memory
that causes a crash later or produces incorrect results or c) work
fine until you make an innocuous change elsewhere.

In contrast, a similar sort of error in Smalltalk brings up the
debugger and it's almost always blazingly obvious what the problem
is.

That is, the consequence of typing violations are far less severe in
Smalltalk (and presumably other safe, dynamic languages) than in C,
assembly language or other low-level languages.

I don't think strong typing should be evaluated in a vacuum.

> However, programs don't just sit there statically. Programs
>run. Type checking is static.
> 
> Smalltalk doesn't even have types if one uses the standard
>dictionary definition of type; Smalltalk has classes which are quite
>a different thing. But Smalltalk does not require that an instance of
>a specific class be passed or assigned, nor does it require an
>instance of one of its subclasses be used as the only alternatives.
> 
> Smalltalk allows, and programmers pass, any kind of instance which
>has enough of the right protocol that it won't fail. If a passed
>object is sent #nextPut:, #nextPutAll:, and #cr, then anything that
>responds to these three messages is OK to pass.

In other words, Smalltalk objects have types but the variables don't.

For a good example of a safe but truly typeless language, try Tcl.  In
Tcl, everything is a string.  This is flexible but the language
doesn't "know" the type of anything and so rarely is able to do any of
those automatic type-specific things most other languages do
(e.g. automatically formatting output in a "correct" manner).

> This isn't some kind of evil to be eradicated, but a true language
>feature unavailable in most other languages. Look around in Squeak;
>how often is, say, a stream passed and how often are these streams
>related only by their protocol?

The proof of this can be seen in how strongly-typed languages try to
implement this sort of behaviour.  (Templates, anyone?)



				   --Chris