type safety (was Re: FAQ terminology harmonisation)

[Chris Pressey]

On Fri, 4 Apr 2003 01:29:53 -0800 (PST)
Thomas Lindgren <thomasl_erlang@REDACTED> wrote:

> There are two problems with records IMO:
> 
> - Records of different record type can be confused
> with each other (breaks type safeness in my eyes, but
> I consider it a bug in the implementation rather than
> something fundamental)
> 
> - The underlying tuples show through the record
> implementation. Unfortunate choice, but here the
> argument (not mine :-) seems to be that "records
> really are just syntactic sugar for tuples".

Exactly the things that keep records from being opaque.

> (Oh yeah, a third, related problem is the dependence
> on include files for record definitions.)
> 
> > We won't have type safety until we have truly opaque
> > types.
> > We have a warning not to let type information leak
> > out of a module.
> > But we currently *have* to implement types on top of
> > existing types:
> > usually tuples, or lists, or binaries could be used,
> > or even refs or
> > pids or atoms... but all of these can be confused
> > with others of the
> > same type, used in a different role.
> 
> It depends a bit on what you mean by type, I'd say --
> you can have exactly the same problem in SML. But I
> think you have a good point that it would sometimes be
> useful to have support for user-defined data types
> guaranteed to be distinct from all other types.

Not just useful, but required in order to honestly say that Erlang is
typesafe.

Perhaps there's some confusion between the concepts of a subtype and an
implementation type.

If I write a module that implements a subtype of some existing type, say
lists, then I'm implicitly guaranteeing that my type can be treated as a
list type - so there should be no problem when using is_list on it.
(You can then further check that it is my subtype of list, or use it as
a regular list with no danger of conflict, etc.)

If I write a module that implements an ADT and I say "The representation
of this type is not defined," like the programming rules recommend, and
like the dict module actually does, then the user *can't* safely
distinguish it from *any* other types in a case statement, because they
don't know what the implementation type is, so is_list or is_tuple or
even is_atom (etc) might accidentally succeed on it.

Of course - given that we already have the "counter-intuitive" tenet of
"crashing is good", if someone can come up with a compelling argument
for the equally counter-intuitive idea of "type safety is bad," that
would work too.  But I am yet to be convinced.

-Chris