[r6rs-discuss] r6rs-discuss Digest, Vol 9, Issue 1

From: Paul Schlie <schlie>
Date: Fri, 11 May 2007 05:43:22 -0400

> Matthias wrote:
>> "Biep" Durieux wrote:
>> Let Scheme remain the language that either does the right thing
>> or defers a final decision.
> ..
> Short: Pascal's answer is spiritually close to what I think.
>
> Long: My own journey may suggest why this purist view is plain wrong.

Re-Ordered:

> Second insight: There is no such thing as "the right thing."

- If there was agreement on the principle, then agreement/deferral
  on specifics should be much easer. As, if it were agreed that in
  principle the specification of scheme should ideally be as simple,
  concise, consistent, and deterministic as necessary to enable the
  further extension of the same through the use of modular libraries,
  but no more; agreement on it's core specification should be more
  easily attained, as then any disagreement on further restrictions
  may be simply deferred (presuming the current core specification
  was not itself already deemed too unnecessarily restrictive to
  enable the same).

  (which was what I though was the goal of R6RS)

> First insight: Scheme is _not_ a programming language.

 - Arguably syntax and semantics more strongly specify a language
   than the words in its then current dictionary.

> Third insight: In light of the first two, the Scheme
> report can either play the role of a marketing and
> branding tool (3-5) or help us eliminate some
> differences between implementation (i.e., making
> portability somewhat easier than it is now).
> ..
> Now the various members of the Scheme family of languages
> are far apart. We can either compromise and get things to
> grow together in the sense of portability, the best
> operational measure of "togetherness" or we can give
> up and just write another marketing tool with little
> meaning for the various extensions.

- My perceptions on scheme's attraction and value lay principally
  in the extensible flexibility of it's relatively minimalist
  core specification; thereby any attempt to transform it into
  yet another more conventional language is the precisely wrong
  direction in attempt to improve it's marketability.

  However, refinements which further consistently improve it's
  deterministic portable extensibility and thereby broaden its
  applicability to potentially unforeseen application, make
  imminent sense.

  Thereby had personally hoped for the specification of:
  - a modular library facility.
  - dynamic exception handling facility.
  - simplified/refined numeric tower, extendable through a combined
    use of modular library and dynamic exception handing facilities.
  - order of evaluation (as it helps improve portability and sacrifices
    nothing in the process; as an unspecified evaluation order is
    valueless to everyone other those who may wish to claim a particular
    implementation is conformant, although it yields differing results
    than some other equally conformant implementation).
  - Unicode text library (as I don't believe Unicode belongs in the
    core language, nor that scheme programs should be allowed to be
    formulated from anything other than the ASCII character alphabet
    as this restriction helps keep the core language implementation
    simple and encourages the development of more uniformly legible
    source code, as opposed to programs utilizing arbitrary alphabets).
Received on Fri May 11 2007 - 05:43:22 UTC