Enabling debug breaks on |> operators

[KevinRansom]

Opened by antofik at codeplex

Currently, I rarely use the |> operator because of their opaqueness in the debugger, and instead have to resort to series of var names that end with more and more prime symbols. The latter is error-prone, and I'd like to be able to use |>s more confidently in my code.

This issue suggests that |> be made to generate a sequence point, at least in debug builds, so that break points can be placed on them. Additionally, the intermediate results of |> chains would have to be represented as a specially-named variable in VS's Locals variable viewer window.

Here's the CC'd conversation as Don and I discussed it on Twitter - https://twitter.com/bryanedds/status/460140352213504000

comments
KevinRansom wrote Apr 28, 2014 at 11:13 AM [x]
This is a great suggestion, we would certainly be interested in seeing PRs to address this.

antofik wrote Nov 24, 2014 at 12:29 AM [x]
Changing match case for SynExpr.Iden in UntypedParseInfo.ValidateBreakpointLocationImpl(range), ServiceUntypedParse.fs:124 enables us to set breakpoint on |> while in "Edit" mode. But while you are in "Debug" mode, breakpoint continues to slide to the whole line. It looks as if breakpoint changes location while changing state from Pending to Bind.
And I cannot find in code nor implementation of IVsDebugger, nor implementation of IDebugPendingBreakpoint2. Am I correct assuming that F# uses some default debug engine?

brodyberg wrote Nov 24, 2014 at 7:43 AM [x]
That's interesting, I'll see if I can repro that and look for the other interfaces you mention.

brodyberg wrote Nov 24, 2014 at 7:59 AM [x]
Oh, one thing I gathered from speaking with Don Syme is that information is being lost at optimization time - for this reason I have been investigating this from the point of view of opt.fs, with a view toward identifying the information the structure has before and after optimization such that we can preserve information so the breakpoint remains after being optimized away.

antofik wrote Nov 25, 2014 at 12:35 PM [x]
brodyberg, it's quite easy to reproduce. Replace SyncExpr.Ident with following snippet (ServiceUntypedParse.fs163, walkExpr function:

                 | SynExpr.Ident op ->
                    if rangeContainsPos op.idRange pos then
                        match op.idText with
                        | "op_PipeRight" -> yield! checkRange op.idRange
                        | _ -> ()
                    else ()

Optimization - that's quite understandable, though several questions arise. First, who is revalidating breakpoint after LanguageService has validated them? Second, we certainly would like to see intermediate results when stopped on |> instruction, so we need to add some autos (like $exception). But I cannot see how it can be done without direct access to the debug engine. Any ideas?

antofik wrote Nov 26, 2014 at 5:43 AM [x]
Or, while in DEBUG mode, we can substitute |> definition with something like

let (|>) x f = 
     let intermediate_result = f x
     ignore() // here we will place breakpoint
     intermediate_result

[brodyberg]

I continue to work on this - and my goal is to apply the change to all the pipes in both directions assuming that makes sense in the final change.

[cmeeren]

Was this forgotten? Dropped? It would be great to see this implemented!

[Happypig375]

Would extending this to all operators make sense? Long operator chains are used quite frequently.

[baronfel]

For example it's quite common to do this in web programming with the combinator models of Suave and Giraffe. Enabling better debugging/stepping of those operators would be much appreciated.

[brodyberg]

Don Syme has guidance for people interested in offering a patch.

…

On Wed, Jun 2, 2021 at 9:11 AM Chet Husk ***@***.***> wrote: For example it's quite common to do this in web programming with the combinator models of Suave and Giraffe. Enabling better debugging/stepping of those operators would be much appreciated. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFDE257FSHL4GOG3M2WMDTQZJ25ANCNFSM4A2PKWDA> .

[brodyberg]

@cmeeren I'm no longer involved in the project.

[Happypig375]

@KevinRansom Was this completed?

[Happypig375]

@KevinRansom ?