You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FsToolkit.ErrorHandling recently added preliminary support for the applicative CE members feature of F# 5. After this was released, some constructs that users had no longer compiled.
Repro steps
Run the following script in a preview-enabled dotnet fsi: dotnet fsi --langversion:preview /path/to/script
The code fails to compile with the following error:
This construct may only be used within computation expressions
around the entire do! block
Known workarounds
The do! expression can be rewritten to
let!_= asyncResult {return()}
and the code will compile. This is semantically the same as do!, but requires user changes.
Related information
Here is a link to the fantomas tools for this snippet. What is immediately jumps out to me is that the do!/return combination is parsed as a SynExpr.Sequential:
We can tell this because the isTrueSeq boolean flag is true, and this is the only place happens.
Note: this next portion is probably wrong, further digging ongoing
So moving on to typechecking, SynExpr.Sequential is checked in TcExprUndelayed (Typechecker.fs line 6196), and at line 6198 moves to check the linear exprs that are contained inside it. I think this is where we start to go wrong. TcLinearExprs takes a boolean flag isCompExpr, which is always set to false. This use case proves to me that this assertion cannot be true. So I think that we need to check for the existence of CE operations in the Sequential Exprs before checking them linearly. Once we have that boolean flag, I think in TcLinearExprswe need to check that flag in the SynExpr.Sequential pattern and check the CE expressions using TcComputationExpression`.
Am I on a sensible path here? Are there other options that I'm missing?
The text was updated successfully, but these errors were encountered:
/Users/chethusk/oss/scratch/do.fsx(5,1): error FS0030: Value restriction. The value 'it' has been inferred to have generic type
val it : Async<Result<int,'_a>>
Either define 'it' as a simple data term, make it a function with explicit arguments or, if you do not intend for it to be generic, add a type annotation.
I'm a dummy, my test script needs to pin the generic parameters. I can confirm that adding DoBang to that check solves this issue. PR incoming, will similarly need help with adding tests.
Discovered as part of investigating demystifyfp/FsToolkit.ErrorHandling#84
FsToolkit.ErrorHandling recently added preliminary support for the applicative CE members feature of F# 5. After this was released, some constructs that users had no longer compiled.
Repro steps
Run the following script in a preview-enabled dotnet fsi:
dotnet fsi --langversion:preview /path/to/script
Expected behavior
This code should compile.
Actual behavior
The code fails to compile with the following error:
around the entire
do!
blockKnown workarounds
The
do!
expression can be rewritten toand the code will compile. This is semantically the same as do!, but requires user changes.
Related information
Here is a link to the fantomas tools for this snippet. What is immediately jumps out to me is that the do!/return combination is parsed as a
SynExpr.Sequential
:For reference, this is coming from the following parse rule (pars.fsy, line 3231-3232):
We can tell this because the
isTrueSeq
boolean flag istrue
, and this is the only place happens.Note: this next portion is probably wrong, further digging ongoing
So moving on to typechecking,
SynExpr.Sequential
is checked inTcExprUndelayed
(Typechecker.fs line 6196), and at line 6198 moves to check the linear exprs that are contained inside it. I think this is where we start to go wrong.TcLinearExprs
takes a boolean flagisCompExpr
, which is always set tofalse
. This use case proves to me that this assertion cannot be true. So I think that we need to check for the existence of CE operations in the Sequential Exprs before checking them linearly. Once we have that boolean flag, I think inTcLinearExprs
we need to check that flag in the SynExpr.Sequential pattern and check the CE expressions using TcComputationExpression`.Am I on a sensible path here? Are there other options that I'm missing?
The text was updated successfully, but these errors were encountered: