# Why do some functions require its arguments to be in a list while others accept these as a sequence? [closed]

With Midpoint[{{4, -2}, {2, 5}}], the vectors must be in a list.

But with EuclideanDistance[{-2, 2}, {3, -6}], they don't.

These seem very similar. It would be nice if there was a consistent pattern so there would be less memorization. Or is there some obscure reason?

• These types of language-designs questions are usually routinely closed but I wonder if a policy change might be in order? Firstly the stated reasons seem pretty suspect ("requires either advice from Wolfram support or the services of a professional consultant"). There is surely some objective, capturable and useful reason why functions are the way they are without necessarily needing to delve into a WRI mind. Moreover, such understanding is useful for learning and understanding ... Nov 12, 2022 at 9:45
• ... the language and especially for designing your own functions in a "compatible" way which perhaps now has greater relevance with the possible emergence of a package ecosystem. Also the closures seem to be a bit inconsistent with several other ... Nov 12, 2022 at 10:07
• ... questions being profitably accepted none of which descended into long-winded debates but left useful pointers IMO (as befitting a site that has "language-design" as an official tag). Nov 12, 2022 at 10:07

I think your observed pattern is very logical and has to do with expected number of arguments. Compare:

• Midpoint[list] can be computed for any number of points, therefore input is a list;
• Mean[list] gives the statistical mean of the elements in list (list length is not known);
• EuclideanDistance[u, v] is defined between two vectors $$u$$ and $$v$$, their number (two) is known in advance;
• Line[{p1, p2,...}] represents the line segments joining a sequence for points $$p_1, p_2, \ldots$$ Again, any number of points $$\ge1$$ is possible.
• I'm not certain everything is quite as consistent as that. For instance Min/Max work both with a list but also without it (but MinMax doesn't), and iteration specifications in multidimensional Table/Sum/Integrate and such are not in a list themselves. The fact that these originate from v1 might have something to do with it and surely it's more convenient not to need putting iteration specifications on a list, but if one would actually want to pass a specifications to such a function, it's a bit awkward in an inconsistent manner. Nov 6, 2022 at 8:55
• In V12.3, Midpoint[{{0,0},{1,0},{0,1}}] is left unevaluated. There is also no example in the documentation with more than two points. Nov 6, 2022 at 13:10
• So much for my theory that extra braces are used if it's a list. As the above points out, only two points are allowed for Midpoint yet it has the extra brace. I think the programmers just flip a coin to decide whether to use braces or not. 😁 Nov 7, 2022 at 2:42

It seems clear to me that the Wolfram team puts an incredible amount of thought into designing functions and function signatures. You can find recordings of design sessions on YouTube, and I've personally never been on a software design team that puts this much effort into design. So, I think it's fair to say there was some reason. What follows is speculative, but based on personal experience.

Let's start with EuclideanDistance. As for consistency, all of the *Distance functions take exactly two arguments. So, as for memorization, if you're using *Distance, you need two arguments. This makes sense to me. It seems to me that distance is inherently a concept that involves two "things".

Now consider Midpoint. I can certainly see the appeal of two arguments. But putting things into lists often implies a certain semantic. For example, Line takes a list of points, because Line is intended as a graphics concept (not the "straight line" concept from geometry, which would be InfiniteLine, btw). Line can also be used as a region, and regions are often defined by vertices or cells or some component parts (i.e. lists of things). So, Line and related symbols work with lists. They could work with variable length argument lists, but so much work is done with lists in Mathematica that basing these signatures on lists makes sense. It also streamlines some very common patterns of composition.

To that last point, what if I had a Line or just a sequence (list) of coordinates in some dimension and I wanted to find all of the midpoints of each segment? The natural thing to do would be to partition the list and map Midpoint over the result. Of course you could MapApply, but the data is already in the form of pairs.

Alternatively, think of Midpoint as a region-based measure of a simple 1D region. Again, we will already be dealing with lists in a region context, so it makes sense for Midpoint to "align" with that context. From this perspective, midpoint isn't inherently about two things, but about a single thing that just coincidentally happens to be defined by two things (boundary points, as it happens).

Even though it takes a list, it makes sense that it's constrained to pairs. There are all sorts of "centers" that one can define for multiple points beyond two, and Mathematica already has functions for some of them: TriangleCenter can find all sorts of centers; RegionCentroid (and the related idea of RegionMeasure); various *Moment functions; statistical functions for central tendencies (e.g. Mean, which works on lists). So, if you have more than two points for which you need some sort of "center", you have lots of options. Midpoint is the 1D graphic/region version. Maybe it could have been called LineMidpoint or something, but that seems a bit overkill.

Anyway, it all seems very consistent to me.