Xref: utzoo comp.lang.lisp:4537 comp.lang.scheme:2019 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!mintaka!ai-lab!gerber!jaffer From: jaffer@gerber.ai.mit.edu (Aubrey Jaffer) Newsgroups: comp.lang.lisp,comp.lang.scheme Subject: Re: Scheme as an Algol-like, not Lisp-like, language Message-ID: <13573@life.ai.mit.edu> 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. 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.