1. Original:

  userinfo.user!stations.station!read-list.doc!title

  (.title ((.read-list ((.stations (userinfo user)) station)) doc))

  userinfo|user.stations|station.read-list|doc.title

---

Update: What about '>' ?

  userinfo>user.stations>station.read-list>doc.title

If arc had a macro for chaining "!" forms (I'll call it "!!" here), then this example could be nicely expressed without so much ssyntax:

  (!! (userinfo user) (stations station) (read-list doc) title)

  (.. (userinfo user) (stations station) (read-list doc) title)

  (. userinfo user stations station read-list doc title)

This would mean that (h k) in table access would sometimes be synonymous with (h k). If k is bound, look up the value of k, else look up the symbol k. If k is ever bound but you actually wanted to pass in the symbol, you can still use (h 'k).

---

Since this all boils down to entities in functional position, why not take it a step further: auto-quote [1] all unbound symbols, the ones most relevant to this discussion being those passed as arguments to functional position entities, including functions, lists, tables and strings.

Ramifications:

  > (def f(x) (list 1 2 x))
  #<procedure: f>

  > (f x)
  (1 2 x)
  > f.x
  (1 2 x)
  > (= x 3)
  3
  > (f x)
  (1 2 3)
  > f.x
  (1 2 3)
  > f.x.0
  1

  > f.h
  (1 2 h)
  > (= h (obj k1 'v1 k2 'v2))  ; [2]
  #hash((k1 . v1) (k2 . v2))
  > f.h
  (1 2 #hash((k1 . v1) (k2 . v2)))
  > f.h.2
  #hash((k1 . v1) (k2 . v2))
  > f.h.2.k1
  v1

---

[1] Perhaps another way to think about this, instead of in terms of quotation, is that all symbols are initially bound to themselves. (Note that this plays nicely with t and nil.)

[2] Actually, by the same principle this could be written:

  (= h (obj k1 v1 k2 v2))

Here's another thing it gives you for free, super convenient alist initialization:

  > (x.1 y.2)
  ((x 1) (y 2))
  > (= a that)
  ((x 1) (y 2))
  > (alref a x)
  1

  > a.x
  1

  (test "call on one arg autoquotes"
    :valueof (call 'idfn xxzx)
    :should be 'xxzx)

Hmm, I wonder if I should shoot for the moon and find the right handler to install for the UNBOUND-VARIABLE condition..

Update: I'm tantalizingly close, but perhaps it's not possible. This page outlines how: http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node322.html

But I'm concerned by the phrase, "If this [restart clause] were part of the implementation of symbol-value.." Does that mean it isn't possible?

I actually think cadr.x is a better way to go for field-getting. If the language has good enough namespacing support, variable names are automatically more malleable than specific symbols. If anything, we could just rephrase it as x.cadr. The trouble is that refactoring x.func into (func x y) is even more work; there'd be a demand for an x.func(y) syntax. Not that that would be a bad idea, just a more complicated one. ^_^

(I originally brought up the similar idea of an a'b => (b a) ssyntax at http://arclanguage.org/item?id=13061 .)

Backing up, let's suppose Arc doesn't need to be like other languages. The current meaning of a.b fits my needs pretty well. I use (a b) significantly more often than (a 'b), partly because I tag my types using 'annotate; even if one of my types is represented by an "a!b"-friendly hash table, I access it using "rep.x!field-name", meaning I use one '.' for every '!'. (BTW, do you think ((rep x) 'field-name) would be clearer?)

Since (a b) is so common for me, I like that it uses one of the conveniently un-shifted punctuation characters (on an American keyboard):

  ;,/.'

P.S. to directly answer your question, yes I think that would be clearer, though more verbose. It's a bit hard for me to pick out the individual elements, because they're all squished together due to the infix syntax.

My current view of the various styles:

  (foo rep/x.field-name)       ; good
  
  (foo rep|x.field-name)       ; undecided; looks pretty weird
  
  (foo rep'x.field-name)       ; tied for favorite

  (foo rep,x.field-name)       ; tied for favorite
  
  (foo rep.x.field-name)       ; okay, but too hard to see the "."s

  (foo rep.x!field-name)       ; don't like the !

  (foo (rep x).field-name)     ; doesn't look lispy enough

  (foo (rep.x 'field-name))    ; good: very lispy, but not too verbose

  (foo ((rep x) 'field-name))  ; too verbose

  (something foo,bar,qux)

  (foo,bar,qux.corge)

I feel like function calls should look like function calls, but when adding syntax, they should look different from non-function calls. According to that rule:

  (= foo (list 1 2 3))
  foo.2         ; good
  car.foo       ; bad

  (= foo (obj x 1 y 2))
  foo.x         ; good
  keys.foo      ; bad

  (= foo "bar")
  foo.0         ; good
  downcase.foo  ; bad

For instance, the : syntax is used for functions only. I think the . syntax should be used for non-functions only. It just helps me to cognitively understand a program with the least amount of effort, but others may disagree.

I agree that Arc shouldn't especially try to be like other languages, but since the distinction between . and ! is mostly arbitrary, choosing a syntax that is more appealing to people coming from other languages is a nice bonus. Especially given that JavaScript is quite popular (for better or worse) and has some nice functional aspects to it (closures, lambdas, etc.) which make it conceptually similar to Scheme, even if the syntax is very different.

> I feel like function calls should look like function calls, but when adding syntax, they should look different from non-function calls.

One of the features of a language like Arc or Scheme (i.e. lisp-1's) or JavaScript is that functions are not treated especially differently from other data types.

Forget special syntax for a moment. In Arc we can call a function with (f x), a macro with (m x), access a list with (xs 0), a string with (s 0) and a table with (h k). We even call each of these, "putting the [function|macro|list|string|table] in functional position." So, even before ssyntax is introduced, Arc has taken pains to go against your wish of making function calls and non-function calls look distinct from one another.

Overloading functional position is very powerful once we do get to ssyntax because it allows us to overload that as well. Now all we have to do is introduce one syntactic convenience, a.b => (a b), and it becomes available to all the types.

If you like the syntax when it represents list, string or table access but not when it's a function or macro call, you could simply not use the syntax on functions and macros. So you have xs.0, s.0, and h.k, and you have (f x) and (m x). Otherwise, I'd consider that the root of your grievance may be that Arc overloads functional position for all these different types to begin with.

I agree that for my code it's a simple matter of not using the syntax in the areas that I don't like it. In fact, I don't need to use any syntax at all: I could use pure S-expressions if I wanted.

I guess what it comes down to is, "I want to use . for property access in tables, or at least use something that's not !" and although it looks weird to me to use . for function calls, I'll concede that Arc is not JavaScript, so I think I can tolerate it.

Thus, combining . and ! might be the best way. Alternatively, I think these would be very nice as well:

  x,y -> (x y)
  x.y -> (x 'y)

  x'y -> (x y)
  x.y -> (x 'y)

  x,y -> (x y)
  x'y -> (x 'y)

The | is used for wrapping a symbol having spaces i.e. |my symbol|, and by having a vertical bar there it helps me remember I am referencing a symbol, not resolving a named variable.

As was I, though I could have been clearer.

> I feel like . is more natural for property accesses