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

[Sam S. <sd...@gn...>]

> * In message <9F8...@G8...>
> * 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" <Joe...@t-...> writes:
>
> 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. 

sounds reasonable.

> >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?

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.