Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!att!ihlpf!lgm
From: lgm@ihlpf.ATT.COM (Mayka)
Newsgroups: comp.lang.lisp
Subject: Re: Unix Lisp Environments (why the slow evolution)
Summary: Keyword-named macros, keyword arguments might help
Keywords: resistance to lisp
Message-ID: <8610@ihlpf.ATT.COM>
Date: 28 May 89 20:37:15 GMT
References: <31670@sri-unix.SRI.COM> <469@skye.ed.ac.uk> <1028@syma.sussex.ac.uk>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 52

In article <1028@syma.sussex.ac.uk>, aarons@syma.sussex.ac.uk (Aaron Sloman) writes:
> By contrast, POP-11 uses a large variety of keywords to distinguish
> syntactic contexts, instead of relying so much on POSITION to
> determine significance. Parentheses are used for procedure calls in
> the normal way, but distinct brackets are used for list expressions
> "[...]" and vectors "{...}" and this also helps to reduce cognitive
> load during reading. (This sort of thing is particularly important
> when large programs have to be maintained by programmers who were
> not the original authors.)

Common Lisp has the ability to handle

	1) Keyword-named functions, macros, and special forms.
		These make the function, macro, or special form look
		more like "constant" syntax that the ordinary
		programmer should not redefine.  Helps it to look
		more like syntax and less like dumb data.

	(defmacro :if (test &key then else)
		`(if ,test ,then ,else)
		)

	(:if x
	   :then y
	   :else z
	   )

	2) Keyword arguments to functions, macros, and special forms.
		Makes syntax less dependent on position, more mnemonic.
		The cost for macros and special forms is only at
		compile time.  Even for functions, keyword arguments
		need not be unduly expensive.

	3) Alternate grouping characters.  Characters such as  [ ]
		and  { }  can be redefined as synonyms for  ( ) , with
		the restriction that opening and closing character
		must match.  A convention could even be agreed upon that,
		for example,  { }  be used for lists that are clearly
		dumb data, leaving  ( )  more clearly as the function-
		calling syntax.

All this can be done within Common Lisp itself.  There need be no
confusion if such constructs are used uniformly within a given
software project.

Has anyone ever considered a plan like this - for the sake of
timid souls who are intimidated by Lisp's "native" syntax?


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@ihlpf.att.com