4 ms·

> Implicits are a generalisation of default arguments. There is an extreme semantic difference between an implicit parameter and a default argument. Have you s

> Implicits are a generalisation of default arguments. There is an extreme semantic difference between an implicit parameter and a default argument. Have you spent any time at all using them? That's like claiming HKT is just a generalization of type constructors. Would you claim that HKT isn't anything new or novel because constructors have been around forever?

YorkshireSeason 9y ago
> Have you spent any time at all using them? Sure I have used both. Default arguments and implicits both have the same key idea: you can omit arguments to functions, and the compiler, guided by type information, synthesises the missing arguments during compilation. In order to understand the difference between both, it is crucial to realise that this compile-time synthesis of missing arguments has two related but different dimensions. - Declaration that an argument is allowed to be omitted (and hence synthesised automatically). - Declaration of the missing argument that is used in this synthesis. Default arguments merge these two into one, e.g. with def f ( int x ) ( bool b = false ) = ... f (2) f (2) all calls f(2) become f(2)(false). The problem with this is that the devault value to be used in synthesis cannot be context dependent. Implicit arguments separate these two, enabling the programmer to make default context dependent, e. g. def f ( int x ) ( implicit bool b ) = ... implicit val c = true f (2) implicit val c = false f (2) Now the first call f(2) is rewritten to f(2)(true), while the second becomes f(2)(false). > Would you claim that HKT isn't anything new or novel because constructors have been around forever? I'm not sure I see the connection: constructors are program constructs, while HKTs are "types for types".
- ionforce 9y ago
  Maybe a disagreement here is fueled by the power level difference in these two features. Beyond the superficial injection examples, Scala implicits also support injecting values constructed dynamically and also recursive/derived implicits.
  - YorkshireSeason 9y ago
    > injecting values constructed dynamically You can also do this with default arguments, e.g. like so: let f x y = let g (a = x+1) b = ... ... For example the following is valid OCaml: let bump ?(step = 1) x = let waa ?( a = step+17 ) b = a * b in x + step + waa 666;; Here the function waa has a default argument whose default argument depends on bump's default argument. > recursive/derived implicits Recursion is quite restricted, for example this is not valid Scala: def f ( x : Int ) ( implicit y : Int ) : Int = { implicit val a = 17 f ( x+1 ) }
    - lptk 9y ago
      Your example of nested functions with default arguments does not correspond to what derived implicits do. As a result of implicit resolution, an expression with an arbitrary number of subexpressions may be synthesized, the shape of which depends on the types involves. Default parameters simply cannot do that. The example you give to justify "recursion is quite restricted" is not a restriction on recursion at all, it's an ambiguity problem. Define `a` as `y` to shadow the function parameter, and it compiles.
      - YorkshireSeason 9y ago
        > does not correspond to what derived implicits do I did not claim it did. The first example disproved ionforce's claim that default values cannot be constructed dynamically. > Define `a` as `y` to shadow the function parameter, Whoops, yes that's correct. I didn't realise this was possible.
        lptk 9y ago
        > The first example disproved ionforce's claim that default values cannot be constructed dynamically. But I don't think that is what they meant. I think they meant something along the lines of what I said above: > an expression with an arbitrary number of subexpressions may be synthesized, the shape of which depends on the types involves
- lmm 9y ago
  > Default arguments and implicits both have the same key idea: you can omit arguments to functions, and the compiler, guided by type information, synthesises the missing arguments during compilation. Saying implicits are a generalization of default arguments because they're both synthesized during compilation is like saying steam trains are a generalization of pipes because they're both made of metal. It elides too big a difference to be helpful, to the point that it's actually misleading.
  - YorkshireSeason 9y ago
    I'm not saying implicits and default parameters are the same thing. I'm saying the key idea behind implicits is the realisation that default arguments merge two ideas that should be kept separate, if we want context dependent defaults. Some of implicit's other features can (and have been) added to default arguments, see my other reply.
    - lmm 9y ago
      > I'm saying the key idea behind implicits is the realisation that default arguments merge two ideas that should be kept separate, if we want context dependent defaults. This isn't true though - that's not what implicits are for and not how they're used. Indeed the clearest proof is that Scala still has default arguments, and they still have the behaviour given in your OCaml example. They're different things.
      - YorkshireSeason 8y ago
        I did not say implicits and default arguments are the same thing. I said that implicits improve upon default arguments in various ways, the key realisation being the split between providing elided values in a context-dependent way, and permitting the elision of values. I should not have said the key idea, but a key idea. Default arguments are convenient if you don't need context dependence of elided arguments. I'd probably have remove defaults in order to have a smaller and more simple language.

YorkshireSeason 9y ago

> Have you spent any time at all using them? Sure I have used both. Default arguments and implicits both have the same key idea: you can omit arguments to functions, and the compiler, guided by type information, synthesises the missing arguments during compilation. In order to understand the difference between both, it is crucial to realise that this compile-time synthesis of missing arguments has two related but different dimensions. - Declaration that an argument is allowed to be omitted (and hence synthesised automatically). - Declaration of the missing argument that is used in this synthesis. Default arguments merge these two into one, e.g. with def f ( int x ) ( bool b = false ) = ... f (2) f (2) all calls f(2) become f(2)(false). The problem with this is that the devault value to be used in synthesis cannot be context dependent. Implicit arguments separate these two, enabling the programmer to make default context dependent, e. g. def f ( int x ) ( implicit bool b ) = ... implicit val c = true f (2) implicit val c = false f (2) Now the first call f(2) is rewritten to f(2)(true), while the second becomes f(2)(false). > Would you claim that HKT isn't anything new or novel because constructors have been around forever? I'm not sure I see the connection: constructors are program constructs, while HKTs are "types for types".

ionforce 9y ago
Maybe a disagreement here is fueled by the power level difference in these two features. Beyond the superficial injection examples, Scala implicits also support injecting values constructed dynamically and also recursive/derived implicits.
- YorkshireSeason 9y ago
  > injecting values constructed dynamically You can also do this with default arguments, e.g. like so: let f x y = let g (a = x+1) b = ... ... For example the following is valid OCaml: let bump ?(step = 1) x = let waa ?( a = step+17 ) b = a * b in x + step + waa 666;; Here the function waa has a default argument whose default argument depends on bump's default argument. > recursive/derived implicits Recursion is quite restricted, for example this is not valid Scala: def f ( x : Int ) ( implicit y : Int ) : Int = { implicit val a = 17 f ( x+1 ) }
  - lptk 9y ago
    Your example of nested functions with default arguments does not correspond to what derived implicits do. As a result of implicit resolution, an expression with an arbitrary number of subexpressions may be synthesized, the shape of which depends on the types involves. Default parameters simply cannot do that. The example you give to justify "recursion is quite restricted" is not a restriction on recursion at all, it's an ambiguity problem. Define `a` as `y` to shadow the function parameter, and it compiles.
    - YorkshireSeason 9y ago
      > does not correspond to what derived implicits do I did not claim it did. The first example disproved ionforce's claim that default values cannot be constructed dynamically. > Define `a` as `y` to shadow the function parameter, Whoops, yes that's correct. I didn't realise this was possible.
      - lptk 9y ago
        > The first example disproved ionforce's claim that default values cannot be constructed dynamically. But I don't think that is what they meant. I think they meant something along the lines of what I said above: > an expression with an arbitrary number of subexpressions may be synthesized, the shape of which depends on the types involves
lmm 9y ago
> Default arguments and implicits both have the same key idea: you can omit arguments to functions, and the compiler, guided by type information, synthesises the missing arguments during compilation. Saying implicits are a generalization of default arguments because they're both synthesized during compilation is like saying steam trains are a generalization of pipes because they're both made of metal. It elides too big a difference to be helpful, to the point that it's actually misleading.
- YorkshireSeason 9y ago
  I'm not saying implicits and default parameters are the same thing. I'm saying the key idea behind implicits is the realisation that default arguments merge two ideas that should be kept separate, if we want context dependent defaults. Some of implicit's other features can (and have been) added to default arguments, see my other reply.
  - lmm 9y ago
    > I'm saying the key idea behind implicits is the realisation that default arguments merge two ideas that should be kept separate, if we want context dependent defaults. This isn't true though - that's not what implicits are for and not how they're used. Indeed the clearest proof is that Scala still has default arguments, and they still have the behaviour given in your OCaml example. They're different things.
    - YorkshireSeason 8y ago
      I did not say implicits and default arguments are the same thing. I said that implicits improve upon default arguments in various ways, the key realisation being the split between providing elided values in a context-dependent way, and permitting the elision of values. I should not have said the key idea, but a key idea. Default arguments are convenient if you don't need context dependence of elided arguments. I'd probably have remove defaults in order to have a smaller and more simple language.