Re: swiss army knife

Matthias Blume <find@my.address.elsewhere> writes:

> Joe Marshall <jrm@ccs.neu.edu> writes:
> 
>
> My point was that the policy exists for the benefit of those who run
> in case-insensitive mode.  If nobody ever used insensitive mode, then
> the policy would not be necessary.

We *must* be talking about different things.

My point is that the policy exists for the benefit of those who run in
*sensitive* mode.  I think I can demonstrate this.  Consider these
alternative policies:

1.  All exported identifiers provided by the system will be in ALL
UPPERCASE.

2.  All exported identifiers provided by the system will be in
StudlyCaps.

3.  All exported identifiers provided by the system will use the
same convention, but you are not told what that convention is.

4.  There is no coherent policy:  any identifier exported by the
system could be in all lowercase, ALL UPPERCASE, Capitalized,
Studly, or whatever.

If I write my code with case-insensitive assumptions, that is, if I
expect `define', `DEFINE', `Define', etc. to all refer to the same
identifier, I can expect my code to work under any of the above
policies.  That includes the `no policy' situation.

If I write my code with case-sensitive assumptions, that is, if I
expect `define', `DEFINE', `Define', etc. to each refer to a
*different* identifier, then I *must* have knowledge of the case of
the exported identifiers in order to use them.  If I do not know the
policy, as in option 3 above, then I cannot determine if I need to
write (define x 3) or (DEFINE x 3) or (Define x 3).  This occurs *even
if* no one uses the case-insensitive mode.  This occurs even if there
*is* no case-insensitive mode.

The people running in case-insensitive mode do not need to know the
policy.  They do not need to know *if* there is a policy.  They do not
need to know if the policy changes.

The people running in case-sensitive mode *must* be aware of the
policy if they want their code to work.  If the policy changes, they
must change their code.  If there is no policy, they must be provided
with an unambiguous explicit enumeration of the cases of every
exported identifier.

How can you therefore say that the policy is for the benefit of the
case-insensitive people?

> Yes another demonstration of what another poster has pointed out
> already: Those who use case-sensitive mode can easily emulate
> case-insensitive mode if they have to.  But the other way around is
> difficult -- which is why the above policy needs to be in place.

I don't understand this, either.  If the insensitive mode works by
canonicalizing the case (a common technique), then sure, the sensitive
mode can simply manually mimic the canonicalization.  But if the
insensitive mode is pervasively insensitive, (for example, if it used
uninterned strings as identifiers and used case-insensitive comparison
upon them) then sensitive mode is at a divantage.