10 ms·

[]+1 = [] 1 []+[] -> error ...

• twotwotwo 13y ago
  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 13y ago
    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 13y ago
      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