On 14-Apr-06, at 10:31 PM, bear wrote:

> Here's the thing; I don't think keywords express anything that
> isn't expressed by an existing type.  Their value is in the
> gray area of *limiting* what you can do with some set of symbols.
> And the philosophical arguments around that are kinda murky -
> especially in a language like scheme, which demonstrates
> the power of *removing* such arbitrary limitations wherever
> possible.
>
> If we think that a variable being immutably bound to a
> particular value, and un-shadowable with a variable of the
> same name and different binding, is a good idea, then we
> should be talking about the new ideas generally - immutable,
> global and unshadowable bindings - not about a particular
> application of them as keywords.

But keywords are not variables.  They are constants.  Just like 123,
"hello" and #\space.  They are (should be) syntactically
distinguished from variables.

Regarding minimality, why didn't Scheme avoid the string type and
simply use vectors of characters?  Actually why not just use lists of
characters like in other languages?  For that matter, ``strings'' and
``symbols'' could have been the same type (either by making strings
immutable, or making symbols mutable, replacing eq? with equal?).  Of
course we could just do away with all of these types and encode
everything with bignums (I won't go as far as encoding everything
with functions, that would be too extreme).  Why does Scheme have
"list" in addition to "cons", "cddr" in addition to "cdr"?  A
practical language cannot be minimal.  Every step away from absolute
minimality must be made with consideration for the benefits.

Let's be realistic.  We are talking about a minor tweak in the symbol
syntax.  The R6RS committee is soon going to make some much bigger
changes in the symbol syntax and other aspects of the lexical
syntax.  So if there is a good time to consider changing the syntax
to allow keywords it is now.  In my 25 years of Scheme programming
the only case I have seen of a variable with a trailing colon is in a
withdrawn part of SRFI 1, so in practice this non-conformity will
have very little impact.

My feeling is that the colon character does not belong in symbols
anyway (either in the middle or at the end).  It should be reserved
as an infix operator to denote a qualified reference to a module
(i.e. foo:bar should mean the thing called bar in the module foo).
Many programming languages use such a notation, and in fact many
Scheme programs use this notation for their own 90%-solution modules.

Marc