6
let inline myfunction x y = ...

let inline mycurried = myfunction x // error, only functions may be marked inline

It seems impossible to explicitly inline curried functions. So whenever mycurried is called, it won't get inlined even if myfunction is inlined properly, is it correct?

So can this be regarded as one of the drawback of curried function?

Will Ness
  • 70,110
  • 9
  • 98
  • 181
colinfang
  • 20,909
  • 19
  • 90
  • 173

3 Answers3

5

I think your question is whether a point-free function can be inlined or not.

The limitation you found is not because of the curried function. Note that in your example the curried function is on the right side, on the left side you have a point-free function.

F# only allows functions to be inline, not constants.

I principle you may think this could be considered as a bug given that type inference is smart enough to find out that is a (point-free) function, but read the notes from Tomas regarding side-effects.

Apparently when the compiler finds on the left side only an identifier it fails with this error:

let inline myfunction x y = x + y

let inline mycurried  = myfunction 1

--> Only functions may be marked 'inline'

As Brian said a workaround is adding an explicit parameter on both sides:

let inline mycurried x  = (myfunction 1) x

but then your function is no longer point-free, it's the same as:

let inline mycurried x  = myfunction 1 x

Another way might be to add an explicit generic parameter:

let inline mycurried<'a>  = myfunction 1

when generic parameters are present explicitly on the left side it compiles.

I wish they remove the error message and turn it a warning, something like:

Since only functions can be 'inline' this value will be compiled as a function.

UPDATE

Thanks Tomas for your answer (and your downvote).

My personal opinion is this should be a warning, so you are aware that the semantic of your code will eventually change, but then it's up to you to decide what to do.

You say that inline is "just an optimization" but that's not entirely true:

. Simply turning all your functions inline does not guarantee optimal code.

. You may want to use static constraints and then you have to use inline.

I would like to be able to define my (kind-of) generic constants, as F# library already does (ie: GenericZero and GenericOne). I know my code will be pure, so I don't care if it is executed each time.

Gus
  • 25,839
  • 2
  • 51
  • 76
  • Note that changing the let binding from a _value_ (`let x = ...`) to a _function_ (`let x arg = ...`) may change the meaning of the function if the expression used to calculate the function has some effects. In the first case, the effects will be evaluated once and in the second, they will be evaluated repeatedly. If you want the effects to evaluate just once, then you cannot use `inline`. If you want to execute them multiple times, then I think it is fair to add an additional parameter. – Tomas Petricek Sep 23 '12 at 20:55
  • Adding a generic parameter is _very subtle_ because it still looks like a value, but it actually behaves as a function (i.e. the effects are evaluated repeatedly), so I would not recommend that. (Aside, I'm pretty sure that the behaviour is actually undefined - i.e. a future version of the compiler might decide to evaluate the effects just once for every generic type argument). – Tomas Petricek Sep 23 '12 at 20:56
  • The error message would not make sense in pure languages (like Haskell), but I think that preventing you from accidentally changing the behaviour of your program when you add `inline` just to optimize it is a very good decision. – Tomas Petricek Sep 23 '12 at 20:58
  • Thanks for adding this explanation to the answer! – Tomas Petricek Sep 27 '12 at 02:16
4

I think you just need to add an explicit parameter to both sides (though I have not tried):

let inline myfunction x y = ... 

let inline mycurried y = myfunction 42 y  // or whatever value (42)
Brian
  • 117,631
  • 17
  • 236
  • 300
2

The compiler only allows inline on let bindings that define a function. This is essentially the same thing as what is happening with F# value restriction (and see also here). As Brian says, you can easily workaround this by adding a parameter to your function.

Why does this restriction exist? If it was not there, then adding inline would change the meaning of your programs and that would be bad!

For example, say you have a function like this (which creates mutable state and returns a counter function):

let createCounter n = 
  let state = ref n
  (fun () -> incr state; !state)

Now, the following code:

let counter = createCounter 0

... creates a single global function that you can use multiple times (call counter()) and it will give you unique integers starting from 1. If you could mark it as inline:

let inline counter = createCounter 0

... then every time you use counter(), the compiler should replace that with createCounter 0 () and so you would get 1 every time you call the counter!

Community
  • 1
  • 1
Tomas Petricek
  • 240,744
  • 19
  • 378
  • 553
  • You're right. Actually you can compile it as inline doing the trick I mentioned: let inline counter<'a> = ...... Anyway I still would prefer a warning than a compilation error and having to rely on workarounds/tricks. – Gus Sep 21 '12 at 13:45
  • @Gustavo I think it is more than fair to get a compiler error when the inlining (which is really just an optimization) would change the semantics of your code. The error just tells you that the compiler _cannot_ inline values (and that makes very good sense). If you want (and can) turn a value into a function, then it is good you have to do it explicitly, because you have to think about whether this gives you the meaning you want. – Tomas Petricek Sep 23 '12 at 20:48
  • @Gustavo And yes, you can compile the code if you write `let inline counter<'T> = createCounter 0` and I think that's bad. It means that you'll always get `1` when you call `counter<_>()` and that is not the intended behaviour. – Tomas Petricek Sep 23 '12 at 20:52