Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!ai-lab!zurich.ai.mit.edu!jaffer
From: jaffer@zurich.ai.mit.edu (Aubrey Jaffer)
Newsgroups: comp.lang.scheme
Subject: Re: Named constants in Scheme
Message-ID: <JAFFER.91May21223843@aarau.ai.mit.edu>
Date: 22 May 91 02:38:43 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@ai.mit.edu
Organization: M.I.T. Artificial Intelligence Lab.
Lines: 24
In-reply-to: jinx@zurich.ai.mit.edu's message of 21 May 91 23:17:08 GMT

>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.