I see a couple potential issues. (Better terms for whether the reader macro evaluates subforms might be "evaluating" and "quoting".)
If the elements inside the syntax are permitted to be non-self-evaluating objects such as symbols or conses, then under the evaluating option one would need to write [1 'x (+ 40 2)].
Second, as I'm sure you realize, the evaluation model at read time is very different from regular evaluation in that it always happens in the read-time dynamic environment and the null lexical environment. This doesn't matter if the computations are just simple arithmetic, but it makes read-time evaluation feel messy to me, especially if someone might later use it with more-complex forms.
You might also consider inside your reader macro borrowing the syntax and meaning of the backquote comma: [ 1 x ,(+ 40 2) ]. This might make the meaning and environment more evident to experienced CL programmers (although comma forms evaluate at run time in the current lexical environment).
On Mon, Dec 3, 2012 at 5:12 AM, Marco Antoniotti < antoniotti.marco@disco.unimib.it> wrote:
Dear all,
I was fooling around with reader macros to implement some - let's say - "tuple" syntax.
Now, I am just curious about the general thinking on this.
First of all, let's note that the problem here in the conflating of the "constructor" with the "printed representation" of an item. I.e., in Matlab you say
[1, 2, 40 + 2]
ans = 1 2 42
In CL, doing the simple thing, you get
cl-prompt> [1 2 (+ 40 2)] [1 2 42]
but
cl-prompt> #(1 2 (+ 40 2)) #(1 2 (+ 40 2))
So, suppose you have your [ … ] reader macro, would you have it work "functionally" or "quoting-ly" (for want of a better word)? I am curious. Note that the Matlab-style version would not break referential transparency if you did not have mutations.
best
Marco Antoniotti
-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY
Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.
pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro