Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!otter!adw
From: adw@otter.hpl.hp.com (Dave Wells)
Newsgroups: comp.lang.misc
Subject: Re: Re: Run-time Type Errors in Smalltalk (was Re: blip (was...))
Message-ID: <2400038@otter.hpl.hp.com>
Date: 11 Apr 91 11:53:10 GMT
References: <887@puck.mrcu>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 60

olson@lear.juliet.ll.mit.edu ( Steve Olson) writes:
>People who get endlessly alarmed about the alleged lack of type saftey in
>a dynamically-typed languge are not well-informed about how Lisp or Smalltalk
>software development actually works.

Disclaimer: there almost certainly are people who *are* overly concerned
with runtime type safety in dynamically-typed languges, and who needlessly
lie awake at night worrying about it.

However. There have also been claims that "type errors are actually quite
rare in dynamically-typed languges". (Anecdotal evidence follows). We have
just developed an 18k LOC, 83 user-class application using ACTOR (SmallTalk
72 with sugared syntax for the PC). We found that a majority of the bugs
would have been caught by even a simple (i.e. 'ANSI-C-like') static
typechecker.

Although most of these (those which we've found so far :-|) were found "on
the first pass through", testing such a relatively large interactive
application exhaustively *and repeatedly* is exceedingly expensive compared
to a comparable compilation-style typecheck.

You may also be interested by the following definition of "=" for Sets,
adapted from the ACTOR kernel source. Can you spot the type error? Can you
explain why it means that testing for membership in a heterogeneous Set
containing both Sets and Strings (say) *sometimes* fails with a runtime
type error (depending on how the Set members hash into physical locations
in the Set)?

/* Infix equality method for Sets. Sets are equal if they are the same size
and have equal members. */
Def =(self, collection)
{ if size(self) ~= size(collection)
  then ^nil
  endif;
  do(self,{using(member)
    if not(member in collection)
    then ^nil
    endif;
  });
}!!

I'd be happy with manifest types with static checking, even if it were
optional. I'd be happy with a type inference system which would tell me
that "<collection> must understand size() and in(). This makes it an Array,
Bag, Set or Interval." But, for the kind of development work we're doing,
I'm not at all happy with neither.

diamond@jit345.swstokyo.dec.com  Norman Diamond at Digital Equipment
Corporation Japan writes:
|Anyway, there is a middle ground ... [details omitted] ...
|
|I would not try to ram either static typing or static classing down
|anyone's throat, but both can be used by disciplined developers and
|maintainers to catch some errors early.  Although it cannot catch all
|errors, it certainly helps.  Part of the folklore of software engineering
|is the magnitude of increase in costs as error detection is delayed.

Exactly.

Dave