The Things I don’t like about Scheme
Scheme is my favorite language so this list is very short.
- (set! car 0)
- lack of efficient access to native arithmetic, including the carry logic.
- Lack of efficient synergy
- Continuations are reusable.
Despite this trick
- dynamic-wind
- multiple values
I am aware that some implementations have managed somehow to prevent (set! car 0) but only for the primitive values.
I have a proposal to solve the problem but perhaps Jonathan Rees’ Scheme48 is a better fix.
These common language extensions provide most of what I want for access to binary arithmetic foundations.
For the last three features I would like to see a program that uses them that cannot be improved by removing the feature.
Here are a few harmless constructs that I find no need for:
- define other than at top level of REPL.
- While I use used macros in several languages, I have not seen a compelling use for Scheme macros.
Scheme without macros already affords all of expressiveness that I have gained from macros in other languages.
Perhaps certain problem domains might benefit from macros but I am not yet convinced.
Here is a candidate.
This is not exactly a complaint but the following problem might be fixed by language design.
As I develop Scheme code I define many values at the top level.
This style is presumably convenient to those who would like to explore my programs.
This style of program is contrary to another pattern of which I am fond—limiting the scope of definition to those areas where it is needed.
The members of my repository somewhat overcome this tension.