type safety

[Chris Pressey]

I had the following thought about type safety:

In order to both hide the structure of a data type (so that one can
later change the implementation without breaking anything) and to allow
the data type to be matched in patterns (in cases and function heads and
so forth,) I think one needs to both partially define the data type, and
partially leave it undefined.

Not as weird as it sounds - e.g. if you have a queue, you could document
it like: "the structure of the queue data type is
  {queue, XXX}
where XXX is undefined outside the queue module."

This gives the data type implementor the opportunity to change the
implementation, but also lets the code that uses the data type
distinguish it from other data types.

I think many Erlang programmers probably do do this in one form or
another, but it's not systemized - it might be worth considering for the
next time the programming rules (specifically 3.11) are updated.

-Chris