Comment by lmm | Hacker News Reader

Comment by lmm | Hacker News Reader

Parent Full thread

As a huge Scala fan, some of this fills me with apprehension.

Existentials should always be a last resort, so it's ok if their syntax is a bit cumbersome; I find the forSome style a lot less confusing in its implications (e.g. "why can't I add a String to a List[_ <: String]" is a common newcomer question) and it avoids confusion with higher-kinded types. So if anything I'd rather drop the List[_] syntax, and use List[T] forSome {type T} exclusively. (Eliminating existentials entirely would be nice, but they're needed for Java interop).

The dotty approach of replacing type parameters with type members fills me with fear. Type parameters are simple and reliable; type members are confusing and the compiler often needs more help to get them right. I can appreciate the desire to not have two features that overlap, but this is removing the feature that works well in favour of the feature that doesn't.

Monads for effects work really well, and the community is just starting to get a library stack together that makes them easy - look at e.g. http4s for where the grassroots innovation is. They're simple to reason about because they're just ordinary types following the ordinary rules, and we have a lot of library support for making them easy to work with. By contrast implicits are still the most confusing and error-prone part of the language - look at all the trouble people have with Future and ExecutionContext. The example given in the slideshow looks like a perfect use case for scalaz Kleisli. Rather than another specialized language feature, the truly scalalike solution would be to make it easier for "function literals" to have user-defined types - perhaps k{ body } to have body be promoted to a Kleisli, a la s"" interpolators.

Scala gets a lot right, and I don't think I'd ever be tempted away to Haskell - strictness and impurity are simply too useful. Some parts can't be changed - subtying is here to stay (and needed for interop), and much as I wish tuples could be replaced with HLists, they probably can't. That by itself is enough to leave room for a successor to eat Scala's lunch. But for now it's a brilliant language, fun and safe and commercially viable; I really do love the language, and a few of these things (union types) could make it even better. But too many of these ideas feel like missteps.

I'm not expert in any of this stuff, but reading that slide, I was kind of getting the impression that existential types and higher-kinded types are being unified, in the grand scheme of Dotty exploiting theoretical equivalences of previously separated concepts. Same with the type parameter/member thing. I think the idea is that syntax will support both options, as seen with the analogous introduction of the value parameter syntax for traits, but the underlying implementation will be abstract members. This seems like it will make writing type level code or interop code much simpler, because there's only one underlying implementation to worry about. But re-reading your comment, I think you agree with that benefit. Do you know why abstract members were chosen as the underlying implementation? Are they more general?

I agree that native HList functionality within tuples and case classes would be really huge for practical programming. It's a huge pain to abstractly define transformations over families of classes. It's awesome that Shapeless works, but more native support within the language could maybe help remove some of the challenge of actually using Shapeless.

> I think the idea is that syntax will support both options, as seen with the analogous introduction of the value parameter syntax for traits, but the underlying implementation will be abstract members.

Right; my problem here is that type inference handles type parameters fine and often doesn't handle type members without an explicit type. If the implementation is always type members that means we're always in the unpleasant case.

> Do you know why abstract members were chosen as the underlying implementation? Are they more general?

Yeah they are - there are some things you can't express as type parameters that you can express as type members. But there's value in making the simple case simple.

Ah gotcha. Well, can't the type inference just work the same as it does now, if you happen to use type parameters? And possibly, couldn't type inference that works in these cases be extended to type members? I would hope that this would be a side benefit of pushing towards more formal and unified underpinnings of surface features.

> Well, can't the type inference just work the same as it does now, if you happen to use type parameters?

I think it can only work with type parameters because they're constrained in what they can do. If type parameters compile down to type members, presumably there is no "marker" that says that that type member obeys those constraints - if there is then it wouldn't really be unification of type members and type parameters.

Interestingly Scala 2.12 will have support for user defined types using function literals (it's actually in 2.11 behind a compiler flag). This feature is referred SAM (single abstract method) functions [1].

Also, there are plans to move tuples to something more like HLists. You can see it here[2] as part of 3 under 'Don Giovanni'.

[1] - https://typesafe.com/blog/scala-211-has-arrived [2] - http://www.scala-lang.org/news/roadmap-next

Yeah, I know about SAM support. But that will only happen if the type is known, and type-annotating every short {} is a pretty big price. Or can I do something like:

    myKleisli >=> {a => Option(a.toString)}

and have SAM figure out that that's another Kleisli?

Yeah, I think that would work.

edit - I think the need for explicit types for each SAM was fixed by https://issues.scala-lang.org/browse/SI-8310

> "why can't I add a String to a List[_ <: String]" is a common newcomer question

Can you explain this, or point to a source that does?

String was a poor example, let's make it "why can't I add a Long to a List[_ <: Number]". With the more verbose syntax "List[T] forSome {type T <: Number}" the issue becomes much more obvious IMO - T could e.g. be Float.

Aha, that makes more sense. I interpret a type like `List[_ <: Number]` as a list with any kind of elements, whereas `List[T] forSome {type T <: Number}` makes sense to be a list with a specific kind of elements, with the type of the elements constrained (of course, assuming that List is invariant).

forsome vs forall

Reply on news.ycombinator.com