Arc Forumnew | comments | leaders | submitlogin
3 points by evanrmurphy 3521 days ago | link | parent

In another part of that thread, aw brings up his experimental table literal syntax [1]:

> I've since realized that I don't like the {a 1 b 2} syntax; I find the key value pairs aren't grouped together well enough visually for me, and the curly brackets don't stand out enough themselves.

I really liked this syntax for table literals. It's what I'm using in my lispy JavaScript project [2]. Do you find the grouping isn't clear enough even when you use strategic whitespace?

  {a 1  b 2}

  {a 1
   b 2}
Arc is the only language I know to rely so heavily on implicit paired grouping:

  (if a b
      c d

  (= x 1 y 2)

  (let x 1

  (with (x 1 y 2)

  ; And, of course:

  (obj a 1 b 2)
And I'm a big fan of this theme. It seems to me that whatever techniques you're employing to help keep the pairs straight in all of these contexts should work in the table literal context as well.

Update: Here's another example of implicit pairs in Arc (although it's somewhat esoteric and debatable):

  (list 1 2 3)
Since lists are made up of cons pairs, of course:

  (1 . (2 . (3 . nil)))



2 points by aw 3521 days ago | link

To clarify: my comment was about my experiment with having tables print with "{a 1 b 2}":

  arc> (list (obj a 1 b 2))
  ({b 2 a 1})
it was this that I found hard to match key value pairs in a long table output and the curly brackets weren't standing out enough by themselves for me when I was scanning a large amount of debugging output.

For input, when I'm the one doing the typing :) -- and anyway the number of key value pairs is usually small anyway -- I'm all for typing fewer parentheses ^_^


1 point by evanrmurphy 3520 days ago | link

Thanks for clarifying, I was being careless about the distinction.

  {glad-to  'hear
   you-like 'writing
   this-way 'though!}