[Openmcl-devel] Why not #"foo" for ns-strings?
Gary Byers
gb at clozure.com
Wed Aug 26 02:59:22 PDT 2009
Figure 2-19 in section 2.4.8 of the spec lists the standard characters
that have standard definitions under the # dispatching macro, the
characters that don't have standard definitions but are reserved for
user-level code, and those undefined characters that're not reserved
for the user (and therefore available to the implementation.) The
spec explicitly prohibits the implementation from defining a #-macro
on a character that's marked with an asterisk in that table (reserved
for the user). It doesn't (as far as I know) prohibit user code
from defining a #-macro on a character that's not reserved for the
user, but such a definition might conflict with something legitimately
defined by the implementation. (As is happening in your case.) The
authors of user-level packages may not know what #-macro characters
are defined by what implementations (and that might change over time),
but a look at Figure 2-19 will tell them what #-macro characters might
be defined by some implementation and what are guaranteed not to be,
and it seems wise for those authors to observe that distinction.
CCL used to use (IIRC) #? to refer to foreign variables; that was
changed (since #? is reserved for the user.) The change from #? to #&
for variables was somewhat disruptive, but it was clearly necessary.
I think that a very early version of what's now the ObjC bridge used
#"foo" (instead of #@"foo") to refer to NSConstantStrings, and I think
that it was changed by popular demand. This would have been in 2002
or 2003, and I'm not sure that I remember all of the reasons people
gave. There's at least some argument that #@"foo" is sufficiently
close to the @"foo" syntax that ObjC uses to suggest that it's a way
of referring to the same kind of thing, whereas #"foo" might suggest
"a string or something string-like, but not necessarily related to
NSConstantString." Whatever the reasons people gave were exactly,
they were similarly persuasive but not compelling, and since there
wasn't a whole lot of code written using the old syntax (or a lot of
people reading or writing such code) it wasn't particularly disruptive
to change from #"foo" to #@"foo" at that time. If there was a good
reason to change back 6 or 7 years later, I think that it'd have to be
"very good" ("strongly persusasive", "pretty compelling") to outweigh
the real costs of making that change. Either #@"foo" or #"foo" could
confict with user code that doesn't try to avoid such conflicts, the
arguments in favor of #@ (whether I actually heard them or am just
making them up ...) would be enough to make me lean toward using #@
in a vacuum, and we aren't in a vacuum.
On Tue, 25 Aug 2009, Ron Garret wrote:
> I started playing around with a package that co-opts the #@ reader
> macro, which in CCL is used to create constant ns-string objects. It
> seems to me that this would be a natural candidate for the #" dispatch
> reader macro instead of #@, since the only character that can legally
> follow #@ is a double quote.
>
> I also have this in my personal init.lisp file:
>
> (defun make-string-reader (c1 c2)
> (set-macro-character
> c1
> (lambda (stream c)
> (declare (ignore c))
> (with-output-to-string (s)
> (loop for c = (read-char stream)
> with cnt = 1
> if (eql c c1) do (incf cnt)
> else if (eql c c2) do (decf cnt)
> until (and (eql c c2) (eql cnt 0))
> do (princ c s))
> s))
> t))
>
> (make-string-reader #\? #\?)
>
> This lets me use European-style ?quotes? to create strings. These
> have the advantage that they are self-balancing, so I can nest strings
> without having to use backslash escapes. (There are also ?smart
> quotes? characters which could be used to create self-balancing
> strings, but there's a bug in the readtable code at the moment that
> barfs on reader macros for characters whose code-char is >256.)
>
> My question is: how would people feel about adopting one of these as a
> standard for ns-strings instead of #@? Either #"foo" or #?foo? or
> #?foo?? That would free up the #@ reader macro, and especially the
> last two would be at very low risk of collision with third-party code
> since no one is actually using unicode in their code despite the fact
> that all major implementations support it nowadays. Existing code
> could be converted with a global search and replace of ?#@"?.
>
> Thoughts?
>
> rg
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>
More information about the Openmcl-devel
mailing list