Final draft of R7RS – small Scheme standard(lists.scheme-reports.org)
lists.scheme-reports.org
Final draft of R7RS – small Scheme standard
http://lists.scheme-reports.org/pipermail/scheme-reports/2013-July/003660.html
7 comments
you may also want to see john cowan's presentation on R7RS-small last year to LispNYC: https://vimeo.com/29391029
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.
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:
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:
#-(or openmcl mcl sbcl cmu scl clisp lispworks ecl allegro cormanlisp abcl)
(error "Sorry, this Lisp is not yet supported. Patches welcome!")
...
(#+openmcl (:file "cffi-openmcl")
#+mcl (:file "cffi-mcl")
#+sbcl (:file "cffi-sbcl")
#+cmu (:file "cffi-cmucl")
#+scl (:file "cffi-scl")
#+clisp (:file "cffi-clisp")
--cffi.asd
(cond-expand
(chicken load-foreign-library)
(racket get-ffi-lib)
...)
Does anyone have any idea what the overall plan for Scheme is?
From what I understand R7RS small is aimed at being closer to R5RS while avoiding the controversial things introduced by R6RS.
But what about R7RS large? What are the overall aims of that? Has that been decided yet?
From what I understand R7RS small is aimed at being closer to R5RS while avoiding the controversial things introduced by R6RS.
But what about R7RS large? What are the overall aims of that? Has that been decided yet?
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.
[1] - https://news.ycombinator.com/item?id=6000829
[1] - https://news.ycombinator.com/item?id=6000829
Is anyone here planning an implementation ?
Here's my hobbyist, incomplete implementation:
https://github.com/cslarsen/mickey-scheme
There is also the much more robust Chibi Scheme that implements all of R7RS.
There is also the much more robust Chibi Scheme that implements all of R7RS.
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.
The goal of the R7 is to avoid this. You could read the article and the spec before saying sneaky comments like this.
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.
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.
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?
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).
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).
Can someone sum up the major changes?
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".
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".
This is very exciting!