🚀 go-pugleaf

Summary:

Expires:

Sender:

Followup-To:


In article <803@cit-vax.Caltech.Edu> susser@cit-vax.Caltech.Edu
(Joshua B. Susser) writes:
>
>I think static type checking would necessarily destroy the polymorphic
>nature of Smalltalk.  Types would have to be declared and message
>bindings checked at compile time.  Even allowing that variables could

This is not i(necessarily) true.  If one allows types to specify unions
of classes rather than just singletons, the polymorphic nature of the
language can be maintained.  Further, if one treats the type
declarations merely as HINTS, and not absolutes, allowing the
programmer to violate them at his will if he so desires, then
we eliminate the problem with a perform.  An interesting point for
ST-80 compiler writers is that actually doing a real message send
can change the state of the image ARBITRARILY.  Treating type declarations
and inferrences based on them merely as hints and providing graceful
fallback code helps to get around this problem.

>be one of several specified types, how would you deal with performs,
>or with applications that created new classes on the fly?  What if you

Have you done this (dynamic classes, that is)?  I have just recently,
and I had to pull some rather sneaky tricks to get things to work how I
wanted.  If this was anything more than a passing remark, I'd like to
hear more.

>Even in a well-implemented system, static typing would be much more
>work for the programmer.  

Here here!

>                          And, I maintain, all this extra work would be
>of no benefit, and probably some detriment.
>
>There is not a problem with the way typing is handled in Smalltalk
>currently.  The vast majority of bugs in Smalltalk programs are not
>type errors.

I would most certainly concur on that. 

>              A type-checking compiler would not be a useful tool in
>Smalltalk - there are already plenty of tools in Smalltalk to allow me
>to make certain I know what I'm doing.  Static typing is for
>early-bound, non-polymorphic languages.

There are two reasons I can think of for a type system: helping to
generate more efficient code, and to educate novice users. I don't
want to repeat myself too much, so see other posting today.

>--Josh Susser
>  susser.pasa@xerox.com (preferred email box)
>  susser@csvax.caltech.edu


	-bob atkinson
	BAtkinson.pa@Xerox.(arpa||com)
	BAtkinson.pa%Xerox.com@Csnet-relay.csnet