[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dynamic vs. static typing
Pascal Costanza writes:
> Anton van Straaten wrote:
> > A 'does not respond' error is a best case. A worse case is
> > sending a message to the wrong object that appears to be
> > understood - exactly the kind of error that can slip through unit
> > tests to manifest at runtime.
> It is my understanding that CLOS is a dynamically typed language in
> which this cannot happen because generic functions are globally
> unique. This ensures that if an object "happens" to understand a
> message then it does intentionally so.
I don't agree. I wrote a regexp package in Dylan, which compiled
regexps into NFAs, and then created an optimal DFA from them. Now,
one of the most central structures in the program was the transition
table. For NFAs I wanted a two-level mapping from characters+epsilon
to (states to state sets). For DFAs, I wanted the transition table to
be characters to (states to states). There was a fair amount of
support code that didn't care /too/ much about the specifics of the
mappings, and I tried to write code that would be generic over
both. The bugs in this code were typically very hard to find. This was
because both the NFA and DFA transition tables were of class
<red-black-tree>, and so they would "happen" to understand generic
calls they shouldn't have -- as a result, the runtime error showed up
quite far from the real source of the error.
The basic problem was that there wasn't any way for me to tell the
compiler that two types that coincidentally had similar physical
representations were really different.
This is also the basic reason I find numerical code difficult to
write: everything is a matrix, and the type systems for most languages
don't distinguish between different-sized matrices. This problem is
aggravated by the fact that most numerical languages let you play
array-conformance tricks as a convenience feature. For this domain I'd
*love* a typed Matlab-like language that could infer matrix shapes,
especially married to an IDE that let you highlight subexpressions to
display their size.