🚀 go-pugleaf

olson@juliet.ll.mit.edu ( Steve Olson) writes:

  >In article <3086@opal.cs.tu-berlin.de> wg@opal.cs.tu-berlin.de (Wolfgang Grieskamp) writes:
  >   Since static or strong typing is a well established paradigm of software
  >   engineering I guess you are in the position to present some 
  >   arguments of evidence against it, arent you? Anyway, you did ...

 >Oops, not at all the same thing (didn't this come up a few weeks ago?).
 >In fact, most dynaically-typed languages (Lisp, Smalltalk) are strongly
 >typed.  Statically typed languages vary in the "strength" of thier typing.
 >I do not keep up with the software engineering literature, but I would venture
 >a guess that strong typing is the well established paradigm, and static
 >typing is, well, what we are arguing over ...

I dont't know the result of the result of the dispute some weeks ago,
but since I began to feel insecure (somebody e-mailed claiming too that
Lisp & Smalltalk are strongly typed) I looked up a reference:

	Cardelli & Wegner: "On Understanding Types, Data Abstractions,
	and Polymorphims"

	"Programming languages in which the type of every expression
	 can be determined by static program analysis are said to
	 be statically typed. ... [The] weaker requirement [is] 
	 that all expressions are guaranteed to be type consistent
	 although the type itself maybe statically unknown; this
	 can be generally done by adding some run-time type
	 checking [1]. Languages in which all expressions are
	 type consistent are called strongly typed languages. If
	 a language is strongly typed, its compiler can guarantee
	 that the programs it accepts will execute without type
	 errors [2]."

I interpret (1) that with a strongly typed language it might become
necessary to perform type checks at run-time (and thus associate
type information with values) in order to REALIZE THE SEMANTICS of a type
construct, but not to check type errors. (2) clearly drops Lisp
and Smalltalk out of the candidates for strongly typed languages.

Thats the way I learned it, I dont know if other references bring up
other definitions. :-)


--
Wolfgang Grieskamp 
wg@opal.cs.tu-berlin.de tub!tubopal!wg wg%opal@DB0TUI11.BITNET