type safety (was Re: FAQ terminology harmonisation)

[Chris Pressey]

On Fri, 4 Apr 2003 09:50:12 -0800 (PST)
Thomas Lindgren <thomasl_erlang@REDACTED> wrote:

> 
> --- Chris Pressey <cpressey@REDACTED> wrote:
> > > 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.
> 
> In that case, I think we have different definitions of
> type safeness.
> 
> To clarify, what I mean by type safeness is roughly
> that integers cannot be mistaken for atoms, conses
> can't be cast to tuples, etc, in contrast with
> languages such as C or C++. "Strong" as opposed to
> "weak" types, as it once was known. User-defined types
> and ADTs are above and beyond that, using this
> definition.
> 
> Anyway, my main point previously was not to define
> type safeness, but to indicate a nice property which
> some languages have and some do not, so I think I'll
> leave it at that.
> 
> Best,
> Thomas

OK.  Yeah, my definition is probably a bit different.

One thought I just had was - if you try hard enough you can subvert the
type safety in any language.  I guess my definition of typesafe would
have to follow from that - that the shortest, most obvious route should
be the one which results in the least confusion between (all) types.

In that sense, C's typing is pretty safe (since casting is not the
shortest route.)

Does coercion figure into it?  I'd say probably, since it's an
intentional confusion of types - in that sense, both C and Erlang lose
points (because coercion IS the shortest route, unfortunately.)

So, it's not as simple as I maybe thought it was, going into it.

The tuple/record thing is still a bummer though.

And until something better comes along, the best I can suggest is that
all ADT's be put in the form of records/tagged tuples (simply because
this is probably the most common implementation type currently in use.)

-Chris