On 9/22/05, Isaac Gouy <igouy / yahoo.com> wrote:> Austin Ziegler wrote:>> On 9/22/05, Isaac Gouy <igouy / yahoo.com> wrote:>>> Humbly suggest that C is not the poster child for static type>>> checking :-) iirc C is not even considered to be type safe.>> Humbly suggest that the same applies to Java (java.lang.Object,>> anyone?), C++, and even C#. The only type safe statically checked>> language that I've used is Ada.>>>> C is statically checked and weakly typed. Ara's point remains the>> same -- the compiler doesn't complain about these very *obvious*>> programming errors.> I'm not interested in quarreling about the meaning of phrases, so I> use textbook definitions - for "type safety" and "strong typing" see> p271 "Programming Languages: Application and Interpretation"> http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/
Could you be a bit less lazy and post the relevant text next time,rather than forcing people go to download a useless text just to discussthings with you?

      Type safety is the property that no primitive operation is      ever applied to values of the wrong type.
  By primitive operation we mean not only addition and so forth, but  also procedure application. In short, a safe language honors the  abstraction boundaries it erects. Since abstractions are crucial for  designing and maintaining large systems, safety is a key software  engineering attribute in a language. (Even most C++ libraries are  safe, but the problem is you have to be sure no legacy C library isn't  performing unsafe operations, too.) Using this concept, we can  construct the following table:
                    statically checked | not statically checked        type safe | ML, Java           | Scheme      type unsafe | C, C++             | assembly
  The important thing to remember is, due to the Halting Problem, some  checks simply can never be performed statically; something must always  be deferred to execution time. The trade-off in type design is to  minimize the time and space consumed by these objects during execution  (and, for that matter, how many guarantees a type system can tractably  give a user)n particular, in shuffling where the set of checked  operations lies between static and dynamic checking.
Basically, the author of the text in question is full of shit by placingJava in the "statically checked type safe" column. A primitive operation*can* be applied to values of the wrong type because all objects in Javaderive from java.lang.Object. All one needs to do is cast improperly.It's *harder*, mind you, to break the type protections in Java, but it'sstill not enough to call type safe. I refer you to<http://www.c2.com/cgi/wiki?JavaArraysBreakTypeSafety>.
  A Java array containing a reference type can be cast to an array of  the supertype. This breaks type safety, and therefore array accesses  have to be type checked at runtime.
  For example this code is valid at compile time and fails at run time.
    String[] strings = new String[1];    Object[] objects = strings;    objects[0] = new Integer(1); // RUN-TIME FAILURE
The author of the text you chose that supports your position alsosuggests that "strong typing" is a meaningless phrase, which merelyindicates his own bias. Also on c2, which I consider a bit more rigorousand authoritative than a random programming language text, see<http://www.c2.com/cgi/wiki?StaticTypeSafety>. There's discussion onthere about whether Java is type-safe or not, but someone has also takenmy position:
  A "type-safe" language that includes a cast operator is not type-safe.
Ada doesn't have a cast operator. Indeed, creating a subrange type ofInteger (e.g., WholeNumbers = Integer(0..INFINITY)) makes a type thatcannot be cast to Integer at all and is not compatible with Integer onany level; conversion is possible, but not casting. On the same page:
  The point is that because type systems are always "optional", the  alleged benefits of systems based upon them are largely illusory. It's  been my experience that the loudest advocates of strong type systems  have been the youngest developers on the team with the least long-term  support and development experience (based on the number of  applications dealt with, not length of time coding). I therefore  associate (perhaps unfairly) stridency in this regard with youthful  exuberance. -- TomStambaugh.
  [...]
  I realize, on rereading this, that I strongly endorse the underlying  discipline that results from working in a strongly typed environment.  I think that my view is that it is the *disciplined thought* that is  necessary, not the type system. Thus, I find that the Java and C++  type systems get in the way of the underlying rigor I bring to the  problem space, where as Lisp and Smalltalk environments let me express  that rigor in metastructure. I almost never write totally unstructured  random code. To the contrary, I generally want my code to reflect more  (or at least different) structure from that enforced by a  C++/Java-style static type system. -- TomStambaugh
The discussion is definitely up in the air as to whether Java is really"type safe" or not. I tend to agree with the position on cast operations-- which are different than *conversion* operations.
-austin--Austin Ziegler * halostatue / gmail.com               * Alternate: austin / halostatue.ca