Here are some random'ish thoughts that the chatter about the new scheme standard process has triggered.
What to call it?
A humorous thread that's popped up about what to name the different flavors of Scheme. Rather than Large and Small Scheme might I suggest:
- Small Scheme and Tiny Scheme
- Small Scheme and Smaller Scheme
The emphasis being, of course, that even a complete implementation of Scheme should remain as compact as possible.
What Goes In The Small Scheme
I can see the debate about what belongs in and out of the small version of scheme is already heating up. My initial reaction was, of course it needs a module system, and I'm sure others would say the same thing about a standard record system. And on, and on, till you end up with standard nobody's quite happy with.
Thinking about it further - I'd suggest the following. Scheme has 3 fundamental abstraction building blocks: closures, macros and continuations. Want a module system? Combine closures and macros. Want exceptions? That's really just continuations and macros.
Why not focus on making these three features as absolutely strong as possible in the core, and leave it at that. Closures I think are pretty much nailed. Continuations, I'm not so sure about. And switching from syntax-rules to syntax-case seems like an absolute no-brainer.
I could also see adding some sort support for tweaking the reader. But other than that, I'd stop there.
As a sort of working demonstration of this small standard, I would publish SRFIs that demonstrated the code needed to implement the more sophisticated features of the larger scheme. For example, the larger Scheme may call for exception handling, therefore, write a module in the smaller scheme that implements this same functionality.
The Real Winners In The Debate
While there's a fair amount of debate about what belongs in the skinny standard, there hasn't been much discussion (that I've seen) about the larger standard. And perhaps that's the real benefit of this whole effort. By splitting the language into two flavors, it takes the pressure off of those who want to see Scheme grow, while still staying true to its roots.
Seeing as I actually use Scheme in my day job, and benefit from advanced features that show up in PLT-Scheme and the like, I'm glad to see a more complete scheme get standardized.
In other words: let tiny scheme be the arena for religious debates, and let small scheme be argued along pragmatic lines.
This was an interesting article. I am a Scheme newbie. Could you one day show us how Closures and Continuations can make Exceptions and Module systems. Thanks a lot.
ReplyDeleteLet me start with the disclaimer that I feel like I have a fairly shallow understanding of all things scheme. Based on what I do understand...
ReplyDeleteI think what goes in the small language is (conceptually) very simple: Any building block that the large language needs to build its features. But only the smallest number of blocks required. The small language is the primitives required to build the large language.
Now, there may be exceptions. No doubt there are a few non-primitive things that are worth putting in the small language. (Just as R5RS had some non-primitive things.) Likewise, there may be some more esoteric areas that the large language wants to address that the small language doesn't want to provide support for. But the exceptions should be few and well rationalized.
I think you nailed it. And I would really like to see some support for reader tweaking.
I tend to think that a standard FFI should be addressed in the small language, since it is a primitive with which other functionality can be added/built. I wonder, though, if that might be the one thing that is too controversial.
Robert:
ReplyDeleteFFI is an implementation feature that should not be part of the language spec; as is the reader tweaking.