From f3dfdd45a6090d4c4fe4944a0cf9f9845fbfff82 Mon Sep 17 00:00:00 2001 From: Martin Odersky Date: Wed, 7 Dec 2016 20:01:16 +0000 Subject: [PATCH 1/3] Enable disqs --- .../2016-12-07-implicit-function-types.md | 43 +++++++++++-------- 1 file changed, 24 insertions(+), 19 deletions(-) diff --git a/blog/_posts/2016-12-07-implicit-function-types.md b/blog/_posts/2016-12-07-implicit-function-types.md index b717dd937..6b61debf7 100644 --- a/blog/_posts/2016-12-07-implicit-function-types.md +++ b/blog/_posts/2016-12-07-implicit-function-types.md @@ -2,7 +2,8 @@ layout: blog post-type: blog title: Implicit Function Types -by: Martin Odersky +author: Martin Odersky +authorImg: /images/martin.jpg --- I just made the [first pull request](https://github.com/lampepfl/dotty/pull/1775) to add _implicit function types_ to @@ -46,18 +47,18 @@ element and the site where it is used. Consequently, it becomes tedious to define all those intermediate parameters and to pass them along to where they are eventually consumed. -Implicit parameters solve one half of the problem. Implicit -parameters do not have to be propagated using boilerplate code; the -compiler takes care of that. This makes them practical in many -scenarios where plain parameters would be too cumbersome. For -instance, type classes would be a lot less popular if one would have -to pass all dictionaries by hand. Implicit parameters are also very -useful as a general context passing mechanism. For instance in the -_dotty_ compiler, almost every function takes an implicit context -parameter which defines all elements relating to the current state of -the compilation. This is in my experience much better than the cake -pattern because it is lightweight and can express context changes in a -purely functional way. +_Implicit parameters_ solve one half of the problem. They do not have to +be propagated using boilerplate code; the compiler takes care of +that. This makes them practical in many scenarios where plain +parameters would be too cumbersome. For instance, type classes would +be a lot less popular if one would have to pass all dictionaries by +hand. Implicit parameters are also very useful as a general context +passing mechanism. For instance in the _dotty_ compiler, almost every +function takes an implicit context parameter which defines all +elements relating to the current state of the compilation. This is in +my experience much better than the cake pattern because it is +lightweight and can express context changes in a purely functional +way. The main downside of implicit parameters is the verbosity of their declaration syntax. It's hard to illustrate this with a smallish example, @@ -354,11 +355,15 @@ this blog post is already too long. ## Conclusion -Implicit function types are a unique way to abstract over the context in -which some piece of code is run. I believe they will deeply influence -the way we write Scala in the future. They are very powerful +Implicit function types are a unique way to abstract over the context +in which some piece of code is run. I believe they will deeply +influence the way we write Scala in the future. They are very powerful abstractions, in the sense that just declaring a type of a function will inject certain implicit values into the scope of the function's -implementation. Can this be abused, making code more obscure? -Absolutely, like every other powerful abstraction technique. To keep -your code sane, please keep the [Principle of Least Power](http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html) in mind. +implementation. A lot of use cases can profit from this power to +eliminate boilerplate and make code clearer. Can this be abused, +making code more obscure? Absolutely, like every other powerful +abstraction technique. To keep your code sane, please keep the +[Principle of Least +Power](http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html) +in mind. From c7b06d4e9dc20df5bf55933ef69faca1ffcd4e3b Mon Sep 17 00:00:00 2001 From: Martin Odersky Date: Wed, 7 Dec 2016 20:06:56 +0000 Subject: [PATCH 2/3] Tweak --- blog/_posts/2016-12-07-implicit-function-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/_posts/2016-12-07-implicit-function-types.md b/blog/_posts/2016-12-07-implicit-function-types.md index 6b61debf7..4cf4d01bd 100644 --- a/blog/_posts/2016-12-07-implicit-function-types.md +++ b/blog/_posts/2016-12-07-implicit-function-types.md @@ -360,7 +360,7 @@ in which some piece of code is run. I believe they will deeply influence the way we write Scala in the future. They are very powerful abstractions, in the sense that just declaring a type of a function will inject certain implicit values into the scope of the function's -implementation. A lot of use cases can profit from this power to +implementation. Many use cases can profit from this power to eliminate boilerplate and make code clearer. Can this be abused, making code more obscure? Absolutely, like every other powerful abstraction technique. To keep your code sane, please keep the From 5936f9edb3fedd1c25bc2011384fc7432a9ecb55 Mon Sep 17 00:00:00 2001 From: Martin Odersky Date: Thu, 8 Dec 2016 09:21:55 +0000 Subject: [PATCH 3/3] Renamed to Dec 7, link to Discourse --- blog/_posts/2016-12-07-implicit-function-types.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/blog/_posts/2016-12-07-implicit-function-types.md b/blog/_posts/2016-12-07-implicit-function-types.md index 4cf4d01bd..d90572cad 100644 --- a/blog/_posts/2016-12-07-implicit-function-types.md +++ b/blog/_posts/2016-12-07-implicit-function-types.md @@ -367,3 +367,11 @@ abstraction technique. To keep your code sane, please keep the [Principle of Least Power](http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html) in mind. + +## Comments? + +If you have comments or questions, I suggest you head over to the +[Scala +Contributors](https://contributors.scala-lang.org/t/implicit-function-types/219) +discourse discussion thread. It would be great to go more into depth there. +