Xref: utzoo comp.lang.lisp:4538 comp.lang.scheme:2020 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!mintaka!ai-lab!zurich.ai.mit.edu!jinx From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas) Newsgroups: comp.lang.lisp,comp.lang.scheme Subject: Re: Scheme as an Algol-like, not Lisp-like, language Message-ID: Date: 27 Feb 91 16:47:02 GMT References: <1991Feb15.191259.20090@aero.org> <1991Feb15.223520.17267@Think.COM> <1991Feb18.191549.7575@aero.org> <1991Feb19.030719.1137@Think.COM> <4234@skye.ed.ac.uk> jaffer@gerber.ai.mit.edu (Aubrey Jaffer) writes: Path: ai-lab!gerber!jaffer From: jaffer@gerber.ai.mit.edu (Aubrey Jaffer) Newsgroups: comp.lang.lisp,comp.lang.scheme Date: 27 Feb 91 03:40:22 GMT References: <1991Feb15.191259.20090@aero.org> <1991Feb15.223520.17267@Think.COM> <1991Feb18.191549.7575@aero.org> <1991Feb19.030719.1137@Think.COM> <4234@skye.ed.ac.uk> > 4. EVAL (making use of 2). >> 5. Powerful syntactic extension facilities that make use of 2. ... >> You are right to claim that Scheme is not a Lisp because of its lack >> of 4 and 5, but >> - Every implementation of Scheme that I know of has both. SCM has neither facility. Eval makes compilation impossible without including an interpreter or compiler in the run-time support. I did not know that SCM did not include EVAL or macros. Now I do. Your comment about EVAL is no different from saying that compilation of code that does IO is impossible without including WRITE (or even more apropos, FORMAT) in the run-time support. It is perfectly possible to build a Scheme system that links only those run-time modules needed, and thus code not using EVAL would never need it. The lack of macros makes pure scheme code easily readable. I would not object to macros if they were required to be syntactically differentiated from variable names in order to preserve readability. I find when reading common-lisp code that I often don't know if a user defined symbol is a macro or a function. To make a more radical suggestion I think that scheme might do very well to NOT include macros. Introducing new syntactic constructs (macros) in order to avoid typing a few lambdas is bad programming style in that the code becomes unreadable. If a syntactic construct provides a programming paradigm not already supported by scheme then it should be added to the language. I agree that macros can be abused and often are. But I disagree with your suggestion that all common and useful constructs should be included in the language. A language can't be (and shouldn't be) that comprehensive. Furthermore, as large as the design group is, it will not include the complete community, nor will it be able to envision all paradigms. In particular, a language designed by consensus, such as the RnRS dialects of Scheme, will have a hard time adding new special forms if part of the design group feels strongly against adding them (I and many others in the MIT Scheme community feel this way). Yet I would like to be able to use WHILE, FLUID-LET and perhaps even DO* even though I might not want them in the language. It is also the case that code can become much more readable with judicious use of syntactic sugar. I find code written with FLUID-LET easier to read than code that passes many additional almost-constant parameters around, or that open-codes FLUID-LET where it would be used. WHILE is often appropriate for imperative programs, and many other special forms can be similarly defended. I don't know how to resolve the tension between providing powerful (and easily misused) tools and discouraging their abuse. Perhaps the best solution is to follow the guidelines that I once heard from Alan Bawden (my paraphrasing): - No Lisp programmer should be allowed to write macros unless s/he's been granted a license. - Alan Bawden has a license and grants all other licenses. I think this would have the properties that I (and perhaps you) desire, but is, unfortunately, infeasible and politically incorrect.