4 ms·

Unfortunately, named arguments lead to arbitrary-order arguments which then make partial application quite awkward. Think: f(fst:x, snd:y), what is the type of

Unfortunately, named arguments lead to arbitrary-order arguments which then make partial application quite awkward. Think: f(fst:x, snd:y), what is the type of f(snd:4)? I think this can be implemented, but then f(3, fst:5) is either an error or counter-intuitive.

skohan 6y ago
Swift's approach to this is pretty good. Arguments have a fixed order, and whether or not they are named at the call-site is explicitly decided by the author of the function signature. In practice the order and identity of the arguments is quite clear in Swift.
- codetrotter 6y ago
  As someone who kind of jumped into Swift coming from other languages, I still find this kind of stuff confusing. Is there a good intro to Swift that goes through only what is unique/peculiar about Swift and explains that in a good way to someone that already knows how to program?
  - bluk 6y ago
    I don't know if you tried reading The Swift Programming Language book ( https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html https://docs.swift.org/swift-book/LanguageGuide/TheBasics.ht... ). It's a fairly quick read and has brief explanations with simple examples. You can skip some sections if you have prior programming experience, but if you're confused about Swift's function arguments, you may want to skim even the basics since a few things like control flow (e.g. the switch statement) are unique compared to C/C++/Java/C#.
tomp 6y ago
I generally dislike this kind of _implicit_ partial application anyways. I prefer Scala-like way of partial application with `_`: f(fst = _, snd = y)
andrenth 6y ago
OCaml supports this: # let f ~fst ~snd = fst + snd;; val f : fst:int -> snd:int -> int = <fun> # f ~snd:4;; - : fst:int -> int = <fun>
Spivak 6y ago
I don’t think named arguments are as much a problem as function overloading and optional parameters for this. Without overloading you could define the answer as g(x) { f(fst:x, snd:y) } always which would make partial application somewhat ergonomic but makes allowing fst without snd horribly ugly when you have to pass in some spiritual null or _ to. I think these ideas are fundamentally opposed and so I don’t think there’s a good way to have a nice syntax for both.
marcosdumay 6y ago
Yes, this can be implemented. And languages can trust the developers to not write stuff like f(3, fst:5). This is not a large scale pattern where people need help to refactor. The one largest obstacle for partial application (at least of the Haskell style) is optional arguments. You just can not have both.
- sukilot 6y ago
  I'd bet 4:1 odds that Haskell supports optional arguments with partial application using something like typeclass magic.
  - marcosdumay 6y ago
    If you want optional arguments and partial application, you need some way to declare that the optional arguments are left blank. Haskell-style syntax has no such way. But yeah, functors are all about building stuff like that. So there are similar things, just with a different syntax.
deleted 6y ago
[deleted]

skohan 6y ago

Swift's approach to this is pretty good. Arguments have a fixed order, and whether or not they are named at the call-site is explicitly decided by the author of the function signature. In practice the order and identity of the arguments is quite clear in Swift.

codetrotter 6y ago
As someone who kind of jumped into Swift coming from other languages, I still find this kind of stuff confusing. Is there a good intro to Swift that goes through only what is unique/peculiar about Swift and explains that in a good way to someone that already knows how to program?
- bluk 6y ago
  I don't know if you tried reading The Swift Programming Language book ( https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html https://docs.swift.org/swift-book/LanguageGuide/TheBasics.ht... ). It's a fairly quick read and has brief explanations with simple examples. You can skip some sections if you have prior programming experience, but if you're confused about Swift's function arguments, you may want to skim even the basics since a few things like control flow (e.g. the switch statement) are unique compared to C/C++/Java/C#.

tomp 6y ago

I generally dislike this kind of _implicit_ partial application anyways. I prefer Scala-like way of partial application with `_`: f(fst = _, snd = y)

andrenth 6y ago

OCaml supports this: # let f ~fst ~snd = fst + snd;; val f : fst:int -> snd:int -> int = <fun> # f ~snd:4;; - : fst:int -> int = <fun>

Spivak 6y ago

I don’t think named arguments are as much a problem as function overloading and optional parameters for this. Without overloading you could define the answer as g(x) { f(fst:x, snd:y) } always which would make partial application somewhat ergonomic but makes allowing fst without snd horribly ugly when you have to pass in some spiritual null or _ to. I think these ideas are fundamentally opposed and so I don’t think there’s a good way to have a nice syntax for both.

marcosdumay 6y ago

Yes, this can be implemented. And languages can trust the developers to not write stuff like f(3, fst:5). This is not a large scale pattern where people need help to refactor. The one largest obstacle for partial application (at least of the Haskell style) is optional arguments. You just can not have both.

sukilot 6y ago
I'd bet 4:1 odds that Haskell supports optional arguments with partial application using something like typeclass magic.
- marcosdumay 6y ago
  If you want optional arguments and partial application, you need some way to declare that the optional arguments are left blank. Haskell-style syntax has no such way. But yeah, functors are all about building stuff like that. So there are similar things, just with a different syntax.

deleted 6y ago

[deleted]