🚀 go-pugleaf

In article <6143@crdgw1.crd.ge.com> chao@sunflower.crd.ge.com (William Chao) writes:
>In the paper "Basic Polymorphic typechecking," by Luca Cardelli,
>Science of Computer Programming 8 (1987) pp. 147-172. On page 150:
>-----------------------------------------------------------------------
>Polymorphic type systems try to reconcile these two goals
>by providing all the safety of statically typed languages,
>and most (but not all) the flexibility of untyped languages.
>-----------------------------------------------------------------------
>My 1st question: Why he says "but not all?"

Languages without mandatory compile-time typing, such as Common
Lisp, are able to manipulate information elements of
heterogeneous, unrelated types in a uniform manner.  A Common Lisp
list, for example, can contain elements of completely different
types - an integer, a complex number, a function, another list,
etc. - and operate on them all in a uniform fashion.  All types
are reusable to the programmer of the list, and the list is
reusable to writers of new types in the future.

>2nd question: It seems that the "full" flexibility of untyped languages
>              will never be achieved by static typing, then static binding.
>	      Does this imply that we got to have dynamic binding to accomplish
>	      the full reusability?

In my opinion, *yes*.

>3rd question: People (especially real-time systems) are against dynamic binding
>	      because it is too slow. Some people use the same reason (too
>	      slow) to against object-oriented programming. Can we do somethings
>	      about this?

Several approaches:

a) Show that a dynamically bound system can or does meet the
real-time constraints *of your application* right now.

b) Look for, or agitate for, a better-optimizing language
implementation.  Much optimization is based on essentially the
same principle as demand paging and RAM caches:  Make the usual
cases faster, at the expense of the rarer ones, while maintaining
a simple, uniform abstraction for the application programmer.

c) Look for, or agitate for, a more powerful processor.  Of
course, greater expense may require competitive justification -
e.g., greater functionality, flexibility, productivity, or
reusability.  But arguments just such as these have in the past
been successfully employed to justify C over assembly language,
the UNIX System over MS-DOS, the X Window System over native
window systems, etc.

d)  Go ahead and prototype your system on a high-reusability
platform.  You may find that a higher level of abstraction permits
the use of better algorithms, resulting in *better* total
performance than low-reusability implementations.  Even if not,
the computer industry's amazing price/performance increases may,
over time, make your solution feasible.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@ihlpf.att.com

Standard disclaimer.