Comment by colonwqbang | Hacker News Reader

Comment by colonwqbang | Hacker News Reader

It seems like different issues are being conflated here. Should function arity overloading be permitted, and when? Should we require a specific syntax for calling locally defined "anonymous" functions, for whatever reason? I don't see what these two things have to do with each other.

(Haskell doesn't support function arity overloading, despite what the article suggests. Haskell also doesn't use a special syntax for calling local functions)

Other questions to ask: If we do permit overloading for toplevel functions why not do it also for local functions? If we think a special syntax is needed to use local variables of function type, why not use the same syntax for local variables of all types? E.g. $localvar, $localfunc() vs globalvar, globalfunc().

It doesn't feel fully thought-out.

My goal was to say that Haskell has a single namespace, not that it supports arity overloading, but your interpretation is valid as the text is currently phrased. I will address that (edit: now fixed). However, I don't believe it says Haskell has a special syntax for local calls.

The arity overloading is related (albeit not required!) because it adds to the expressive power of Lisp 1. As the examples show, you need a single function for defining the initial accumulator and the reduction operation, instead of passing two arguments or a composite type (see this example from Clojure [1]). By allowing a single function to encode more information via multiple arities, you also only need to override a single name (which must adhere to all arities). It is also an important characteristic of Elixir, so the article would be lacking if it was not included in the discussion.

[1]: https://clojure.org/reference/reducers#_using_reducers

> If we think a special syntax is needed to use local variables of function type, why not use the same syntax for local variables of all types? E.g. $localvar, $localfunc() vs globalvar, globalfunc().

Elixir doesn't have global variables, so trying to unify from that angle would not necessarily help (it would only make local variables of all types more verbose).

Reply on news.ycombinator.com