The way I understand it, when you type in (eval '(- 3 4)) at the shell, eval passes its argument to ac. Ac in turn calls ac-call for things that are function calls. Ac-call converts an arc function call into an equivalent scheme form. During this process, it finds the underlying scheme name of an arc function by calling ac-var-ref. If you just pass in the actual function, it can't find the scheme name of the function and so can't evaluate it.
I think that there are some nice possibilities lurking in this idea. Perhaps there could be a macro defined that modifies def to use this functionality (kind of like pm:def).
Yes, I thought of that after I wrote the comment. Avoiding repetitions like this is exactly what macros are for. I guess I'm not used to thinking in lisp yet.
pau wants 'use to be a function, though, so there would have to be a separate macro, or the other way around, or something.
I'm still a noob, and my idea could be completely off base, but I think that it could be possible to devise a system that allows something like optional namespaces. The idea would be to have each symbol in the environment map to a table rather than directly to a function or variable. The table could have one entry per type (for example, pat's table could have one entry that's a macro, one that's a function, and one that's a variable). In standard cases, the value lookup function could return the entry that was last added to the hash table and thus mimic a Lisp-1 for all purposes. However, if the programmer specifies the type of a symbol, then the table would return the corresponding entry. There could be an fairly unobtrusive syntax for this. In one such syntax, the symbol pat would be:
I'm sorry, but could you explain your example a bit more? I don't think that I understand the issue here. If pm is redefined as a table through the let, why wouldn't we be able to access the macro version through the modifier? the table would clobber the variable version (@pm), but not the macro version right?
Local variables never override macros. In the first case above, the let will return the expected value correctly, because pm at that time hasn't been defined yet. In the second case, it will not return the expected value, because pm is defined as a macro, and (pm 1) gets replaced with whatever (pm 1) expands to, let notwithstanding.