[twotwotwo]

It's using prefix notation, so

  => (+ [] [])
  []

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.

[ravestar]

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?

[twotwotwo]

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:

  => []"foo"3"hey"["wakka""wakka"]
  []
  u'foo'
  3
  u'hey'
  [u'wakka', u'wakka']
  
  => (+[1][2][3])
  [1, 2, 3]

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