Azure-functions-host: Feature Planning: first class F# support

[christopheranderson]

This is a tracking item for first class F# support. We'll be tracking the requirements and issues for first class F# support via this item. Feel free to leave comments about features/design patterns.

See Don's post below for more details

[enricosada]

My feedback:

good: f# function, not methods. async (the f# expr) also, not only Task. But a Task overload is useful
ideal: having a Type provider over function.json, so the run signature and types are generated and type safe. It also help about discoverability of parameters, because the Run function atm doesnt have an interface (afaik). Less binding magic (is ok for c#) and more generated types.

The last value of the script can be the main function (not the invocation).
That value should be cached by host, and invoked at each time the azure function should be triggered.

for example for the ResizeImage sample something like:

using discriminate union

let resizeIt original resized = async {
    let resizeSmallTo = myResizeImpl 200<px> 300<px>
    do! original |> resizeSmallTo resized 
}

type Resizer = AzureFunction<"../function.json">

resizeIt |> Resizer.Run.AsAsync

So the generated type is:

type ResizerRun =
   | AsAsync of (string -> string -> Async<unit>)
   | Sync of (string -> string -> unit)

and if needed there are other types in the signature (like the context, TraceWriter, etc)

using class

Or something like that but with Resizer as class with two static method Run/RunAsync who return an instance of the class.
The class will implement an interface, so from host can be casted to the interface and called with arguments.

the interface can be generic, like

interface ICanBeRun 
{
    Task<object> Run(IDictionary<string, object> args, Contex ctx, TraceWriter tw)
}

and the implementation of the type provider will cast args by name, and call the f# function.
So the binding magic is done inside the type provider

type SomeType =
  class
    member Run : f:(string -> string -> unit) -> ICanBeRun
    member RunAsync : f:(string -> string -> Async<unit>) -> ICanBeRun
  end

About logging:

Instead of passing context.log, just redefine printfn as context.log.
So doing printfn "Hi %s!" "devs", will write "Hi devs! to log.
Maybe that can be done opening a module, so is opt-in.

let printf format = Printf.ksprintf (fun s -> context.log(s)) format

[dsyme]

Hi @christopheranderson @fabiocav , here is my take on a first-cut of the feature specification. Please edit into the top of this issue, or delete the template above and edit directly here ( then I can edit too)

Specification is at https://github.com/dsyme/azure-webjobs-sdk-script/blob/dev/docs/fsharp-support.md

[tpetricek]

Regarding the debug flag - it seems that the C# compilation process always uses debug mode, just like the current F# prototype. The call to GetScriptCompilation here in the source code - in master always sets the second parameter debug to true.

[fabiocav]

@tpetricek that is correct. We have discussed introducing a configuration that to drive that logic (e.g. when users had the portal open, remote debugging or set explicitly), but that work hasn't been prioritized, so it should be safe to just continue to compile in debug mode for the time being.

[dsyme]

@fabiocav @christopheranderson Could you update this thread with links about where we should submit draft documentation and website updates to complete the items in the "Delivery" section please? When we met in Redmond you showed me the various sites to submit to (I think one site was internal to MS), but I don't think I kept a record of them

[dsyme]

Ping @fabiocav @christopheranderson :)

Could you update this thread with links about where we should submit draft documentation and website updates to complete the items in the "Delivery" section please?
When we met in Redmond you showed me the various sites to submit to (I think one site was internal to MS), but I don't think I kept a record of them

Thanks!
Don

[christopheranderson]

Documentation can be submitted to:

• https://github.com/Azure/azure-content/tree/master/articles/azure-functions

Specifically, we'll need a functions-reference-fsharp.md doc, maybe some touch ups.

Summoning @ggailey777, who might know other docs that would need updating.

If we want to update any marketing material, it just needs to be enumerated as an issue to our Portal repo. Specifically, we probably want our front page talking about F# and linking to samples.

[mathewc]

FYI: @fabiocav has merged the work @dsyme, @tpetricek and others have done into dev, and it will go out with the next release :)

[fabiocav]

Updated the existing F# templates to work with the new model here: https://github.com/Azure/azure-webjobs-sdk-templates/pull/291

Need to work on additional templates covering additional scenarios and bindings.

[lindydonna]

@dsyme We're tentatively targeting this week for lighting this up in the Azure portal, and Chris will write a blog post that describes what's new. We should have some docs that go out with this as well, something similar to https://github.com/Azure/azure-content/blob/master/articles/azure-functions/functions-reference-csharp.md. Rendered version: https://azure.microsoft.com/en-us/documentation/articles/functions-reference-csharp/