I can certainly understand if you'd prefer for certain Arc utilities to not be automatically quoted for you, since it saves a single character and costs a lot of flexibility, but I wouldn't say it's ambiguous.... I think I'd use "ambiguous" to refer to code that takes advantage of unspecified behavior.
I'm sure you've considered this, but we can technically accomplish the kind of code you prefer:
(copy (table) 'first "Farley" 'last "Mowat")
(tablist:pair:list 'first "Farley" 'last "Mowat")
; using 'switch from Anarki's lib/util.arc (but it uses (is a b)
; rather than testify.a.b, so functions still don't work)
(let x 'y
(switch x 'y (pr "YES")))
But I agree, it'd be nicer if the standard utilities had these behaviors, so that good behaviors could have good names. ^_^ (Incidentally, this is a place where namespaces could make the issue a matter of library development rather than language overhauling.)
As for your question about (e "div" ...) versus (e 'div ...), I think it would work either way. The tag name (not to be confused with an attribute name) can be anything that has the desired [pr _] behavior.
Is y a symbol? or a variable name from somewhere else in the code? Unless you've memorized every macro's inner workings it's clearly open to more than one interpretation.
Unless you've memorized every macro's inner workings it's clearly open to more than one interpretation.
That's the thing. To interpret (case ...) at all, you have to know what 'case is supposed to do as a macro. At least one suggestion on this forum (http://arclanguage.org/item?id=10858) would intentionally(?) have your example work in a different way:
(case x 'y (dosomething))
== reads as ==>
(case x (quote y) (dosomething))
== expands to ==>
(let gs123 x (if (in gs123 'quote 'y) (dosomething)))
When I started out with lisps, I had trouble with this. I kept reading (quote x) as though it might evaluate x, or (let ((foo bar)) ...) as though it might involve a function call to foo. It wasn't just a matter of vocabulary; even if I figured out what (quote ...) did, some macro form around that code might give it a completely different meaning! What if one of these unintelligible commands had the side effect of rebinding 'quote? It took me a while to realize lisp programmers weren't quite as sadistic as that, but that revelation in itself doesn't make the whole issue go away. ^_^ You sorta do have to memorize every macro.
Of course, we could just go for read macros everywhere, rather than putting cheap abbreviations into the normal macros:
; assuming 'x abbreviates (quote x), which it does
(obj 'key "value")
; assuming #'x abbreviates (fn () x)
(if condition
#'then
#'else)
; assuming #,x abbreviates (fn (gs123) (zap gs123 x))
(push elem #,place)
; assuming #. var x y z abbreviates (fn (var) x y z), with the read
; macro terminating once a mismatched closing parenthesis is reached
(w/outstring #. var
body1
body2
body3)
; assuming all of the above
(mac #,case (var . body)
(w/uniq #. g-var
`(let var #. ,g-var (case-part-2 ,g-var ,@body))))
(case x #''y #'(dosomething))
A good portion of the macros I write do nothing but prevent the need for these abbreviations (except they do put the #. variable in a more idiomatic spot), so it's a significant move. I kinda intended to show how bad it was, but what do you think? If we found hieroglyphics we could get used to, maybe they wouldn't be bad at all....
