Wednesday, August 08, 2007

My Vote: Yes On R6RS

I've been debating if it's appropriate to blog my reasoning for my vote yesterday morning on the latest Scheme standard. My decision was finally tipped by Will Farr, who did just this. As far as I can tell, nothing terrible has happened. (Right Will?)

I voted Yes. My comment, though not needed, was:

While there are some aspects of R5.97RS that I'm uncomfortable with, I think it's an overall step in the right direction. I'm confident that time will tell which aspects of the report need to be corrected, and that this will be done for R7RS.

Pretty cheesy, but what do you want for a message composed at 5:30am?

Overall, the standard is really good. I love that Unicode, syntax-case, libraries, byte level access and many other goodies were added. My first thought, like others, was that the core spec was too long, but after looking through it, I really don't think it is. Sure, the page count might be a bit high, but the core spec doesn't appear to have any obvious fluff to me.

So, what did I mean by aspects of R5.97RS that I'm uncomfortable with? Two things. First, I would have preferred to skinny down the standard library part of the report of the report. I would have been more comfortable with making chunks of it various SRFIs.

Currently, SRFIs provide libraries for lists, strings and dates. Why can't that same approach work for records, hashtables, and enumerations?

This strikes me as important because I'd like to see the standard stay as small as possible, and at the same time continue to grow the set of existing SRFIs. I think this is a real issue, because, as Java has shown, there's no limit to how large your standard library can grow. What happens when we want to add in stacks, queues, or more threading support? Does that go into the R7RS, or SRFIs?

The other point that was nagging me was that libraries aren't composable. I've come to really like Chez Scheme Modules, which provide basic control over namespace, yet can be composed together in interesting ways to provide more functionality. It seems more appropriate to provide a low-level, general purpose, feature like modules in the spec to me, rather than the heavier-weight library system.

After asking around, I learned that I'm essentially asking for are local libraries. Here's what the rationale document has to say on that topic:

Moreover it is debatable whether a top-level library should be the same construct as a local module. The job of the library system is to organize the top-level namespace, and not to serve as a target for expansion of sophisticated macros. Of course, the broader roles and syntactic similarity of module and library suggest merging the concepts, but merging the concepts further broadens the role of each. Such generalization may seem intuitively right to Scheme programmers, but all attempts by the editors at such broadening led away from consensus rather than toward it.

In other words, the drafters of the standard and I are on the same page - they just couldn't find a way to make it work. These are very smart folks, if they say they can't figure out a way to merge the concepts, then I believe them.

I'm pretty confident that by the time R7RS comes out, we'll either have figured out the solution to this problem, or will have decided that it's a non-problem altogether.

One final thought: vote yes, vote no, but whatever you do, just vote. Your vote is due Sunday, so get it in.

No comments:

Post a Comment

LinkWithin

Related Posts with Thumbnails