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 scheme-reports@scheme-reports.org.
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.
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.
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.
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.
Well, of course I don't agree that it was a prank. I was quite serious.
I also don't agree that the license "doesn't even start to come close to being OSI compliant." OSI-approved licenses are a subset of OSI-compliant ones.
"Undoubtedly"? *I* doubt it. In fact, it isn't true.
I would never abuse the OSI process by submitting a license for consideration unless I thought that license met the Open Source definition. Life is too short for such machinations.
Of course Microsoft owns the copyright on those licenses: they wrote them. And no, not even the GPL is released under the GPL: the GPL's license says "Anyone may copy and distribute this license, but changing it is not allowed." This is presumably to prevent proliferation of lots of just-slightly-modified copies of the GPL.
"Open Source" is not a trademark, nor is "open source", for various technical reasons. "OSI Approved" *is* a trademark, and you can slap it on your software if you are 1) making source code available and 2) using a license on OSI's list.
A license doesn't have to be OSI-approved in order to be an open-source license. An OSI-approved license is one that is an open-source license in the judgment of various people, not just the OSI board members.
The practical problem with a 3rd party (like me) submitting someone else's license is that if the OSI wants changes, the 3rd party has no authority to make them. It makes sense to deal directly with the license author.
I don't speak for the OSI, Microsoft, my employer, or anyone but me.
What I was thinking was that the license is a decent license no matter who wrote it, and worth approving *because* of who wrote it. Nelson pointed out a potential issue, and I withdrew my recommendation, but not the judgments it's based on -- I stand by those.
Slashdot Mirror
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 scheme-reports@scheme-reports.org.
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.
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.
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.
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.
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.
That's compatible, not incompatible.
Well, of course I don't agree that it was a prank. I was quite serious.
I also don't agree that the license "doesn't even start to come close to being OSI compliant." OSI-approved licenses are a subset of OSI-compliant ones.
"Undoubtedly"? *I* doubt it. In fact, it isn't true.
I would never abuse the OSI process by submitting a license for consideration unless I thought that license met the Open Source definition. Life is too short for such machinations.
Of course Microsoft owns the copyright on those licenses: they wrote them. And no, not even the GPL is released under the GPL: the GPL's license says "Anyone may copy and distribute this license, but changing it is not allowed." This is presumably to prevent proliferation of lots of just-slightly-modified copies of the GPL.
"Open Source" is not a trademark, nor is "open source", for various technical reasons. "OSI Approved" *is* a trademark, and you can slap it on your software if you are 1) making source code available and 2) using a license on OSI's list.
A license doesn't have to be OSI-approved in order to be an open-source license. An OSI-approved license is one that is an open-source license in the judgment of various people, not just the OSI board members.
The practical problem with a 3rd party (like me) submitting someone else's license is that if the OSI wants changes, the 3rd party has no authority to make them. It makes sense to deal directly with the license author.
I don't speak for the OSI, Microsoft, my employer, or anyone but me.
What I was thinking was that the license is a decent license no matter who wrote it, and worth approving *because* of who wrote it. Nelson pointed out a potential issue, and I withdrew my recommendation, but not the judgments it's based on -- I stand by those.