-
Notifications
You must be signed in to change notification settings - Fork 832
Description
I'm having a lot of confusing issues with type inference when using type aliases with sequences. The behavior and errors reported differ between Visual Studio, .NET Interactive notebooks, and FSI.
Repro steps
-
See the attached
SequentialLogic.ipynbnotebook and note the error ofError: input.fsx (9,5)-(9,9) typecheck error Value restriction. The value 'Not'' has been inferred to have generic type
val Not': (Signal -> Signal)
Either make the arguments to 'Not'' explicit or, if you do not intend for it to be generic, add a type annotation.The error does not make any sense to me because
Signal -> Signalis exactly the intended type ofNot'and is not generic. -
See the attached
SequentialLogicsolution and openSignal.fsin theCPUSimulatorproject in Visual Studio 2022. Note thatNot',And', and so on have no error butXor'reports the errorI suppose this error may make a little sense to me given that
Signalis a type alias ofseq<bit>and thatseqcan have subtypes (such aslistorarray, is that correct?). But what doesn't make sense is thatNot',And', and so on are defined identically but do not report the same error. Nor do they report the same error as the .NET Interactive notebook.Note: I just noticed that if I delete the code after
Xor'in the project, the errors show up for all the<operator>'definitions. This is strange to me. -
Enter the code into
FSI, and you'll get yet another distinct error case forNot'as opposed to the .NET Interactive error and the Visual Studio non-error forNot'.> let Not' = liftToSignal1 Not;; let Not' = liftToSignal1 Not;; ----^^^^ stdin(52,5): error FS0030: Value restriction. The value 'Not'' has been inferred to have generic type val Not': ('_a -> Signal) when '_a :> Signal Either make the arguments to 'Not'' explicit or, if you do not intend for it to be generic, add a type annotation.
Expected behavior
I would say the expected behavior is:
- Consistently reported errors
- Errors that make sense (in the case of the .NET Interactive error)
- Errors that do not adjust when code defined after the problematic code is removed
- I expected the use of the "lift" functions to be straightforward to avoid having to explicitly define parameters and/or provide additional type annotations. Note that the "lift" functions themselves are explicitly typed.
Actual behavior
Several inconsistent errors as described above.
Known workarounds
Either explicitly type all functions and/or provide parameters. For example, if I define Not' in the .NET Interactive notebook as
let Not' input = liftToSignal1 Not inputthe error goes away. This doesn't quite make sense to me given liftToSignal1 is explicitly type annotated, and I don't type annotate input here. Defining Not' as
let Not' : Signal -> Signal = liftToSignal1 Notalso gets rid of the confusing errors.
Related information
Provide any related information (optional):
- Operating system: Windows 11
- .NET Runtime kind (.NET Core, .NET Framework, Mono): .NET 6
- Editing Tools (e.g. Visual Studio Version, Visual Studio): Visual Studio Community 2022, Visual Studio Code with .NET Interactive Notebooks extension, and
dotnet fsi
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
