🚀 go-pugleaf

[anonymous quotes...]
>>>         object-oriented programming. Smalltalk has, in effect, no
>>>         types, but there are typed extensions to Smalltalk, e.g.,
>>
>> Again, CL and Smalltalk have *run-time* types - restrictions on
>> the use of *objects* during program *execution*.  Languages such
>> as Ada have *compile-time* types - restrictions on the use of
>> *identifiers* during program *compilation.*

I think there is some confusion here between "having types" and "being
typed".  In particular, it is possible for a language to have types
(as Smalltalk and CL do) and still to be untyped (as Smalltalk and CL
are).  These languages are not "weakly typed", they are "untyped".

All languages "have types", in the sense that values in the language
can be categorized (even if there is only one category).  CL has the
types "integer", "real", "string", "cons", etc.

A language is said to "be typed" if the identifiers of the language
(variable, function names, etc.)  are constrained to represent values
of specific types.  The difference between strong and weak typing
involves how much you can say about the types of values that the
identifiers can take.

Here are examples in C (a typed language) and Icon (an untyped
language with a syntactic resemblance to C):

  int add(a,b) int a,b; {return a + b;}   /* C */

  procedure add(a,b) return a + b end     # Icon

The C procedure is typed because the identifiers "a" and "b" are
restricted to represent values of type int, and the identifier "add"
is restricted to represent a value of type (int X int) -> int
(actually the type restriction "add" is a rather trivial one since it
is a constant).

In the Icon procedure, "a" and "b" may have values of any type: int,
real, or even procedure.  If one of both of them is not numeric (or
convertible to numeric) then a run-time error will occur when you try
to add them.  Likewise, the identifier "add" in the Icon program is
untyped.  It may take on a value of a different type (even int) during
the execution of the program.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman