I think it's supposed to be like structure access from C-style languages, like linkedList.tail.tail.head or whatever. For instance, if you're working with a list of mailing addresses at the REPL, assuming it's structured a certain way, you can get the third digit of the fifth address's zip code by typing "addresses.4!zip.2". Using the same mechanism, you can access a list of lists as "matrix.i.j".
There are plenty of times I get frustrated that a.b.c doesn't expand to (a (b c)), but I don't think they outnumber the other case. And anyway, having a.b.c.d.e mean (a (b (c (d e))) isn't as useful when you can already say (a:b:c:d e).
reminds me of ssyntax's strict evaluation rules. I might have been tempted at some point to treat this as meaning the third zip code of the fifth address, thinking in error that . had higher precedence than !. Force of habit from arithmetic expressions with a similar shape, e.g.
a + b / c + d
In ssyntax, everything is evaluated from left to right regardless of the operator.
In ssyntax, everything is evaluated from left to right regardless of the operator.
Actually, no. . and ! are evaluated left-to-right in relation to each other, but there are currently three priority levels; from highest to lowest they are: (1) : and ~, (2) . and !, (3) &. Characters within the same level needn't be evaluated left-to-right, though . and ! are. For example,
arc> (ssexpand 'a.b:c.d) ; : takes precedence over .
(compose a.b c.d)
arc> (ssexpand 'a.b&c.d) ; . takes precedence over &
((a b&c) d)
arc> (ssexpand 'a:b&c:d) ; : takes precedence over &
(compose a b&c d)
Then, since & has lower precedence than ~, you can't do
arc> even&~odd
which causes Arc to hang (which is actually a bug).
Further, though ~ and : are in the same level, : takes priority over ~ regardless of order.
arc> (ssexpand '~a:~b)
(compose (complement a) (complement b))
If you're interested in rewriting code to use ssyntax, you can check out my sscontract library (and let me know if it's broken!): http://arclanguage.org/item?id=11179
> I think it's supposed to be like structure access from C-style languages
http://files.arcfn.com/doc/evaluation.html agrees with you. I may begin using it only in such contexts to help preserve the metaphor, meaning I'd stop taking shortcuts like car.xs for (car xs) because it's not an example of structure access (though xs.1 is).
