We Need An R5.1RS « It Seemed Like A Good Idea, At The Time

Blog
About

We Need An R5.1RS

January 15, 2009 at 8:49 pm | In idiocy, retracted | 11 Comments
Tags: retracted

Even Newer Edit: R6RS is decent, it’s not worth the effort to reimplement the work they’ve done.

Edit: I have, for the most part, realized that this post was an error. After a few more hours of thought, I have come to the conclusion that implementation detection and redefining the load function are tasks eminently better fitted to an external library than to a modification to the core language. While I still believe that Unicode and Unix shebangs are desirable features in the core language, enough implementations support these things that I don’t really feel the need to raise a fuss about it.

Pages: 1 2

11 Comments »

RSS feed for comments on this post. TrackBack URI

Gone are the days when the entirety of Scheme (with the possible exception of continuations, which still give me trouble) could be learned in a day or two.

This is the claim that annoys me most about people who are upset about the R6RS. The days in which ‘Scheme’ was cotermious with ‘the language used in SICP’ never existed. The original Scheme system could perhaps be understood in a couple days, but that certainly wasn’t true of R5RS. For example, just understanding the macro system of R5RS is a project of several months, if not years. As you say, continuations are also complicated, and the interaction of continuations, state and the top level is a hopeless nest of tangled interactions. Internal define is also pretty messy.

Comment by Sam TH — January 15, 2009 #
Check out ERR5RS:

http://scheme-punks.cyber-rush.org/wiki/index.php?title=ERR5RS:Charter

Comment by Grant Rettke — January 15, 2009 #
I have looked at ERR5RS, but I take issue with the way that it intends to declare a single library system. I really think that the issue should be left open for a while longer, until we see a truly successful Scheme module system take off. Until then, I believe that it’s too early to precisely define what form a Scheme library system should take.

Comment by Will Donnelly — January 15, 2009 #
How do you define success for a module system?

PLT’s and Chez’s work just fine.

Comment by Grant Rettke — January 16, 2009 #
Have you looked at SRFI-0? Feature based expansion of code is a better idea than explicitly checking the name and version of a Scheme system.

Your proposed solution of retrieving the name and version of the Scheme system in use sounds very similar to browser sniffing, which is frowned upon because it breaks your code whenever an incompatible new version of an existing system is released, or a completely new system is released. I wouldn’t say it isn’t occasionally useful in highly specific situations, but that hardly makes it worth standardising, IMHO.

Comment by Peter Bex (sjamaan) — January 16, 2009 #
Grant:

Can I install a PLT module under Chez Scheme? That’s what I mean by “success”. Anything less is a compromise that the Scheme community shouldn’t have to accept.

Peter:

I like SRFI-0, but it doesn’t do anything to allow the user to use implementation-specific extensions reliably. Specifically, the syntax definition in the SRFI says:

–> a symbol which is the name or alias of a SRFI

this implies to me that the solution will *only* apply when a SRFI has already been written for that feature set.

Besides that, I take issue with your statement that browser sniffing “breaks your code whenever an incompatible new version … is released”. This should not be true of a properly designed system, which should either degrade gracefully to a known standard featureset when it sees an unknown browser, or should very rightly give an error message if it requires a given nonstandard feature to accomplish its task.

I agree with you that such a system should not be used in every case, but that it is useful in “highly specific situations”, and I submit that this is just such a situation. The whole idea is to allow implementation-specific extensions to be safely used *before* they are standardized. If some such mechanism is not provided, how is the general mass of people to make use of them, and thereby make them popular enough to be standardized? Are we going to force them to only use one Scheme implementation, and leave the users of all the others out in the cold? Or are we to standardize on features before people have had a chance to use them in a variety of real-world situations?

It is a distasteful solution to me too, but it seems to be better than any available choices, including that of inaction. My hope would be that the task of using the information so gained would be mostly taken up by “compatibility” libraries, similar to the way that CFFI unifies the different foreign function interfaces found in Common Lisp-land.

Comment by Will Donnelly — January 16, 2009 #
Sorry about that; I got confused by Chicken’s feature system; it is based on SRFI-0, but it allows users and Chicken itself to register custom feature names that are not SRFI names. This is used for providing backwards compatibility when a procedure is moved to another library, for example, but also to select a macro implementation depending on the macro system that is loaded (syntax-case, syntactic closures, or defmacro style macros, for example).

I think this system, if properly standardized, could fulfill the need you have. It allows you to ask exactly what you want to ask: “does this system support feature X?”, instead of “is this scheme system A, B, C or D of which I happen to know they support feature X right now?”.

You say that version sniffing does not have to be a problem. But consider that now scheme system E start supporting this new feature. Does everybody now need to change their code and add system E to the list? What about a scheme system that decides to drop support for the feature in a future release? Your code will definitely not be anticipating that.
I’ve seen version sniffing break numerous times in web browsers, so I don’t trust it one bit.

Comment by Peter Bex (sjamaan) — January 17, 2009 #
I agree that, if properly standardized, a feature-based system could work. The problem is, who gets to define the features, names, and usage definitions? Once you reach that point, you may as well just have an SRFI anyway.

As an example of my point, look at the way that these different Schemes implement subprocesses:

CHICKEN:
http://chicken.wiki.br/Unit%20posix#process

PLT:
http://docs.plt-scheme.org/reference/subprocess.html#(part._.Simple_.Subprocesses)

Guile:
http://www.gnu.org/software/guile/manual/html_node/Processes.html#Processes

Scheme48:
http://groups.csail.mit.edu/mac/projects/s48/1.8/manual/manual-Z-H-10.html#node_idx_704

Chez Scheme:
http://www.scheme.com/csug7/foreign.html#./foreign:h1

STklos:
http://www.stklos.net/Doc/html/stklos-ref-4.html#Processes

You will notice that most of these implementations are similar, falling into the groups of process-launching or forking. But even among these groups, there are still subtle differences among interfaces. If I call (process “…”), what do I get back? Is it a three- or four-element list? Is it some special “process” object? And if I fork, how am I supposed to talk to the subprocess?

I couldn’t rightly justify supporting any of these solutions as the “definitive” standard over all the rest, so neither can I justify recommending such a feature system until that issue can be worked out.

Possibly some sort of “compatibility list” would be a good idea. That way, the implementor of a new Scheme could simply look out there, and if their semantics are compatible with some other Scheme (as are, for the most part, CHICKEN and Chez Scheme’s PROCESS definitions), they could simply register the feature, for example: ‘CHICKEN-PROCESS-COMPATIBLE.

I don’t pretend to have any answers here, I’m mostly just trying to think out loud through to consequences of the different choices, and hopefully get other people to think on similar lines as well.

Comment by Will Donnelly — January 17, 2009 #
I think I understand what you mean. Hacking around in applications through testing scheme versions seems like a worse solution to me than simply being unportable. Of course, you might disagree (and I’m sure you do), but I think the Right Thing to do here is propose a real SRFI.

If the end goal is to have truly portable Scheme programs, we should look into more long-term solutions. I’m very afraid that introducing a hook like this just helps maintain the status quo even more.

Comment by Peter Bex (sjamaan) — January 17, 2009 #
One way to help people think through and standardize on an approach is to work on the next standard itself, R7RS.

Comment by Grant Rettke — January 18, 2009 #
Peter:

While in principle I agree with you, in practice it seems that relying on implementations to adhere perfectly to the specifications is fraught with danger.

Have you ever tried running “(scheme-report-environment 5)” on different implementations? MzScheme, Guile, and MIT Scheme all throw errors because the procedure isn’t defined. And that’s just from R5RS, which has had a decade to be implemented.

While, arguably, MzScheme never makes any claims to R5RS compatibility, Guile and MIT Scheme certainly do, and I’m not prepared to just dismiss any of them out of hand for failing to implement a function.

But now in the absence of a decent way to get a Scheme environment, it becomes impossible to call EVAL in a portable fashion.

I think you may misunderstand me a little. I do not propose implementation detection features for the use of arbitrary applications (though undisciplined coders may use them that way), but rather to ease the creation of compatibility libraries that will allow Scheme code to be portable across implementations.

Until I can call EVAL on my top nine implementations without three of them throwing an error, I’m afraid I must still insist that some sort of detection abilities are necessary.

I do agree that we should look into long-term solutions, and I have been convinced inasmuch as I now believe we shouldn’t enshrine such a hack in a standard. Thankfully, it seems that the various unspecified bits of R5RS offer enough variation to reliably detect Scheme implementations in user code.

Comment by Will Donnelly — January 18, 2009 #