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
Linux (and other open OS's) have had to fight this from the very beginning. It may seem DOA now, but then Linux did too for a lot of people.
And while we still need the occasional closed source firmware blob or driver, there are now also systems where we can replace every little bit from the BIOS upwards with open alternatives.
In the mobile space, RockChip has released sufficient source to allow Ubuntu to be ported to the RK3188 CPU's (quad core Cortex A9), so there's movement. Given that RockChip is one of 3 CPU providers dominating the Chinese Android devices, if this helps their market share you can expect MTK and AllWinner (the two other main CPU providers) to be more open too.
That does not mean these systems are open - a lot of pieces still will be locked down often because they license GPU's etc. and don't have the rights to open up everything, but several of the Chinese/Taiwanese manufacturers in fact do seem to want to make custom builds available (not least because a lot of these devices ship as XBMC devices - many distributors now ship with XBMC by default, and at least one offers to flash their Android sticks with plain Linux + Linux version of XBMC instead of Android)
Well, the purpose of distributed programming is to be distributed first.
Is this language targeting desktops/servers only? What about Android/iOS/WP/BB and rest of the mobile world?
Vendor lock-in exist for specialized areas (eg. documents, protocols). There are areas when some producers _must_ support common standards. Microsoft for ex. had to introduce support for native code in WP8. HTML/JS is a second area where support from vendor is a must. OpenGL is next one (not for WP, but its a minor platform, but... surprise, surprise Microsoft supports WebGL!).
Smalltalk/Pharo application developed on Windows or Linux Machine can be deployed on iPad or Android and it will work without a single byte change. These things are made by single individuals as hobby projects with a great success.
Language is not a platform, it is a way to describe a computation. In this particular case, the researchers discovered that using a relational language to describe state transitions in a distributed systems helps to reason about the distributed system and reduces the amount of code required to describe it's behavior significally. It is in no way dependent on any particular platforms, as it is some kind of libary you have to plug somewhere, it is a /language/.
[]+[] -> error ...