From ... From: Erik Naggum Subject: Re: Q: 101 Buzzwords in Scheme Date: 1998/01/02 Message-ID: <3092758408130571@naggum.no>#1/1 X-Deja-AN: 312192931 References: <685r5q$5tf$1@nntp1.ba.best.com> <34A6D530.23E7@sonic.net> <68e08l$krc$1@agate.berkeley.edu> <68j8sg$gn3$1@agate.berkeley.edu> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.scheme,comp.lang.lisp * Brian Harvey | First of all, it's unfortunate that there are notations '# and #' whose | meanings are unrelated. is '# a notation? for what? # is a dispatching macro character in Common Lisp -- it takes another character to become a reader macro function. Scheme has this implicitly, too, in the vector syntax: #(...). but this is like saying that since #(:foo) is a vector of one keyword and (#:foo) is a list of an uninterned symbol, something is "unfortunate" in the syntax. I don't buy this (rather silly) argument at all. | And in the case of #' the meaning has nothing to do with quotation. #(...) has nothing to do with lists, either. #:... has nothing to do with keywords, #+... has nothing to do with the plus operator, etc, for all #x and x. what's the big problem? on other hand, (mapcar #'foo ...) replaced (mapcar 'foo ...) and in many cases, #'(lambda ...) replaced '(lambda ...), so it is not as unrelated as you seem to want it to be, | More deeply, I find it confusing that the meaning of (function foo) | has very little to do with the meaning of (function (lambda ...)). | The first is a selector, extracting an existing piece of information | from a data structure; the second is a constructor, creating a closure. it's amusing to see how mistaken you are when you criticize Common Lisp, almost to the point of being ridiculous. I wanted to comment on this previously, too, but it's not very constructive, however, when it goes on and on unchecked, you do need correction. the accessor you allude to is `symbol-function'. it only works on symbols, but `function' works on function names, which also exist in the lexical environment, where they aren't symbols any more than lexical variables are. | But then, I don't like the way SETF blurs the distinction between list | mutation and variable rebinding, either. My students have enough trouble | keeping it straight when they are restricted to distinct SET! and | SET-CAR! notations. This is the same sort of issue, I think. "list mutation"!? `setf' is a lot more than that. indeed, from the history of the name that I obtained this newsgroup (I believe that, too, was Kent Pitman giving a lecture :), it's from "set field", and referred initially to fields in structures, but grew into a more general mechanism. I don't see the problem with this, either. (setf variable value) is very obviously very different from (setf (car variable) value) and it would take a serious amount of _misunderstanding_ to confuse the two. however, (setf symbol value) is like (setf (symbol-value 'symbol) value), which is also a mutator of a slot in a data structure, this time a symbol. (this is also the old (set 'symbol value) in a new wrapping.) personally, I think Scheme's lack setf and its insistence of a pre-setf mode of writing mutators is really _ugly_. #\Erik -- The year "98" was new 1900 years ago. | Help fight MULE in GNU Emacs 20! Be year 2000 compliant, write "1998"! | http://sourcery.naggum.no/emacs/