Subject: [clisp-list] on "increases STACK by n" in the CLISP source and up/down in the debugger

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Mon Mar 10 01:53:07 2003

Hi,

everytime I enter the CLISP debugger, I start to sweat because I feel uncomfortable. If I do more than "abort/continue/:a" then I must issue the HELP command. Why?

In the output of help, I'm looking for the single most important line:
>Bottom    :b       go to bottom (most recent) frame, inspect it

Aha, so the bottom is the newest - surprise?. My brain now has to backtrack, and it is well known that the human brain is bad at that.

Likewise, when I look at the description of many procedures (UP) in the C source code, there are comments like
 # UP: tests the limits for a String argument
 # increases STACK by 3
Question: will there be more or less arguments on the stack afterwards?
What would be your response?

My mental representation of a stack is that of a pile of paper. It realises last-in-first-out (LIFO). The newest is at the top, the oldest is hidden at the bottom, long forgotten. What is yours?

"Increasing" the stack to me means putting more on it. In CLISP, it's just the opposite.

Similarly, I believe computer science or stack-oriented languages like Forth have a concept of "top of stack" (TOS or ToS): "top" designates the newest element, the one that will be popped next (if the stack is not empty).

In natural language or in psychology, going down means go to deeper levels of memory or details - long seemingly forgotten things. C.G. Young explained in his symbolic interpretation of dreams how a house's cellar - at the bottom - not the houses' roof (loft) is a place where you look for things of the past.

CLISP's way is just the opposite of each of these usages.

My model of a stack is not that of a stalactite where the newest drops of water hang out at the bottom. What is your model of CLISP's stack?

I suppose CLISP's usage of stack direction is based on a model of the 680x0 processor, whose stack register A7 moves downwards - in terms of memory addresses - when things are pushed on the stack (CLISP started out in assembly language on an Atari computer), as do other processors (80z86 etc.).

Shall the effect of debugger commands like UP/DOWN and higher-level program documentation depend on the direction of the register of some processor the user does not care about? Say no!

For years now, CLISP has imposed cognitive load and effort on me. Maybe it's time to put at end to that.
a) I stop using CLISP
b) I stop complaining
c) Comments in code get reversed, as well as the debugger commands.

Thanks for your attention,
	Jörg Höhle.

---

From: Sam Steingold <[email-masked]>
Date: Mon Mar 10 08:43:14 2003

> * In message <[email-masked]>
> * On the subject of "[clisp-list] on "increases STACK by n" in the CLISP source and up/down in the debugger"
> * Sent on Mon, 10 Mar 2003 10:51:51 +0100
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>

I could never understand this either.
I prefer "adds 3 objects to STACK" or "removes 4 objects from STACK"
or just "skipSTACK(-3)" or "skipSTACK(4)".

> My mental representation of a stack is that of a pile of paper. It
> realises last-in-first-out (LIFO). The newest is at the top, the
> oldest is hidden at the bottom, long forgotten. What is yours?

when I type bt, I want the most important, i.e., the most recent frame
to be the last one printed, so that I won't have to scroll back up to
see where I am (thus I _want_ bottom to mean bottom of the screen _and_
most recent frame).
Unfortunately, this is not easy to implement, so both gdb and clisp
print the most recent frames at the top of the backtrace.
what about other debuggers?

> "Increasing" the stack to me means putting more on it.

stack supports PUSH and POP.  there is no INCF for stacks.
so "increasing the stack" is a TYPE-ERROR.

> c) Comments in code get reversed, as well as the debugger commands.

Proposal:
code comments: replace decrease/increase with push/pop
debugger help: top == most recent.

what do people think?

Actually, I would like to replace comments "can trigger GC" with
declarations GC_unsafe and comments "pushes 3 objects on the stack"
with declarations push_STACK(3). E.g., get_buffers() in io.d will look
like this:

GC_unsafe push_stack(2) local void get_buffers (void) {}

instead of

# < STACK: decreased by 2
# can trigger GC
local void get_buffers (void) {}

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Illiterate?  Write today, for free help!