Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

R7RS Scheme Progress Report

Unknown Lamer posted about 3 years ago | from the quite-the-guile-scheme dept.

Programming 47

John Cowan recently gave a talk on the progress of R7RS (slides), the next revision of the Scheme language standard, at LispNYC. After the R6RS debacle, the community stepped back and is now basing the next standard on R5RS; the work has been split into two languages — R7RS-Small and R7RS-Large. The first working group is preparing to issue a final draft of the R7RS-Small language (PDF; clocking in at 73 pages vs. R5RS's 50) within the next few weeks. Read on for a summary of the planned changes to R7RS (more or less in the order of presentation).The talk details a number of improvements over R5RS and R6RS, and is divided into two portions. The majority of the talk discuses the status of the small language, with the last portion giving a quick update on the future intent of the large language group.

First on the list of major new features is a mandatory library system designed to be easily implemented atop existing module systems. R6RS's library system proved to tackle too much at once and be incompatible with everything already in a use (a persistent concern in the design of the R7RS-Small language). The R7RS system, on the other hand, is static, simple, and just powerful enough to promote implementation of portable libraries.

Exceptions are stripped down from R6RS (which proved too incompatible with existing implementations for practical use). guard (similar to try...catch in other languages) and with-exception-handler are supported: the latter runs the handler in the context from which the error was triggered (permitting recovery from the error like invoke-restart ) Unlike r6rs, exceptions lack a strictly defined hierarchy and can be any object (you could e.g. throw 4 if you really felt like it).

Dynamically scoped variables, in the form of parameters, are now part of the standard. Unlike Common Lisp special variables, parameters are first-class objects bound to expressions rather than symbols that are declared dynamically scoped. For reasons of simplicity it was decided to make parameters immutable (i.e. any "mutation" has to be done by rebinding). This has the (intentional) side-effect of making parameters play more nicely with threads (when mutation is permitted, setting a parameter that has not been rebound in the current thread requires synchronizing all threads and can have unexpected results).

As expected, R7RS includes bytevectors to complement strings. The small language standard only permits accessing bytevectors as ordered sets of unsigned 8-bit values (the large language standard will offer more flexible access). Binary I/O is implemented via a set of parallel procedures (open-binary-input-file vs. open-input-file, etc.) in contrast to the incredibly complicated dual binary/text ports provided by R6RS. Additionally, string and bytevector ports similar to SRFI-6 are provided instead of the incompatible string ports provided by R6RS.

Taylor Campbell noted that integer division in most languages is insufficiently expressive, and so R7RS will provide Euclidean division and centered division in addition to the usual suspects. Mathematicians rejoice!

As with R6RS, Unicode support is mandated. Unlike R6RS, the only characters that must be supported are those present in ASCII. For supported characters, Unicode case mapping and normalization are mandatory. One interesting diversion from Unicode and R6RS is that string order comparison is implementation-dependent: this gives implementers latitude with the internal encoding of strings.

Any user of Scheme knows that the language strives for consistent and obvious names for bindings. R7RS furthers this goal by resolving the long-standing inconsistency with core data structure creation, copying, mutation, mapping, etc. Lists, strings, and vectors now have a consistent set of each: make-TYPE, TYPE-copy, TYPE-set!, etc. Conversion procedures between all three types are also provided.

Finally, number of minor improvements were made. Most notable: record types are compatible with SRFI-6 (widely in use today); case sensitivity is the default (with optional insensitivity via include-ci); s-expression and nested block comments were added; IEEE infinities and NaNs have read syntax; strings may contain C-style escape sequences; Common Lisp circular list notation is supported; and common extensions to syntax-rules were standardized.

The final 20 minutes of the talk were about the status of R7RS-Large.

The R7RS Large language is currently on hold, mostly because all the small language members are on the large language committee as well, so there is a lack of time to work on both simultaneously. Work is planned to resume upon release of the final draft of the small language. Some work, however, has been completed.

The main focus of R7RS-Large is providing Scheme "with batteries included." John Cowan started the process by looking beyond the Lisp and Scheme communities (Python is mentioned) to figure out which libraries modern programmers expect their language to include.

This resulted in a list of around 250 packages that was narrowed down to around 80 packages through an initial voting process. It was decided then than some desirable packages (e.g. a foreign function interface) had to be omitted due to complexity. It is expected that implementers will continue experimenting and gradually come to a consensus on the larger packages using the existing SRFI process, and perhaps another revision of the standard down the road.

Of the packages planned for inclusion, the most prominent are: networking, threads, regular expressions, delimited continuations, URI handling, date and time parsing/arithmetic/formatting, hash tables, ambient environment access, file system directory access, gettext (i18n support), and pattern matching.

Most will be optional; packages will only be made mandatory if a number of the other packages require them. A compliant R7RS-Large implementation will only have to either provide a package fully or not at all (half implementations are forbidden).

Interestingly, R7RS large with all packages will be even larger than Common Lisp.

To avoid getting bogged down in stylistic discussions, a decision was made to focus on functionality above other concerns. The resulting packages may not be aesthetically pleasing to everyone, but will provide useful functionality. Users who disagree with naming, scope of functionality, argument ordering, etc. will be free to use the library system to import only the bindings they want, rename functions, wrap things into the style they want, etc. Basically, a compromise between the MIT approach and "Worse is Better" is being sought.

Here a call for volunteers is made: Since the focus will be on functionality over pure aesthetics, developers outside of the Lisp and Scheme communities are actively encouraged to participate in the R7RS-Large language process. No fixed time commitment would be required; the goal is to get a lot of people involved with a few core members maintaining momentum and guiding the process. The R7RS-Large language is most definitely a language designed by and for developers. So, make your voice heard!

Overall R7RS is shaping up to be the standard R6RS should have been (which, of course, could not have happened without the lessons of R6RS). The split between an elegant core language with each design issue meticulously fretted over and voted upon and a looser library standard should, hopefully, result in a core language that will stand the test of time with a standard library that can be used to get actual work done.

Sorry! There are no comments related to the filter you selected.

These are the droids you're looking for? (2, Funny)

Anonymous Coward | about 3 years ago | (#37603986)

So what happened to R2D2?

Re:These are the droids you're looking for? (1)

mrmeval (662166) | about 3 years ago | (#37605148)

They cut it into a small piece and a large piece then made them incompatible.

It's inebriated to have two opposing versions of the same version...or ... what?

Re:These are the droids you're looking for? (1)

John Cowan (186239) | about 3 years ago | (#37606734)

That's compatible, not incompatible.

Ahhh... It's been a while... (2)

eepok (545733) | about 3 years ago | (#37603992)

It's been quite a while since the summary made so little sense to me that I didn't bother to read the article. Sometimes, I like to be reminded of how much I just don't know.

Thank you Scheme Language Standard!

Re:Ahhh... It's been a while... (0)

Synerg1y (2169962) | about 3 years ago | (#37604540)

Lol, you know what this sounds like? A bunch of suits discussing mvc without knowing a line of underlying code. "We want it to be multi-platform, robust, dynamic, and future proof"

Of course the final product runs on Solaris and requires a nightly reboot, you know?

I know of schemes like XML??? Good luck replacing that...

Then there's this kind of gibberish when I actually try and figure r7rs out... []

Conclusion: r7rs is a rhetorical play on acronyms .

Re:Ahhh... It's been a while... (0)

Anonymous Coward | about 3 years ago | (#37604774)

I know of schemes like XML??? Good luck replacing that...

I can't tell if you're joking or if you just didn't bother to figure out what scheme is supposed to be...

Re:Ahhh... It's been a while... (1)

Synerg1y (2169962) | about 3 years ago | (#37605122)

A jest at the lack of definition anon (XML would be schema), do I have an anon troll trying to figure out if I take slashdot seriously?

Re:Ahhh... It's been a while... (0)

Anonymous Coward | about 3 years ago | (#37605572)

For me it's a little different. I know Scheme is an inferior language, so there's no point in knowing about any of this. Hence I care so little, that I didn't bother to read the article. Sometimes, I like to be reminded of how superior I am.

Thank you Oh Allmighty Haskell! :P

(Also, somebody needs to be reminded of the definition on "summary" again.)

Re:Ahhh... It's been a while... (0)

Anonymous Coward | about 3 years ago | (#37608902)

Heh, heh. This was kind of the opposite for me. I've been a Scheme fan/student/user for a few years, and while the kind of Slashdot article you see almost every day about stuff like GPUs, Agile Development, Affiliate Programs, carbon graphene nanotech, and iPhones just makes my eyes glaze over, this was a summary which I mostly understood!

Crap... (1)

Greger47 (516305) | about 3 years ago | (#37604000)

I didn't understand a word of that gobbledygook. I better turn in my nerd credentials, before someone catches on. :(


Re:Crap... (3, Interesting)

arielCo (995647) | about 3 years ago | (#37604458)

Don't. It's increasingly harder to be a polymath, even if you confine your domain to technology, perhaps even in CS.

You may have inferred that Scheme [] is related to Lisp [] ; they call it a "dialect", stretching a bit the analogy with human languages. Common Lisp [] is another, and I had brief run-ins with both while peeking under the hood of two great projects: Maxima [] and the gEDA suite [] . They left me impressed and determined to learn the language, as soon as I had the mood/time to wrap my easily-distracted brain around it.

Re:Crap... (1)

JonySuede (1908576) | about 3 years ago | (#37604546)

Do as the great mathematician Paul Erds did and use amphetamine instead of coffee, it works great ! And your insurance can reimburse it if you have the right symptoms !!!

Re:Crap... (0)

Anonymous Coward | about 3 years ago | (#37604656)

I used the proper html entity for the accent in his name, it appeared in the preview and on submission it was gone....

any how is the link []

Re:Crap... (2)

TopSpin (753) | about 3 years ago | (#37604720)

There is a functional language called Scheme. It is a minimal LISP with some advanced features and noted for having a very small specification. The current version is (deep breath) R6RS. Don't panic; that just means Revised(6) Report (on the algorithmic language) Scheme. The previous version was R5RS and the next is R7RS. Yes, you could drop all the consonants and have the same result, but that doesn't occur to academics.

The gist of the story is that R6RS isn't being adopted by implementations (scheme has many divergent implementations) and that R7RS is being worked on with a higher rate of adoption in mind.

And yes, if you have spent much time around Slashdot and taken an interest in the technical topics (as opposed to the political controversies) you are expected to know enough of this to follow the summary. Not that it was written all that well...

Re:Crap... (1)

Synerg1y (2169962) | about 3 years ago | (#37605792)

From the article, I didn't even pick up that this was a programming language lol... []

Thanks for the clarification.

This stuff sounds like it pre dates my education, I've heard of LISP, but never worked with it, it's something that runs somewhere fortran and C reign and we're a .NET shop with the oldest app being in classic ASP, and some seriously outdated PHP, but LISP? who still runs this and why?

Re:Crap... (1)

Raenex (947668) | about 3 years ago | (#37606118)

but LISP? who still runs this and why? []

The main advantage is that the language is extendable via macros, which can reduce a lot of boilerplate. It's also very popular in academia for this reason, because it let's you explore new language features by extending the language.

Re:Crap... (1)

mellon (7048) | about 3 years ago | (#37608282)

Nobody runs it. There is nothing to see here. These are not the droids you are looking for. []

Re:Crap... (0)

Anonymous Coward | about 3 years ago | (#37608942)

A lot of the "cool, cutting-edge" features you see in popular modern languages like Python, Ruby, JavaScript, etc. - stuff like closures, functions as first-class objects, lambdas, and filter/map/reduce - come straight from Lisp. Even the very idea of XML is just a variation on the list structure of Lisp. It's taken fifty years for these modern languages to catch up to Lisp.

Re:Crap... (1)

Riktov (632) | about 3 years ago | (#37608948)

(re-posting what I just posted anonymously)

A lot of the "cool, cutting-edge" features you see in popular modern languages like Python, Ruby, JavaScript, etc. - stuff like closures, functions as first-class objects, lambdas, and filter/map/reduce - come straight from Lisp. Even the very idea of XML is just a variation on the list structure of Lisp. It's taken fifty years for these modern languages to catch up to Lisp.

Re:Crap... (1)

Synerg1y (2169962) | about 3 years ago | (#37612324)

I would imagine so lol, the wiki says it's the 2nd oldest OOP, language technology progress tends to be a grab the best and most features you can out of what exists, add a few of your own and name the sucker. Thus why we have a ton of programming languages that are used every day to do the same things differently. Also, it's not very easy to depreciate languages when there are million dollar apps written in them.

The syntax for LISP is ehm less then elegant though [] a small factor to someone who's been using it for a couple of decades, but unattractive to somebody thinking about learning it.

Re:Crap... (0)

Anonymous Coward | about 3 years ago | (#37614308)

The syntax of Lisp(S Expressions) seems strange, like the syntax of Smalltalk seems strange, because most languages in heavy use today are constructed using a ALGOL/C syntax style. Still S Expressions have their advantages, being the reason they're still used in CL and Scheme.

Re:Crap... (1)

MechaStreisand (585905) | about 3 years ago | (#37746488)

You're an idiot. Don't comment on stories about lisp if you're too dumb to have even heard of it.

Re:Crap... (2)

John Cowan (186239) | about 3 years ago | (#37606762)

The numbers in R5RS, R6RS, and R7RS are really superscripts: R5RS stands for "the Revised Revised Revised Revised Revised Report on the Algorithmic Language Scheme".

Personally I think that joke's pretty worn out, but the Working Group decided otherwise.

Uhhhh (1)

VIPERsssss (907375) | about 3 years ago | (#37604130)

WTH? It's like I opened up "The Two Towers" at page 219 having never read Tolkien before.

Re:Uhhhh (1)

osu-neko (2604) | about 3 years ago | (#37608696)

Not every /. story is intended to be edifying for you personally. Feel free to simply skip over the stories that are of interest only to others.

It's what Slashdot is supposed to be.


Chibi-scheme is worth a look (4, Informative)

e4liberty (537089) | about 3 years ago | (#37604434)

Chibi-scheme [] is a nice C-based implementation following the R7RS-Small standard closely -- the author is the R7RS-Small committee chair.

Re:Chibi-scheme is worth a look (2)

John Cowan (186239) | about 3 years ago | (#37606864)

Not quite R7RS conformant yet, but that's definitely a goal. It's already R5RS conformant.

There is also a longer range plan to accept JavaScript, Lua, Go, and bash as source languages and translate them to Scheme.

Re:Chibi-scheme is worth a look (1)

Unknown Lamer (78415) | about 3 years ago | (#37607180)

When I watched the talk I noticed the multi-language goals of Chibi Scheme seem to overlap with those of Guile — is there any reason there isn't collaboration? Guile did recently get a fancy new VM (with a direct compiler, wingo has made grumblings about rectifying that...), and good progress has been made toward getting Emacs-Lisp running on it (it can load subr.el and run dunnet at least, I've seen it with my own eyes). It seems like getting multiple languages to interoperate other is going to be a huge challenge (you know, with that whole type system mismatch thing...); #nil being "beautiful in an ugly way" is one such example ('tho BT, the one working on the elisp compiler right now, isn't particularly fond of it). I'm not sure what the intentions for Chibi Scheme are wrt interoperability — I noticed you mentioned that the bash compiler probably won't be able to call Scheme?

And, thanks for stopping by and commenting! I hope my summary didn't misrepresent your presentation any; if it did let me know and I'll make the appropriate edits for accuracy. (I noticed that I managed to skip over the numeric tower stuff so at least one slight revision is already needed).

Re:Chibi-scheme is worth a look (1)

Anonymous Coward | about 3 years ago | (#37607492)

Cool Anecdote Bro moment: I took a look at Guile after it showed up in a recent slashdot article. (Having some small experience in Scheme, and then a bunch of self study in Common Lisp). I liked Guile.... once I had it running. That was the catch. Getting the latest version running involved a lot more dependency hell than I would prefer; the new version wasn't in the ubuntu repositories, so I had to compile it, and that meant getting a dozen other pieces (some of which themselves weren't in the repos and needed to be compiled from source). I'm afraid to try it in windows.

I'd hope that full featured R7RS implementations are easier to get up and running on multiple platforms. (IMO, Common Lisp is currently pretty far ahead of Scheme in that respect. Apparently much progress had been made in the past 5-or-so years on the CL front, over several implementations. Maybe with the exception of Racket, but that seems to have diverged some from the rest of Scheme in the few years since I last used it as DrScheme). Certainly the portability and ability to integrate will be helpful for people to consider writing and distributing their nifty new programs in Scheme. Certainly students and hobbyists would prefer to be able to download and install ready-to-use versions, like they do with other mainstream languages, instead of a bunch of separate chunks that need compiling.

Re:Chibi-scheme is worth a look (1)

John Cowan (186239) | about 3 years ago | (#37608400)

Well, both Guile and Chibi are both meant to be embedded, but in different ways. The Guile 2.0 shared library is about ten times the size of the Chibi shared library (on 32-bit Linux); on the other hand, Guile 2.0 has a compiler, whereas Chibi is a fast bytecode interpreter. In general, Chibi optimizes for space: it doesn't provide multiple versions of procedures in the SRFI 1 list library, for example. Running Chibi (perhaps with some features compiled out) on an embedded chip makes sense; Guile is aimed at desktop and perhaps server applications.

I don't think there are any substantial errors in your summary, and I appreciate the writeup. If you want to add stuff, riff through the slides, it's faster.

Re:Chibi-scheme is worth a look (1)

mdmkolbe (944892) | about 3 years ago | (#37612836)

Sadly, it is an interpreter. R7RS is unproven until a serious compiler implements it. There are too many possibilities for unforeseen problems. (I say this from experience; been there, done that, don't have the time right now.)

Scheme with a bigger lib than common lisp ! (1)

JonySuede (1908576) | about 3 years ago | (#37604438)

Was not one of scheme original goals to a have small and extendable language and let's it's users use the library they want ? They have lost that goal somewhere along the road from r4rs to r6rs

Re:Scheme with a bigger lib than common lisp ! (2)

Sodel (1917500) | about 3 years ago | (#37605218)

"Was not one of scheme original goals to a have small and extendable language and let's it's users use the library they want ?" That's *exactly* what they're getting: a small, meticulously crafted kernel language, upon which you can build whatever you like!

Interested in avoiding the fragmentation of a thousand non-standard libraries that do more or less the same thing? Got you covered there, too! R7RS-Large is a portable set of libraries for your applications. Fragmentation, be gone!

From the summary, the high-profile libraries include "networking, threads, regular expressions, delimited continuations, URI handling, date and time parsing/arithmetic/formatting, hash tables, ambient environment access, file system directory access, gettext (i18n support), and pattern matching." Yeah, that's going to be bigger than Common Lisp. On the other hand -- and I say this as a CL user -- it's almost a little sad, given the side of the Common Lisp standard, that so many of those features are left unstandardized.

Re:Scheme with a bigger lib than common lisp ! (1)

JonySuede (1908576) | about 3 years ago | (#37605350)

Do you know what ambient environment access is ? (This is not a flamebate question, my google cannot seems to be able to explain it to me)

Re:Scheme with a bigger lib than common lisp ! (0)

Anonymous Coward | about 3 years ago | (#37606196)

I haven't the foggiest idea. Probably should have edited that one out of my pasted text.

Re:Scheme with a bigger lib than common lisp ! (1)

JanneM (7445) | about 3 years ago | (#37606586)

"Do you know what ambient environment access is ?"

You can read out the state of your Lava lamp.

Re:Scheme with a bigger lib than common lisp ! (2)

John Cowan (186239) | about 3 years ago | (#37607060)

Either I misspoke or someone misheard. "Environment enquiries" is a Common Lisp term for functions that return things from the environment such as wall-clock time, internal time in jiffies, the name and version of the implementation, the name of the hardware and OS the implementation is running on, the host name, the working directory, the Unix environment variables, the command-line arguments, and so on. Most of these things wound up in R7RS-small one way or another already, but I didn' t know that when I made the package list.

Re:Scheme with a bigger lib than common lisp ! (1)

JonySuede (1908576) | about 3 years ago | (#37607422)

Environment enquiries is more sensible that ambient environment access, thank you for the clarification

Re:Scheme with a bigger lib than common lisp ! (2)

White Flame (1074973) | about 3 years ago | (#37605550)

Yes, I agree. There is such a blind reverence to the CLHS and "[just grab a lib|roll your own] is so easy, why bother?" is so prevalent that it seems that many in the CL community don't even conceive of the possibility of an updated standard, just delving into what nuances can be extracted from the current spec for edge cases and optimization conditions. Plus, many of the libraries are something that a CL hacker banged together in his interactive sessions and aren't very robust or documented, but become ad-hoc standards simply because nothing else is out there. It's amazing that arguably the best functional/imperative/metaprogramming language out there has formed such a terrible ecosystem (The Lisp Curse, etc).

Good on Scheme for moving forward, and while I didn't watch the videos, it sounds like much of this new functionality is standardizing on libraries instead of burdening the core too much.

Re:Scheme with a bigger lib than common lisp ! (0)

Anonymous Coward | about 3 years ago | (#37611620)

Here, here. It will be bigger because the Common Lisp (CL) camp refuses to modernize and hence won't contain as much functionality. Funny to see Scheme get standard libraries before CL but perhaps it is apropos. The standard retort in the CL forums when anyone asks why there isn't a standard for... networking say... is that it wasn't used widely when the CL standard was created and why would you need a standard networking module anyway since vendors provide their own... Oh, maybe because "we like coding to standards so our code is portable"!

Here's a translation into plain English (1)

pdxChris (162827) | about 3 years ago | (#37608308)

The Scheme programming language began as a research and teaching project at MIT in 1975. Since then, it has become very influential among advanced researchers and designers of programming languages. It's also had some successful use in industry. Scheme is defined by a Report on Scheme; this is the 7th Revision of that report, thus R7RS. This hour long talk about the latest revision will be of interest to three groups of people:
1. Those who already familiar with Scheme, Lisp, or functional programming, and who want a preview of the just-about-finished new version of Scheme.
2. Those who would like to get a nice overview, which gives a taste of the mindset and software tools that comprise the world of Scheme. Compare & contrast with how your favorite language works! Learn something new! Whee, what a rush!
3. Those who would like to see a nicely done technical talk, which gives a little bit of history, a little bit of politics, and quite a few technical explanations and examples in context.
If you're not interested in any of these three things, then this isn't the talk for you.
The video can be followed without any prior understanding. I think that just the slides will be totally confusing for those who are not already familiar with Scheme.

Problems with R7RS (1)

mdmkolbe (944892) | about 3 years ago | (#37613830)

Pointless changes:

  • Renamed "textual" ports to "character" ports. Note that they kept "binary" ports which is properly parallel to "textual". The parallel of "character" (noun) is "byte" (noun), not "binary" (adjective).
  • Library system incompatible with R6RS. R6RS already had a least common denominator library system that all the major Schemes have already implemented. Good luck getting them to implement yet another library system. The summary is misleading when it claims R6RS libraries are complicated. R6RS libraries are about as simple as you can get and still handle the corner cases when macros are involved. In fact, from what I see, the R7RS-Small modules are a super-set of the R6RS features and are more complicated than R6RS libraries.
  • Record system incompatible with R6RS. R7RS-Small records are a proper subset of R6RS records, but rather than use a compatible syntax, they used a syntax that makes it ambiguous use R6RS and R7RS records syntaxes together. They could have either used a subset of the R6RS record syntax or chosen a different keyword or a syntax that distinguishes the two.

More problems:

  • Added parameters and "include". However, parameters have a well known problem with converters, and "include" has well known hygiene problems. R7RS adds these features without addressing these problems.
  • Missing case and normalization insensitive string compare. R7RS adds normalization insensitive string compare and keeps the case insensitive string compare from R6RS, but omitted a string compare that is both case and normalization insensitive. Was someone asleep at the wheel?
  • (Nitpick) The "guard" keyword violates Huffman coding. There are too many other uses for that word, and it is a shame to steal it from the user. (Yes, "try" in Java also violates Huffman coding. Java can better justify it since Java distinguishes keywords from identifies whereas Scheme does not.)

Of course the biggest problem is that R7RS doesn't have any of the major implementors involved in the process. Absent their participation, the process is all but certain require features that cause problems down the road. (No disrespect to Chibi-scheme, but it is hardly one of the top 5 Schemes.)

Re:Problems with R7RS (1)

John Cowan (186239) | about 3 years ago | (#37620832)

1) The WG has already voted to use "textual port" instead of "character port", but the new draft has not yet been published.

2) It is false that "all the major Schemes" have implemented R6RS libraries. The definition of "major" is subjective and subject to change, but Chicken is a major Scheme by any standard, and has not implemented them. It's true that the R7RS library format is not quite a subset of R6RS's, but adding the R7RS features to an R6RS library implementation is expected to be trivial. The main R6RS feature omitted is phasing control, which is irrelevant to R7RS-small because it only allows syntax-rules macros. R7RS-large may wind up with explicit phasing controls or not.

3) It's true that the R7RS record system is incompatible with R6RS to the extent that they both use the name "define-record-type", but by the same token R6RS was incompatible with the de facto R5RS standard implemented by almost every Scheme (and trivially implementable on R6RS systems as well). R7RS simply reverted to the de facto standard rather than accepting the committee-designed R6RS system.

4) Parameters do not have a problem with converters: some implementations have a problem with converters. In any case, the problem only surfaces if the implementation supports parameter mutation (as distinct from binding), which is outside the scope of R7RS. I do not know what you mean by saying that "include" has a problem with hygiene.

5) Since R7RS does not define exactly what normalization means, it might or might not be case-sensitive, but if it is Unicode NFC or NFD, it would not be. Implementations and users are free to add their own double-dip comparison operators.

6) "Guard" was chosen for the sake of R6RS compatibility. You can't have it both ways. In any case, there are no reserved words in Scheme (although "quote", "quasiquote", "unquote", "unquote-splicing", and "import" are problematic to redefine).

7) So far, exactly one implementer has been negative about R7RS. Others have been silent, mildly positive, or positive. It would be difficult for the WG to require features that cause problems in implementation when we have not specified any features that have not yet been implemented.

Re:Problems with R7RS (1)

mdmkolbe (944892) | about 3 years ago | (#37632196)

First, thank you for taking the time to address these concerns. If I am critical, it is only because I want to see R7RS succeed and be a good language spec.

1) I'm glad to hear about the use of "textual". Watching from the sidelines, it seems like the process has been prone to reinventing things in ways that different than R6RS without being better. That makes it hard for implementors to provide compatibility and smooth upgrade paths.

2) I'll grant that Chicken is a major Scheme. Your point about phasing being unneeded in R7RS-small is well taken, provided R7RS-small libraries/modules can be scaled up to include phasing as any implementation with syntax-case will have to do. Still, once you eliminate the phasing issue, I guess I don't understand why R7RS-small modules are any better or easier to use or implement than R6RS libraries sans phasing.

3) I guess I have a different view of the world than you. In my neck of the woods, SRFI's don't get a lot of support and aren't actually de facto standards. Thus, I tend to think of R6RS trumping SRFI-9 rather than the other way around. It is unfortunate that R6RS collided with SRFI-9, but R7RS has the opportunity to reconcile the two as SRFI-9 is a semantic subset of R6RS records. It would be nice to either use the syntactically restricted subset of R6RS records, or even if they used the same keyword, to make their syntaxes distinct. As it is, I believe there are invocations of define-record-type that are inherently ambiguous as to which syntax is being used.

4a) (parameterize ([param (param)]) ) is not equivalent to if the converter isn't idempotent. This might not be an issue until you consider if someone wants to save and restore param value from an outer scope in an inner scope. For example, (let ([old (param)]) (parameterize ([param new]) ... (parameterize ([param old]) ...) ...)). Throw call/cc's in there that jump across the dynamic-wind of the parameterize and implementations based on SRFI-39 will get quite problematic.

4b) The problem shows up in things like (define-syntax my-include (syntax-rules () [(_ file) (include file)])). On hygienic macro systems, this macro is not equivalent to the "include" macro. The "include" macro imports things into the scope where it is used, but "my-include" imports things into the scope where "my-include" is defined, not where it is used. Sometimes that is what you want, but often it is not. Any macro that uses "include" inside it will have this issue, and this makes it impossible for the user to write more sophisticated variants of "include" (e.g. that do instrumentation). In general, anything that converts from non-syntax to syntax has to deal with this problem. This is most clearly seen with "datum->syntax" where it is solved by passing an extra argument from which the marks are taken. (Also, R7RS isn't clear about whether things are placed into the scope of where "include" is called or where the "include" identifier originates; there is a difference even in syntax-rules.) I can elaborate on this further if it isn't clear what I'm getting at.

5) Given that on a system with Unicode, you almost never want to do a non-normalizing case-insensitive match and that it is hard for a user to efficiently implement their own normalizing case-insensitive match, it seems an odd corner of the rectangle to omit.

6) OK, I'll blame R6RS for that one.

7) But how many of the "big 5(+/-2)" have been positive? Silence from the implementors is a bad thing, because silence is non-participation. R6RS for all its faults at least had strong implementor representation. My understanding is that R7RS is not so strong in this regard, and that worries me. Some features may sound good on paper, but end up being impossible to efficiently and/or correctly implement. Note that I'm drawing a distinction between being possible to implement and being possible to implement well. Each Scheme implementation will have a different definition of "implement well", so R7RS needs to operate within the intersection of those. For example, "implementing well" is different for a compiler vs an interpreter vs a bytecode compiler. Implementors like Kent are unlikely to add R7RS to Chez Scheme unless it can be done without sacrificing performance or compatibility. And so on and so forth.

Re:Problems with R7RS (1)

John Cowan (186239) | about 3 years ago | (#37659536)

Sorry for the delay in responding: ./ won't let me post from behind $EMPLOYER's firewall.

2) It's still an open issue whether we will support both implicit and explicit phasing in R7RS-large. Personally, I think that since you are not allowed to give identifiers different definitions at different phases in R6RS (as you can in Racket), implicit phasing should suffice. The R7RS extensions to R6RS library syntax make more work for implementers, but less for users. In particular:

Allowing interspersed import and export declarations make it possible to keep them next to their referents;

Cond-expand support (which has no phasing problems because the features cannot be set from Scheme) is a more general kind of configuration;

Wrapping code in begin, include, or include-ci means that it's possible to add new clauses to the library language, since it is distinct from Scheme.

3) The WG looked at several different record proposals including SRFI 9, R6RS-syntax, and a couple of others. SRFI 9 narrowly won, beating an alternate proposal that would use R6RS syntax, SRFI-9 semantics, and a different name. Those who voted for SRFI 9 emphasized backward compatibility with existing code.

4a) I've added a note to the trunk of the draft (not yet published) warning about the unexpected behavior of binding parameters to self if the converter is not idempotent. I've only used converters as checkers myself, so it hasn't come up for me.

4b) Include is only allowed at program top level, macro top level, and REPL top level, so your code is not valid R7RS. I believe that disposes of this objection.

5) I've filed a ticket for this issue; like the other outstanding tickets at this stage, it will turn into a formal comment from the public review.

7) Two implementers have been negative about the effort, one of them definitely not in a Big N for any reasonable N. The Guile and Chicken maintainers have said that R7RS is a goal for them, though of course without a schedule or firm commitment, which would be premature at this stage. Another maintainer has said the same privately. But I think you overestimate how different R7RS actually is. Modulo the library syntax itself, I expect it will be trivial to provide all the R7RS libraries on any R6RS userland, for example. (I'm going to tackle it as a proof of concept if no one else does it first.)

If you have time, please take a look at the draft itself, or at least the list of changes from R5RS at the end, and comment further on

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?