• Home
• All tickets
• All wiki pages

Source for wiki CaseSensitivityArcfide version 9

author

arcfide

comment

ipnr

99.31.12.26

name

CaseSensitivityArcfide

readonly

0

text

= Aaron W. Hsu's View on Case Sensitivity in Working Groups 1 & 2 =

== Problems ==

  * Scheme implementations always take their own approach to case-folding in that they choose one or the other, and don't care about the standard
  * Case behavior is excessively religious and emotional
  * We have two precedences, one R6RS and one R5RS, in standards for doing different case behavior
  * In the presence of different character sets and traditions, certain case behaviors are more prevalent
  * The solution to the behavior must be compatible both in Scheme Core and Scheme 7

== Proposed Solution ==

  * (Scheme Core) Case behavior by default is implementation dependent
  * (Scheme Core) Implementations must implement both case folding and case preserving modes
  * (Scheme Core) Implementations must recognize the flags `#!fold-case` and `#!no-fold-case`
  * (Scheme Core) Support the `||` case-preserving reader syntax, but do not have them delimit atoms
  * (Scheme Core) Implementations must recognize the parameter `case-sensitive` values `#t` and `#f`
  * (Scheme Core) The module system should provide some means for controlling case sensitivity at a suitable level of granularity
  * If the character set used by a Scheme implementation is Unicode, then the official Unicode case folding algorithm should be used

== Clarifications ==

The use of parameters in Scheme Core would affect any procedures called that make use of the reader. Specifically `read` would be sensitive to such parameters.

== Rationale ==

I would like to avoid creation of "compatibility" layers in Scheme implementations that intend to break the default case sensitivity defaults. Since most code that needs to run or most legacy code that is important can be counted on to still run under their same implementations in this proposal, this actually improves the conformance and maintains a large body of backwards compatible source code without requiring modification. Such source code can easily be moved to systems with different defaults by using flags or modules. This is no more difficult than requiring special encantations in the target Scheme implementation. It is also standardized, so the user can easily make a library entirely portable in this regard by either using a flag or providing a module. Doing so is superior to requiring each implementation to have a unique encantation for calling the code with the correct behavior. 

The use of a parameter allows for much nicer interactions with the reader at a Scheme Core level without complicating the semantics. It also means that you have more control at run-time of the reader without making this more complex. It permits an acceptable level of control in Scheme Core, while scaling up to phasing levels and procedural macros in Scheme 7. 

== Issues ==

Should `case-sensitive` interact with the flags? That is, if a reader or load call encounters a flag, should the parameter be altered? Should the parameter's value be altered only in the call or should it persist?

  At the moment I am inclined to think that it is okay for the two to interact, and probably a good thing, provided that the extent of that interaction remains limited by the call. That is, the value of the parameter should be reset to the incoming value on return. This is because the scope of that flag should only extend to the end of the file, and should not have an effect on continuing computation in the environment that made the call.

== Endorsements ==

John Cowan endorses this page, with the following exceptions:

 * The proposal for Scheme 7 is premature
 * The parameter should be named "fold-case"
 * The Unicode folding algorithm should be used whether the Scheme is Unicode-based or not, as there are no folding algorithms for other coded character sets and it's trivial to subset the Unicode one.

time

2010-02-14 06:14:31

version

9