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
typeAH=| AH
member_.For(x,f)= f x
member_.Yield x = x
[<CustomOperation(MaintainsVariableSpace=true,AllowIntoPattern=true)>]member_.foo(x,[<ProjectionParameter>]y)=letx= y x
x,"A"[<CustomOperation(MaintainsVariableSpace=true, AllowIntoPattern=true)>]member_.select(src,[<ProjectionParameter>]f)= f src
letfoo(x:int)=
AH {for x in x doletn= x
foo (n + x)
select n
}
The above code compiles successfully, but the result is not the value of n, as intuitively expected, but "A". I understand why this is the case, but can we be smarter when parsing the CE?
Because if you don't consider the implementation of CE, it is easy for users to write wrong expressions.
But if the CE implementation considers how to avoid this, there is only one conclusion: do not generate tuples.
Not generating tuples often makes some code impossible to optimize.
The text was updated successfully, but these errors were encountered:
The above code compiles successfully, but the result is not the value of
n
, as intuitively expected, but"A"
. I understand why this is the case, but can we be smarter when parsing the CE?Because if you don't consider the implementation of CE, it is easy for users to write wrong expressions.
But if the CE implementation considers how to avoid this, there is only one conclusion: do not generate tuples.
Not generating tuples often makes some code impossible to optimize.
The text was updated successfully, but these errors were encountered: