From ... From: Erik Naggum Subject: Re: A modest proposal (long) Date: 2000/03/02 Message-ID: <3160966858202840@naggum.no> X-Deja-AN: 592108380 References: <3160942638240195@naggum.no> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 951978063 5185 195.0.192.66 (2 Mar 2000 06:21:03 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 Mime-Version: 1.0 NNTP-Posting-Date: 2 Mar 2000 06:21:03 GMT Newsgroups: comp.lang.lisp * Erann Gat | The problem is not special variables. The problem is the way you tell | Lisp which variables you want to make special and which you don't. so let me disagree vociferously with that, too. if we make necessary things inconvenient to express, it is not their expression that will suffer the most, but common recognition of their necessity. the fact that special variables solve a problem that exist in _every_ programming language so conveniently, namely how to ascertain proper restoration of global variables, means that people aren't going to reinvent tricks with unwind-protect and the like (if they know about unwind-protect -- Kent Pitman has made the cogent argument that languages can be judged on the existence of such a language feature -- I'll argue that the same applies to programmers and whether they know about it). as soon as you start to make these special variables stand out as the wart on the language that you appear to believe they are, people will naturally avoid them (and the more so the more weirdo syntax soup you introduce, the threat of which I now realize is part of my objection to your syntax-heavy proposal), and choose the next best thing that looks like it could be sufficiently convenient. then they start to make buggy or needlessly verbose code, which they'll loathe. you're rocking the boat and making life miserable for those who _need_ special variables and need them _not_ to look _too_ special, because that destroys their very significant convenience factor. I say: don't do that. solve the actual problems, don't just push your special brand of cosmetics. | The issue is not just one of querying. It's also one of control. There's | no way to undo the effects of a defvar short of uninterning the symbol. so let's find a way to do that, instead, then. (how hard can this be?) I think a Common Lisp environment needs universal functionality to "undo" or "kill" all definition forms. Allegro CL has a nifty feature to kill various definitions from the Emacs interface, and I use it seldom enough to appreciate it very highly every time, but it does not accept defvar. (I'll file a request for enhancement for that.) this might be considered annoying, but in the meantime, here's a couple tiny functions to muck with the gory internals of symbols in a way that is guaranteed to make a whole slew people want to puke violently, but if they get over it and realize that Common Lisp is all about _exporting_ an elegant interface to lots of really hairy stuff to begin with, they might actually rejoice and use these functions. (in-package :excl) #+allegro-v5.0.1 (defun symbol-special-p (symbol) (declare (optimize (speed 3) (safety 0)) (symbol symbol)) (check-type symbol symbol) (if (and (not (eq nil symbol)) (zerop (ldb (byte 1 #.(system::mdparam 'compiler::md-symbol-flag-constant-bit)) (excl::sy_flags symbol)))) (not (zerop (ldb (byte 1 #.(system::mdparam 'compiler::md-symbol-flag-globally-special-bit)) (excl::sy_flags symbol)))) nil)) #+allegro-v5.0.1 (defun (setf symbol-special-p) (special symbol) (declare (optimize (speed 3) (safety 0)) (symbol symbol)) (check-type symbol symbol) (if (and (not (eq nil symbol)) (zerop (ldb (byte 1 #.(system::mdparam 'compiler::md-symbol-flag-constant-bit)) (excl::sy_flags symbol)))) (setf (excl::sy_flags symbol) (dpb (if special 1 0) (byte 1 #.(system::mdparam 'compiler::md-symbol-flag-globally-special-bit)) (excl::sy_flags symbol))) (error "Cannot change special status of constant symbol ~S." symbol))) perhaps needless to say, you can hurt your Allegro CL system with the latter function, even though I have tried to restrict a few particular damages that users are likely to try (and I know how to restrict). if you don't have Allegro CL 5.0.1, this won't necessarily fail, but _you_ had to remove the read-time conditionals so _you_ take the responsibility. | > again, there is a need to change the language to make it more amenable to | > beginners and experienced users alike: unlike all other languages now in | > current and widespread use, Common Lisp violates the notion that what you | > see is what you get with respect to the _names_ of the symbols. | | Maybe it would help to review the distinction between a variable and a | symbol (and the name of a symbol) just to make sure we are all on | the same page. find, but sometimes, it isn't everybody else who need to be on your page. | The point is that none of this has anything to do with symbol names. duh. I'm trying to redirect your attention to a worth-while problem, entirely _away_ from messing with stuff you shouldn't be messing with. | I thought that's what I was doing, but it seems I still have not made | myself clear. You seem to think that I am saying that the problem is | the existence of dynamic variables and symbol-value. I'm not saying | that at all. What I am saying is that the way things currently stand, | when you write 'X' you can't in general know whether what you've written | is a reference to a stack frame or a slot in an object on the heap. | And, in fact, as you yourself pointed out the meaning of X can change | over time if you are running interpreted. IMO that's bad. and IMNSHO, it isn't bad at all. I have pointed out that we need a few accessors into the environment to solve your uncertainty problem, and perhaps we need a `notspecial' or `lexical' declaration to be able to undo the pervasive effects of the `special' declaration. however, I care so much about the language that I'm unwilling to consider your proposal when I understand the issues so much better than you do and I consider your proposal to be a major disturbance over a petty issue that mainly has to do with a disportional sense of uncertainty. now, I fully recognize that uncertainty is one of those things that make people go nuts and that it is vitally important in a community to avoid swarms of neurotics who run around with proposals that are mainly intended to affect their mental state in some vaguely positive way, so I instead propose something that will make the uncertainty go away by adding a very low-level certainty instead of making any changes to superficial features that will take yet more forms as the swarm of neurotics has only been decimated for now, not actually cured of their unhealthy uncertainty. | > it's not a question of case, | > it's a matter of making (setf (readtable-case *readtable*) :preserve) | > work the way people _actually_ expect it to. think about it. please. | | It would help if you would stop talking in riddles. geez. there are no riddles. I'm talking about something other than you do, because I think what you're talking about is counter-productive. you missed that point entirely when you thought I was still talking about your concerns over specialness when I talked about symbol names. I'm a little concerned with the breakdown of communication that occurs when people don't notice that others aren't talking about the same thing they are, anymore, but just keep on and on about whatever they had in mind. | Works the way I'd expect it to. so try typing in (setf (readtable-case *readtable*) :upcase) and tell me what you expect to happen and/or that this is not a useful thing to do. (note again that this is no longer a question of special variables.) #:Erik