Scheme has traditionally had a minimalist philosophy about the language itself. Basically, the language defines only very low-level syntax and operations -- think arithmetic, variable and function definition, basic control flow, etc. It was then up to libraries to add additional functionality.

R7RS small maintains this same mentality. R7RS big is basically R7RS small with a large standard library.

And as political background, this is basically the "we'll offer both options" resolution to the R6RS acrimony. R6RS tried to take the language in a more "batteries included" direction, which led to a lot of resistance from some quarters, and was part of why Racket ended up disclaiming itself as being a Scheme and going in its own direction (the Racket team was quite involved in R6RS, and I believe stung by the way it was essentially rejected by a big part of the Scheme community). R7RS-small is sort of a spiritual successor to R5RS, and R7RS-large is trying to carry on what R6RS attempted, but in a way that can be factored out of R7RS-small and used to complement it.

The problem people have been trying to work through is that many people like a small, clean, minimalist core Scheme, but many other people (well, some are the same people, myself included) don't think the current standard is enough to produce useful interoperability. Especially implementors like being able to write small self-hosted experimental or embedded Schemes without a large standard. But many people writing Scheme code are not all that happy about the poor interoperability story that ends up resulting, because there is not quite enough standardized to write libraries that will work on all the major schemes, which is why there's no Scheme equivalent of CL's Quicklisp repository of cross-implementation libraries (the SFRI system is the only real attempt to make this sort-of happen, and is not really good enough).

Thanks so much for your very detailed explanation! With interop, do you mean FFI?

For R7RS-large, are there plans for a module standard?

Maybe interop isn't quite the right term. I meant being able to write portable Scheme code, something that can run on, say, both Guile and Bigloo. The current standard leaves so much undefined that most practical Scheme code is nonportable.

Well said.

And yet, R7RS-large _still_ will not have a standardized FFI.

You actually CAN'T have a standard FFI, without having a blessed implementation, as so much of FFI is implementation specific. Besides, it would force FFIs in scheme to do The Right Thing to handle continuations (many don't). And call/cc is expensive enough as it is.

There are many languages without blessed implementations that define ways to interoperate with other languages. For instance: C++[0], Haskell[1], Java[2], Common Lisp[3], and others[4]. The FFI needn't describe how Scheme structures should behave, it need only describe how to send and receive data that a foreign library can interpret; IE, C data structures.

0: http://en.cppreference.com/w/cpp/language/language_linkage

1: https://www.haskell.org/onlinereport/haskell2010/haskellch8....

2: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/

3: https://common-lisp.net/project/cffi/

4: https://en.wikipedia.org/wiki/Foreign_function_interface#Exa...

Alright. I didn't know. But I will say that Scheme is a particularly hard language to build an FFI for. In order to do The Right Thing, and have continuations work across language boundries, you have to integrate continuations into a system that is gleefully unaware of their existance. Depending on the design decisions made, making the FFI do The Right Thing is either impossible, or painfully expensive. So many implementations don't. The only thing RnRS could do is define as implementation inspecific an API as possible, and define any use with continuations undefined behaviour. And that would only be moderately better than not having them at all.

Why should continuations need to safely work across language boundaries? Plenty of Schemes support FFIs with the enormous warning that call/cc exists and you should be aware of that.

This solution is hugely superior to having none at all; as it means that bindings to foreign libraries may trivially be ported across many Schemes. Choosing the right Scheme will be less about what libraries are available, and more about which provides the best execution environment for your needs.

In this case, doing the right thing happens to be doing nothing more than warning the user, as is often the case. Attempting to design a system that safely captures foreign state with continuations is almost certainly an over-engineered solution.

Actually, you're right. God, what was I thinking. The only potential problem is that implementations that DO implement callcc across ffi will wind up with code that won't run on implementations that DON'T. That would be bad, but not the end of the world. The real problem is that it's unlikely such a thing would be standardized.

R7RS would have to been an extraction, because big came first. That is probably the way to do things

  1. kitchen sink
  2. extract core
  3. redefine kitchen sink as `small` + extras

R7RS-small was ratified back in July 2013, while R7RS-big still isn't ratified.

That is great news. I remember when they got announced, -big was first with -small to follow.