I think it depends on the semantics of the situation. I don't like seeing things like "car.a" or "car.cdr.car.a" because I know that car and cdr are functions, so it kinda screws with my brain.
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
In other words, I'm okay with the . syntax when the first argument is a non-function. But I don't like seeing/using the . syntax when the first argument is a function.
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.
Note: if it were possible to combine the two without causing big problems (see evanrmurphy's post), then I might be okay with using the same syntax for both forms.
> I think it depends on the semantics of the situation. I don't like seeing things like "car.a" or "car.cdr.car.a" because I know that car and cdr are functions, so it kinda screws with my brain.
> 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.
Actually, I like that Arc overloads so many things. I suspect the primary reason I dislike using . for functions is because of my JavaScript background. After years of programming in JavaScript, it's become very ingrained into me that . means "property access"
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:
