As in Lisp, commas aren't needed to separate list items. []+1 is parsed like [] followed by positive 1 (+1), which is why it ends up executing even though it's infix notation passed into a prefix-notation parser.
WAT. I entered 3 items to input: [] + and 1 - this it is evaluated without error, but was expecting ([] + 1) or something as a result or error. Why there is no error? Why symbol + and a number are evaluated like + was an operator?
The + in +1 is bound tightly to the number like the - in -1. Think of it as meaning "positive," not addition.
Also, Hy's lexing appears to have an interesting feature where you don't always need a space to delimit things, so []+1 is automagically broken up into [] and +1. Here are some other examples where it breaks things up:
So without parens, []+1 is like []; +1; in Python and prints out the same result. With parens, the first token of ([]+1) is treated as a function (as would be typical in Lisp) so it tries to execute the Python [](+1), and you get the error that [] isn't callable.
So []+1 ran, but not for the obvious reasons. I'm basically poking at the REPL like you to try and puzzle this out; if you want to dig further, you could look at Hy's docs or source or contact the folks that wrote it.
Edit: an additional detail, not sure if it's informative or just confusing-- "+ 1" is apparently lexed by Hy as two items, not as positive 1:
=> [] + 1
[]
Traceback (most recent call last):
File "<input>", line 1, in <module>
NameError: name '+' is not defined