🚀 go-pugleaf

In article <10287@june.cs.washington.edu> david@june.cs.washington.edu (David Callahan) writes:
>>> More accurately, run-time typing places the burden on the run-time
>>> system, whereas compile-time typing places the burden on the
>>> compiler *and* the programmer (who must provide explicit type
>>> declarations and obey them at all times during program
>>> development). 
>
>This statement is misleading. Many research languages perform
>compile-time type checking based on type-inference algorithms and
>allowing a powerful, polymorphic type system. While research work
>indicates that type-inference at reasonable generality is undecidable,
>it does not seem to be a tremendous problem in practice.

Consider a dynamically constructed list of objects such that:

a) The types of the elements have no necessary relation - i.e.,
the list is totally heterogeneous;

b) The types of the elements are not knowable at compile time, but
are each knowable at run time - i.e., a TYPE-OF or CLASS-OF
function is available;

c) The length of the list is not knowable at compile time, but is
knowable at run time.

Programs in run-time typed languages make ubiquitous use of such
lists.  If one cannot create and manipulate such lists easily and
efficiently in the research languages you describe, I suggest that
there is indeed a "problem in practice."  The distinction between
compile-time typing and run-time typing remains a valid one.

Moreover, a programming environment which requires specification
of all program parts in advance of compilation (e.g., in order to
perform type inferencing across function calls) faces essentially
the problems of compile-time typing:  hindrance of incremental
system development and obstruction of smooth system evolution.

Type inferencing within a function, or on programmer request
(e.g., via optional declarations), is of course a welcome optional
optimization.


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

Standard disclaimer.