[RFC FS-1092 Discussion] - Anonymous type-tagged unions discussion #519
Replies: 20 comments 62 replies
-
Benefits of the feature threadSomething that is not elaborated on much is the benefit of erased/ad-hoc unions over discriminated unions. Using anonymous records as an example, here are some benefits over named records
Is there a list like this can be drafted for Erased Union types? |
Beta Was this translation helpful? Give feedback.
-
First, this could only be supported if the erased type is always "obj", since the erased type must be stable under instantiation of generic parameters. Second, I need to think further about whether this extensibility can be supported. Note you can of course always user a tag for type UserMessage<'T> = UserMessage of 'T
type SystemProtocol =
| TimeoutMessage of ...
| RestartMessage of ...
member ActorContext.Receive<'UserMessage> : unit -> IO<(SystemProtocol | UserMessage<'UserMessage>)> |
Beta Was this translation helpful? Give feedback.
-
|
Adding onto what @Horusiath said, the biggest benefit for me is drastically reducing the surface area of library code that has a need for many overloads (in my case wrapping JS libraries via Fable). I recently committed ~1300 lines of code to one of my libraries... the reason for this was because a part of an API added support for Here's a quick way to visualize: // For those not familiar with Fable, U5 is just a generic 5 case DU with Case1 of 'T, Case2 of 'U etc.
type Matcher = U5<string, Regex, int, float, string * HTMLElement -> bool>
type QueriesForElement =
abstract getByLabelText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element
abstract getAllByLabelText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract queryByLabelText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element option
abstract queryAllByLabelText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract findByLabelText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<'Element>
abstract findAllByLabelText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<ResizeArray<'Element>>
abstract getByPlaceholderText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element
abstract getAllByPlaceholderText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract queryByPlaceholderText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element option
abstract queryAllByPlaceholderText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract findByPlaceholderText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<'Element>
abstract findAllByPlaceholderText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<ResizeArray<'Element>>
abstract getByText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element
abstract getAllByText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract queryByText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element option
abstract queryAllByText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract findByText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<'Element>
abstract findAllByText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<ResizeArray<'Element>>
abstract getByAltText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element
abstract getAllByAltText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract queryByAltText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element option
abstract queryAllByAltText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract findByAltText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<'Element>
abstract findAllByAltText<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<ResizeArray<'Element>>
abstract getByTitle<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element
abstract getAllByTitle<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract queryByTitle<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element option
abstract queryAllByTitle<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract findByTitle<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<'Element>
abstract findAllByTitle<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<ResizeArray<'Element>>
abstract getByDisplayValue<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element
abstract getAllByDisplayValue<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract queryByDisplayValue<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element option
abstract queryAllByDisplayValue<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract findByDisplayValue<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<'Element>
abstract findAllByDisplayValue<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<ResizeArray<'Element>>
abstract getByRole<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element
abstract getAllByRole<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract queryByRole<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element option
abstract queryAllByRole<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract findByRole<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<'Element>
abstract findAllByRole<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<ResizeArray<'Element>>
abstract getByTestId<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element
abstract getAllByTestId<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract queryByTestId<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> 'Element option
abstract queryAllByTestId<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> ResizeArray<'Element>
abstract findByTestId<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<'Element>
abstract findAllByTestId<'Element when 'Element :> HTMLElement> : matcher:Matcher * ?options: obj -> JS.Promise<ResizeArray<'Element>>The methods of this interface all accept a |
Beta Was this translation helpful? Give feedback.
-
|
@Shmew how is this a better solution than having a Also is it better than |
Beta Was this translation helpful? Give feedback.
-
Yes, having the user do
From what I understand, |
Beta Was this translation helpful? Give feedback.
-
|
It's great to look at concerte examples like this and assess the tradeoffs between op_Implicit, unions and call-site tagging. Thanks for doing this. |
Beta Was this translation helpful? Give feedback.
-
Interop threadThere are some questions raised by some folks about interop. How will C# "see" erased unions? How does this differ, if at all, from how it "sees" Discriminated Unions? |
Beta Was this translation helpful? Give feedback.
-
|
My original thought was C# would just see the compiled representation. I agree that union type like We could potentially also add optional attribute to enforce the compiled representation type which results in more predictable behaviour for C# consumers, in situations where it is desired. Assuming we can have attributes on aliases. |
Beta Was this translation helpful? Give feedback.
-
Component design threadWhat kind of component design considerations do we envision with this feature? One of the things listed in the RFC is being able to effectively get function overloading. That's obviously great when you public surface area is F# functions. But this raised some questions. Consider the following: type C() =
static member M(x: (int | string)): (double | int) = ...
static member M(x: (double| string)): (double | int) = ...
static member M(x: (int | string)): (int | double) = ...
static member M(x: (int | string)): (double | string) = ...From an orthogonality standpoint, code like this seems like it should be valid. What kind of components and patterns would benefit from this kind of code? What kind of guidance should generally be issued? |
Beta Was this translation helpful? Give feedback.
-
|
I don’t think if this overloading should be allowed. static member M(x: (int | string)): (double | int) =
static member M(x: (double| string)): (double | int) = ...The common upper bound type for x in both statements is basically object, same for the return type. Or Maybe I am missing something on code generation. Does IL allow writing function the same signature or it is totally up to the language to decide which version to invoke? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, this is not allowed, per the standard rules of method signatures needing to be unique w.r.t. erasure |
Beta Was this translation helpful? Give feedback.
-
Supporting (string) literalsThe original lang suggestion was motivated for Typescript interaction with Fable. In Typescript, it's very common that erased unions accept literals, mainly strings. The feature would be much more helpful for Fable (and I assume also for other F# to JS/Python/... transpiling tools) if F# also supported this. It should be helpful for standard F# as well. let doSomething (mode: ("auto" | "default" | (* flags *) {| a: int; b: bool |})) = ()
// Named literals could work too as in pattern matching but maybe they're confusing?
let [<Literal>] Auto = "auto"
let [<Literal>] Default= "default"
let doSomething2 (mode: (Auto | Default)) = ()This can also be a much better replacement for type RequestMode = ("same-origin | "no-cors" | "cors") |
Beta Was this translation helpful? Give feedback.
-
|
The example by @alfonsogarciacaro would require also work to support singleton types/literal in types. let doSomething (mode: ("auto" | "default" | (* flags *) {| a: int; b: bool |})) = The compile would help you enforce the match cases: match mode with
| :? "auto" -> ...
| :? {| a: int; b: bool |} as o -> ...
// warning incomplete match, "default" was not handled.or match mode with
| :? "1px" -> ...
| :? "auto" -> ...
| :? "default" -> ...
| :? {| a: int; b: bool |} as o -> ...
// error "1px" is not a subtype of ("auto" | "default" | (* flags *) {| a: int; b: bool |}From the caller side, there is no way you can pass other string literals: doSomething("10px")
// error "10px" is not a suitable value of type ("auto" | "default" | (* flags *) {| a: int; b: bool |}This is all checked at compile time, whilst still giving a efficient IL code, as the common LUB for |
Beta Was this translation helpful? Give feedback.
-
I totally understand that - that's why I wondered about the string literals as possible distinct cases and how that would work because from looking at the type only there is no distinction. EDIT: the comment you added nicely clarified that 👍 so calling is also only possible using literals.
In our app we delegate writing data to a storage engine that takes events from all application contexts and deals with them. In our case the functions that deal with a subset of messages just take in a DU that in our case is already how the storage messages are structured. We don't want to deal with a non structured list of 100s of events, so grouping them into subgroups with DU's is natural in that case. I'm sure there are cases where the erased unions are the best solution and the downsides are acceptable - but they seem to be rare. |
Beta Was this translation helpful? Give feedback.
-
|
@JaggerJo
Now take that example, and imagine, some subsets of messages have a common interface. type ITimeStamped =
abstract Timestamp: unit -> 'aWith your example, you'd have to implement the interface for each subset DU grouping. type StorageMsg =
| ContextA of ContextAStorageMsg
| ContextB of ContextBStorageMsg
| ContextB of ContextCStorageMsg
interface ITimeStamped with
member x.Timestamp =
match x with
| ContextA a -> a.Timestamp
| ContextB b -> b.Timestamp
| ContextC c -> c.Timestampvs It just exists already if you use union types, since the common LUB is the common interface among the types. let subset: (ContextAStorageMsg | ContextBStorageMsg | ContextCStorageMsg) = ...
subset.Timestamp |
Beta Was this translation helpful? Give feedback.
-
|
What is the benefit of putting quotation marks around things? If we allowed |
Beta Was this translation helpful? Give feedback.
-
|
@charlesroddie this isn't what's being suggested if I'm understanding you correctly. The use case for allowing string literals is mostly a quality of life benefit as opposed to better typing. Although, you do gain the ability to provide more information when a function returns specific string literals. In the context @alfonsogarciacaro is talking about where he would find it useful is when something can only be certain values, but are strings. So what's currently done is a DU is used and transpiled as just strings. The benefits here is that you don't need to write plumbing to convert strings to the DU and vice versa. An example outside the context of Fable where this would be handy is (de)serialization. Like if we had a JSON schema with this field definition: {
"type": "string",
"pattern": "^one$|^two$|^three$"
}We would currently would need to define it something like this: type SomeJSONField =
| One
| Two
| Three
// This return value is string, when we know it will always be ("one" | "two" | "three")
member this.Text : string =
match this with
| One -> "one"
| Two -> "two"
| Three -> "three"
// Have to return a result because we can't constrain our input
//
// not relevant to the context of (de)serialization assuming
// we're not handling it ourselves, but demonstrates a use-case
static member FromString (value: string) : Result<SomeJSONField,string> =
match value with
| "one" -> Ok One
| "two" -> Ok Two
| "three" -> Ok Three
| _ -> Error "Invalid JSON Field value"
type SomeJSON = { Field: SomeJSONField }This makes it a pain to handle going from one representation to the other:
With this feature all of that can be removed: type SomeJSON = { Field: ("one" | "two" | "three") } |
Beta Was this translation helpful? Give feedback.
-
Syntax thread
Since this is erased to an object, I suppose we can add a keyword to signal erasing, like as suggested in fsharp/fslang-suggestions#712. So we will have |
Beta Was this translation helpful? Give feedback.
-
|
I agree. Most of the code samples in the RFC scream "use a DU instead". It should be made clear that this is not something to use instead but something that fixes a very certain problem. It should also be made clear that it comes with a cost of type safety, interoperability and performance. |
Beta Was this translation helpful? Give feedback.
-
|
All extremely important points. 2. is clarified here: #591 |
Beta Was this translation helpful? Give feedback.
-
Will erased unions impact the possibility of getting actual anonymous unions or polymorphic variants ? |
Beta Was this translation helpful? Give feedback.
-
|
I don't see how this would obstruct adding polymorphic variants, other than now having 3 categories of union types. You could potentially have these side by side working with each other. let three = `Int 3;;
val three : [> `Int of int ] = `Int 3
let four = `Float 4.;;
val four : [> `Float of float ] = `Float 4.
let _: (`Int of int | `Float of float | string) = [three; four; "something else"];;Doesn't necessarily have to be one or the other, although I haven't had a need for anonymous DU. In such cases, I've always used DU. |
Beta Was this translation helpful? Give feedback.
-
|
When reading the RFC part of it seems like its surfacing something like the internal only https://github.com/dotnet/fsharp/blob/main/src/fsharp/FSharp.Core/prim-types.fs#L1172-L1187 Why cant that internal type test be made public as this would allow generics to be treated efficiently in a pattern match, currently its for internal use but would be just as useful as this aspect in erased unions and the code is already there. |
Beta Was this translation helpful? Give feedback.
-
|
If I understand this feature correctly and if it gets implemented, I think it should be called Anonymous Union Types instead of Erased Union Types, because it appears to work like declaring an unnamed union inline which is exactly what anonymous records do. Edit: I guess @JaggerJo beat me to the punch |
Beta Was this translation helpful? Give feedback.
-
|
@lfr They are not exactly anonymous in the sense that anonymous DU which @JaggerJo is referring has a discriminator whereas this is tagged by the type itself. See also #519 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
THe RFC now uses the name "anonymous type-tagged union types" |
Beta Was this translation helpful? Give feedback.
-
For that type of situation why not this? let temp : (int<c> | int<f>) = 10<c>@dsyme would this type of code with UoM be valid? I see in the RFC this:
|
Beta Was this translation helpful? Give feedback.
-
|
@JaggerJo but you could much more easily combine single case DUs together e.g. type Celcius = Celcius of float
type Farenheit = Farenheit of float
type Kelvin = Kelvin of float
let justCelOrFar (x:Celcius|Farenheit) = ... |
Beta Was this translation helpful? Give feedback.
-
|
If these "tagged patterns" could be aliased, that would also be excellent: type CelOrFar = Celcius|Farenheit
type AllOfThem = Celcius|Farenheit|Kelvin
let foo (x:CelOrFar) = ... |
Beta Was this translation helpful? Give feedback.
-
|
With inherited types is the order of types in a match important? Say you have 4 different subtypes inheriting and want to pattern match: type A() = class end
type B() = inherit A()
type C() = inherit B()
type D() = inherit C()
let test (x:A|B|C|D) =
match test with
| :? A as a -> printfn "%A" a
| :? B as b -> printfn "%A" b
| :? C as c -> printfn "%A" c
| :? D as d -> printfn "%A" d
test (D())Looking at this code if it were a common occurrence to pattern match I could see that creating some syntactic sugar to optimise a little would be better, so they can be dealt with as normal DU's unwrapping: |
Beta Was this translation helpful? Give feedback.
-
Yes, we could improve the match case behaviour such that it will give warnings, if unreachable match statement is given. Just hasn't been prototyped yet, but don't see it being impossible. You are correct that |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@dsyme
Would this still be allowed? > let size: (int|string) = "default";;
val size : (int | string) = "default"
> let sizef: (float|string) = 1.0;;
val sizef : (float | string) = 1.0
> let s: (int|float|string) = if true then size else sizef;;
val s : (int | float | string) = "default" |
Beta Was this translation helpful? Give feedback.
-
|
Scala 3 does allow for things like http://dotty.epfl.ch/docs/reference/new-types/match-types.html |
Beta Was this translation helpful? Give feedback.
-
Yes |
Beta Was this translation helpful? Give feedback.
-
|
I'm about to read through the discussion, but just to mention I've taken a pass over the RFC and it is now here: https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1092-anonymous-type-tagged-unions.md The revised RFC uses different motivating examples and includes very specific and extensive guidance on when it is reasonable to use these types. The RFC now also uses the name "anonymous type-tagged unions" - it's a bit clumsy but specific |
Beta Was this translation helpful? Give feedback.
-
How does interop between F# Projects look like? |
Beta Was this translation helpful? Give feedback.
-
|
Ah, so you added the code to do it but it not yet available for testing? |
Beta Was this translation helpful? Give feedback.
-
|
I can't speak for certain, as I am wildly unfamiliar with the IDE side of things. But you should be able to clone and test locally if you want to try it out. It requires the lang version to be set to preview though.
|
Beta Was this translation helpful? Give feedback.
-
|
You also need to specify the compiler location too I think, I forget now :-) |
Beta Was this translation helpful? Give feedback.
-
|
On windows: |
Beta Was this translation helpful? Give feedback.
-
|
This is where a tryFsharp website would come in handy with new prototypes. |
Beta Was this translation helpful? Give feedback.
-
I feel that type information for RHS is known, what we don't know is the "must-convert-to" until we involve That said, I understand the example given. |
Beta Was this translation helpful? Give feedback.
-
Pattern MatchingOne question I have, on which myself am unsure about is how should pattern work? Should it be a type test or instead something else. Using type-test the following case would have to be specially handled. let handleSize (size: (int|int8|double|string)) =
match size with
| :? (int|int8) -> printfn "Got Integer"
| :? (double|string) -> printfn "Got Double or Float)"The current draft changes as it stands now, for There are few options I can think of.
let handlesize2 (size: (int|int8|double|string)) =
match size with
| :? int
| :? int8 -> printfn "got integer"
| :? double
| :? string -> printfn "got double or string"
let handlesize3 (size: (int|int8|double|string)) =
match size with
| (int|int8) i -> printfn "got integer"
| double d -> printfn "got double"
| string s -> printfn "got string" |
Beta Was this translation helpful? Give feedback.
-
I believe this is my preferred approach, at least in a first approximation.
I don't think this is correct - for me the only logical interpretation of |
Beta Was this translation helpful? Give feedback.
-
|
Going through the source, trying to see if I can tackle this, wondering when should this rewrite happen at (PatternMatchingCompilation.fs) or likely after/during Optimizer phase. |
Beta Was this translation helpful? Give feedback.
-
I believe it should be a modification to the pattern match compiler. (I think it may not be a simple change - ir if it's a simple change it may take a while to determine what it is - so I'm kind of expecting to have to help you with this) |
Beta Was this translation helpful? Give feedback.
-
Sure, some overview of how pattern matching compilation works would give me some pointers. I think its probably within |
Beta Was this translation helpful? Give feedback.
-
Working with ListsWould we be able to do something like this: let items:(int|string) list = [ 1; "test"; 3 ]This would be very useful as a way of allowing lightweight unions of lists without the need to create lots of custom discriminated unions; this gets more problematic if you want to have e.g. one list that accepts ints or strings and another that accepts ints or floats or strings, but if the above was allowed, this would be a succinct way of solving this. In Farmer I come up against this very frequently, especially within the context of computation expression keywords. One of the design goals of Farmer, from the consumer point of view, is to limit exposure to things like DUs, or at least keep them as simple as possible; the above feature would be a great way to maintain type safety whilst keeping an API lightweight and generally "out of the way". |
Beta Was this translation helpful? Give feedback.
-
|
@Swoorup Actually, no, this won't work. In .NET a boxed > Unchecked.compare (box 3) (box "3");;
System.ArgumentException: Object must be of type Int32.
at System.Int32.CompareTo(Object value)
at <StartupCode$FSI_0002>.$FSI_0002.main@()
Stopped due to errorSo these types will not support the comparison or equality constraints. Effectively |
Beta Was this translation helpful? Give feedback.
-
|
@dsyme I assume this would apply for any constraints that might be required on a container type etc.? |
Beta Was this translation helpful? Give feedback.
-
Most .NET containers are unconstrained and allow the IEqualityComparer interface to be implemented explicitly and passed as a parameter to the constructor. So you will be able to sue those. |
Beta Was this translation helpful? Give feedback.
-
|
@dsyme // this compiles in the type-directed cast branch but gives runtime error.
let s: IComparable Set = Set.ofList [1;2;3;4;"test"];; |
Beta Was this translation helpful? Give feedback.
-
|
The F# comparison logic is built on the non-generic IComparable and Equals(). However these raise exceptions when used on values of different runtime types, as the example above shows. |
Beta Was this translation helpful? Give feedback.
-
Accessing common membersWould we be able to write: let count (x:(System.Collections.IDictionary|System.Collections.Generic.IDictionary<_, _>)) = x.Count |
Beta Was this translation helpful? Give feedback.
-
|
No. You would have to pattern match. let count (x:(System.Collections.IDictionary|System.Collections.Generic.IDictionary<string,string>)) =
match x with
| :? System.Collections.IDictionary as d -> d.Count
| :? System.Collections.Generic.IDictionary<string,string> as d -> d.Countor I'd imagine we will support this (if it's not working already: let count (x:(System.Collections.IDictionary|System.Collections.Generic.IDictionary<string,string>)) =
(x :> System.Collections.ICollection).Countsince all collections support that. Though of course in this case you could write this in the first place: let count (x: System.Collections.ICollection) = x.Count |
Beta Was this translation helpful? Give feedback.
-
|
@Happypig375 While theoretically possible, a seperate suggestion might be needed for that, including being able to access interface members from concrete type without the need for casting, since the type-directed RFC doesn't cover it. |
Beta Was this translation helpful? Give feedback.
-
|
I think this feature will help with a whole raft of issues that are either currently solved today with cumbersome Named DUs or by raising runtime errors and being careful to avoid them. I personally hit these issues when working on wrapping Deep Learning Libraries and when building a distributed actor system. On reading the proposal and discussion I thought I'd add my 2c. Specifically I have some concrete use cases in mind that may need some consideration.
let gemm(A:'a,B:'a when 'a : Matrix<2,'T>,alpha : 'T,beta : 'T when 'T : int | half | float | float32) : Matrix<2,'T> =
when 'T : int = GemmI(A,B,alpha,beta)
when 'T : half = GemmH(A,B,alpha,beta)
when 'T : float32 = GemmF(A,B,alpha,beta)
when 'T : float = GemmD(A,B,alpha,beta)
// Perhaps non-matched cases would be prevented from being entered at the call site;
// for example instead of warning that the match statement is not exhaustive perhaps the
// non-matched combinations could cause a type error at the call site.
let gemm(A:Matrix<2,'T>,B:Matrix<2,'T>,alpha:'T, beta:'T when 'T : int | half | float | float32) : Matrix<2,'T> =
match A,B,alpha,beta with
| :? int | :? int | :? int | :? int -> GemmI(A,B,alpha,beta)
| :? half | :? half | :? half | :? half -> GemmH(A,B,alpha,beta)
| :? float32 | :? float32 | :? float32 | :? float32 -> GemmF(A,B,alpha,beta)
| :? float | :? float | :? float | :? float -> GemmD(A,B,alpha,beta)
/// 'T, 'U and 'V would be restricted based on their usage in the later functions.
/// In this case 'U = 'V = (float32 | float) where as T = (half | float32 | float)
let squeezeAndExcite(X:Matrix<4,'T>, weights1:Matrix<3,'U>, weights2:Matrix<2,'V>) =
conv2D(X,weights1) * matmul(weights1,weights2)
type ThinningAlgorithms = | Rosenfelt = 1 | Stentiford = 2 | ZhangSuen = 3
/// This example only works on grayscale (1 channel) of uint8 and float32, and
/// while other functions support all the thinning algorithms this one only supports ZhangSuen and Steniford.
let thin(X: Img<1, uint8 | float32>, ?algo : ZhangSuen | Steniford) = ( . . . )
let foo(x:int | float,y:int | float) : (int | float) =
require(equals(typeof(x),typeof(y))) // Analyzer restriction
match x, y with
| :? int, ? int -> x + y
| :? float, ? float -> x + y
| _,_ -> failwith "Mixed types are unsupported" // The analyzer would prevent this from being executed. |
Beta Was this translation helpful? Give feedback.
-
|
Will this feature support returning values? Sorry if I missed it. For example: let doSomeFileWork xxx : Result<SomeWork, (FileNotFoundEx | DiskOutOfSpaceEx | InvalidAccessRightsEx )> = ...This way we could bring ourselves little bit closer to checked exceptions and make exceptions part of functions signature. With upcoming analyzer support throwing in such functions could be a warning candidate. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it supports returning union, given that on the consumption side you have F# codebase |
Beta Was this translation helpful? Give feedback.
-
|
Nice. I assume the idea is to infer the common "exn" type in this case, not obj? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, but as developer I don't think you'd normally be concerned about the underlying compiled representation. |
Beta Was this translation helpful? Give feedback.
-
|
I think we should be able to eliminate parenthesis, when this is used directly in functions? Thoughts @dsyme ? let foo(x: (int | float), y: (int | float)) : (int | float) = vs let foo(x: int | float, y: int | float) : int | float = Less noise, imo |
Beta Was this translation helpful? Give feedback.
-
|
I think that's not possible technically, there are conflicts in the type grammar due to |
Beta Was this translation helpful? Give feedback.
-
|
Performance question, is the plan for the compiled output to include the If the compiled output is going to include the type matching logic of the |
Beta Was this translation helpful? Give feedback.
-
|
i think this potentially would be great for also Fable world and TS translation? or at least for usage from TS users i think this would be a great plus as they already "know" this format for definying unions anonymously, + they would undertand this easilly in signtures too. but just a profane consideration |
Beta Was this translation helpful? Give feedback.
-
Discussion thread for https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1092-anonymous-type-tagged-unions.md
Beta Was this translation helpful? Give feedback.
All reactions