5 ms·

Implicit function types in the next version of Scala look very interesting. The main example in the presentation compares Kleisli functors to impure imperative

Implicit function types in the next version of Scala look very interesting. The main example in the presentation compares Kleisli functors to impure imperative code, and then gradually transforms the imperative code to Kleisli equivalent using implicit function types without changing the body of the imperative code -- that was pretty cool. I don't know if Scala 3 will be a game changer wrt to language adoption, but it's certainly going to deliver a lot of compelling new features/enhancements [1] Based on the 6 week rolling release schedule a stable release should land presumably no later than this summer? That seems wildly optimistic but they released 0.4 last month... [1] http://dotty.epfl.ch/#so-features http://dotty.epfl.ch/#so-features

fnl 9y ago
Indeed, if people would only use implicits the way Odersky recommends, I'd love Scala. The problem is, too many people do exactly what he warns about in this video. And so my love-hate relationship continues... :-)
- virtualwhys 9y ago
  If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. Otherwise, refresh my memory, what was he warning about with implicits? There's currently no way around definition site boilerplate (e.g. `implicit name: Type`); `implicit` keyword and providing a variable name are required. Implicit function types eliminate definition site boilerplate while providing function composition -- looks like a solid enhancement for FP in Scala.
  - fnl 9y ago
    That sounds like a great idea. So no more importing of implicits in Scala 3 to use them on methods of another package (or namespace)? That would make them quite a lot more "wieldable". What Odersky warns about is defining implicits on built-in types. Which IMO too often gets abused to hide poor design.
  - tekacs 9y ago
    > If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. That PR [1] is (IMO thankfully) not merged yet (marked as on hold) and reminds me of the indentation-based syntax proposal - ambitious, far from consensus on it being 'a good thing' by actual users, full of workarounds or escape hatches being sought by everyone, almost unilateral and very little to suggest it's even solving the problem it claims to (and it's fuzzy on what that is, exactly)[2]. Matching Rust's rules on this seems like the source motivator for Odersky and that only leads me to recall a conversation I had with a friend on these two languages and about a dozen or so practical, dramatically boilerplate- or complexity-reducing solutions that library authors or I had coded up; these would be either outlawed or made into large, complex workarounds under this scheme (Rust rules). Even in a codebase directly under my purview, we would have to duplicate implicits across modules (and keep them in sync), merge deliberately-separated modules and give up on some functionality altogether to support this proposal. These are mostly 'free' additional type safety constraints that we would just have to give up on. I'm not against making changes to make implicits easier to 'see'[3] - I'd only say that an approach with the above problems that gets worked around anyway is not the solution. [1]: https://github.com/lampepfl/dotty/pull/2060 https://github.com/lampepfl/dotty/pull/2060 [2]: Indeed even in this HN thread there are people criticising implicit parameters in a bunch of places (definitely not going away, IIRC Odersky likes them) - when people say 'they don't like implicits', between the various user demands they might well be removed in every variation. [3]: Indeed in IntelliJ IDEA and Ensime, every implicit conversion is underlined at the point of use. In that thread, someone suggests making implicits importable only with a modifier.
- Randgalt 9y ago
  So true. Implicit parameter explosion is one the worst aspects of maintaining Scala code. In larger projects trying to comprehend how to import and understand which implicit parameters are used/needed can be maddening.

fnl 9y ago

Indeed, if people would only use implicits the way Odersky recommends, I'd love Scala. The problem is, too many people do exactly what he warns about in this video. And so my love-hate relationship continues... :-)

virtualwhys 9y ago
If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. Otherwise, refresh my memory, what was he warning about with implicits? There's currently no way around definition site boilerplate (e.g. `implicit name: Type`); `implicit` keyword and providing a variable name are required. Implicit function types eliminate definition site boilerplate while providing function composition -- looks like a solid enhancement for FP in Scala.
- fnl 9y ago
  That sounds like a great idea. So no more importing of implicits in Scala 3 to use them on methods of another package (or namespace)? That would make them quite a lot more "wieldable". What Odersky warns about is defining implicits on built-in types. Which IMO too often gets abused to hide poor design.
- tekacs 9y ago
  > If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. That PR [1] is (IMO thankfully) not merged yet (marked as on hold) and reminds me of the indentation-based syntax proposal - ambitious, far from consensus on it being 'a good thing' by actual users, full of workarounds or escape hatches being sought by everyone, almost unilateral and very little to suggest it's even solving the problem it claims to (and it's fuzzy on what that is, exactly)[2]. Matching Rust's rules on this seems like the source motivator for Odersky and that only leads me to recall a conversation I had with a friend on these two languages and about a dozen or so practical, dramatically boilerplate- or complexity-reducing solutions that library authors or I had coded up; these would be either outlawed or made into large, complex workarounds under this scheme (Rust rules). Even in a codebase directly under my purview, we would have to duplicate implicits across modules (and keep them in sync), merge deliberately-separated modules and give up on some functionality altogether to support this proposal. These are mostly 'free' additional type safety constraints that we would just have to give up on. I'm not against making changes to make implicits easier to 'see'[3] - I'd only say that an approach with the above problems that gets worked around anyway is not the solution. [1]: https://github.com/lampepfl/dotty/pull/2060 https://github.com/lampepfl/dotty/pull/2060 [2]: Indeed even in this HN thread there are people criticising implicit parameters in a bunch of places (definitely not going away, IIRC Odersky likes them) - when people say 'they don't like implicits', between the various user demands they might well be removed in every variation. [3]: Indeed in IntelliJ IDEA and Ensime, every implicit conversion is underlined at the point of use. In that thread, someone suggests making implicits importable only with a modifier.
Randgalt 9y ago
So true. Implicit parameter explosion is one the worst aspects of maintaining Scala code. In larger projects trying to comprehend how to import and understand which implicit parameters are used/needed can be maddening.