Mutual Recursion with Async Workflow Possible Compiler Issue

[psantoro]

The placement of a mutually recursive async workflow's ending curly brace seems to impact compilation success when it probably shouldn't. The sample code with comments demonstrates the issue. If I'm mistaken, I'd appreciate an explanation (i.e. some offside issue that I'm not seeing).

Repro steps

1. Step A - Compile the sample code in the attached zip and note the errors related to climateControl3.
   main.zip

Expected behavior

I would have expected that the placement of the ending curly brace in climateControl3, which is the same as in the non-mutual recursive function climateControl2, would not generate compiler errors.

Actual behavior

The above sample code will generate climateControl3 compiler errors when compiled:

main.fs(45,5): error FS0588: The block following this 'let' is unfinished. Every code block is an expression and must have a result. 'let' cannot be the final code element in a block. Consider giving this block an explicit result.

main.fs(53,5): error FS0010: Unexpected keyword 'and' in lambda expression. Expected incomplete structured construct at or before this point or other token.

main.fs(62,5): error FS0010: Incomplete structured construct at or before this point in binding. Expected incomplete str uctured construct at or before this point or other token.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0\fsc.EXE"' : return code '0x1'
Stop.

Known workarounds

The placement of the ending brace should follow the example in climateControl1.

Related information

Provide any related information

• Operating system - Windows 7 with updates
• Branch
• .NET Runtime, CoreCLR or Mono Version 4.5-4.7
• Editing Tools (e.g. Visual Studio Version) VS2017 with updates, F# 4.1, and VIM
• Links to F# RFCs or entries on https://github.com/fsharp/fslang-suggestions
• Links to performance testing scripts
• Indications of severity

[chillitom]

The repro code in case anyone doesn't want to download the zip.

#light
module app.main

open System
open System.IO

type message =
    | HeatUp
    | CoolDown
 
let climateControl1 = MailboxProcessor.Start( fun inbox ->
    // NOTE compiles
    let rec heating() = async {
        printfn "Heating"
        let! msg = inbox.Receive()
        match msg with
        | CoolDown -> return! cooling()
        | _ -> return! heating()} // NOTE placement of }
 
    and cooling() = async {
        printfn "Cooling"
        let! msg = inbox.Receive()
        match msg with
        | HeatUp -> return! heating()
        | _ -> return! cooling()} // NOTE placement of }
 
    heating()
    )

let climateControl2 = MailboxProcessor.Start( fun inbox ->
    // NOTE compiles
    let rec heating() = async {
        printfn "Heating"
        let! msg = inbox.Receive()
        match msg with
        | CoolDown -> return ()
        | _ -> return! heating()
    } // NOTE placement of }
 
    heating()
    )

let climateControl3 = MailboxProcessor.Start( fun inbox ->
    // NOTE does not compile
    let rec heating() = async {
        printfn "Heating"
        let! msg = inbox.Receive()
        match msg with
        | CoolDown -> return! cooling()
        | _ -> return! heating()
    } // NOTE placement of }
 
    and cooling() = async {
        printfn "Cooling"
        let! msg = inbox.Receive()
        match msg with
        | HeatUp -> return! heating()
        | _ -> return! cooling()
    } // NOTE placement of }
 
    heating()
    )

[<EntryPoint>]
let main argv =
    printfn "test"
    0

[dsyme]

We will treat this by design, though please feel free to add an issure at http://github.com/fsharp/fslang-suggestions. Just indent the closing } where necessary, e.g. by 2-spaces or as you've shown.

[cartermp]

@dsyme What is the rationale for by-designing this? I think it's fairly reasonable to expect people to want to put the closing brace as the example shows.

Currently, the auto de-indentation feature in VS will auto de-indent to the same indentation level as the let binding, which I consider correct:

After all, it's valid already, and given that the async declaration is on the same line as the let declaration, it makes sense to me that the closing brace can be at that same indentation level.

[dsyme]

@cartermp OK, I try to take a look next week at what it would take to fix this.

[cartermp]

Thanks!