There has been some discussion on the WG1/WG2 lists about keywords. Here, for
what it's worth, is my 2 cents' worth.

The question arose about whether keywords ought to be supported in `Thing1' and/or `Thing2'. I personally think keywords are a good thing, and have felt thus since I wrote 1401 Autocoder code back in the previous millennium. Properly used, they can make code much more readable. They aren't essential, though, and therefore have no place in Thing1.

Some well-known Scheme systems support keywords as a datatype, and others don't. Some Schemes that support keywords have Common-Lispish OPTIONAL and
KEYWORD arguments.

There is a simple way out of this mess. For Thing1, you write 'foo:, which is a symbol, i.e., (symbol? 'foo:) => #t. For Thing2, (symbol? 'foo:) still evals to #t, but there is a new predicate: (keyword? 'foo:) also evals to #t, while (keyword? 'bar) => #f.

Thus in this proposal, `keyword' and `symbol' are not different datatypes, but rather being a keyword or not is an attribute of any symbol. An inefficient implementation of keyword? could even parse the result of symbol->string, looking for wherever the colon was supposed to be.

This allows Thing2 programs to be a bit more careful in checking keyword arguments, while still not breaking ANY valid Thing1 programs. (Thing2 can choose to allow keywords to be self-evaluating, but I am aggressively of no opinion on the merits of doing so; even so, self-evaluation would still not break any valid Thing1 program.)

I would vote *AGAINST* OPTIONAL and KEYWORD lambda syntax, in my experience, there are too many nasty corner cases to handle there, and often the interactions between these are too surprising. In other words, everything I want can be achieved by adding a keyword? primitive. The merits of including keywords in WG2 amount to a more efficient implementation, and standardization, which might help some library APIs.

As for whether it should be 'foo: or ':foo or some other read/print syntax, I don't care.

-- v
_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports