Email list hosting service & mailing list manager

A proposal for reserved read-syntax characters John.Cowan (21 Jul 2005 13:37 UTC)
Re: A proposal for reserved read-syntax characters Jorgen Schaefer (21 Jul 2005 14:35 UTC)
Re: A proposal for reserved read-syntax characters John.Cowan (21 Jul 2005 15:07 UTC)
Re: A proposal for reserved read-syntax characters bear (21 Jul 2005 15:43 UTC)
Re: A proposal for reserved read-syntax characters Thomas Bushnell BSG (21 Jul 2005 23:03 UTC)
Re: A proposal for reserved read-syntax characters Jorgen Schaefer (21 Jul 2005 16:03 UTC)
Re: A proposal for reserved read-syntax characters John.Cowan (21 Jul 2005 18:04 UTC)
Re: A proposal for reserved read-syntax characters Jorgen Schaefer (21 Jul 2005 15:55 UTC)

Re: A proposal for reserved read-syntax characters bear 21 Jul 2005 15:43 UTC


I agree that certain characters ought not appear in
identifiers without use of some escape mechanism.  But
rather than list them, I'd prefer to do it by category.

Just looking at the categories, I think characters with
the "General Category" of CC (control characters) CF
(formatting controls), PS (open punctuation), PC (close
punctuation) ZL (line separator), ZP (paragraph separator)
and ZS (space separator) should probably be excluded from
identifiers.

PS includes our familiar open-paren, open-bracket,
open-curly, and many other symbols, most of which were
in your list.  PC includes the closing versions of each.
ZL, ZS, and ZP, as I understand it, basically means
whitespace of various kinds.  And CC and CF characters,
where they are not whitespace, are still probably not
good ideas for identifiers.

If we want to reserve a bunch of characters for reader
macros in implementations where reader macros are definable,
I'd suggest the class SO (other symbols, including dingbats);
they're eyecatching, occasionally iconic, and for the most
part linguistically neutral.

				Bear