On 8 Sep 2009, at 8:41 pm, Vincent Manis wrote: > Those of us who use Scheme regularly are generally pretty happy with > our various implementations. Gambit, Chicken, PLT, Chez, etc. are all > quite useful for building quite large and complex systems, and we all > know how to port code from one of these to another without that much > hassle. (I often say that porting reasonably-written code from any > good Scheme system to another is about as difficult as, or maybe less > difficult than, porting SQL code from Oracle to PostgreSQL.) So why do > we need a new standard at all?
I think that most of the effort in porting something between implementations is unnecessary. Now, if two Schemes had taken opposite stances in some deep philosophical debate about, say, how hashtables should be modelled, then I'd be... not exactly ecstatic, but unconcerned about them having different models. I'd see it as a temporary affair, until the great "Is A Hashtable More Like An Alist Or A Procedure" (or whatever) war subsided, and we ended up with one or the other winning, or a sensible way of merging the two views into one appeared. But when they have different ways of accessing the network, different ways of opening a subprocess to run a command, and different ways of structuring my code into separate files and expressing the relationship (so even if I wasn't using such platform-specific features, I'd have unportable code), then it feels like unnecessary work doing the porting. Sure, I think implementations should have their nonportable private extensions. That's necessary to be a testbed for ideas. Then the best approach to whatever problem is being solved can become popular and be ported to other Schemes and end up as an SRFI. > R7RS is not primarily for us, but rather for the > people who ought to be using Scheme but aren't. This is also a good point ;-) > Those people perceive: > > - Scheme is only for toy programs. > - At present, Scheme is fractured into many dialects, all so > incompatible as to make programs inherently nonportable. > - To find out what Scheme is, you have to navigate a maze of > reports, SRFIs, manuals, and blog postings, and maybe read the source > code for your implementation. Yeah, the Scheme documentation landscape is rather poor. I'd love to write a "Practical Real-World Scheme" book, in line with the recent O'Reilly offerings on Haskell and Erlang, but I'm rather short of time at the moment... > R7RS, therefore, needs to accommodate these three audiences. I'm not > sure about which kind of presentation is best for this, but probably > the most important thing the R7RS Editors (who may or may not be a > smaller group than the set of WG members) can provide is an overall > map that defines what's where, so that one knows where a hash table > specification can be found, if it's not in the main Ultra-Scheme > document. (A language that doesn't have hash tables as a predefined > datatype will get slammed by the Perl/Python/Ruby crowd AND the Java/ > C# crowd, so pointing at a SRFI or saying that the implementation > might provide hash tables or commenting that any computer science > student who's taken data structures can implement them will not > inspire confidence in a prospective Schemer.) Yeah. I'd be all for textually including the interesting SRFIs into R7RS, for this reason, and to protect the standard against SRFIs being updated in future (AIUI there's no process for that at the moment, but there might be one in future?) > By contrast, an HTTP > client is very clearly an application library; nobody except a Python > programmer would think of it belonging in the core language > specification. Or a Java programmer ;-) java.net.URL is pretty ingrained, IIRC... > I'm unable to present my thoughts without some kind of concrete > example. I am explicitly not saying I want the Editors to produce > these documents, just that this is one of many ways of organizing a > Report that embodies the vision I have. > > - Top Level Guide to R7RS Scheme > - Core Subset Specification > - Ultra-Scheme Specification > - Additional Specifications > - Embedded Systems Features > - Collections and Data Structures > - Threads \ > - Environments |------ these are just examples > - Object System / > - ... > - Rationale > - Non-normative appendix on conventions and operating system > interface That looks good to me. > This somewhat contradicts my earlier stand on options. What I was > reacting to with our earlier discussion of options, I now see, was > that I perceived a fine granularity on them. I don't want a Report > that says that set-cdr! is `inessential' or `optional'. Either include > it or don't include it. The granularity level shouldn't be at the > individual procedure level, but rather at the feature level: not hash > tables, but collections; not fork, but POSIX support; and so on. This > vastly reduces the combinatorial explosion inherent in a large number > of fine-grained options. Definitely :-) ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
