Hacker News Reader

Comment by abjKT26nO8 | Hacker News Reader

I much prefer languages which simply do not make a distinction between functions and operators.

This distinction seems useful only in the context of lower-level languages like C where the operators translate directly to single machine code instructions and thus they provide clues about performance.

But in a higher-level language this distinction is superficial. It's just another function, just with a much shorter name and perhaps using infix instead of prefix notation. E.g. in Lisps there is no such distinction. "+" is a valid function name. In Haskell - same, but you also have a built-in syntax for specifying that you want your function to be called using infix notation by default.

View on HN

In principle I agree with this. But as a relative beginner to Haskell operators and their precedence levels are a barrier.

Operators/functions like `+` have well-understood semantics but I don't see how anyone could have an intuition for what `.:` does.

On precedence, I find myself wishing my editor could show me the expression fully parenthesised so I can see if I'm not mentally parsing it correctly.

If we teach operators to children they won't become adults biased against some operators they haven't learned.

See Silhouette's post that is parallel to the parent. These operators don't make sense until you know the underlying concepts. Teaching the whole thing to children seems ambitious enough to probably be unrealistic.

Operators/functions like `+` have well-understood semantics but I don't see how anyone could have an intuition for what `.:` does.

As with many concepts in programming, or any other field that has its own language for that matter, a lot of this comes down to experience.

If you're used to OO-friendly languages like Java or Python, you probably think of the operator (.) as looking up a field or method on an object. If you're used to FP-friendly languages like Haskell, you probably think of (.) as function composition, and it's just as familiar and everyday a sight.

To someone who is new to Haskell or broader functional programming concepts, it might not be immediately clear why ($) is useful if you already have (.), but it's something you soon use as second nature. Before long, you come across concepts like Functor, Applicable and Monad, and with them operators like (<$>), (< * >) and (>>=). The behaviours those operators represent don't even exist outside the context of the underlying abstractions, so someone who isn't familiar with the abstractions won't understand what those operators mean or why they are useful. Again, though, in Haskell these things are routine, everyday tools, just like using (++) to increment a variable in a language like C or JavaScript. That increment operation makes little sense in a functional language where mutability is not the default, and Haskell has no direct equivalent and indeed uses (++) to mean something completely different.

By the same token, to someone who uses (.) all the time for composition of two unary functions, using (.:) for composition of a unary and a binary function is only a small mental jump and makes sense.

None of this is to say you can't take things too far, but it's important to distinguish between using unnecessarily cryptic notations for no good reason (usually a bad idea) and using notations that might appear cryptic to someone who doesn't yet know the concepts but that provide a concise notation for something that is used all the time by someone who does (often a good thing).

How do you deal with namespaces (or anything analogous like package names) there?

E.g. if you have a function named "+", it can likely clash with other functions named "+"

If the programming language supports function overloading that can be resolved through the types

By the way, I actually like RPN calculators, and low level stack based programming languages, where operators and functions also work the same way, but that is mostly interactive or for small self contained programs

This is a problem of the model of polymorphism a language has. It's orthogonal to the function/operator distinction. It doesn't arise based on having this distinction or not.

In Haskell you use typeclasses (you can think of them as Go interfaces or Rust traits) and without them you cannot introduce nameclashes. In Scheme (the Lisp that I know)... you don't have anything. You import things from libraries, define variable bindings and depending on the order of all this your variable is going to be bound to something, most likely a procedure... but which one? Depends on the order. Not great. I prefer the Haskell approach to this, but then Haskell is a bit complicated in other areas. :/

But again, this has little to do with "operators vs functions".

> But again, this has little to do with "operators vs functions".

It has to do with it in the sense that you can add package names or namespaces to function names which are already text, but it looks bad to do this with symbolic infix operators like "+"

It would be nice if everything that operates looks exactly the same, but maybe the field of mathematics could start with fixing their notation then instead: mathematics uses a bit of everything you can imagine:

add, subtract, multiply, division, power, root and log are all binary operators and instead of making them all look the same, mathematicians have chosen to:

* infix symbol for add and subtract

* no symbol at all (usually) for multiply

* superscript for power

* horizontal bar and put things on top of each other for division

* another horizontal bar and a superscript on the left for root

* function-name notation with subscript for log

Maybe this is a global optimum that math has converged to because this mix of different things actually is the easiest way for the human brain to read formulas the fastest, e.g. the arbitrary grouping that division creates and the fact that this eliminates the need for some parenthesis, and the easy visual difference between all the different notations, may really help. In some programming languages, if you've got dozens of parenthesis or deeply nested indentation, can you easily tell which argument is to which function?

Or, it's just a historically grown monster that could as well have turned out entirely different and can have other forms that would be faster to interpret.

A lot of these things were established long before mathematicians started talking about functions, let alone give a robust definition of what a function is. It may have obscured the fact that these things are very similar to each other.

At the point when there was an effort to formalize these things ideas like RPN starting popping up.

Mathematics also deals with a much more flexible medium. It's written on a plane, in 2 dimensions, whereas programmers confine themselves to just one. Mathematicians are also free to make up their own notation and symbols, whereas programmers are confined to a single alphabet and most often can't extend the syntax.

EDIT: Case in point: some mathematicians argued for a while if abs (absolute value) is a function. Some argued that it's not, because you need two formulas to define it. When somebody pointed out that (for real numbers) it's just "sqrt(x^2)", the first ones agreed. Sounds silly in retrospect now that we have a set-theoretic definition, but at the time it wasn't obvious and all these functions looked very different from each other.

> Case in point: some mathematicians argued for a while if abs (absolute value) is a function. Some argued that it's not, because you need two formulas to define it. When somebody pointed out that (for real numbers) it's just "sqrt(x^2)", the first ones agreed.

Isn't that a circular definition, though? sqrt(x²) = ±x, which isn't a function since there are two values in the domain for each value in the range (other than zero). The version they're equating with abs(x) is the absolute value of the square root, or abs(x) = abs(sqrt(x²)), which is true but wouldn't help prove that abs(x) is a function.

Of course, the underlying problem was the premise that a function must be defined by exactly one formula.

When people take the square root of a number during working with real numbers, they almost always mean the non-negative root. It's a convention. Only when they start considering complex numbers, this convention breaks, and the square root ceases to be a function - even according to the modern definition -, because "non-negative" still doesn't narrow it down to a single number in the general case.

Isn't that basically what I said? The convention is that sqrt(x) is generally read as abs(sqrt(x)). The definition is that sqrt(x²) = x, which has positive and negative solutions in x for any x² > 0. You can choose to ignore the negative solutions (or the positive solutions) to make it a function, but I wouldn't consider that any simpler or closer to a single formula than the piecewise-defined version of abs(x). It's an arbitrary restriction—much like the mistaken idea that a function must be defined by exactly one formula.

Why not just say that abs(x) = ±x, ignoring the negative solutions? If you'll accept "the non-negative square root of x²" then I see no reason to reject "the non-negative component of ±x". Both are single formulas with positive and negative solutions combined with a qualifier rejecting the negative solutions.

> The definition is that sqrt(x²) = x, which has positive and negative solutions in x for any x² > 0.

When people write "sqrt", they mean the function, or, "principal square root". "A square root" is a different thing. Saying "the definition" makes sense only within the context where the definition is established, otherwise we have to fallback to the common usage. Wittgenstein would laugh at this conversation.

Also, I'm not arguing for this convention ("it needs to have a single formula to be a function"). And when you start substituting symbols, almost nothing withstands this test. Because then you can always always twist the formula into several cases. And generally thinking about functions as something that is defined by formulas is a very limiting view. Almost all functions cannot be defined by formulas.

In C++, argument-dependent lookup (https://en.cppreference.com/w/cpp/language/adl) lets you specify operators in the same namespace as the type of (any of) their arguments.

It's mostly true that operators are equivalent to functions, but there's an important distinction at parse time too for most languages.

You can have functions named foo, bar, and foobar, but without some sort of convention (usually whitespace or other delimiters) it isn't possible to look at the string foobar and identify whether this is supposed to refer to the single function by that name or to whatever having foo and bar adjacent means in your language (probably composition or application).

Contrast that with operators like +, which serve as delimiters by themselves and can be unambiguously placed next to other function names because they're drawn from a different character set.

Whether that convenience is worthwhile is up for debate, but I think it would be surprising to type a+b and get some kind of parse error that can be rectified just by typing a + b instead.

> Whether that convenience is worthwhile is up for debate, but I think it would be surprising to type a+b and get some kind of parse error that can be rectified just by typing a + b instead.

I kinda prefer that a+b lexes as one identifier: a+b. Also rabbits-are-cute.

Exactly.

a+b should be the same as a.add.b

A high level programming language should be designed for communication instead of dictating the computations.

Reply on news.ycombinator.com