[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: READ-CASE-SENSITIVITY (Version 1)

> I notice that our reader calls CHAR-UPCASE on characters which the read
> table defines as possible constituents of a symbol name.  Suppose that
> instead of a hard-coded call to CHAR-UPCASE, it FUNCALLed a function
> contained in the read table, with #'CHAR-UPCASE being the initial value
> in the standard read table.  That would be a very simple change, but would
> give you all the flexibility you might want.  The only drawback is that it
> could slow the reader down, since our call to CHAR-UPCASE is actually
> expanded inline now.

Hummm.  I like this approach, but I'm not sure people will be happy
with a slower reader.  Of course, the function call might skipped
in the "normal" case, and CHAR-UPCASE called in-line; and that may
be good enough.

I'm also somewhat uneasy about allowing arbitrary translations.
Suppose "a" is translated to "b".  Does that mean PRINT should
escape any "a"s in print names?  DO we have to restrict the set
of valid functions?

> I like the idea of doing things like this as keyword arguments to
> COPY-READTABLE, both to avoid inventing new function names and to protect
> the standard readtable from alteration.  For example:
>                 (COPY-READTABLE *READTABLE* NIL 
>                                 :SYMBOL-CHAR-TRANSLATION #'IDENTITY))

KMP writes;

   Date: Wed, 22 Feb 89 14:13 EST
   From: Kent M Pitman <KMP@arpa.scrc-stony-brook>

   I would support such a proposal.

   However, I would prefer to see CHARACTER spelled out. This won't be used
   often enough to justify abbreviation. 

OK.  However, there are lots of "CHAR-" functions in Common Lisp,
so it could go either way.

   Also, I'm not sure that the `SYMBOL' part of the name is warranted
   or even a good idea. For example, this option might control whether
   you had to write #\Control-\a or could get away with #\Control-a.
   Obviously, that's a matter to be decided by the Characters
   committee, but if we choose an overly specific name, we'll make
   it harder for them to explain.

I'm happy to see the "SYMBOL" go, but I don't want to end up
creating confusion about when the translation occurs.  I was
expecting it to happen at step 8, point 1 (CLtL, page 337).
Is that ok?

  Symbolics has used the function name SET-CHARACTER-TRANSLATION for a
  while and to my knowledge no one has complained that it did not
  affect (for example) strings. As such, I'd prefer


   Providing no way to modify a readtable's character translation function
   would avoid the problem of people modifying the standard readtable, but
   it would probably also be a nuisance in other situations. My vote would be
   for adding a setf-able function READTABLE-CHARACTER-TRANSLATION as well.

I prefer being able to set things when it's reasonable to do so,
and I'd like to have the function anyway so that I can call it
on a readtable and see what its translation function is.

-- Jeff