> Functions Are Asymmetric

No, bijective functions are symmetric.

Injectivity is enough to invert a function.

> Even though they may take any number of arguments, they must each have one return value. [...] This is true of all functions.

Mathematical functions take one value and produce one value. This is true of all mathematical functions.

Programming functions can be modelled this way by treating multiple input arguments as a single product, and non-scalar outputs containing multiple values as a single product.

Programming functions don't even have to always return one value:

  - Haskell's Void type
  - Rust's ! type
  - TypeScript's never type

Arguably, programming functions must take at least one value as input, otherwise how can they be called?

In that sense, programming functions are asymmetric: It rarely makes sense to write a function you can't call, but it often makes sense to write a function that never returns.

When does it make sense to write a function that you can't call? When the point of the function is to prove something as a result of being compiled. The value lies in the compilation, not in being called.

A better title for this article: Some Functions Are Asymmetric.

Which is less of a profound insight.

Functions map members of a set A to members of a set B. These can simply be Cartesian products whose members are tuples. In my dream PL syntax a function call would be a function name followed by a tuple, and that tuple would be no different than the tuples you would use in any other part of the program (and so you could use all the tuple manipulation library goodies). If the function preserves any other structure of the type, like an identity element, that could be stated so you could have morphisms. And that identity element or other properties could be declared just as other stuff like 'const' are declared, and since the compiler can't verify all these stated properties, it's on the user to provide correct info, just like it's on the user to write a correct program, so nothing lost here, and anything more, like verification by the compiler, would be a bonus.

Mathematicians have been packing all this stuff nicely for a couple of centuries now, maybe we could use more of their work on mainstream computing, and it could also be a nice opportunity to get more people to appreciate math and structure.

Something that has side effects all over the place should just not be called a function, but something else, maybe "procedure" would be an appropriate, clear term.

> Maybe that doesn’t seem strange. It’s just how we’re used to functions working. Ah, those steeped in functional programming might say, but maybe this is the wrong way to look at it. Because if we curry functions and use partial application, we can say that they always have one argument and return one value, and then they are symmetric.

Ah, those steeped in functional programming might say, but maybe this is the wrong way to look at it. Because if we represent the represent the functions with explicit continuations, we can say that they have N arguments and pass N arguments to their continuations, and then they are symmetric.

It seems like this has fertile overlap with Scheme and the (concurrent computatation) Actor model.

Of course, I can imagine the Execution control library authors know full well about those, with existing C++ goals and designs making that a bridge too far.

Functions can accept/return multiple values though?

// In typescript const [a, b, c] = foo(d, e, f)

You could even pass this to itself

foo(…foo(d, e, f))

Also one definition of a function is a map from a domain to a range. There’s nothing that forbids multiple values, or is there?

> One shall be the number, and the number shall be one.

Monty Python fan detected :D

Sorry if this is low effort, but I wanted to show some appreciation for a subtle Monty Python reference here! I won't spoil it though...