Hmm, may be there are some languages that deal with nulls at compile time: Swift’s Option Chaining: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html
Kotlin’s null safety: http://kotlinlang.org/docs/reference/null-safety.html Ceylon’s optional types: http://ceylon-lang.org/documentation/1.0/spec/html/introduction.html#compiletimesafety Btw. Ceylon type system is pretty interesting because it has sub-typing and union/intersection types. > On 03 Mar 2015, at 23:31, Robbert van Dalen <[email protected]> wrote: > > Hi, > > I’m trying to model scala’s Option[+A] in Avail. > see: http://www.scala-lang.org/api/2.11.5/index.html#scala.Option > > The following little DSL is what I’ve come up with: > > Method "`?" is [ <> ]; > Method "_`?" is [ a : nontype | <a> ]; > Semantic restriction "_`?" is [ a : nontype's type | a? ]; > > Method “_+`?_" is > [ > a : number?, > b : number? > | > if |a|×|b| = 1 then [a[1] + b[1]?] else [?] > ] : number?; > > With these definitions, the following block: > > a : number? := 1? +? 2?; > b : number? := 1? +? ?; > <a,b> = <3?,?> > > yields true. > > So empty tuples denote ’None’ and 1 element tuples denote ‘Some’. > > But there are some obvious problems with this approach: > > 1) it is wasteful: it requires a tuple to wrap a value. > 2) options are not first class: they are an interpretation of <any…|0..1> > 3) we have to re-implement all methods on optionals (see "_+`?_") which are > just slightly deviations from their non-optional counterparts. > > Now to be honest, Scala also suffers from 1, as does Haskell and many more. > And Scala also suffers from 3), although that can be alleviated somewhat by > the use of implicits, albeit with a heavy penalty. > > But what about plain Java? > > I actually believe that you can use plain Java (or the JVM) to solve 1 and 2 > with: > > … nulls! > > Alas, most java method implementations usually don't account for 3, with the > dreaded Null Pointer exception as the consequence. > > But why shouldn’t they? > Dealing with nulls in Java actually means you understand that *every* > non-primitive A in Java is actually an Option[+A] in disguise. > So I’m saying null *isn’t* the million dollar mistake. Null is actually a > practical/efficient implementation of Option[+A]! > > Of course, there is a downside: > > … less efficiency! > > Because the manipulation of (Some) objects that you *know* are never going to > be null, still need to be checked for being null (None) at runtime. > And to reduce duplicate code, we *must* implement the more generic optional > case, subsuming the non-optional case. > > Now surely, compilers should be able to figure out - at compile time - > whether a value will never be null, and weed out the unnecessary null checks! > Currently, I cannot think of any compiler capable of that feat. > But I have high hopes that Avail will in the near future. > > Lastly, you may wonder why I’m so keen on implementing Option[+A] efficiently? > Because they are used extensively in the real world > Consider: > > - The double NaN > - The SQL null > - .. > > However, there is one tricky thing about using null values. > They force you to use a three-valued logic or partial-order. > Because null is not equal to null. > Just try joining SQL columns with the != predicate, and you’ll know! > > cheers, > Robbert.
signature.asc
Description: Message signed with OpenPGP using GPGMail
