doug@snitor.uucp (Doug Moen) (05/19/91)
chip@soi.UUCP (Chip Morris) writes: >The question is, can a language supply us with a >suitably general, regular style and still permit the kind of analysis >that frees the programmer from worrying overmuch about efficiency in >the small, when, in the last stages, it becomes important? >Perhaps one must grudgingly admit an analysis advantage to Common >Lisp's otherwise distressingly assymetrical treatment of the function >position. >I think that a Schemer's valid excuse should be "oh, my program >doesn't change the meaning of EQ, CAR, etc." And maybe s/he should be >able to rely on analysis tools to assert this to a compiler in the >bulk of cases where it can be deduced. >A laudible goal for a language design is that "simple" programs >can be analyzed as such and efficiently compiled. To what extent does >this conflict with conceptual regularity and generality? Scheme would have the same "analysis advantages" as Common Lisp if it supported named constants; ie, variables which are given values when they are defined, but which cannot be reassigned. We would also want to loosen up the standard to permit primitive procedures to be defined as constants, rather than as variables. This solution is more regular and general than the asymmetric treatment of the function position in Common Lisp, because it permits expressions such as (* pi 2) to be evaluated at compile time, rather than run time, without the need for global program analysis. (This assumes that both * and pi are defined as constants.) Many procedural languages (eg, Algol 68, Pascal, C, Common Lisp) support named constants; why not Scheme? -- Doug Moen | doug@snitor.uucp | uunet!snitor!doug | doug.tor@sni.de (Europe)
sfk@otter.hpl.hp.com (Steve Knight) (05/21/91)
The named constant solution Doug writes about is very natural for Scheme. Pop11 adopts essentially this solution without any significant drawbacks. Note that one can only optimise (* pi 2) given that '*' is side-effect free and the result is immutable and uniquely allocated. Steve
jinx@zurich.ai.mit.edu (Guillermo J. Rozas) (05/22/91)
Many procedural languages (eg, Algol 68, Pascal, C, Common Lisp)
support named constants; why not Scheme?
Some of us in the community, and in the reports authors group, do not
like having different classes of variables. We believe that all
variables are created equal, and thus all of them are inherently
mutable.
In addition, we believe that user programs have precedence over the
system, and thus if a program decides to define its own CAR variable
and use it in whatever way it pleases, it should be allowed.jaffer@zurich.ai.mit.edu (Aubrey Jaffer) (05/22/91)
>Some of us in the community, and in the reports authors group, do not >like having different classes of variables. We believe that all >variables are created equal, and thus all of them are inherently >mutable. But when macros are finalized we WILL have 2 different classes of variables. Lets use the same environment for constants as for macros. I point out that if macros (and constants) are syntactically distinguished, it is immediately appearent which symbols are constants. Having constants allows me to use nmemonic names in case statements. Here would be code for a fortran style 3-way if: (&defconstant &.LT. -1) (&defconstant &.EQ. 0) (&defconstant &.GT. 1) (case (if3 (< x y)) ((&.LT.) (do_x)) ((&.EQ.) (do_nothing)) ((&.GT.) (do_y))) This does not solve the problem of redefining system routines.
alan@lcs.mit.edu (Alan Bawden) (05/23/91)
In article <JAFFER.91May21223843@aarau.ai.mit.edu> jaffer@zurich.ai.mit.edu (Aubrey Jaffer) writes: But when macros are finalized we WILL have 2 different classes of variables. Lets use the same environment for constants as for macros. Good grief, I certainly hope not. I thought one of things we all agreed upon was that names for variables and names for syntax belonged in the same namespace. But perhaps I misunderstand what you mean by "classes of variables".
oz@ursa.ccs.yorku.ca (Ozan Yigit) (05/23/91)
jinx@zurich.ai.mit.edu (Guillermo J. Rozas) writes:
Some of us in the community, and in the reports authors group, do not
like having different classes of variables. We believe that all
variables are created equal, and thus all of them are inherently
mutable.
Are you talking about theory or practice? Why is it acceptable, for
example, to have language extensions like (define-integrable blah foo)
or (declare (usual-integrations)) and *not* acceptable to have
something like (constant foo whatever) ??
We know all variables are created equal, but it seems some variables
and implementations are more equal then others. ;-)
oz
---
In seeking the unattainable, simplicity | Internet: oz@nexus.yorku.ca
only gets in the way. -- Alan J. Perlis | Uucp: utai/utzoo!yunexus!ozjinx@zurich.ai.mit.edu (Guillermo J. Rozas) (05/23/91)
In article <OZ.91May22172840@ursa.ccs.yorku.ca> oz@ursa.ccs.yorku.ca (Ozan Yigit) writes: Path: ai-lab!mintaka!olivea!samsung!cs.utexas.edu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!newshub.ccs.yorku.ca!newshub.ccs.yorku.ca!oz From: oz@ursa.ccs.yorku.ca (Ozan Yigit) Newsgroups: comp.lang.scheme Date: 22 May 91 22:28:40 GMT References: <chip.674143084@soi> <1991May15.172635.18635@Think.COM> <chip.674492719@soi> <1991May18.203022.9325@snitor.uucp> <JINX.91May21191708@chamarti.ai.mit.edu> Sender: news@newshub.ccs.yorku.ca (USENET News System) Organization: York U. Communications Research & Development Lines: 20 jinx@zurich.ai.mit.edu (Guillermo J. Rozas) writes: Some of us in the community, and in the reports authors group, do not like having different classes of variables. We believe that all variables are created equal, and thus all of them are inherently mutable. Are you talking about theory or practice? Why is it acceptable, for example, to have language extensions like (define-integrable blah foo) or (declare (usual-integrations)) and *not* acceptable to have something like (constant foo whatever) ?? No, you are talking about two related but different languages. MIT Scheme is not standard Scheme nor viceversa. Currently it is not even the case that correct standard Scheme programs will run on MIT Scheme (because (eq? '() #f) -> #t in MIT Scheme), and the converse is nowhere near close. Thus arguments about MIT Scheme programs do not apply. We know all variables are created equal, but it seems some variables and implementations are more equal then others. ;-) Again, the standard dialect, that perhaps no one implements, says one thing, which I believe strongly. Perhaps I should restate the goals of MIT Scheme and of the original reports. MIT Scheme is developed only to support certain CS classes and research at MIT. It has no other purpose or goal. We make it available outside because people ask for it, not because we are interested in promoting it. As such, we have never made any claims that it will adhere to standards of any sort forever, although it may do so. If there is a conflict between a standard and the requirements of the classes or the researchers, compliance with the standard will carry very little weight. RnRS Scheme was a common dialect agreed upon by various people working with dialects of Scheme so that they could read each other's code, not so that they could run it verbatim. As such, clarity in the semantics (rather than performance) were paramount. I believe this to still be the goal of the reports, and as such, efficiency-related issues are not terribly important to the authors. Nor is the intent of the reports to describe a complete implementation. The only purpose of IEEE Scheme, as far as I know, was to legitimize the choice of Scheme by some commercial ventures that were having a hard time justifying the choice of a non-standard educational language, since the reports did not carry the weight of a standards body. Most of the authors of the report grudgingly agreed to an official standard to help our friends in industry, not because we felt that it was necessary or particularly good to have. Given these constraints, I think you can understand why it is perfectly consistent to expect dialects/implementations to do whatever they please, and yet have the standard language be small and clear.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/24/91)
In article <JINX.91May23122124@chamarti.ai.mit.edu>, jinx@zurich.ai.mit.edu (Guillermo J. Rozas) writes: > Perhaps I should restate the goals of MIT Scheme and of the original > reports. > > RnRS Scheme was a common dialect agreed upon by various people working > with dialects of Scheme so that they could read each other's code, not > so that they could run it verbatim. As such, clarity in the semantics > (rather than performance) was paramount. I believe this to still be > the goal of the reports, and as such, efficiency-related issues > are not terribly important to the authors. Nor is the intent of the > reports to describe a complete implementation. > > The only purpose of IEEE Scheme, as far as I know, was to legitimize > the choice of Scheme by some commercial ventures that were having a > hard time justifying the choice of a non-standard educational > language, since the reports did not carry the weight of a standards > body. If implementations do not conform to the standard, the usefulness of Scheme as an educational language is greatly diminished. I want to give my students examples that they can _use_. I want to write tools for them that will run on the Schemes they have access to. We have here TI PC Scheme, MacScheme, Elk, OakLisp, T, Gambit (on Macs), and when I can find some time we'll have MIT Scheme. Now, () -vs- #f is something I can live with. The widely varying ways of defining macros is something I've sorted out for TI PC Scheme, Elk, OakLisp, and T, and don't expect any difficulty with for the others. But there are limits to what I have time for. There are other people writing educational stuff that I would like to be able to use, and I'd rather not have to spend a lot of time porting it. I don't _expect_ to run MIT Scheme code using bitstrings. But I shouldn't have to put a lot of effort into porting code that uses only standard data types. Recently I received a program which I would like to consider using, but I'm afraid that if RnRS Scheme was "so they could read each other's code" then it has already failed; the program is in Chez Scheme and it looks as though it'll be easier to translate some Miranda code than to figure out what the Chez Scheme stuff is up to. (If I had a Chez Scheme manual, that would be a different story, but I haven't.) -- I rejoiced that at least So-and-So could spell "hierarchical", but the _real_ explanation was that he couldn't spell "heir". -me