Just because there's a literal syntax for something doesn't mean it evaluates to itself; take lists and symbols, for example. :) How about a table syntax that evaluates like 'obj?
This doesn't strike me as being particularly odd, since it's exactly the same for lists already.
arc> (read "'(a (- 5 4))")
(quote (a (- 5 4)))
arc> (eval:read "'(a (- 5 4))")
(a (- 5 4))
arc> (eval:eval:read "'(a (- 5 4))") ; would call a with 1
Error: "reference to undefined identifier: _a"
Here's where I think the real gotcha is:
arc> '{b 1 a 2 a 3}
{a 3 b 1}
arc> '`{,(uniq) 1 ,(uniq) 2}
(quasiquote {(unquote (uniq)) 2})
arc> `{,(uniq) 1 ,(uniq) 2}
{gs1700 2}
Having a table as syntax can be a bit unintuitive, since it doesn't preserve order and multiplicity in the source the way a list does. Still, I personally try not to rely on side effects or evaluation order in expressions like this, and I figure that whenever someone does rely on those, they'll be writing code, so they can just use 'obj.
EDIT: Now that I think about it some more, those concerns can be mitigated too.
I do lots of my programming in Groovy, where the tables made by literal syntax do preserve order. They use LinkedHashMap, which essentially stores its references in both a hashtable and a linked list, so you get hashtable access speed and fast insertions and deletions while preserving order, at the cost of space efficiency.
As for the multiplicity issue, that can be caught by the reader. That is,
arc> `{,(uniq) 1 ,(uniq) 2}
can produce an error at read time rather than silently treating the expression as `{,(uniq) 2}. Since any table already loaded has unique keys, nothing that can be written out will trigger this error when it's read back in.
EDIT: Well, I suppose there might be some question as to whether the reader should really have to compare things by 'iso, which would put a wrench in any plans for writing recursive/repetitive mutable structures. But I'll stop arguing with myself and give someone else a turn. :-p
is what is happening is that the reader parses "{...}" into a table object with a as a key and (- 5 4) as the value, and then the Arc compiler would, when it was passed a table object to compile, recursively compile the values of the table?
If so, then the part I wasn't getting was that the reader would return an actual table object which the Arc compiler would then work on... I hadn't thought of that approach.
