[r6rs-discuss] #!fold-case and #!no-fold-case

From: William D Clinger <will>
Date: Tue, 26 Jun 2007 19:20:44 -0400

Alan Watson wrote:

> Would it be worth having #!r6rs return a value? Perhaps an unspecified
> value? Perhaps the symbol whose spelling is #!r6rs? (Note that this
> symbol need not be an identifier.)

Yes! Perhaps. Perhaps again, although I don't see why the
R6RS should care.

> I have to wonder if #!fold-case and #!no-fold-case would not be better
> replaced by appropriate R5.91RS-like declarations. The scope would be
> clearer.

The problem is that #!fold-case and #!no-fold-case affect
the lexical syntax, which means they have to be detected
and acted upon during the read phase, which normally comes
before the macro-expansion phase that would be the first
to see the declarations. By the time macro-expansion gets
under way, it's too late for a #!no-fold-case to undo the
effect of a #!fold-case. (It might not be too late for
#!fold-case, but both need to work.)

> We could also preserve readability by making #!fold-case and its friend
> evaluate to something.

Yes! Again, I don't think the non-binding appendix has
any reason to care. For that matter, the non-binding
appendix has no authority prevent them from evaluating
to something, so #!fold-case and #!no-fold-case aren't
really as much of a problem as #!r6rs.

> > I don't know quite what to do with #!no-fold-case when
> > presented with symbols such as
> >
> > Pi\x3bb;\x39b;\x3c3;
>
> I think you mean that don't know what to do with #!fold-case when
> presented with this symbol.

Yes, thank you.

> I suspect that #!fold-case is largely about getting pre-R6RS source to
> work in an R6RS implementation. Therefore, I would feel happy if it only
> dealt with ASCII symbols that do not contain hex escapes, since
> non-ASCII symbols or symbols with hex escapes were non-standard anyway.

Agreed. That's the answer I was hoping to hear. We'll
see whether anyone disagrees with it.

Will
Received on Tue Jun 26 2007 - 19:20:44 UTC

This archive was generated by hypermail 2.3.0 : Wed Oct 23 2024 - 09:15:01 UTC