This is consistent [...] Why would you expect a quoted argument to be evaluated?
I misspoke regarding consistency. What I meant was that the "useful" way (conditionally evaluating the branches) would be inconsistent, but the consistent way doesn't seem very useful (because the point of special forms is to behave specially).
Yeah, it's been done before [...] but that doesn't make it a bad idea
Certainly not! I didn't mean to imply first-class macros/special forms are a bad idea --- let alone just because they've been done before. I meant that the ideas are similar; since there's been more discussion about first-class macros, it might be useful to ponder those.
Even so, first-class special forms seem less promising than first-class macros. rntz already pointed out that functions can mimic PicoLisp's behavior for special forms, but you can even mimic the "useful" behavior for certain cases of if:
arc> (def iffn (x y z) (if (eval x) (eval y) (eval z)))
#<procedure: iffn>
arc> (iffn '(prn "test") '(prn "then") '(prn "else"))
test
then
"then"
arc> (iffn '(do1 nil (prn "test")) '(prn "then") '(prn "else"))
test
else
"else"
But that's still kind of a joke. And what about ones that don't even evaluate their arguments, like fn? If
(car:map if '(t) '((pr "a")))
corresponds to
(if 't '(pr "a"))
then does
(car:map fn '(t) '((pr "a")))
correspond to
(fn 't '(pr "a"))
which isn't even valid syntax? (At least by the way Arc's quote and fn interact; I understand PicoLisp's quote and fn are unified to just quote.)
I'm not against first-class special forms iff we can reason about them. It's just that reasonable interpretations look like solutions in search of the problem.
