On Mon, Dec 3, 2012 at 8: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.
I struggled with this very question in Antik (grid syntax with #m). What I decided was it should mimic CL #(, i.e., not evaluate. For evaluation, I have function(s), particularly #'grid, so
ANTIK-USER> (setf *default-grid-type* 'foreign-array) FOREIGN-ARRAY ANTIK-USER> (grid 1 2 (+ 40 2)) #m(1.000000000000000d0 2.000000000000000d0 42.000000000000000d0)
(Note #'grid doesn't take as arguments any options like the grid type, just elements, but there are other functions that will.) My reasoning was mainly to be consistent with CL, but also somehow a reader macro triggering an evaluation seemed wrong; a function was the most appropriate way to do that. I can't recall right now the problem that caused me to switch (before, it did do evaluation), but it was a mess and this was the easiest way to clean it up.
Liam
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