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

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Wed Mar 19 07:04:04 2003

Hi,

Sam Steingold wrote:
>> 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?

>Proposal:
>debugger help: top == most recent.
>what do people think?
Fine, but you omit up/down behaviour specification
up: more recent elements
down: towards bottom

>there is no INCF for stacks.
>so "increasing the stack" is a TYPE-ERROR.
Not in my model. A stack has volume (since it can be empty, and grow). Thus, canonical increasing for stacks is growing, decreasing is popping or shrinking.
What do native english (or american :) speakers have to say?

>code comments: replace decrease/increase with push/pop
Prefer below declaration

>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) {}

I appreciate declarations that are easily scanned both by humans and computers. The loose comment form does not exactly fit that category.
I appreciate when tools exist that validate such information. Will declarations be verified by GCC?

Be careful that it does not hurt other code-analysing tools, e.g. ctags, protoize, context-diff-with-function-name, etc. etc.

Also, a push_stack(<integer>) declaration does not handle every situation. Some functions grow or shrink the stack by a data-dependent amount. listof() comes to mind. How do you represent these?

Other than that: I'm in favour of this incompatible user-level change.

Regards,
	Jorg Hohle.

---

From: Sam Steingold <[email-masked]>
Date: Wed Mar 19 08:35:06 2003

> * In message <[email-masked]>
> * On the subject of "AW: [clisp-list] on "increases STACK by n" in the CLISP source an d up/down in the debugger"
> * Sent on Wed, 19 Mar 2003 16:03:13 +0100
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>
> Sam Steingold wrote:
> Not in my model. A stack has volume (since it can be empty, and
> grow). Thus, canonical increasing for stacks is growing, decreasing
> is popping or shrinking. 

sounds reasonable.

> I appreciate declarations that are easily scanned both by humans and
> computers. The loose comment form does not exactly fit that category.

no, but static checking tools are coming up all the time (e.g., splint
<http://lclint.cs.virginia.edu/>), and they may be taught to check many
things in CLISP, e.g., GC safety and stack preservation.

> Be careful that it does not hurt other code-analysing tools,
> e.g. ctags, protoize, context-diff-with-function-name, etc. etc.

yes.  e.g.,
        GC_unsafe void foo()
will work fine while
        push_stack(2) void foo()
is likely to break tags.
anyone care to check?

> Also, a push_stack(<integer>) declaration does not handle every
> situation. Some functions grow or shrink the stack by a data-dependent
> amount. listof() comes to mind. How do you represent these?

e.g.,
GC_unsafe pop_stack(*) global object listof (uintC len) {}

we can avoid potential parentheses breakage by using underscore:

GC_unsafe push_stack_2 local void get_buffers (void) {}
GC_unsafe pop_stack_ global object listof (uintC len) {}

> Other than that: I'm in favour of this incompatible user-level change.

Anyone else?

-- 
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>
Diplomacy is the art of saying "nice doggy" until you can find a rock.