I take this discussion to be on the default behaviour of cmucl, and
how "newbie-friendly" it is. If I'm wrong, please ignore this message.
I think that the default behaviour of cmucl is rather unacceptable.
* If you are learning lisp, you are consing a lot and this means pages
and pages of silly GC messagery that you don't care about and that
scroll off the results of your previous interactions.
* (setf x 1) Defines a special out of the box. No newbie knows what a
special is, and few can understand it before they have some
experience. And it bites. It bites HARD and it looks like a bug in
cmucl when it does so.
having ext:*top-level-auto-declare* default to nil would still give
a warning without giving newbies hell.
I think the defaults of these settings should be newbie friendlier.
Expert users can then change them if they feel like it. I think the
cost to the expert users of changing the defaults to these values
would be zero, while the benefits for newbies would be large.
Just my two cents.
Regards,
Mario.
Fred Gilham <[EMAIL PROTECTED]> writes:
> > > Newbies should know what happens when you define things at
> > > toplevel and wonder why things don't behave the same anymore.
> > > (I've been bitten by this many times when I just wanted to do
> > > something quick and named a variable X, which is also used on
> > > other code.)
> >
> > So you are saying that the PRESENCE of the warning means you are
> > safe, right? When you get the warning, you are declaring a new
> > special and therefore will not be affecting existing
> > definitions. Things will behave as they had. When you DON'T get the
> > warning, you may be setting a special defined elsewhere, and thing
> > might not behave the same anymore.
> >
> > I don't think newbies are going to follow that line of
> > reasoning. More likely, when they see a warning, they are going to
> > think they are doing something wrong.
> >
> > Maybe the warning should read, "Good choice of names, this special
> > isn't used elsewhere". ...I must be missing something!
> >
> > I think there is a real problem of a related sort elsewhere:
> > ~/> lisp -noinit
> > * (defun hello () dlkfj)
> >
> > HELLO
> > *
> >
> > ...Here, I wouldn't mind a warning that dlkfj is assumed special.
>
> It would be a really bad idea to remove the warning about special
> variables. You could argue that CMUCL shouldn't create special
> variables when you do setf at the top level --- that is a sufficiently
> good argument that people have created a flag to make the behavior
> customizable. But if CMUCL is going to create special variables with
> setf, it should certainly warn about it. After all, just because
> you're not using a variable named "foo" when you create it at the top
> level with setf doesn't mean it won't pop up later.
>
> Another, practical reason is as follows.
>
> * (setf *gc-verbse* nil)
> Warning: Declaring *GC-VERBSE* special.
>
> NIL
> *
>
> Can you see what happened here? I tried to set *gc-verbose*, but
> mistyped it. I got a nice warning that I had done something I hadn't
> intended to. Then I can go back and properly type it in:
>
> * (setf *gc-verbose* nil)
>
> NIL
> *
>
> A number of times this has saved me from wondering why the thing I
> wanted to happen didn't happen.
>
> As far as your example, the "dlkfj" in your hello function is not a
> special variable, it's an undefined free variable. That's a different
> ball of wax. And you will get a warning if you compile:
>
> * (defun hello () dlkfj)
>
> HELLO
> * (compile 'hello)
> ; Compiling LAMBDA NIL:
> ; Compiling Top-Level Form:
>
> ; In: LAMBDA NIL
>
> ; (BLOCK HELLO DLKFJ)
> ; Warning: Undefined variable DLKFJ
> ; ;
>
> ; Warning: This variable is undefined:
> ; DLKFJ
> ;
>
> ; Compilation unit finished.
> ; 2 warnings
>
>
> HELLO
> NIL
> NIL
> *
>
>
> In actual development it's best to use an IDE like Ilisp or Slime
> (Slime is really good!) or even Hemlock. When you use one of them,
> you find yourself compiling everything incrementally and you can see
> the results on a function-by-function basis. When I try to develop
> without one of the above I feel like I've got one hand tied behind my
> back.
>
> It will let you easily compile everything so you can see the warnings
> and it will also (especially if you use Slime) hide most or all of the
> noise CMUCL will otherwise give you.
>
>
> --
> Fred Gilham [EMAIL PROTECTED] || Progressive (adj): Value-free;
> tolerant; non-judgemental. E.g. traditional archery instruction
> methods spent tedious hours teaching the archer to hit a bulls-eye.
> Progressive methods achieved better results by telling the student
> archer to shoot in the manner he or she found most comfortable, then
> calling whatever the arrow hit the bulls-eye.
