[ERR5RS] idioms for flagging case-(in)sensitivity

[William Clinger]

I am moving this conversation to the mailing
list from
http://scheme-punks.org/wiki/index.php?title=ERR5RS_talk:Lexical_Syntax
because the indentation was getting out of hand,
and we need to get more people involved in this
conversation anyway.

Alan Watson wrote:

> Perhaps I am wrong, but the sense I get from
> Chris Hanson's original suggestion cited above
> is that he was most concerned with
> case-sensitivity in programs rather than data.

That's true.  Almost everyone who has weighed in
on this topic has been more concerned about
programs than data.  Data present the more
fundamental problem, however.

> Perhaps I have not explained myself clearly
> enough.

I understood you well enough, but I will repeat
your suggestions for others to read.  As for
myself, I was mainly waiting for you to present
a concrete proposal on the web page at
http://scheme-punks.org/wiki/index.php?title=ERR5RS:Lexical_Syntax

> I am suggesting: (a) including the flags in
> the reader and having them correspond to
> values (as in your suggestion); (b) not having
> them produce side effects on ports or the
> reader; (c) requiring that their presence at
> the top level in programs produce an observed
> behaviour compatible with the appendix to the
> R6RS; and (d) having a pair of procedures that
> take a port and cause it to be case-sensitive
> or case-insensitive (or some equivalent
> interface).

(a) won't do any good unless you say more about
the values of those flags.  (b) is ambiguous: do
you mean the flags would not be required to have
side effects, or do you mean the flags would be
required not to have side effects?  (c) is
pretty hard to achieve, since the very same file
can be read as program or as data.  (d) would be
easy for me to implement, but I suspect that
some other implementors would prefer not to
implement both the R6RS semantics and an
entirely separate ERR5RS semantics.

> This has useful compatibility with the
> appendix to the R6RS, but does not require
> that the flags be comments or have a special
> significance to the reader, does not require
> datum comments, and allows one, if one so
> desires, to write a reader that is completely
> compatible with the appendix to the R6RS.

Neither your proposal nor mine is completely
compatible with R6RS non-normative appendix B.
In my opinion, my proposal is more compatible
with that appendix than yours.  As for why you
think differently, I suspect you forgot that the
same file can be read as program or as data, or
perhaps you are using "completely compatible
with" to mean "completely compatible with a
small proper subset of".

> [Alan's proposal] has the disadvantage that
> for standard use the programmer must know
> whether the data should be read in a
> case-sensitive or case-insensitive manner (and
> convert the port appropriately), but I think
> this will apply in most cases

The whole point is to have the data itself
describe whether it wants to be read
case-sensitively or insensitively.  If we didn't
want that, then we'd just have two different
read (or get-datum) procedures.

> and, as I have mentioned, it is possible to
> implement a fully-compatible reader if
> necessary.

I don't think it is possible to implement a
single reader that is fully compatible with both
your proposal and non-normative appendix B.  All
you mean is that it is possible to implement a
reader that is fully compatible with your
proposal but incompatible with non-normative
appendix B, and it is also possible to implement
a reader that is fully compatible with appendix
B but not with your proposal.

> I think this suggestion covers the most common
> cases simply and elegantly but allows for
> generality. It can be criticized because it is
> not completely compatible with the appendix to
> the R6RS, but the other suggestions are also
> incompatible.

After the "fully-compatible" claim, you admit
"it is not completely compatible".

Will



      ____________________________________________________________________________________
Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.  http://overview.mail.yahoo.com/