> ------------------------------------------------------------------------
> (defparameter *titles*
> '(Mr Mrs Miss Ms Sir Madam Dr Admiral Major General)
> "A list of titles tha can appear at the star of a name")
>
> (defparameter *names*
> '((John Q Public) (Malcolm X)
> (Admiral grace Murray Hopper) (Spot)
> (Aristotle) (A A Milne) (Z Z Top)
> (Sir Larry Olivier) (Miss Scarlet))
> "List of names")
>
> (defun first-name (name)
> "Select the first name from a name represented as a list"
> (if (member (first name) *titles*)
> (first-name (rest name))
> (first name)))
> --------------------------------------------------------------------------
I gave it a try,
CL-USER 2 >
*NAMES*
CL-USER 3 >
FIRST-NAME
CL-USER 4 > (trace first-name)
(FIRST-NAME)
CL-USER 5 > (first-name '(Admiral Major Paul))
0 FIRST-NAME > ((ADMIRAL MAJOR PAUL))
1 FIRST-NAME > ((MAJOR PAUL))
2 FIRST-NAME > ((PAUL))
2 FIRST-NAME < (PAUL)
1 FIRST-NAME < (PAUL)
0 FIRST-NAME < (PAUL)
PAUL
CL-USER 6 > (compile 'first-name)
FIRST-NAME
NIL
NIL
CL-USER 7 > (first-name '(Admiral Major Paul))
0 FIRST-NAME > ((ADMIRAL MAJOR PAUL))
0 FIRST-NAME < (PAUL)
PAUL
CL-USER 8 >
LWW 4.1.20
I am thinking that you compiled first-name and that the recursive call might
to tail-call optimized. Try just evaluating first-name and run it again.
Wade
"Wade Humeniuk" <········@cadvision.com> writes:
> I am thinking that you compiled first-name and that the recursive call might
> to tail-call optimized. Try just evaluating first-name and run it again.
Yes, tail-call optimization will fool the user and the trace facility,
by converting the internal calls into jumps. Besides using the
interpreter, one can also bump up the debug optimize quality, which is
always advisable when one wants to use interactive debugging aids on
compiled code. For stuff compiled from files, include
(declaim (optimize (debug 3)))
in the file containing the code and recompile+reload.
For interactive compilation using compile, do a
(proclaim '(optimize (debug 3)))
prior to your calls to compile.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> Besides using the interpreter, one can also bump up the debug
> optimize quality, which is always advisable when one wants to use
> interactive debugging aids on compiled code.
Heh, that sounds painfully obvious, but I've been bitten by this
before. "Hey, Tom, did you ever figure out what was going on in that
code?" "Uh, yeah." "How?" "Uh, I told the compiler to optimize for
debugability."
I felt pretty stupid (kinda like "why won't gdb give me useful
information?" "Did you compile with -g ?" "No"), but it's a mistake
that's a little easier to do in Lisp, and I always remember to compile
with (debug 3) when I need it, now.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
> What's the usual way of developing in Lisp? You type a function in the
> toplevel, test it there and paste it back to a file where it get's
compiled,
> type everyting into a file and evaluate it and only compile when ready for
> delivery, compile using (declaim (optimize (debug 3))), or what? :)
The way I do it in LWW is to write the function in a file with the LispWorks
Editor. Make sure the cursor is somewhere inside the defun and evaluate
the function from there using a right-mouse-click and selecting
Definitions->Evaluate or use the key bindings (#\meta-control-\x) of the
Editor. I only use the Listener when I need to run some code interactively.
If everything is working fine with the interpreted code I then compile the
function and run it again just to make sure eveything is working.
Then.... On to the next function.
Wade
······@hushmail.com writes:
> On 06 Nov 2001 23:57:12 +0100, "Pierre R. Mai" <····@acm.org> wrote:
>
> >"Wade Humeniuk" <········@cadvision.com> writes:
> >
> >> I am thinking that you compiled first-name and that the recursive call might
> >> to tail-call optimized. Try just evaluating first-name and run it again.
> >
> >Yes, tail-call optimization will fool the user and the trace facility,
> >by converting the internal calls into jumps. Besides using the
> >interpreter, one can also bump up the debug optimize quality, which is
> >always advisable when one wants to use interactive debugging aids on
> >compiled code. For stuff compiled from files, include
> >
> >(declaim (optimize (debug 3)))
>
> What's the usual way of developing in Lisp? You type a function in the
> toplevel, test it there and paste it back to a file where it get's compiled,
> type everyting into a file and evaluate it and only compile when ready for
> delivery, compile using (declaim (optimize (debug 3))), or what? :)
You type it into an Emacs buffer and (using ILISP - or Franz's ELI)
you evaluate the function in the underlying lisp. You run it and check
whether what you did made sense. All of this while you mix and match
with (re)compiling and (re)loading your "system" :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
······@hushmail.com writes:
> On 06 Nov 2001 23:57:12 +0100, "Pierre R. Mai" <····@acm.org> wrote:
>
> >"Wade Humeniuk" <········@cadvision.com> writes:
> >
> >> I am thinking that you compiled first-name and that the recursive call might
> >> to tail-call optimized. Try just evaluating first-name and run it again.
> >
> >Yes, tail-call optimization will fool the user and the trace facility,
> >by converting the internal calls into jumps. Besides using the
> >interpreter, one can also bump up the debug optimize quality, which is
> >always advisable when one wants to use interactive debugging aids on
> >compiled code. For stuff compiled from files, include
> >
> >(declaim (optimize (debug 3)))
>
> What's the usual way of developing in Lisp? You type a function in the
> toplevel, test it there and paste it back to a file where it get's compiled,
> type everyting into a file and evaluate it and only compile when ready for
> delivery, compile using (declaim (optimize (debug 3))), or what? :)
You can do whatever you feel comfortable with, or any combination
thereof. You can compile single definitions without pasting them into
a file by using compile. The (temporary) use of a debug quality of 3
is orthogonal to your other habits. You can effect this either
through the inclusion of declaim inside a file, or proclaiming it
before compiling (with either compile or compile-file).
It is similar to recompiling your application code with gcc -g prior
to using the debugger, in that it optimizes your code for better
debuggability, rather than other qualitites.
I personally develop almost exclusively inside files, which I then
either compile and load in-toto (often using a DEFSYSTEM facility), or
from which I evaluate and compile single definitions, when I'm
repeatedly doing some locally confined modifications and testing them
out.
In either case I'm working mostly/exclusively with compiled code, yet
I'm still constantly doing interactive testing in the read-eval-print
loop.
> >in the file containing the code and recompile+reload.
> >
> >For interactive compilation using compile, do a
> >
> >(proclaim '(optimize (debug 3)))
> >
> >prior to your calls to compile.
Which you can of course also do prior to your calls to compile-file,
so that you don't have to include a declaim form in them.
>
> It looks like this is the default setting for the toplevel (I didn't have to
> use the proclaim to get the 'right' behavior from trace).
The optimization settings that apply to the toplevel also apply to
file compiled with compile-file, unless you explicitly override them
in the file with a declaim form. So you _did_ have to use the
proclaim to get the _expected_ behaviour from trace, unless you didn't
compile the definitions with compile. CL interpreters very seldomly go
out of their way to do tail-call elimination, regardless of the
optimization settings.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> wrote:
>Yes, tail-call optimization will fool the user and the trace facility,
>by converting the internal calls into jumps. Besides using the
>interpreter, one can also bump up the debug optimize quality, which is
>always advisable when one wants to use interactive debugging aids on
>compiled code. For stuff compiled from files, include
>
>(declaim (optimize (debug 3)))
>
>in the file containing the code and recompile+reload.
>
>For interactive compilation using compile, do a
>
>(proclaim '(optimize (debug 3)))
>
>prior to your calls to compile.
BTW in ACL there is a compiler switch named trust-declarations-switch whose
value can be NIL, T or a function (4 arguments: the values of the safety, space,
speed and debug optimization qualities). The default value is a function that
returns T if speed is greater than safety. For example, if safety is 3,
declarations made to optimize code are always ignored (the default function
makes a reasonable assumption, but it is better to know). Is there something
similar in LW?
--
www.algo.be
Logo programming : www.algo.be/logo.html