Having Nil not need a type parameter is absolutely not necessary for immutability. It just makes code involving Nil a tad more readable. Also cons lists are not our only option in immutable code, just as the mutable world is richer than just having ArrayList everywhere. On Oct 15, 2012 8:37 AM, "Kevin Wright" <kev.lee.wri...@gmail.com> wrote:
> > > On 15 October 2012 12:01, Reinier Zwitserloot <reini...@gmail.com> wrote: > >> On Monday, October 8, 2012 1:33:06 AM UTC+2, Simon Ochsenreither wrote: >> >>> I think it is an interesting example how some "pragmatic" and >>> superficially simpler approach tends to break down and cause complexity in >>> both the spec and the implementation compared to the "academic" solution. >>> >> >> Yes, java has no type that represents "there is no value that is this >> type, not even 'null'". It would be cool if this type existed; a method >> that had this as return type cannot actually return, ever. It has to exit >> abnormally: Either it runs System.exit(0), which should probably at that >> point return this special Nothing type (so that you can type: return >> System.exit(0)), or it has to throw an exception. There are no other ways >> out. >> > > There are other cases too, it also crops up in recursion where there's > absolutely no information whatsoever available for type inference. Just > consider: > > def method[A](x: A): A = method(x) > > > Something like this, without tail recursion, would ultimately crash the > JVM with a StackOverflowException. > > More importantly though... even given a variant that did terminate and > didn't stack overflow, what type could reasonably be inferred *except* for > Nothing? > > > >> Unfortunately, introducing this kind of concept is exactly the kind of >> thing java does NOT do, and languages like Scala DO do: it's not a matter >> of superiority, it's a matter of tradeoffs: If this Nothing exists, it >> cannot actually be a subtype of Object; a List<?> cannot accept an instance >> of List<Nothing>, because I can still put nulls in List<?>, and nulls are >> not a valid value for Nothing. Hell, generics in general play havoc with >> this: Using trickery I can make a List<Nothing> with nulls in it, and then >> write return thisHackedList.get(0), which means in practice that Nothing >> needs type checking (i.e. that would lead to a ClassCastException or >> similar, even if .get(0) returns null). >> > > Fortunately, this is *exactly* you you want to do with an immutable list! > > The only way to add an element to an immutable list is to create a new > list containing the old one as a subset. This means that the type of every > element in the existing list must subclass the element type of the new list. > > To put it another way, this means that the element being added to an > immutable list must be a superclass of the element type of all elements > already in the list. > > And, because such lists are immutable, they must be built up by starting > with an empty list. This empty list must have an element type such that > *anything* you might add to it is a superclass. > > The element type of such an empty list MUST be the subtype of every other > type in existence. > > That type is Nothing, and Scala's empty list (called Nil) is, indeed, an > instance of List[Nothing] > > List[Nothing] not only makes sense, it's actually a necessary requirement > to get immutability right. It also only works if Nothing is very much a > subclass of Object, and Null, and anything else you care to mention. > > > >> That's the kind of thing where java has decided that the practical upside >> of having a 'Nothing' value is not actually that much; it's largely >> academic, and it definitely "feels bad" that the language is not complete, >> and that this awesome concept is not actually in your language. However, >> adding it to the language definitely incurs a cost: The compiler needs to >> do all sorts of things to treat Nothing specially, and this is going to >> make the spec much more complicated. >> > > What of the cognitive cost to having this concept that developers must > necessarily encounter, then forcing them to use hacks and workarounds > because it cannot be represented in their programming language? > > > >> Scala-like design says you accept the complexity hit, and theorizes that >> if you go whole-hog on this you can actually remove a lot of complexity >> because the language is much more flexible. So far that seems like it's >> been working out reasonably well for scala. The java-like design says that >> these mostly academic features just aren't important enough, and in >> practice the language will be simpler if you just don't have them. Where >> people need them, they'll kludge it. >> > > Isn't that what they tried with Date? and then Calendar? > > >> Sounds ugly. Yet, java's popularity and the robustness of java-based apps >> like google ads and many a server out there suggest it's fine. >> > > It's a testament to what a decent developer is able to work around, but > the ecosystem developed on the back of Java's strengths and in spite of its > flaws - not *because* of its flaws! > > (Some newer languages got all of this right from the start.) >>> >> >> Right. I'm saying, well, the jury is still out on this. Is it actually >> right to burden your language with the Nothing concept? >> >> I'm pretty sure that retrofitting Nothing onto java is a grave mistake at >> this point. >> >> > I fear that the bigger mistake is to add lambdas, and immutable > structures, and the whole > the-free-lunch-is-over-my-GPU-has-1000-cores-we-desperately-need-to-get-concurrency-right > infrastructure, then to cripple it by missing something so fundamental from > the type system! > > -- > You received this message because you are subscribed to the Google Groups > "Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
