Hi Jason,
What you wrote reflects that you thought this through with care.
You wanted an opinion so here you go:
* Identifiers made case-sensitive.
Rationale: This makes integration with other langauges easier. Since the usual way to write Scheme is all lowercase, this should not be an issue. Many implementations already deviate from the standard in this regard.
At least all the Scheme implementations I checked have case-sensitive identifiers?
* Replacement of the macro system
This entails the removal of define-syntax, syntax-rules, let-syntax, letrec-syntax. They are replaced with define-macro and let-macro.
Rationale: R5RS's syntax-rules defines a sub-language used for hygenic and [referentially transparent] macro transformation.
The replacement removes the sub-language and replaces it with macro expanders which are written in plain Scheme code. While this puts the hygenic and referentially transparent properties on the programmer, it reduces the amount of knowledge the programmer needs and gives her more power and flexibility.
The system will provide expand-macro in order to allow inspection of the macro-expansion results.
While at its core Scheme is the making of a programming language out of lambda calculus, the macro facilities are more like a 'feature' there to provide a needed practical function, than because they'd be so scientifically or otherwise perfect they just needed to be in the language for that reason.
Define-macro and let-macro come with this enormous hygiene issue:
; [Your macro library:]
(define-macro (give-me-the-first-element-please var) `(car ,var))
; [User's code:]
(define car +) ; User's custom language!
(give-me-the-first-element-please '(1 2 3))
=> error.
Thus you can see the limited purpose of define-macro and let-macro. Of course it can work perfectly in a code base that's like a closed system, such as in Gambit's sources, and, in any code base where programming is done with this possibility in consideration.
The syntactic-closures based macro systems (syntax-rules/syntax case including define-syntax, syntax-rules, let-syntax, letrec-syntax) bring incredible complexity and with that low debuggability through a very complex identifier concept based a kind of duality of the identifier symbol in itself and the syntactic environment in which it is used in a particular instance, and brings a complex API for handling macros with this, that by nature is not Schemy and not suited for debugging.
Per came with the suggestions above based on having spent approx 6 months fulltime on developing the Black Hole module system, which does hybrid define-macro and syntactic closures expansion.
There might be some caveat I didn't get, but, I'd guess you could actually make a macro expander that supports both an alias macro system as per above and a syntactic-closures for compatibility with code that uses it, possibly by splitting expansion into two expansion phases, thus isolating all the identifier-related complexity.
Removal of do
Rationale: Use of do rather than let for looping is not typical in Scheme, and the form is hard to read.
Never used it, the presence of the ~50 lines or so it probably occupies in the evaluator and compiler never bothered me.
car and cdr replaced with pattern matching and iterators
The names car and cdr are vestigates of the PDP-11. They and their variations (such as caddr) are difficult to read and reason through. Pattern matching can be used to extract values from data structures easily and concisely, and so the language will instead offer pattern matching along the lines of this.
[..]
&
The standard procedures made generic
[..]
The point with Scheme is to provide a language in which you can do anything [at-least-somewhat-in-the-direction-of-highlevelish]. The language is not intended to be complete. It's *your* role to make it complete for your purposes.
Partially, it is put this way, because there's always some variation or improvement you could do to a pattern matching, iterator or generics system, while with the limited scope the Scheme language works with it's easy enough to get to a minimum language around which consensus can grow quite spontaneously and widely and in a way that is lasting.
Very much secondarily, there might be some performance characteristic in how generics would combine with the type system, that make them unsuitable for being a feature included by default.
I admit pattern matching, iterators and generics would be really nice to have. It is not so difficult to implement it in a given environment such as Black Hole, at all.
I didn't need it so much as for it to be worth it to implement it at all though.
You can be the one to implement it!
I'm sure many would be happy to use it, if it's experienced as really neat.
values, let-values, let*-values and call-with-values removed.
values is the tool for bringing symmetry between procedure invocation and return, and thus it is a bringer of important symmetry. Since the language is fundamentally about symmetry, I cannot see any reason for removal. Of course an implementation can implement values any way it wants to, including just as an alias for lists.
Any language or system will always contain like a design balance/equilibrium that could be described as involving an aspect of compromise. This brings a limit in suitability for some interval of purposes.
Scheme provides extensive code abstraction features, but for instance, is not exactly as heavily optimized for contemporary CPU caching as C and C++ is through their much more extensive use of structures [of structures etc.] that are focused in completely sequential RAM address intervals. Partially therefore, you might be better off implementing video codecs in C.
So the task is always yours to choose appropriate tools for a given task, in consideration of their unique characteristics.
Please feel free to share any thoughts or reflections.
Regards,