I think the main point here is that keywords args are about convenience
in programming-in-the-large situations where we can't spend a lot of
time to carefully plan every detail.
+1
The main disagreement is about
whether the language should exhort people to go ahead and plan anyway
If we don't standardize keywords somehow, we will get exactly what we have now, a whole bunch of trivially different ways to do the same thing. (Arguably Racket and Kawa are non-trivially different.)
While I strongly agree that too much focus on convenience is detrimental
to good programming, I think convenience is essential to
programming-in-the-large.
And indeed to scripting.
> In fact, we can leave SRFI 177 can be underspecified, and this
> may be a good idea. For example, we may leave it open (at least for the
> time being) whether SRFI 177 keyword "procedures" are actual procedures
> or just macros.
By making them procedures, we allow them to be invoked as procedures with all keyword arguments set to #f. That's a very important feature to me. Macros are second-class in Scheme and deliberately so; we should use our first-class facility of procedural abstraction as much as possible. That's why we have call/cc instead of the R0RS syntax (catch procname . body), which in modern terms is (call/cc
The thing is, conflicting keyword can be either a problem or a solution
depending on what you want. There may be cases where someone's problem
is that keyword that look identical behave differently.
In particular, keyword parallelism between similar procedures is often a good thing. CL has gobs of procedures with keys like :test.
In my personal opinion, Racket is a good lesson for Scheme at large. I
find many aspects of it are simply too complex (keyword-apply, pathname
objects, the way immutable and mutable datatypes have incompatible APIs)
Alas, the last can't be avoided. The Liskov Substitution Principle tells us that mutable and immutable varieties of a particular kind of object have no type relationship. Trivial incompatibilities like immutable pairs not having the same standard procedures as mutable pairs can be fixed, but not the fact that we need either mutable only or both mutable and immutable pairs. We can't just, by adjusting the imports, replace mutable pairs with immutable pairs. In particular, rest lists will break, as I found out when I mechanically converted the code of SRFI 1 to its immutable equivalent.
I would be fine with having `:foo` read as a keyword object in standard
Scheme like it is in Common Lisp. Then the hack wouldn't be needed.
And this is where the Right Thing conflicts with the R7RS-large charter. R7RS-large *has* to be a superset of R7RS-small, which means the decisions made there cannot be rethought. If there is to be a distinction between mutable pairs and immutable ones, car and cdr have to be mutable and something else (icar and icdr) have to be used for the mutable case.
That's why I *can* incorporate SRFI 117 into R7RS-large, because it is backward compatible, and why I *can't* incorporate SRFI 140, admirable though it is. R7RS-small defines the value of (string-set! (string-upcase "foo") 0 #\G) as "GOO", not an error.
Maybe hash-table SRFIs are a good point of comparison here. SRFI 69 is
nice and simple; its successors can do more, but most of the time you
only need the basics.
Which is why SRFI 125 is downward compatible with it, even with the annoying parts of 69 that are deprecated in 125.
I would advise against this on PR grounds. With R6RS and R7RS, Scheme is
already a bit confusing to outsiders. If another standard was added (for
any reason - even if it makes sense from a technical point of view) it
will make Scheme's public image more confusing and may decrease morale
for insiders.
+1
What would boost morale the most is to come to an agreement on
fundamental issues like keywords and strings, and ship R7RS-large using
them. John seems to share this opinion, and is doing an excellent job
juggling these conflicting demands.
We aren't going to have consensus. The point of doing the Red and Tangerine Editions first is that they were safe, portable, and helped build trust in the process, so that people won't bail completely if their favorite features are shot down.
To the extent that compromises need to be made, I would opt to add
further delay in shipping R7RS-large until we get it right.
On the other hand, I'd like to see it while I'm still alive, if possible.
if we get keywords,
strings and immutable datatypes sorted, probably the rest of the
language will be easier.
Ha. These are the *easiest* hard problems, I fear.
He played King Lear as though someone had played the ace.
--Eugene Field