But isn't iso short for isomorphic which, as I understand it, is the same as "these two things are equivalent" - which maps much more closely to "has the same content as," not "refers to the same entity"?
The problem is that as people learn the language they will build mental maps of what works and what doesn't and in the process will write code that depends on things that could legitimately be considered bugs or arbitrary side effects of the current implementation.
Whether or not this matters to you or even should matter is another concern, but this has been a spot of contention for languages like Python and OCaml whose spec is the code.
The plan with intrasymbol syntax is (a) not to break traditional Lisp read and (b) to expand in place. If you have those two constraints, instead of just saying "ok, put any syntax anywhere," you can introduce syntax into Lisp without getting too unLispy.
Right. Maybe it's the traditional Lisp read that's the main factor here because it seems that you could expand in place without issue given even arbitrary expressions.
If a.b expands to (a b) then (f v w).(g x y) would just expand to ((f x y) (g x y)). At first glance, that definitely appears to be a cool way to grab just one of the results from a function return (ala (f x y).2).
Hmm, on the down side, you could have statements like (or worse):
(bst-find tree 45 f<).(if (< 10 42) (/ 4 3)
(> 4 2) x
'r)
That being said, having to change read to get this to work may affect far too much and make arc too ugly.