Hacker News Reader

Comment by throwawaymaths | Hacker News Reader

If you look at how anonymous functions are compiled at a low level you'll understand why that's not possible: a function is literally "the module it's in" + the bytecode "line number" + arity (so that it knows how many register items to instantiate). For inlined anonymous functions, a secret private function gets created.

View on HN

I consider this to be pretty much an implementation detail though and not necessarily set in stone. The Function data structure is their public interface though and it does define an arity.

Okay, so make the lambda's binding refer to several of those 'structs' and have .( dispatch to the correct one based on the airity at the call site.

That will introduce unnecessary overhead in the basic case. At some level you do want to access the "low level" function (interfacing with Erlang, e.g.) if you really want that sort of dispatch you can write your own polyfunction data type.

So the answer to "why does Elixir require a dot?" is "because of dubious design choices for the innards", rather than any sort of reason that makes sense based on its actual syntax or features.

That's not a dubious design choice. It's actually amazing. How would you design a lambda that can be pickled and rerun across time (run on a different invocation of the vm), or space (sent across a network and executed)?

Well like... the same as it is except allowing multiple arities in the definition.

As other languages that run on existing environments most likely have done. C#, F#, Clojure, TypeScript, Swift, and many others probably had to take similar considerations. Then at a lower level, if you want to maintain ABI compatibility, that may also impose restrictions.

Much of the software we write needs to deal with the constraints of its environments. It would be unfortunate if we decide to give all of them the uncharitable description of being defined by "dubious design choices for the innards" even when known well-defined patterns surface from designing within constraints.

It would be unfortunate if we were unwilling to call design choices dubious and learning from past mistakes instead of rationalizing why they're actually fine. I don't know Elixir but you're telling me in 2023 I'm supposed to learn that a language calls anonymous functions with a different syntax than regular ones and not be annoyed? Like.. that just sucks. If you have to do it that way for unfixable reasons, at least deliver the bad news with an apology instead of a white lie about why it makes perfect sense.

I am completely fine with calling past dubious design choices. This isn't one of them. That was your labeling, provided with no evidence or reasoning, not mine, and that's what I was criticizing.

The Lisp-1 and Lisp-2 discussion is several decades old, with many discussions arguing the benefits of one over the other. The article highlights some of those trade-offs, which should be clear if someone is willing to get past superficial syntax notes.

However, given how intent you are on putting words in my mouth and on distorting contrasting opinions as white lies, let's call it a day.

Ah, I didn't mean to say your take was a white lie. The white lie I referred to was the implicit claim in the article, that it had to be this way, instead of that it's correcting something unfortunate.

This reminds me of when Paul Graham asked a question about Python and someone said they weren't going to do their homework for them.

As a developer who came to Elixir from Clojure I had the same reaction to fun.(), “this sucks”. Then someone explained why. So, okay, there is a good reason but “bleh.” I think that lasted maybe a day, by which time I had accepted it as part of the language. It’s just not a big deal when the language offers so much in return. And I liked Clojure.

Reply on news.ycombinator.com