[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dynamic vs. static typing

On 25 Nov 2003, at 19:42, Neelakantan Krishnaswami wrote:

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

Huh? But that's easy! Just write subclasses of the data structures you 
need and write methods for the generic functions you don't want that 
just throw appropriate exceptions.

Or am I still missing something?


Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."