Prohibition on length-1 tuples can make laplace functions annoying to use

[WardBrian]

@avehtari ran into this today, where he wanted to define a covariance function that takes only a single argument.

The prohibition is purely syntactic, because (1.0) is already equivalent to 1.0 (e.g. a real).

Some options:

• Allow length 1 tuples with a required trailing comma (this is what e.g. Python does): (1.0, )
• Add a helper function that creates length one tuples (e.g. singleton_tuple(1.0))
• Allow a non-tuple tuple type as the forwarded arguments, in which case it looks for functions of only 1 argument.

All of these have a bit of a "magic" feel that makes me uneasy. The first is the most general, but we specifically avoided allowing this in the original tuples PR

[bob-carpenter]

I like the length-one tuple option with Python syntax (1.0, ). Then we should generalize to allow trailing commas everywhere, I would think.

I suppose it wouldn't work syntactically to just have tuple(1.0) do the job? "singleton" is very verbose. uni_tuple(1.0)?

[WardBrian]

Then we should generalize to allow trailing commas everywhere, I would think.

Allowing them universally should be pretty easy, the difficulty is if you want to preserve them during auto-formatting. We could just say "the formatter will remove any optional trailing commas", but usually people put them there for a good reason. Of course, we could do this for now and try to improve the formatting later.

I suppose it wouldn't work syntactically to just have tuple(1.0)

We might run into issues with the fact that tuple(...) is the type declaration syntax, but it's hard to say until I try it

[bob-carpenter]

We could have the formatter default to the trailing comma. I have come to like it in Python to visually distinguish tuple parens from regular parens.

[SteveBronder]

I also like the trailing commas approach. Though In the math library I could check if the input argument is not a tuple and if so wrap it in one.

[SteveBronder]

Though I think doing this for laplace would trick users into thinking that (X) produces a tuple

[nhuurre]

1. You can work around this by adding a dummy int argument to your covariance function, right? I assume "annoying to use" does not need to be fixed for this release.
2. Length-zero tuples are also forbidden. Would zero-argument covariance functions ever be useful?
3. You wouldn't need to manually pack arguments if we had closures. (The old closure PR is now outdated but it seemed feasible, I just didn't care enough to finish it.)

[WardBrian]

I assume "annoying to use" does not need to be fixed for this release.

Correct, I am assuming whatever we decide it would not actually be in 2.37

[avehtari]

1. Did that (both added a dummy and was annoyed)
2. Unlikely, but for example having known dimensional identity normal prior and non-centered parameterization in likelihood would match this

[spinkney]

3. You wouldn't need to manually pack arguments if we had closures. (The old closure PR is now outdated but it seemed feasible, I just didn't care enough to finish it.)

I vote for this to get in post 2.37. @andrjohns is writing gaussian copula (stan-dev/math#3206) that would benefit from closures.