type safety (was Re: FAQ terminology harmonisation)

[Chris Pressey]

On Fri, 04 Apr 2003 00:28:09 +0100
"C.Reinke" <C.Reinke@REDACTED> wrote:

> [me]
> > Because no matter how well I try to make it opaque, I can't.

Sorry if my tone came across as a bit curt, I was in a rush.

> While I don't disagree with the general message, you may be
> overly pessimistic about data abstraction.

Probably more pedantic than pessimistic.  I'd like to be able to call
Erlang typesafe, but it's not quite there.

> In fact, I thought
> this was handled in the programming rules, but re-reading
> those after your message shows it isn't.

Half-way - it suggests all messages be sent as tagged tuples - I would
add that that should be extended to user-defined types as well.
(If we can't be opaque, we should at least be consistent.)

> [...]
> The basic idea is that if there is one abstract type in the 
> language, we might be able to build other abstractions on top
> of that. Functions fit that bill wonderfully (the only thing
> you can do with a function is to apply it). In particular, 
> there is no need for a module implementing an abstract type
> to expose anything but the API functions.

I'm not sure that solves the problem - it just moves it from one
existing type to another (or, I don't follow you and you'll have to give
me an example.)

I think the problem is more with the pattern matching than the types.

In order to achieve type safety, I need to be able to construct a value
that does NOT match in any of the following assertions:

  is_tuple(X)
  is_record(X, R)
  is_list(X)
  is_binary(X)
  is_pid(X)
  is_function(X)
  etc...

For this to be, I would need a facility to create an opaque type which
is not merely a subtype of one of those.

The *only* assertion that ought to be able to match it in a case (or
other) statement would be:

  is_type(X, T)

where T is the name of my type.  THEN Erlang will be typesafe.

Of course, if structs were added *as a unique type*, i.e. NOT just
implemented as dicts or tuples, then

  is_struct(X, S)

would work too.

Or, if it would not break existing code, the 3rd option would be to make
records opaque, i.e.:

  (is_record(X, R) and is_tuple(X)) == false

-Chris