Re: Iteration in lisp

Duane Rettig <duane@xxxxxxxxx> writes:

However, there is absolutely a very good reason for doing this warning
in other situations - namely, in compiled code.

In my personal opinion (i.e., not an attempt to interpret the spec):

I agree that style warnings for all manner of things in compiled code
is fine, because they are suppressable ... with the caveat that
in implementations that implement eval by

(defun eval (x)
(funcall (compile nil `(lambda () ,exp))))

I think they should suppress style warnings that might be given by
the file compiler or even perhaps explicit uses of COMPILE. Because
compile is sub-primitive here, the implementation shouldn't take its
incidental use of compilation as an excuse to overwhelm the user with
random output.

And interactively, with an immediate funcall, the user will find out
soon enough about the style problem.

My remarks were about the ability to do things like automatic
programming by cobbling together bits of code and EVAL'ing it.


That reason is, in a
single word: "spelling". In reality, lisp programs which are
candidates for compilation are less likely to have (setq x 1) for a
form, and more likely to have a form that looks something like
(setq *long-variable-with-spelling-that-doesnt-match-its-defunition*
1) for which it may be hard to see the mistake (how long did it take
for you to find it?). In this case it is likely that no actual
variable looks like this one, and thus it is likely that this name is
a mistake.

And even so, with EVAL, I'd rather not know and find out at runtime.

- - -

The reason for my remark was particularly aimed at two camps:

(1) The extreme camp that says "oops, you misspelled something. I've
helpfully autodeclared it pervasively special." I think this is
really definitely not good.

(2) The moderate but still unwanted-by-me situation of taking

TOPLEVEL-LISP-PROMPT> (setq x 3)

or a programmatic call to (eval '(setq x 3))

as an opportunity to lecture the person about how x is undeclared and
maybe you don't really mean for it to be special. As I said, I can tolerate
it being silently taken as lexical in an implementation that wants to offer
such support, even by default. But what I don't want to be told is "I'm not
going to do something cool and innovative, nor am I even going to do the
obvious only thing that's left to do in the absence of something cool and
innovative--I'm just going to tell you that Lisp is hard to use and that you
should have an unpleasant interactive experience."

I actually don't know which implementations do this. I just know people
complain that some do and seem not to like writing SETQ at toplevel.
I have found Lisp very hard to teach with DEFVAR having to be used
interactively in a teaching session, because that forces me to have to use
*'s or have non-*'d variables end up pervasively SPECIAL. So it's the cascade
of those two things that troubles me. I want to use non-*'d variables in
early teaching, and so I want to use SETQ on them, not DEFVAR.

.

Relevant Pages

  • Re: lambda-returning defmacro, capture
    ... (setq fff 10)) ... most extent implementations treat ... caught at runtime if you haven't (def* fff ...) before running tst. ... special variable and so at compile time, ...
    (comp.lang.lisp)
  • Re: Trying to learn Common Lisp
    ... which might occur in meta-programming, ... compile the file and load ... the compiled code. ...
    (comp.lang.lisp)
  • Re: request for help with macro
    ... >>> Use of the following macro definitions in compiled code seems to cause ... Garnet is known to work with ... > Though I am able to compile this stuff with CMUCL.... ... > protect the user from seeing anything but the GUI). ...
    (comp.lang.lisp)
  • Re: circulatory analysis
    ... > clisp uses much less stack on compiled code. ... Did you compile your ... > debugging of compiled clisp programs is less easy. ... What will help, is increasing the available stack memory, though use ...
    (comp.lang.lisp)
  • Re: request for help with macro
    ... >> I'm trying to patch up some of the garnet stuff to compile with SBCL. ... >> Use of the following macro definitions in compiled code seems to cause ... Though I am able to compile this stuff with CMUCL.... ...
    (comp.lang.lisp)