Arc Forumnew | comments | leaders | submitlogin
1 point by rocketnia 4460 days ago | link | parent

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?

  arc> (= a 'foo)
  arc> {a (- 5 4)}
  {a 1}
  arc> '{a (- 5 4)}
  {a (- 5 4)}
  arc> `{,a (- 5 4)}
  {foo (- 5 4)}

1 point by aw 4460 days ago | link

With this syntax, how would we be able to use the same reader for reading data files and for loading Arc source code?

For example, what would

   (read "'{a (- 5 4)}")

Part of the power of Lisp is that Lisp programs can be manipulated as data and vice versa; this also makes coming up with new syntax hard.


1 point by rocketnia 4459 days ago | link

For that particular example, I see no problem:

  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)}")
  {a 1}
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


3 points by aw 4458 days ago | link

oh, so for

  arc> {a (- 5 4)}
  {a 1}
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.