|Currently, ac treats 't, 'nil and symbols corresponding to numbers (e.g. '2) as special cases where rebinding is prohibited.|
Obviously rebinding these symbols is a big deal, but should it really be prohibited? The restriction would seem to be an instance of trying to protect the programmer from him/herself, which Graham expresses wanting to avoid in "Some Work on Arc" :
arc> (= t 1)
Error: "Can't rebind t"
arc> (= nil 1)
Error: "Can't rebind nil"
arc> (= 2 1)
Error: "Can't take car of 2"
> [...] the third type of restriction, the kind intended merely to keep the user from getting into trouble, would be encapsulation. There won't be any of this type of restriction in Arc, if I can help it. There might (or might not) be situations where this kind of restrictive language would be a net win, but it's not the kind of language I'm trying to write.
It is also inconsistent with the way other symbols fundamental to Arc are allowed to work, for example 'car :
So why not treat 't, 'nil and number symbols the same way, as symbols initially bound to their important meanings but still rebindable? Here is the behavior I would like to see (demonstrated at the Arc REPL of my dreams):
arc> (= car 'foo)
Maybe their original values could be restored with something like the following:
arc> (= t 'foo nil 'bar 2 'baz)
arc> `(,t ,nil ,2)
(foo bar baz)
But even if they couldn't be, it doesn't undermine the main point, which is that these symbols should be rebindable despite that it's dangerous in order to be in line with Arc's design philosophy. (That is, unless there's some other reason not to allow rebinding of these symbols, in which case please tell me!)
arc> (= t (is 'x 'x)
nil (is 'x 'y)
2 (+ 1 1))
arc> `(,t ,nil ,2)
(t nil 2)
 aw pointed this out in a related subthread about the (un)rebindability of 't: http://www.arclanguage.org/item?id=11281