type safety (was Re: FAQ terminology harmonisation)

[Sean Hinde]

Hi,

> > > 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?
> 
> 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?).

My point was really to challenge your bold assertion that these patterns
would get "everywhere across the code base". In a telecoms type system there
would typically be nicely designed small interfaces between major subsystems
- thus allowing the internal representations to be managed independently.

I don't think any sane person would argue that better tools for checking
different aspects of program correctness are a bad thing, but it seems
obvious that different domains rely on different tools in different
proportions (as you acknowledge).

Some other fairly random (but related) observations from my Erlang use:

* queue is a pain to use I agree!

* Sometimes (!) my brain is not big enough to understand a problem
completely enough to write the whole system fully type correct without first
trying to run something  and watch what it does. You might argue that I
should start small and grow, but I like the ability to sketch in new bits of
functionality which I know will crash if that condition appears but I just
want to watch it happen.

* Programs must be tested thoroughly in order to be sure they do the correct
thing. This as true of a Haskell program as it is of an Erlang program. The
end result of this is that the vast majority of Erlang type errors are found
before going live, and that the Erlang paradigm of "let it crash" and the
very high quality crash reports means that problems found during test are
easily fixed. 

The result seems to be pretty much good enough in the normal Erlang problem
domain.

> 
> 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.

Hence we agree :)

Sean



 NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.