Arc Forumnew | comments | leaders | submitlogin
2 points by aw 5256 days ago | link | parent

> Just to be clear: do you mean that an arc reader, on encountering #table(a 1 b 2) should create an object equivalent to that returned by (obj a 1 b 2)

Yes, for that example. Though with #table(...) the values are always literals, so #table(a (+ 1 2)) wouldn't be (obj a (+ 1 2)) but instead would return the same value as (obj a '(+ 1 2))

a table literal in code should also contain other code to be executed at runtime ... I prefer {...} to #table(...)

right, if you want your table literal to be able to act like a "template" in the sense that you can insert expressions to be evaluated, then we'd need some kind of syntax to "unquote" the expression.

But I don't know how to do that and get everything to work.

I'm certainly open to suggestions, I'd just need working syntax to implement it.

The other option is not to try to get the syntax you like for constructing tables to be the same one as the writer/reader uses to output/read literal tables.

You could come up with a {...} syntax you like to use while programming, and that would be easier than coming up with a {...} syntax that the writer would also use to output tables, because that has the complication that every table needs to be able to be written out in a way that can be read back in.

For example, suppose you wanted a {...} syntax that worked like obj. Then, in regular Arc:

  arc> {a (+ 3 7)}
  #hash((a . 10))
or, using #table as the read/write syntax:

  arc> {a (+ 3 7)}
  #table(a 10)
That's easy to do. Now, if you also wanted your {...} to be used as the read/write syntax, that would be a lot more difficult, maybe impossible. At least I don't know how to design a syntax that would work for both, and still be able to read/write any table value.