brian_jaress ([info]brian_jaress) wrote,
@ 2007-08-12 15:40:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Current mood: numb
Entry tags:r6rs, scheme

Why I Voted No

Today I sent in my ballot on r6rs ratification. I voted no, and decided to also post the explanation required on the ballot here. Rather than simply copy and paste in the S-expression ballot, I edited this into a format better suited to a website. I also changed the mailing list links to point to the specific message rather than the whole thread. The words are the same:

Although my initial impression of the draft was mildly positive, after looking it over more thoroughly I am voting against ratification. My vote is based on my overall impression of the draft, but here are some illustrative examples of particular things I don't like about it:

Fist, the problem of two record systems that don't quite work together. This was raised by Will Clinger, most recently in his essay "Fixing the Syntactic Record Layer."

Second, the fact that you cannot simply take a record value and access one of its fields by name. I explained my problem with that on the mailing list. None of the explanations given for this in the rationale, the mailing list, or the srfi discussions satisfy me. (And the only direct reply seemed to misunderstand the example -- we want a container that requires certain behavior of the values it contains while not requiring that they be on an approved list or inherit from the same ancestor. Importing the accessors of each type of value we wish to contain makes the container's import list the approved list.)

Third, the condition system with its simple conditions and compound conditions. After reading through this part of the specification and disliking it, I found a reasonable counterproposal on the mailing list. It was rejected with a statement that it conflicted with other decisions of the editors and did not appear to be different in any other way. (It is, however quite different. It makes all condition types record types, eliminating the need for almost everything in section 7.2, and it makes it much easier to handle an exception by supplementing the condition with more information and re-raising it.)

Those three are just illustrative examples. I am casting my vote based on my overall impression of r5.97rs: Too many things in the draft are designed primarily to work around limitations imposed by other things in the draft.

The explanation of the condition system in particular helped me crystallize what I had felt while reading the draft. It was yet another explanation of the form "We must do X because we have decided to do Y and Z." Meanwhile, Y and Z are required by W, which is required by P and Q, which we need because we have X and Y. The editors are happy to explain each feature by pointing to the features that require it (or at least conflict with every alternative they are aware of) but don't seem to have considered the glaring possibility that all are bad and that this is why they are mutually forcing each other into a series of workarounds.

The introduction to the draft still begins with, "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary." I feel I understand that principle much better now that I have seen r5.97rs itself violate it. If you start by planning to add lots of features, add them in ways that introduce weaknesses and restrictions, then refuse to remove or replace any of your additions as a way of repairing the damage, you end up with a mess that piles workaround on top of workaround and calls them features.


(Post a new comment)

(Screened Post)
Re: thank you!
[info]brian_jaress
2007-08-15 07:28 am UTC (link)

As far as I know, Livejournal doesn't give me a way to delete individual lines. If you'd like, I can delete the whole comment, but that seems like a shame. (Maybe someone can point out an LJ feature I overlooked?)

I mostly use scsh but sometimes Stalin or another compiler -- usually for sysadmin scripts or data processing.

One thing I like about the SRFI process is that each one is optional. That makes it a lot easier to make a bash script alternative like scsh or an ECMAScript alternative like Guile that's a real Scheme. Lynn Winebarger sent a great explanation to the mailing list where she wrote, "Scheme is not so much a language in the usual sense as a commitment to providing a certain kind of continuation semantics."

(Reply to this)(Parent)(Thread)
Re: thank you!
(Anonymous)
2007-08-20 04:02 am UTC (link)
hm, i can repost without the personal data if that would be preferable. i like scsh a lot, but outgrew guile ages ago. i do wish that mr shivers would turn the SREs into an srfi, but hes never responded to my mails on the subject. (his srfis tend to be the best, in terms of usefulness, acceptance, and clarity.) i somewhat disagree with ms winebarger's comment, but agree entirely with its spirit (and the entire rest of the post, as i recall it). i have a question for you, however. given that r6rs is worse than useless, but also given the divergence in dialects, what minimal libraries/features do you think would be required to allow for crosscompatibility without destroying the language or its spirit? thanks!

-elf

(Reply to this)(Parent)(Thread)
Re: thank you!
[info]brian_jaress
2007-08-21 08:06 am UTC (link)

OK, I've "screened" the original comment, which should mean that only I can see it. Sorry it sort of hung out there for a while. No need to repost it unless you want to.

I really don't know what the minimum for compatibility should be. I think part of the problem is that you're breaking the essence of the language if you try to achieve it using a required feature list -- any list long enough to give real-world compatibility would be too long and restrictive.

But here are a couple of ideas I pulled out of my hat just now:

  • Establish "levels" like they have for Java, so Scheme would be rnrs and SchemeEE would have that plus an officially blessed set of srfis.

  • Lay down some principles and primitives for extensibility (how to request extensions by name, how to package them for distribution, how to avoid clashes and duplication, etc.) then separately update the srfis to use that system.

If you did both of those, you'd have turn-key compatibility between the "enterprise" Schemes and compatibility via bundling the dependencies for Schemes in general.

(Reply to this)(Parent)(Thread)
Re: thank you!
(Anonymous)
2007-08-21 11:54 am UTC (link)
heh, i just read this after responding to mr wright's comments on my comments. you phrased things above better than i did in my responses. i should start looking here first :) (thank you for your response there, as well.)
i obviously agree that specifying a huge required-feature list is Bad.
if i understood what you said above correctly, suggestion 1 is a subset of suggestion 2, in the sense that with #2 in place, #1 becomes an extension loading a standard other set of extensions.
are you familiar with srfis 0, 7, and 55? if these could be merged together, cleaned, and generalised, it would form a strong basis for implementing most of #2 (as well as module systems). personally, i'm in favour of a CSAN project or something similar as well as the srfi's, for both sharing code and libraries that aren't necessarily general/universal but might still be useful to others, and as a means of exploring and tuning srfis (by enabling people to see multiple means of doing the same task and being able to find the best one and why). (i also think that the only good thing to come out of perl thus far is CPAN.... the idea and implementation are both sound.) many implementations already have extensive library and library-installation systems (chicken, guile, gauche, plt, scsh, etc... plus slib, of course), and it would be great if these were more generally available.
another interesting aid-to-compatibility that ive been thinking on a lot recently is a standardised meta-ffi or reverse-meta-ffi. such a thing would not define cross-representation between scheme and language N, but rather would define the syntax of defining such representations. this would theoretically allow for a level of binary crosscompatibility (as well as significantly improving the reference implementations for srfis).
for real-world apps, the most annoying lack-of-standards (srfis included) for me is no standard regexps and no standard network procs. its rare for me to need more than r5rs plus srfi1 (list lib), srfi13 (string lib), srfi43 (vector lib), some means of errors/conditions, some means of printing, light threads, and the above two (although i would use arrays as well if they were cleaner). binary io is nice too, although rarely necessary (cause read-char works just fine, thank you). :)
thoughts?

-elf

ps. thanks, btw, for keeping this thread alive. its unfortunately rare for me to be able to discuss scheme seriously with people, and its massively enjoyable. thanks!

(Reply to this)(Parent)

Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…