oz@yunexus.yorku.ca (Ozan Yigit) (03/18/91)
In article <1991Mar15.163509.12130@rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes: >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 :-<. I hope not. The repository is intended to share code, hopefully as painlessly as possible, and currently (unfortunately) without any guarantee that anything in it is necessarily R^nRS compliant. On the other hand, I do try to spend the time on such conversions whenever I get a chance, and that R^nRS-ness is one of the goals of the repository. I also encourage those who have done such conversions to share their code, and try to identify either a) implementation specificity or b) need for conversion help. I have no interest in wasting anybody's (nor my own) time, but, what would you like me to do with something like "zebu" which has a selection of non-standard C-scheme-isms? I think it is interesting and useful, so it is in the repository. >Many instances of useful Scheme code use macros. RRRS mentions no >macro system, _yet_. I have have included Kent Dybvig's extend-syntax stuff in the repository. The file syntax.sha contains the MacScheme [posted] version [I think this one is most up-to-date but please send me any fixes], the Dbyvig original, and a MIT C-scheme version etc. I would guess that any code using the es stuff will require the least amount of work to adapt to the upcoming R4RS macros. [I say yeys!!hallelujah!! ;-)] oz --- In seeking the unattainable, simplicity | Internet: oz@nexus.yorku.ca only gets in the way. -- Alan J. Perlis | Uucp: utai/utzoo!yunexus!oz
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (03/18/91)
In article <21900@yunexus.YorkU.CA>, oz@yunexus.yorku.ca (Ozan Yigit) writes: > In article <1991Mar15.163509.12130@rice.edu> dorai@titan.rice.edu > (Dorai Sitaram) writes: > >I'm posting this rather than just emailing Richard since people seem > >to listen when he talks ;-> Be sure I did receive E-mail. Not terribly informed E-mail, but vehement. > and it's likely that his discomfort with > >Ozan's repository becomes contagious :-<. > I hope not. I hope not too. I think the _idea_ of the repository is excellent, I think Ozan Yigit deserves heart-felt praise for doing it, and I hope that it grows. Nor do I see any objection to having system-specific code in it. For example, there was some PC-scheme-specific stuff mentioned in this newsgroup, and it would be good to have stuff like that in the repository. My objection was not to having dialect-specific code in the repository, but to having dialect-specific code which is not LABELLED as dialect- specific. SLaTeX was not as it happens the program I had in mind, though it is rather more Chez-specific than the ones I was thinking of. Let's briefly consider the question of square brackets. It is not a trivial matter to hack them with an editor script (comments, strings, characters, escapes inside symbols if you have them). That's why I hacked an #ifdef into Elk. More to the point is that I did this with great trepidation. Square brackets are not part of Scheme or Common Lisp syntax, and I have no Chez Scheme manual. So when I see [eq? x y] in what is purportedly Scheme code, I genuinely DO NOT KNOW WHAT IT MEANS. It was a *guess* that I could replace the square brackets by parentheses, ONLY a guess. Square brackets could have been embedded Prolog, or escapes to an underlying Common Lisp, or syntax for some kind of evaluated vectors, or ... I've met all _sorts_ of things using square bracket syntax in the past, that's precisely why they're not in the standard. The same applies to all the other extensions. Maybe I _could_ hack them IF I KNEW WHAT THEY MEANT. To someone who _has_ a Chez Scheme manual as well as the R^3.99RS it may be obvious how to translate everything. The point of writing to the standard whenever you can is that other people may not have the same manuals as you, but they do have the same standard. -- Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.
greg@vis.UUCP (03/19/91)
There is a serious problem with hand translating popular scheme
programs into everyone's favorite dialects. This splits the programs
into incompatible versions which develop separately and require
retranslation every time an interesting new version becomes available
(in the original dialect or in the derivative versions). I have a
proposal for how the dialect problem can be handled which minimizes
this problem. This is also a good opportunity to address at a
practical level the sufficiency of the Scheme standard. Here is my
proposal:
(1) Non-standard scheme code should be kept in the repository in a
directory named for the dialect, e.g. chez-scheme, mit-scheme, etc.
(2) Dialect conversion software for all of the popular dialects should
be strongly solicited. It should include:
(2a) Standard scheme implementations of as many features as possible.
(2b) Implementations of the features which need to be macros using
both the extend-syntax feature and (as soon as its ready) the R^4
macro mechanism.
(2c) A standardizing scheme preprocessor (SPP) which translates files
written in extended-scheme dialects into either the standard dialect
or a supported non-standard dialect. The SPP needs to handle (i)
non-standard lexical notations, (ii) include files (a feature of some
scheme dialects), (iii) expand macros (if desired), and (iv) any
remaining features which cannot be implemented with procedures or
macros, e.g., include files. One SPP program should be sufficient as
long as it is given the source and destination dialects as parameters.
(3) As soon as a piece of non-standard scheme can be standardized
using the methods in (2), it should be moved to the standard scheme
directory in the repository. However, it is important that this not
be done if *any* hand massaging of the code is still required. I
should be able to use code from the standard scheme repository as
follows:
(3a) Suppose that I'm using standard scheme and that the code I want
to use was written, for example, in Chez Scheme. Then I should (i)
run SPP over the source file with the parameters ('chez-scheme
'standard-scheme) and (ii) load the new source file with the standard
version of the library functions called for (which need to be in the
repository).
(3b) Suppose that I'm using, e.g., R4-scheme and the code was written
for Chez Scheme. Then I should (i) run the SPP over the source file
with the parameters ('chez-scheme 'r4-scheme), (ii) load it with
either the standard or the R4 library functions called for plus the R4
version of the Chez macros (in short, with the R4 version of the Chez
extensions).
An arrangement like the above has several benefits: (i) It allows
scheme programmers to maintain their local copy of any major program
in the original dialect, so they can share their fixes and
enhancements, and (ii) it allows for easier experimentation with new
language features, assisting in the evolution of the standard language
without losing portability or requiring the standard language to
implement features which may not maintain their popularity.
One of the important features of the lisp-based languages is that its
relatively easy to write programs which do processing on scheme
programs. Doing this without losing comments and with minimal
disruption to the layout of the original code is a bit more difficult,
but not very difficult and should be a good challenge for scheme
programmers. Scheme implementors should be discouraged from adding
extensions which can't be mechanically preprocessed into standard
Scheme. Ideally experimental features would be put into the
preprocessor before integrating them into the
reader/compiler/interpreter of some Scheme dialect. A simple
extension to any Scheme dialect would be to run the SPP automatically
when loading or compiling files, inferring the source dialect from the
file's extension. That way, there is no need for most extensions to
ever be part of the local scheme implementation.
_Greg
J. Greg Davidson Institute for Software Research and Development
+1 (619) 452-8059 6231 Branting Street San Diego, CA 92122 USA
greg@vis.com ucbvax--| telesoft--|
vis!greg@nosc.mil decvax--+---ucsd----+--vis
vis!greg@ucsd.edu ihnp4--| nosc----|oz@yunexus.yorku.ca (Ozan Yigit) (03/19/91)
In article <4990@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >My objection was not to having dialect-specific code in the repository, >but to having dialect-specific code which is not LABELLED as dialect- >specific. Richard, I am sorry. You are right. I will correct this in the source files where it is not already so labelled, and in README also, which did give some indication of dialect-specificity, [like "Chez version of ... blurt"] but I must have missed some. [Grumble] My sincere apologies for any inconvenience this has [already] caused. I will post an update on this issue once this is done. oz --- In seeking the unattainable, simplicity | Internet: oz@nexus.yorku.ca only gets in the way. -- Alan J. Perlis | Uucp: utai/utzoo!yunexus!oz