type safety (was Re: FAQ terminology harmonisation)
Fri Apr 4 18:15:10 CEST 2003
> Hmm... This emphasis on exact matching on type would potentially break
> an aspect of Erlang I have learnt to appreciate: pattern matching. I can
> make a function match exactly or match with increasing degrees of
> generality. A special case function first, followed by general case. If
> none match, an exception occurs. I can work with a bit of dicipline and
> tag my tuples, and enforce that functions only acccept tagged tuples.
yes, pattern matching and data abstraction do not usually go well
together, as the former tries to expose internal structure whereas
the latter tries to hide it.
The problem is usually with pattern matching coupling too closely
(you change the implementation in one module and suddenly have to
adapt patterns all over your code base). There have been various
attempts to address that, reconciling pm and adts, but you seem
to refer to a different problem?
You can still do case selection on a special case/general case
basis, you just need to make sure that this doesn't depend on
the implementation type but only on the API.
Or, perhaps you mean that you sometimes want to be able to treat
different things as if they were the same? You can still do that,
but no longer by accident (because the different things just happen
to be implemented using the same representation right now). The
different things would have to support the same API (a kind of
interface subtyping). That also means that your case selection code
will still work when someone changes one of the internal
More information about the erlang-questions