Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support 'without' for Anonymous Records #762

Open
cartermp opened this issue Jul 1, 2019 · 39 comments

Comments

Projects
None yet
10 participants
@cartermp
Copy link
Member

commented Jul 1, 2019

I propose we support expressions of the following:

let a = {| X = 1; Y = 2; Z = 3|}
let a' = {| a without Y |} // {| X = 1; Z = 3 |}

That is, being able to construct a new anonymous record that is a subset of another one.

The existing way of approaching this problem in F# is to manually construct a':

let a = {| X = 1; Y = 2; Z = 3|}
let a' = {| X = a.X; Z = a.Z |} // {| X = 1; Z = 3 |}

Pros and Cons

The advantages of making this adjustment to F# are:

  • Less code involved to create a subset
  • This sort of "drop a row"-style programming would be familiar to those using Python and Pandas for data science-y tasks

The disadvantages of making this adjustment to F# are :

  • Anonymous Records can do even more than normal records, making the "smooth path to nominalization" less of a goal for these types.

Extra information

Here's what the RFC says about this:

Supporting "smooth nominalization" means we need to carefully consider whether features such as these allowed:

  • removing fields from anonymous records { x without A }
  • adding fields to anonymous records { x with A = 1 }
  • unioning anonymous records { include x; include y }

These should be included if and only if they are also implemented for nominal record types. Further, their use makes the cost of nominalization higher, because F# nominal record types do not support the above features - even { x with A=1 } is restricted to create objects of the same type as the original x, and thus multiple nominal types will be needed where this construct is used.

However, Anonymous Records already support {| x with SomethingElse = foo |} to construct a new AR that has more fields than the one it was constructed from. This means that the middle point is already sort of violated, since you cannot reproduce this with record types.

Estimated cost (XS, S, M, L, XL, XXL): S-M

Affidavit (please submit!)

Please tick this by placing a cross in the box:

  • This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
  • I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

  • This is not a breaking change to the F# language design
  • I or my company would be willing to help implement and/or test this
@jwosty

This comment has been minimized.

Copy link
Contributor

commented Jul 1, 2019

Would you be able to chain multiple withouts, as in something akin to this?

{| a without Foo without Bar |}
@cartermp

This comment has been minimized.

Copy link
Member Author

commented Jul 1, 2019

I would expect a semicolon-delimited list of labels, sort of an inverse to what you can do today:

let a = {| X = 1; Y = 2; Z = 3|}
let b = {| a with A = 3; B = 4; C = 12 |}

So it would probably look like:

let _ = {| a without Foo; Bar |}
@jwosty

This comment has been minimized.

Copy link
Contributor

commented Jul 1, 2019

What are your thoughts on allowing combining with and without?

{| a without Foo; Bar
     with Baz = ... |}
@7sharp9

This comment has been minimized.

Copy link
Member

commented Jul 1, 2019

It might be worth noting that in Elm:

Pretty much no one ever used field addition or deletion. In the few cases where people did use it, it got pretty crazy pretty quickly.

@7sharp9

This comment has been minimized.

Copy link
Member

commented Jul 1, 2019

RE: https://elm-lang.org/blog/compilers-as-assistants#simplified-records

The syntax in Elm was actually really nice and intuitive.

@cartermp

This comment has been minimized.

Copy link
Member Author

commented Jul 2, 2019

@jwosty I think combining would probably be out of scope - works for simple stuff, but there'd have to be some rule for determining what subsequent with or withouts applied to - just the base a, or the result of a without ... or a with ...?

@dsyme

This comment has been minimized.

Copy link
Collaborator

commented Jul 2, 2019

I think I'm basically OK with this - it is true that it is no worse than {| x with A = 1 |} and aligned with it.

Note this would make without a reserved keyword. I'm ok with that if under a /langversion switch but we should be aware of it, and it would be the first such new keyword we've introduced via /langversion

@cartermp

This comment has been minimized.

Copy link
Member Author

commented Jul 2, 2019

Just to clarify, for backwards compat, would we still compile something like this?

let without x = ()

without 12
@yatli

This comment has been minimized.

Copy link

commented Jul 2, 2019

to the extreme:

let y = {| x without without |}

without as a keyword would be highly contextual, so I guess it would not interfere with most parts?

@cartermp

This comment has been minimized.

Copy link
Member Author

commented Jul 2, 2019

Correct, I can't think of a way for it to collide unless we explicitly took a breaking change here.

@dsyme

This comment has been minimized.

Copy link
Collaborator

commented Jul 3, 2019

Don't be shy :)

let without = {| with="or"; without="you" |}
let with = {| without without without |}
@Tarmil

This comment has been minimized.

Copy link

commented Jul 3, 2019

I was going to propose with out in 2 words, but then I realized that out isn't actually a keyword in F#, so it's no better than without 😄

More seriously, we don't have contextual keywords yet, do we? This feels like too minor a feature to introduce such a major concept.

@EBrown8534

This comment has been minimized.

Copy link

commented Jul 3, 2019

@cartermp @dsyme Is there any reason we couldn't {| thing not with whatever |}? This would avoid the keyword issue and, quite possibly, make just as much sense.

@yatli

This comment has been minimized.

Copy link

commented Jul 3, 2019

perhaps because not is a function?
If thing is a functor then it's ambiguous.

@dsyme

This comment has been minimized.

Copy link
Collaborator

commented Jul 3, 2019

I guess with- would work, as a new keyword (in the language with is never followed by - today)

{| a with- Foo; Bar
     with Baz = ... |}
@cartermp

This comment has been minimized.

Copy link
Member Author

commented Jul 3, 2019

Would there be an issue with a contexual keyword like this? I don't think it's too crazy. Generally I don't think I'd like with-; we don't really have a precedent for tagging - or + onto letters or words (like Scala or OCaml's co/contravariance)

@7sharp9

This comment has been minimized.

Copy link
Member

commented Jul 3, 2019

I think with- looks confusing, you could end up with it on a pattern match to inverse the matches for consistency.

@dsyme

This comment has been minimized.

Copy link
Collaborator

commented Jul 4, 2019

Would there be an issue with a contexual keyword like this? I don't think it's too crazy. Generally I don't think I'd like with-; we don't really have a precedent for tagging - or + onto letters or words (like Scala or OCaml's co/contravariance)

It feels hard TBH

@cartermp

This comment has been minimized.

Copy link
Member Author

commented Jul 4, 2019

I'm little with- simmer a bit and it doesn't seem too bad.

@cartermp

This comment has been minimized.

Copy link
Member Author

commented Jul 5, 2019

@dsyme

This comment has been minimized.

Copy link
Collaborator

commented Jul 8, 2019

perhaps this would fly, though it's a bit weird too:

{| a with not Foo; not Bar; Baz = ... |}

or

{| a with -Foo; -Bar; Baz = ... |}

or for the unix heads (joke)

{| a with rm Foo; rm Bar; Baz = ... |}
@matthid

This comment has been minimized.

Copy link

commented Jul 8, 2019

Can someone describe why this is needed? What are the applications or existing use-cases / scenarios?

@dsyme

This comment has been minimized.

Copy link
Collaborator

commented Jul 8, 2019

Can someone describe why this is needed? What are the applications or existing use-cases / scenarios?

I think the OP explains why - basically, if you can create a new anonymous with extra fields, it seems reasonable to also support removing a field.

I don't think it's crucial at all, it's just a reasonable completion of the anon record feature within the criteria of the original RFC.

@matthid

This comment has been minimized.

Copy link

commented Jul 8, 2019

Yes I understand what the feature should do. I'm asking because you could also "solve" this another way: Why not allow Anonymous Records at places where fewer fields are required?

let f {| X = x |} = x
f {| X = 1; Y = 2 |} // 1

This obviously needs to solve how we can represent this in IL and also some other corner cases, but it would remove the need to explicitly remove fields.

However, for this to be useful you need to know what the feature use-cases are (which hasn't been answered)

@7sharp9

This comment has been minimized.

Copy link
Member

commented Jul 8, 2019

Im all for more record row polymorphism type features, it is really curious that the feature was almost never used in Elm though.

@cartermp

This comment has been minimized.

Copy link
Member Author

commented Jul 8, 2019

@matthid This was filed as a suggestion after speaking with @Rickasaurus and his team at an F# meetup. The "drop a column" use case is applicable to any scenario where you'd do the same with Pandas/Python. It is also a dual to the "add a column" functionality you can do now with no apparent downside aside from just being another thing you can learn.

Your comment - effectively structural subtyping - was also brought up as highly relevant to that space, but it's explicitly called out as a non-goal here: https://github.com/fsharp/fslang-design/blob/master/FSharp-4.6/FS-1030-anonymous-records.md#design-principle-no-structural-subtyping

So the issues listed in the RFC would have to be resolved for that to progress.

Though the two suggestions are sort of related, but the ability to "drop a column and move on" seems distinct enough from structural subtyping to warrant its own issue.

@dsyme

This comment has been minimized.

Copy link
Collaborator

commented Jul 8, 2019

Though the two suggestions are sort of related, but the ability to "drop a column and move on" seems distinct enough from structural subtyping to warrant its own issue.

Yes, drop-a-column may well get used in places where there is no strongly-typed consumer with the new set of columns made explicit.

@cartermp One criticism of these features might be that these operations have no corresponding things in the type algebra, e.g. given type R = {| X:int |} you can't write {| R with Y:int |} nor {| R with rm X |} (equivalent to {| X:int Y:int |} and {| |} respectively). But I don't think that really matters, just mentioning it for completeness

@matthid

This comment has been minimized.

Copy link

commented Jul 8, 2019

Though the two suggestions are sort of related, but the ability to "drop a column and move on" seems distinct enough from structural subtyping to warrant its own issue.

Not necessarily. One could think of a implementation where structural subtyping is implemented by the compiler initializing a new instance. In this scenario there is no "need" for "remove" as they would be gone for reflection as well. Note that I'm not saying that I like that particular suggestion of mine. Just tried to understand the reasoning behind this original suggestion better. Thanks.

@cartermp

This comment has been minimized.

Copy link
Member Author

commented Jul 8, 2019

@dsyme as I was writing the RFC I was actually wondering if it was worth exploring that kind of type algebra for normal records 🙂. Decided not to write it out.

@matthid

Not necessarily. One could think of a implementation where structural subtyping is implemented by the compiler initializing a new instance. In this scenario there is no "need" for "remove" as they would be gone for reflection as well.

Sure, the compiler could employ whatever tricks it needs, but that doesn't guarantee that the programmer also understands that the compiler is doing this for them. It also requires type annotations wherever you use it to make it clear that you're working with a subset. A "drop a column" approach still ties you to the nominal representation, but it's extremely clear that you've got a subset after constructing one.

@EBrown8534

This comment has been minimized.

Copy link

commented Jul 12, 2019

@matthid FWIW to a newbie like myself, the "drop a column" approach makes the most sense.

In my opinion, there is absolutely no situation where I should accept a {| X : int |} and be able to pass a {| X : int; Y : int |} strictly because the X is no longer the same. In the context of Y it has a new meaning. I should have to do {| thing with -Y |} or {| X = thing.X |}. It means I decided how to do the conversion.

I think the suggestion of structural subtyping falls too close to implicit conversions -- F# doesn't have implicit conversions, and in my eyes these two are one-and-the-same.

@drk-mtr

This comment has been minimized.

Copy link

commented Jul 13, 2019

(Another newbie comment)

Personally I'm not into the with-, however I guess an upside might be that you could move to with+ for additions. That avoids the scenario where someone accidentally adds a field due to a typo. I realise a change of syntax for additions isn't part of this proposal though, so probably a moot point!

@yatli

This comment has been minimized.

Copy link

commented Jul 13, 2019

does x and z have the same type:

let x = {...}
let y = {| x with foo = 1 |}
let z = {| y without foo |}

let _ = (x = z)
@yatli

This comment has been minimized.

Copy link

commented Jul 13, 2019

what is the precedence of:

{| x with foo = 1 without foo |}
@cartermp

This comment has been minimized.

Copy link
Member Author

commented Jul 15, 2019

@yatli Please refer to the RFC here: fsharp/fslang-design#370

@abelbraaksma

This comment has been minimized.

Copy link

commented Jul 15, 2019

@yatli, x and y are the same types, but y has a different value for foo. Variable z is a new type, without the field foo.

@yatli

This comment has been minimized.

Copy link

commented Jul 16, 2019

@cartermp thanks, I think it answers my latter question.
Still I’d like to know, in the “1+1-1” case, does it have the same type as the original.

@abelbraaksma that’s a gotcha, we’ve got different assumptions here—whether the type of x has foo already or not.

@Tarmil

This comment has been minimized.

Copy link

commented Jul 16, 2019

@cartermp thanks, I think it answers my latter question.
Still I’d like to know, in the “1+1-1” case, does it have the same type as the original.

If I'm not mistaken, the identity of an anonymous record is determined by its defining assembly and its field names and types. So given your example:

let x = {...}
let y = {| x with foo = 1 |}
let z = {| y without foo |}
  • if x was defined in another assembly, then all 3 variables have different types.
  • if x was defined in this assembly:
    • if x had a field foo: int, then x and y have the same type.
    • if x had a field foo: SomeOtherType, then all 3 variables have different types.
    • if x didn't have a field foo, then x and z have the same type.
@yatli

This comment has been minimized.

Copy link

commented Jul 16, 2019

thanks @Tarmil, imho this kind of detail should be clarified, and written into the RFC.

I was assuming that every mutated anonymous record will produce a different type, and two mutations have different types even if the type signature appears to be the same:

  • if x didn't have a field foo, x and z have different types.

@cartermp do you expect the behavior as @Tarmil described?

@cartermp

This comment has been minimized.

Copy link
Member Author

commented Jul 16, 2019

@yatli Note that this is already covered in the existing anonymous records RFC. If you feel specific sections need clarification, please comment on the PR - it's easier to address that way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.