ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (03/15/91)
I'm teaching a course on symbolic programming this year, so I'm always on the lookout for Scheme examples that I can use. There seems to be something about Chez Scheme that makes people using it more likely to share their code than others. But there also seems to be something about Chez Scheme that makes people provide code that others can't use. As a comparatively minor example, apparently Chez Scheme lets people use square brackets [...] as well as round parentheses (...) for lists. Fine. But it's not in the R*RS and it wasn't in the draft standard I saw, and none of the Schemes I have access to supports that "feature". Then there are things like heavy use of setf, which is not in the R*RS, nor the standard, nor ... I really don't want to sound ungrateful, oh, let's be honest, I *AM* ungrateful. When someone says "I have some Scheme code you can use" and I then burn up net cycles FTPing it and then have to spend more of my time converting the stuff *to Scheme* than if it had been in Common Lisp or Pop in the first place, I am *NOT* grateful. Is it really the case that R*RS Scheme is such a pathetically crippled language that people _have_ to use Chez extensions all over the place? Any interesting examples I come up with this year I am going to send on to Ozan Yigit, but you can be sure I'll have tried them under three different Schemes first. -- The purpose of advertising is to destroy the freedom of the market.
dorai@titan.rice.edu (Dorai Sitaram) (03/16/91)
In article <4977@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > There seems to be >something about Chez Scheme that makes people using it more likely to >share their code than others. But there also seems to be something >about Chez Scheme that makes people provide code that others can't use. I'm posting this rather than just emailing Richard since people seem to listen when he talks ;-> and it's likely that his discomfort with Ozan's repository becomes contagious :-<. >As a comparatively minor example, apparently Chez Scheme lets people >use square brackets [...] as well as round parentheses (...) for lists. >Fine. But it's not in the R*RS and it wasn't in the draft standard I >saw, and none of the Schemes I have access to supports that "feature". Changing all ['s and ]'s to ('s and )'s using global replace is about the easiest thing one can do. Changing them _back_ is not -- for obvious reasons. Which is why it helps to retain []'s for those folks who want to maintain and modify the Ch*z source. >Then there are things like heavy use of setf, which is not in the ^^^^^^^^^^^^^^^^^!!!! >R*RS, nor the standard, nor ... Nor Ch*z!! You're probably -- but maybe not, in which case I retract this paragraph -- referring to my own use of something called setf in SLaTeX. Obviously, I _defined_ this macro before using it. So? >I really don't want to sound ungrateful, oh, let's be honest, I *AM* >ungrateful. When someone says "I have some Scheme code you can use" >and I then burn up net cycles FTPing it and then have to spend more >of my time converting the stuff *to Scheme* than if it had been in >Common Lisp or Pop in the first place, I am *NOT* grateful. Are you saying you find that you have to _rewrite_ the code instead of defining the few procedures and macros that are not primitive in your Scheme? For instance, probably the only non-RRRS Ch*z procedure I would use is printf, and this is provided by Ken Dickey's format.scm. Extend-syntax is provided by extend.scm for Schemes ohne extend-syntax. >Is it >really the case that R*RS Scheme is such a pathetically crippled >language that people _have_ to use Chez extensions all over the place? Many instances of useful Scheme code use macros. RRRS mentions no macro system, _yet_. >Any interesting examples I come up with this year I am going to send on >to Ozan Yigit, but you can be sure I'll have tried them under three >different Schemes first. I'd of course be glad to see code from you. I kinda liked "The Craft of Prolog". --d
rar@saturn.ads.com (Bob Riemenschneider) (03/16/91)
In article <1991Mar15.163509.12130@rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes: => In article <4977@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: => => >I really don't want to sound ungrateful, oh, let's be honest, I *AM* => >ungrateful. When someone says "I have some Scheme code you can use" => >and I then burn up net cycles FTPing it and then have to spend more => >of my time converting the stuff *to Scheme* than if it had been in => >Common Lisp or Pop in the first place, I am *NOT* grateful. => => Are you saying you find that you have to _rewrite_ the code instead of => defining the few procedures and macros that are not primitive in your => Scheme? For instance, probably the only non-RRRS Ch*z procedure I => would use is printf, and this is provided by Ken Dickey's format.scm. Not that I'm as ungrateful as Richard ( :-) ), but there are a number of non-standard constructs in the SLaTeX code other than the brackets: eval-when, #\255 and #\254, #!eof, and possibly some other stuff after clear-tabs. (MacScheme won't load output-line, and I haven't tried to figure out why yet -- somehow just seeing that the procedure definition consists of about 100 lines of completely undocumented code made me think it might turn out to be a tough job. Especially given the rather primitive state of the MacScheme debugger.) Each is easy to fix, but combined, they're an annoyance. -- rar
net@opal.cs.tu-berlin.de (Oliver Laumann) (03/16/91)
In article <1991Mar15.163509.12130@rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes: > Changing all ['s and ]'s to ('s and )'s using global replace is about > the easiest thing one can do. Now it's not *that* easy, there might also be square brackets in string and character constants, in comments, etc. > Are you saying you find that you have to _rewrite_ the code instead of > defining the few procedures and macros that are not primitive in your > Scheme? There are tons of things in Chez Scheme that cannot be defined by using only the functionality specified by the R*RS. For instance, there is the #& reader syntax, an error handling and reporting mechanism (error handling still isn't defined in the R*RS last time I looked), functions for exception handling, dynamic-wind and fluid-let (how are you going to define this in an R*RS-implementation?), etc. -- Oliver Laumann net@tub.cs.tu-berlin.de net@tub.UUCP net@pogo.ai.mit.edu
matthias@leto.rice.edu (Matthias Felleisen) (03/16/91)
In article <2877@kraftbus.cs.tu-berlin.de> net@opal.cs.tu-berlin.de (Oliver Laumann) writes: > ... dynamic-wind and fluid-let (how are you going >to define this in an R*RS-implementation?), etc. ... >Oliver Laumann net@tub.cs.tu-berlin.de net@tub.UUCP net@pogo.ai.mit.edu This is a standard result in the literature: {Haynes, C. and D.P. Friedman}. Embedding continuations in procedural objects. {\it ACM Trans. Program. Lang. Syst. \bf9}(4), 1987, 582--598. Preliminary version: Constraining Control. In {\it Proc. 12th ACM Symposium Principles of Programming Languages\/}, 1985, 245--254. And I suspect that Kent would be more than happy to provide you the defining SCHEME files: dyb@iuvax.cs.indiana.edu. Wrt error handling, I agree w/ you that R^{139}RRS doesn't do it right: Scheme needs errors that unlike continuations, can be caught at any place in the program. -- Matthias
dorai@titan.rice.edu (Dorai Sitaram) (03/17/91)
In article <2877@kraftbus.cs.tu-berlin.de> net@opal.cs.tu-berlin.de (Oliver Laumann) writes: >In article <1991Mar15.163509.12130@rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes: >> Are you saying you find that you have to _rewrite_ the code instead of ^^^^ >> defining the few procedures and macros that are not primitive in your >> Scheme? > >There are tons of things in Chez Scheme that cannot be defined by using >only the functionality specified by the R*RS. For instance, there is Oliver, bitte nehmen Sie meine Ausdruecke nicht aus ihrer Kontinuation. ;-> I'll be the first to agree that Ch*z has stuff that's impossible to define in other Schemes (foreign-lang interface, system commands, among other things). My comments were limited to one little(!) piece of trilingual and hardly pedagogical code written for LaTeX users (and as such probably has no business being in the repository -- but, thanks, Ozan!). (As Bob Riemenschneider shows, the #!eof, etc., do require "easy but annoying" rewriting.) --d
net@opal.cs.tu-berlin.de (Oliver Laumann) (03/17/91)
In matthias@leto.rice.edu (Matthias Felleisen) writes: > > ... dynamic-wind and fluid-let (how are you going > >to define this in an R*RS-implementation?), etc. > ... > This is a standard result in the literature: > {Haynes, C. and D.P. Friedman}. Embedding continuations in procedural > objects. [...] Thanks for the reference. I realize that it must be possible to write a procedure in R*RS-Scheme that accomplishes the same functionality as Chez Scheme's fluid-let, but note that fluid-let is a special form. There is no language construct in the R*RS (yet?) that allows one to define a new special form. Thus, you *still* have to edit each occurrence of fluid-let in a Chez Scheme program in order to make it R*RS-conforming. -- Oliver Laumann net@tub.cs.tu-berlin.de net@tub.UUCP net@pogo.ai.mit.edu
oz@yunexus.yorku.ca (Ozan Yigit) (03/18/91)
In article <2884@kraftbus.cs.tu-berlin.de> net@opal.cs.tu-berlin.de (Oliver Laumann) writes: >Thanks for the reference. I realize that it must be possible to >write a procedure in R*RS-Scheme that accomplishes the same >functionality as Chez Scheme's fluid-let, but note that fluid-let is a >special form. Actually, there is another reference that shows that fluid-let may require a bit more than simple syntactic extension for implementation in order to avoid interfering with tail-recursion. B. Duba, M. Felleisen, D. Friedman, ``Dynamic Identifiers can be Neat'' Indiana University Computer Science Technical Report No. 220, April 1987 ... oz