kjx@comp.vuw.ac.nz (R James Noble) (04/09/91)
What is the difference between foo + 43 400 / foo foo[400] foo.a and in which cases do we expect the compiler to generate type errors ? Obviously, even in so-called statically-typed languages, division and array indexing can produce runtime errors that could be considered type errors (on the variable foo, especially if it had a subrange type). An interesting perspective on type systems is the contained in Sethi's introductory text _Programming Langauges_ (the "teddy bear" book) which includes the following: (I parapharse without permission) Type systems can be strong or weak. A strong type system will not pass programs that are not type safe. A weak type system is not strong - that is, it may pass programs that are not type safe. I am not interested in weak type systems (lying to the compiler). A weak type system will permit execution of non-type safe programs; possibly with run-time errors, possibly not. Because of this, any other distinction between weak type systems is meaningless. For a given (strong) type system, any programs it admits will be type-safe. However, there may be many type-safe programs a strong type system will not admit. For example, a type system could fail all programs. This would be a strong type checker, although not a useful one. We can distinguish strong type systems from each other by the (size of) the subset of type-safe programs they actually admit. The heterogenous list example is a program which is type safe, but would not be accepted as such by almost all static type checkers. In pratice, type systems must decide how to check programs, and when to perform these checks. For example, Smalltalk checks type at runtime, as operations are invoked (messages sent). Smalltalk also checks numerically indexed structure access at run time (array indexing). However, it checks some symbolically indexed structure accesses at compile time (instance variables of self, viewing objects as structures with named slots). Pascal, on the other hand, checks assignment mostly at compile time, and often doesn't check structre access at all (array bounds turned off, variant record bounds checking nonexistant on most Pascal I've seen). In fact, often some assignment isn't checked, or is only checked at runtime (subrange variables). My point is that our ideas of static or dynamic typing, are not theoretically defined; rather they are names coined for various language implementation techniques. (And yes, _of course_ you can read "programming" for "language implementation". So what). The theoretical defintions tend to be after the fact. For example, is Ada, replete with garbage collection, array checking, arithmetic error exception generation and hidded tags on variant records (please excuse incorrect terminology) statically or dynamically typed? How about Oberon? -- R James Noble, Graduate Student, Computer Science Department Victoria University, Box 600, Wellington 1, New Zealand kjx@comp.vuw.ac.nz
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/14/91)
In article <KJX.91Apr10012252@turakirae.comp.vuw.ac.nz> kjx@comp.vuw.ac.nz (R James Noble) writes: > Obviously, even in so-called statically-typed languages, division and > array indexing can produce runtime errors that could be considered > type errors (on the variable foo, especially if it had a subrange type). And they could also be considered exceptions, which are not type errors. I'm not sure what people are trying to prove with this division example. ---Dan