[Top][All Lists]

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

Re: Module name mangling

From: Michael Livshin
Subject: Re: Module name mangling
Date: 30 Jan 2001 17:49:05 +0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Crater Lake)

Dirk Herrmann <address@hidden> writes:

> It surprises me, though, that '%' should be in the list of safe
> characters.

naturally, the set of safe characters in URL's is bound to be slightly
different from the set of safe characters in filenames.  that is
there's no real reason for them to be the same, so it's reasonable to
consider them as different.  or something like that.  hmm.

if we want to disallow '%' too, what about making '_' the escape
character?  it's not very frequent in Scheme identifiers.

so, we would allow the alphanumeric characters (lower-case only,
perhaps, to avoid surprises on Windows and OS X?), the hyphen, and the
underscore as the leading char of hex char encoding.  the
(reasonable?) rule that filenames can't begin with a digit is enforced
by the fact that Scheme identifiers can't begin with a digit.  and all
dots save for the last one (which begins the '.scm' suffix) should be
encoded too.

what about Unicode names?  the 'two digits' rule only covers ASCII, so
perhaps we could just allow any non-zero number of digits, now that we
don't want to use the URL encoding anyway.  but that requires
different quoting rules.  perhaps a single underscore before two
digits, and double underscore before more than two digits, ending with
a single underscore?

[ yes, I parrot some stuff said earlier in the thread by others.  just
  wanted to have it all in one place. ]

anything I missed?

another obvious idea (which looks like more of the Right Thing to me,
actually) is to not specify any cross-platform filename encoding at
all, and leave it platform-dependent.  but that doesn't play well with
CVS.  ugh.

Being really good at C++ is like being  really good at using rocks to
sharpen sticks.
                -- Thant Tessman

reply via email to

[Prev in Thread] Current Thread [Next in Thread]