5 ms·
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
by 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 agoThe + 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