Re: strong/weak typing terminology (was Re: [Caml-list] Scripting in ocaml)

[Chad Perrin <perrin@apotheon.com>]

On Sat, Dec 23, 2006 at 02:48:23PM +1100, skaller wrote:
> On Fri, 2006-12-22 at 13:17 -0700, Chad Perrin wrote:
> 
> > This all seems rather simple to me:
> > 
> > It's type-safe if you cannot get type errors without subverting the type
> > system.
> 
> You are missing something. There's no such thing as a 'type error'
> at run time in a statically typed language. At run time object values
> are just bit strings, they don't HAVE any types -- and even that
> is an abstraction (really you just have registers and machine
> code .. not even really bit strings).

That's not quite true.  A "type error" is what happens when an operation
is performed on a value of a type different from the operation's type.
For instance, integer addition on a float or string, or concatenation on
an integer or float, is a type error in most languages.  Statically
typed languages are commonly thought to avoid such type errors at
runtime almost tautologically, but play with casts and pointers in some
dangerous ways in C/C++ and you may quickly learn that is not the case.


> 
> Python has a static type system. Did you know? Everything has
> type 'object'.

That's a pretty weird interpretation of the Python type system -- and
it's categorically false, because there are many things in Python that
are not objects.  You might be able to make such a claim for Ruby, even
though I would consider even that to be a dubious claim due to the other
type-related behavior of the language.  In fact, objects have types.
That's sorta the point of objects, from a certain perspective: defining
types to extend your type system in a manner that makes it possible to
achieve certain benefits in coding such as reusability and modularity.


> 
> So in fact Python is quite type safe, and statically so.
> Big deal. The type system isn't expressive enough for that
> to mean anything!
> 
> Similarly, Ocaml is NOT type safe because array bounds can
> be violated at run time. This is because the type system
> is not expressive enough to capture the array bound as
> part of the type.

I don't know OCaml quite well enough to say this with authority, but at
a guess I'd say that's not a type error.  It's an error, but not a type
error, because it does not involve applying an operation to a value of a
given type (or similarly mismatch types).  It's more akin to a buffer
overrun than a type error.

Also, this directly contradicts your own earlier definition of "type
safety", because OCaml is pretty clearly a statically typed language.


> 
> So saying a language is type-safe is meaningless unless
> you also say how expressive the type system is: either
> way the program isn't safe, and the choice of typing is
> often dictated by what can be statically checked, rather
> than what NEEDS to be checked. So 'type safe' is a fairly
> vague concept in this sense.
> 
> It really comes down to "I think Ocaml is a better programming
> language for my purpose than C++".

So much for language theory.  I guess it's all balderdash, then.

By the way, I wrote a longish email (I didn't think it was *THAT* long,
but apparently it was) earlier today that never made it through to the
list.  I can only guess that it must be in moderation because of its
length.  It gets into some depth on the subject of defining type system
characteristics, and might be worth a read if it ever appears.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors.  A program
is what you give the audience." - Larry Wall