Subject: [clisp-list] default settings of *load-compiling* and *print-pretty* (naive be nchmarks)

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Fri Aug 1 05:26:19 2003

Hi,

the recent thread in comp.lang.lisp started by John Proctor lead me to ask you the following:

1. Would people object if -C (*load-compiling*) were set (to true) by default?
2. What about the default value of *print-pretty*?

Ad 1 pros and cons:
+ benchmarks à la "time clisp hanoi.cl" would yield much much
  improved times (should beat Python any time).
+ other implementations (MCL?) only have a compiler anyway
  and use a read-compile-funcall-print loop.
+ novices may benefit from "unused variable/undeclared variable" warnings
- novices may be confused by such warnings
- step is much less useful with compiled functions

Ad 2
*print-pretty* had been set to false for many years. It was only not too long ago that the decision was made, IIRC based on "todays machines are fast enough" reasoning, to set it to true in the default configuration.

I'm unsure whether Proctor's program would have been or was much affected by the value of *print-pretty* in CLISP (it made a lot of a difference with CMUCL).

What do CLISP users think?

Regards,
	Jörg Höhle

---

From: Douglas Philips <[email-masked]>
Date: Wed Aug 6 14:52:09 2003

> 1. Would people object if -C (*load-compiling*) were set (to true) by 

YES!
ARG!

> - step is much less useful with compiled functions

How would I turn it off? Would -C on the command line mean not to do 
that?

What's worse (in the 2.30 version I tested, maybe this is fixed in 
latest CVS head??)

% cat lose.lisp
(let ((x 0))
         (defun worker () (incf x))
         (defun sample()
                 (worker)
                 x))

% clisp -C -i lose.lisp
...
;; Loading file lose.lisp ...
WARNING in SAMPLE :
Function WORKER is not defined
;; Loaded file lose.lisp
[1]>

So, if I cannot use closures "at the top level" without getting 
gratuituous and annoying messages with -C then -C should not be the 
default.

And it would be so nice if it really did "the right thing"... in which 
case I would support it.
<D\'gou

---

From: Sam Steingold <[email-masked]>
Date: Thu Aug 7 15:03:05 2003

> * In message <[email-masked]>
> * On the subject of "Re: default settings of *load-compiling* and *print-pretty* (naive be nchmarks)"
> * Sent on Wed, 6 Aug 2003 17:49:59 -0400
> * Honorable Douglas Philips <[email-masked]> writes:
>

actually, if you set *load-compiling* to T and save the image, you will
get the behavior Jorg proposed, so the issue is relevant regardless of
whether the proposal passes.

I guess we need -noC (or -!C) to revert the effects of -C, so that

$ clisp -C -i foo.lisp -x (saveinitmem)
$ clisp -M lispinit.mem -noC -i bar.lisp

will load bar.lisp without compiling (now it will compile it).

> What's worse (in the 2.30 version I tested, maybe this is fixed in

indeed, this has been fixed in the CVS head.

> And it would be so nice if it really did "the right thing"... in which

please try CVS head.
(you will probably want to read the 200+ lined of src/NEWS)
<http://cvs2.cons.org/ftp-area/clisp/snapshots/NEWS>

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
MS: our tomorrow's software will run on your tomorrow's HW at today's speed.

---

From: Pascal Bourguignon <[email-masked]>
Date: Tue Aug 19 05:34:02 2003

> 1. Would people object if -C (*load-compiling*) were set (to true)

- You'd have to keep the -C option for compatibility with existing scripts.

- You'd have to add a new option to prevent compiling at load time.

- People would have to remember to  use this new option to get useful
  debugging information.

- People would have  to remember removing it once  they put their code
  in production.

I don't see the advantage to have it the other way, once a choice have
been made to have it this way.  I would prefer not change it.

> 2. What about the default value of *print-pretty*?

I've got *print-pretty* set to T  and this does not bother me.  What's
the problem?

> *print-pretty* had been set to false for many years. It was only not
> *too long ago that the decision was made, IIRC based on "todays
> *machines are fast enough" reasoning, to set it to true in the
> *default configuration.
> 
> I'm unsure whether Proctor's program would have been or was much
> affected by the value of *print-pretty* in CLISP (it made a lot of a
> difference with CMUCL).
> 

-- 
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.