Re: Module name mangling

[Dirk Herrmann]

On 28 Jan 2001, Marius Vollmer wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > Although Martin's solution works perfectly doing url encoding for
> > filenames, I now feel that such a patch would mean overdoing things:
> > We only have to care about a very limited set of characters, namely
> > those which can not be used within filenames on some systems.  For
> > all other characters, we should not care whether they are typically
> > hex-encoded in urls or not, but rather try to keep filenames
> > _readable_ as far as possible.
> 
> Keeping the filnames readable is a nice goal. But, as you say, the
> main problem is to decide just _what_ characters to encode.  I thought
> that the URL method would specify that list of characters.  Is that
> not the case?  Once we have that list, we can of course use a more
> pretty encoding than hex numbers.

IMO, if we actually agree about preferring a 'readable encoding', we don't
have to know about all those characters yet.  Currently, the only name
that is problematic is "and-let*.scm".  We know this, as it was reported
as a bug to us.  Other than that it seems that the use of 'strange
characters' in module names is rare.  So, IMO it would be sufficient for
now to provide encodings for '*' and '%' (for '%' only because it
will be used for the encoding scheme).  If we later realize that there
are more characters which should be added to the list, we can easily fix
it then.

We could try to find a final solution now, but it is unlikely to find one
anyway, because there are so many other problems that we have not yet
dealt with:  Unix allows an arbitrary number of '.' characters in a
filename, while for other well known systems there may be only one '.',
which only may be followed by a limited number of characters.  This can
not simply be but into an encoding as with the suggested scheme, because
we would like the '.scm' postix to stay unencoded :-)  Thus, a 'perfect'
module-name>encoded-filename function would be much more complex than the
current solution.  However, if we were trying to take all this into
account, we would spend a lot of time for solving a problem of very
limited relevance.

Best regards,
Dirk Herrmann