I'm new to LISP (only a little over a year) but I already feel the same way about R*RS as I do about ANSI SQL: You'd be crazy to target it instead of making the most of the runtime you've chosen.
Has anyone here ever deployed to multiple runtimes? Why did you do it? I'm curious.
E.g. libraries that can be implemented in pure Scheme should arguably target R*RS rather than any particular implementation, to save on reimplementation efforts.
Since RnRS doesn't prescribe any graphics library procedures, or any foreign function interface that could be used to link to C libraries, it is impossible to write a pure RnRS program that draws to the screen. (Likewise if you replace "graphics" with "audio", "GPU operations", or anything else that isn't provided by the standard.)
If you want to write a graphical program in Scheme, you must work with a particular implementation. Either one that provides a graphics library itself, or one that provides a foreign function interface, which you use to load a C graphics library. If you want your program to run on multiple implementations, then it must somehow use implementation X's FFI when running on implementation X, but use implementation Y's FFI when running on implementation Y. (Either that, or you use a uniform interface to someone's "multi-platform FFI" library, which itself will run different code depending on what implementation it's on.)
Therefore, if you hope to write multi-platform code, your code or a library you use must detect what implementation it's on, and execute different code depending. Ideally, it would even execute code that says "Sorry, don't know about this implementation's FFI" when appropriate.
Incidentally, Common Lisp provides the #+ and #- notations, which provide for code that runs conditionally on whether the implementation defines a certain symbol. And incidentally, there is a Common Lisp "Common Foreign Function Interface" library that works in exactly this way:
As it happens, a new item in R7RS-small is "cond-expand", which is equivalent to #+ and #-. Implementations will probably provide their own names as a feature. Thus, you could write multiple-platform FFI code that looked something like this...
So, as of now, it would be possible for someone to write a multi-platform Scheme FFI library, which would use standard features of R7RS to select the correct interfaces to foreign libraries on supported Scheme implementations, and would gracefully error out on unsupported R7RS Scheme implementations. Then you could use this to write R7RS code that did graphical stuff and would work on multiple implementations. I don't know of anyone who has done this so far. (There are multiple-platform graphics programs written in Common Lisp that use CFFI; they can generally be installed with Quicklisp. This appears to show proof of concept.)
My understanding is that would be R8RS, and would be a continuation of R6RS. They seem to be doing the tick tock sort of model of alternating focuses for "releases".
Thanks - in fact bgruber's video link above [1] about R7RS-small also includes a section about R7RS-large too. I hadn't seen the video when I asked my question.
Basically another working group will work out the details at a later date and it will be much larger - about 80 packages and probably bigger than Common Lisp according to the video.
It is the Scmeme way: You'll quickly see half a dozen of different and incompatible implementations, but not a single newsworthy project on top of them. And soon after that, they will get bored and start yet another cycle of speciation.
It was R6's goal also. But it didnt accomplish the stated goal but just introduced more incompatibility into the overall Scheme ecosystem. But instead letting all implementations at least get up to R6, they now have R7 on the horizon. They afre churning standards out more quickly as implementors can implement them.
And frankly, I dont see what the point will be: R7 small is not much differrent than R5, so it is kind of pointless. R7 big is as big as common lisp, and very few implementations will have the resources and the willingness to implement it and discard their current non-standard APIs they had for years. And even if the majority of them manages to implement R7, they will finally reach the point where Common LIsp was 1994, with no added value over Common Lisp, provided of course they dont decide to obsolete R7 also and get to R8 before that.
So R6 is bad because it's a big departure from R5 but R7-small is bad because it doesn't change much?
The point of R7 is to make it is easy for implementation to upgrade from R5 after the controversial R6.
Ideally, most of the libraries in R7-big will be able to be written mostly in R7-small. If they are smart, they'll make a R7-big FFI library, and then every other library can be written in R7 + C.
This means an implementation would only need to implement R7-small and would get all the libraries of R7-big for free.
Can someone familiar with the process explain where this lies in the standardization process?
Does "final draft" mean this is the official R7RS-small standard, does it mean this is the final text being sent to the steering committee for endorsement, or does it mean something else entirely?
this is the final text being sent to the steering committee for endorsement
I think that is correct. The Working Group had put up draft 9 for public vote, which (narrowly) made the 85% ratification requirement set by their charter. There was a final objection made by Gerald Jay Sussman, whose opinion carries a lot of weight when it comes to Scheme... The WG voted unanimously for a change that addressed his concerns, and the Steering Committee approved the making of this change, after which we had this tenth draft. I do believe the WG is done with it. Therefore it seems basically set in stone, unless the Steering Committee edits it, which seems to me outside the scope of what they do (although I don't feel I completely understand how this works).
There is a "Language Changes" section beginning on page 77 of the PDF. R7RS-small should be considered mostly as building upon R5RS. Some potentially major changes include the introduction of a record system (user-defined types--basically structs), bytevectors, parameters (variables with dynamic scope), an enshrining of Unicode (implementations don't have to provide all of it--they can even be just ASCII--but what subset they provide must be Unicode-compatible), and a library system (you can define a library that "export"s a specific set of identifiers, and you can "import" identifiers from a library, optionally renaming individual ones or prefixing them all).
There are also various fairly minor changes, such as giving "log" an optional second argument (being the base of the logarithm), requiring "write" to handle circular data structures, adding "when" and "unless" macros, and adding some utilities like "file-exists?", "delete-file", "get-environment-variable", and "command-line".
Don't think of 7 as being after 6. It is more of a continuation of 5, a smaller standard with fewer bells and whistles. Due to this, a summary of major changes may not be appropriate.
