[Chicken-users] R6RS Rant
On Jun 4, 2007, at 11:49 PM, felix winkelmann wrote: On 6/4/07, Mitchell Wand [EMAIL PROTECTED] wrote: We are sorry to report that Will Clinger has resigned from the Editors Committee, effective on May 21, 2007. We accept his resignation with regret and thank him for his service. According the Charter, the Steering Committee has three months to replace a resigning editor. The Steering Committee has therefore decided to wait until after the ratification ballot before taking steps to replace him. There goes another one... R6RS has become a debacle. Dropping consensus was a terrible idea. While it dooms Standard Scheme to a toy language wasteland it had the benefit of a stable, reliable, platform for extension. Taking SRFIs in popular use verbatim as the standard (ex: the inclusion of the KMP algorithm in SRFI-13) may not be the catholic response, but using close to 98% of the popular SRFIs gives us proven APIs. If I may be so bold, it seems the greatest issue is the library arena. Drop it. Define a core only. There is so many similar extensions of R5RS in std use that an agreeable R6RS would not be a rewrite of R5RS. (BTW, I think the full numeric tower extended characters/strings should be core. Doesn't mean a compiler can't be told to not use them.) I suspect there is a core in R6RS on which consensus can be reached. For example, why can't we just agree on a record concept sufficient to represent conditions. The issue of composite vs multiple inheritance shouldn't be a deal breaker. How an implementation provides record type composition shouldn't be a problem, so long as it does. And the holes. Hell, everyone deals with filenames, but R6RS has no API. Record inheritance but no pathname concept. Yeah, I would love algebraic type extension, multi-valued continuations (I use Feely's extension in F-operator for this but I don't think I should need to), delimited-continuations, reader/ printer extension, defined syntax vs. semantic phases, syntax extension, namespaces, packaging, ...) but we ain't gonna agree on it (or not most of it anyway). Rant, rant, ..., Kon cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS Rant
Kon Lovett wrote: If I may be so bold, it seems the greatest issue is the library arena. Drop it. Define a core only. There is so many similar extensions of R5RS in std use that an agreeable R6RS would not be a rewrite of R5RS. (BTW, I think the full numeric tower extended characters/strings should be core. Doesn't mean a compiler can't be told to not use them.) What I miss most from R5RS is the user-visible way to include and/or define libraries. Today I use chicken and write (require-extension extension-names ...) but I'd love for this to be the same across most Schemes. Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS Rant
On Jun 5, 2007, at 1:37 AM, Sunnan wrote: Kon Lovett wrote: snip What I miss most from R5RS is the user-visible way to include and/ or define libraries. Today I use chicken and write (require- extension extension-names ...) but I'd love for this to be the same across most Schemes. Umm, I might see my 60th birthday before packaging is core Scheme. (I don't think there should be anything else, except optional.) Well, 'require-extension' is an accepted SRFI. And Chicken does support 'require' (I use it in the bloom-filter egg, however it isn't PLT-Scheme compliant) 'load' (I use it in the 'procedure-surface' egg). But, yes. There is no agreement on the simple process of acquiring a library. Because, library is not a simple concept. Best Wishes, Kon Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS Rant
Umm, I might see my 60th birthday before packaging is core Scheme. (I don't think there should be anything else, except optional.) You forgot to mention your current age :) Well, 'require-extension' is an accepted SRFI. And Chicken does support 'require' (I use it in the bloom-filter egg, however it isn't PLT-Scheme compliant) 'load' (I use it in the 'procedure-surface' egg). require-extension is very useful, even just as a cross-platform way of loading SRFIs. But you should read the SRFI-55 mail archive to see the incredible opposition it draws from some folks. Or try asking for require-extension on the PLT or Scheme 48 mailing lists. Anyway... Two glaring omissions related to (load): 1) (include ...) is not standardized 2) no one has thought of specifying what nested (load) or nested (include) should do. That is, what happens when you have x.scm dir/y.scm dir/z.scm where x.scm does (load dir/y.scm), and y.scm does (load z.scm). Does dir/y.scm load the correct dir/z.scm, or the non-existent z.scm? Same for (include), of course. R5RS does not standardize this, neither do most implementations specify what they do. In practice, most schemes use the absolute path convention, while SISC uses the relative path convention. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
