Summary: strong/weak typing and pointers

[Mike Meyer]

Steven Bethard <steven.bethard at gmail.com> writes:

> Gabriel Zachmann writes:
> In summary, there are basically three interpretations of "weak-typing" discussed
> in this thread:
>
> (1)  A language is "weakly-typed" if it allows code to take a block of memory
> that was originally defined as one type and reinterpret the bits of this block
> as another type.
>
> (2) A language is "weakly-typed" if it has a large number of implicit coercions.
>
> (3) A language is "weakly-typed" if it often treats objects of one type as other
> types.
>
> Definition 1 is the definition most commonly used in Programming Languages
> literature, and allows a language to be called "weakly-typed" based only on the
> language definition.  However, for all intents and purposes, it is only
> applicable to statically typed languages; no one on the list could come up with
> a dyamically typed language that allowed bit-reinterpretation.

Definition 1 is a black/white proposition instead of being a
continuum. Once you allow the simple case needed for real-world work
of allowing an object to be treated as whatever it is or a sequence of
bytes, you can treat any type as any other type.

> Definition 2 seemed to be the definition most commonly used on the list, most
> likely because it is actually applicable to a dynamically typed language like
> Python.  It has the problem that in a language that supports operator
> overloading (like Python), programmers can make their language more
> "weakly-typed" by simply providing additional coercions, thus whether or not a
> language is called "weakly-typed" depends both on the language definition and
> any code written in the language.

This problem can largely be made to go away by limiting it to builtin
types. Likewise for definition 3.

I'd call Ruby's allowing builtin types to be changed a
misfeature. Builtin types should be subclassed.

            <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.