Rethink how names are given to compiler-generated closures

[dsyme]

The heuristic used to name compiler-generated closures like foo@376 and clo43@53 is weak. In general the compiler tries to use a related name, e.g. the let identifier being bound, plus the source line number. The source line number seems to be useful, though we could perhaps use @line365 or similar.

The main problem appears to be with the name portion. I need to collect specific micro samples but some things I've noticed are

• Unnecessary use of the backup name clo
• Sometimes other compiler-generated names are used as the basis for the name. In debug code I've even seen closure names like Pipe input at line 63@53 recently after the addition of pipeline debugging and I think some are appearing in our codegen tests for queries

Anyway, we can surely have a better heuristic where useful names are always given.

[kerams]

let a = [1 .. 50] |> List.map (fun x -> x * 2)

For simple cases like this it would be fantastic to see List-map@line1columnXX instead of a@1.

let a = [1 .. 50] |> List.map (fun x -> x * 2), [1 .. 50] |> List.map (fun x -> x * 2)

Here the two closure would be differentiated by the column number, not a@1 and a@1-1.

let a b = async {
    try
        return b + b
    with _ ->
        return 0
}

This generates a@2, a@3-1 a@3-2, a@2-3, a@2-4 and a@5-5. Perhaps keep the a prefix (when the closures are compiler-generated and completely invisible to the user), but also include a hint as to the purpose of the particular closure?

[Daniel-Svensson]

I like it how it works for simple lamdas in functions where they are named based on function name and line number such as https://sharplab.io/#v2:EYLgHgbALANANiAZgZwD4HsAOBTAdgAgGUBPZAF2wFsBYAKDOJ3wGEAKASnwF478/842MvgCGAJzHd8AbVQBGGACYYAZlQBdXv0pVg2SQH0AdAFkhAC3QATDty38AghJHEjlEZnytEAVwJh8AFoAPnwwAGp8RXZ7fiA=

I hope that case will continue to give as good names so it is easy to se which function and line a lamda belongs to

[dsyme]

For simple cases like this it would be fantastic to see List-map@line1columnXX instead of a@1.

@baronfel My intuition is that using "List.map" wouldn't be a good change - that is, using the name of the method being called will just be very unusual.

I hope that case will continue to give as good names so it is easy to se which function and line a lamda belongs to

Yes, the main change I'm looking at is to not use the name of local values that aren't functions. For example,

open System
type C() =
    let arr = [|1,2,3|]
    member _.Method() =
     let y = List.map (fun x -> x+ 2) [ 1; 1 ]
     y, y

Here we are using y as the prefix name for the closure, this feels confusing because "y" is neither a function or type name.

See https://sharplab.io/#v2:EYLgHgbALANANiAZgZwD4HsAOBTAdgAgGUBPZAF2wFsBYAKDOJ3wGEAKASnwF478/842MvgCGAJzHd8AbVQBGGACYYAZlQBdXv0pVg2SQH0AdAFkhAC3QATDty39Bw4lIAyAS3JHKIzPlaIAVwIwfABaAD58MABqfEVOaXw5AG4k/E1afj5iGHxie34gA===

This would change to use "Method" as the prefix.

[dsyme]

This generates a@2, a@3-1 a@3-2, a@2-3, a@2-4 and a@5-5. Perhaps keep the a prefix (when the closures are compiler-generated and completely invisible to the user), but also include a hint as to the purpose of the particular closure?

Giving useful names ("async-try-block", "async-try-handler", "async-combine-delay"....) to the anonymous closures generated through computation expressions and other code generation is indeed a good idea. It would mean propagating an optional closure name string all the way through from syntax tree to typed tree output but it should be possible.

[teo-tsirpanis]

Sonething else to consider is nested functions. In cases like

let f1 x y =
    let rec impl z =

let f2 x y =
    let rec impl z =

neither impl's compiled name indicates inside which function it is nested.

[dsyme]

@teo-tsirpanis Yes, I agree, I guess we could use f1-impl @ line 31 or something

[NinoFloris]

That would be very helpful in stack traces. We may want to just take the module level function name and optional nested function name to keep names somewhat concise. Narrowing it down from that point is usually easy enough.

[dsyme]

These names can get long, that's mainly what worries me.

And I ask myself: what notation would be most intuitive to a beginner?

[teo-tsirpanis]

How about making it @l59, adding a small hint that 59 is a line number but without bloating stack traces for those who already know what it means?