On Fri Apr 20 02:46 2012, Ambrose Bonnaire-Sergeant wrote: > I've been doing some thinking about the treatment of nil in a > statically typed version of Clojure. > > It occurs to me that nil is significantly different to Java's null > reference, which is almost a Bottom type. > > Java's null is a subtype of any reference type. Clojure's nil is just > nil, subtype to nothing except itself. > > To accomodate this, nil should be implicitly added to the result type > of any interaction with Java via interop. > > (Union syntax: (U x0 .. xn) is the union of types x0..nx) > > <expr> :- <type of expr> > > (Integer. 1) :- (U java.lang.Integer nil) > (.getClass 1) :- (U java.lang.Class nil) > (class 1) :- java.lang.Class > > So the equivalent type of java.lang.Object (in Java-land) is > (U java.lang.Object nil) (in Clojure-land). > > The exception to the implicit nil rule would be when a the result of > an interop expression is a primitive value. A Java primitive cannot be > null. > > (. Integer MAXVALUE) :- int > > Hopefully I expressed my thoughts clearly. Does this strategy seem > correct? Are there any other uses of null that I should be handling?
I think what you have here makes a lot of sense. As noted elsewhere in the thread, constructors should never return a null reference: they either succeed or throw an exception. The problem with Java, of course, is that there is generally no way to find out if a given method will return null. There are some attempts at annotations to help indicate that a Java reference may not be null [1], but there is no standard in this respect. It would be nice to have Typed Clojure be able to recognise some of these, or at least have the ability to add hint that a certain call will not return null. I'll give your typed clojure a try. Sincerely, Daniel [1]: http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
signature.asc
Description: Digital signature
