Hacker News Reader

Comment by choeger | Hacker News Reader

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.

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.

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?

I don't know if you tried reading The Swift Programming Language book ( 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#.

OCaml supports this:

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

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.

I generally dislike this kind of _implicit_ partial application anyways. I prefer Scala-like way of partial application with `_`:

    f(fst = _, snd = y)

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.

I'd bet 4:1 odds that Haskell supports optional arguments with partial application using something like typeclass magic.

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.

Reply on news.ycombinator.com