type safety (was Re: FAQ terminology harmonisation)

[C.Reinke]

Sean,

> > 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). 
> 
> Just out of interest what problem domain are you using Erlang for? In
> several years of using Erlang in relatively complex internet and telecoms
> type applications I've not found this to be a real problem at all. Major
> components of the systems exist as separate OTP applications and do not
> share any common patterns, and within subsystems, tagged tuples seem to do
> fine.

I'm not using Erlang much, certainly not for anything useful (yet;),
but I've been working with several functional languages (including
Lisp, KiR, Clean, ML, Haskell, and Erlang), and for the last years,
Haskell has been my main development language. I've encountered the
problem I described in all languages that support pattern matching,
even within subsystems, so I'm slightly surprised by your statement
(what happens to your receive statements when you've got to extend
one of your tagged tuples?).

The reason why I still use Haskell instead of Erlang is that (a)
my applications focus more on computation than on communication,
and (b) due to my work in language design, I like to prototype
domain-specific languages by embedding them into a general purpose
host language. In both of these areas, Haskell simply offers more
expressiveness and more concise specifications, and Concurrent
Haskell goes a long way when concurrency is needed.  So while I
think Haskell is incomplete in several respects, and Erlang covers
some of those areas better, Erlang has its own blind spots and
Haskell is overall a better match for my problems.

Current problem domains include a domain-specific embedded language
for dynamic 3d scenes and a refactoring tool for Haskell (as
mentioned before, we'd love to find someone to extend the latter
project to cover Erlang as well;-). In both domains, there are lots
of non-trivial data types (e.g., some mimicking the grammars of the
DSEL or of Haskell) with lots of constructors. 

If those can be seen in modules all over the project, it is tempting
to use the powers of pattern matching. But then you've got yourself
a task whenever the types change (which is admittedly more likely in
the kind of research & prototyping environment I'm working in).
That's not difficult to get right (in fact, this is one of the areas
where the type system will tell you precisely where type providers
and type clients disagree over their common interface), but it is
annoying and tiresome (by the end of our functional refactoring
project, that task may be automated:), so when large numbers of
modules are involved, types have a tendency to get frozen.

Cheers,
Claus
http://www.cs.kent.ac.uk/people/staff/cr3/