Re: Issue: STANDARD-VALUE (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 21 Oct 88 13:48 PDT
    From: masinter.pa@Xerox.COM

    Envos Medley does this only slightly differently: there's a list
    IL:*PER-EXEC-VARIABLES* instead of *STAHDARD-VALUES*. If you really add a

Had I said STAHDARD? Must be that famous Boston accent creeping in. I meant
STANDARD.

    new variable that really has to be rebound when a new debugger or EXEC is
    invoked, you can push something onto it.

I'm not proposing we advertise the variable that holds them. That's
implementation-dependent.


    The initial value is ((*PACKAGE* (COND ((PACKAGEP *PACKAGE*) *PACKAGE*) (T
    (PROMPTPRINT "Invalid package, reset to LISP") (SETQ *PACKAGE*
    (FIND-PACKAGE LISP))))) (* *) (** **) (*** ***) (+ +) (++ ++) (+++ +++) (-
    -) (/ /) (// //) (/// ///) (HELPFLAG T) (*EVALHOOK* NIL) (*APPLYHOOK* NIL)
    (*ERROR-OUTPUT* *TERMINAL-IO*) (*READTABLE* *READTABLE*) (*EVAL-FUNCTION*
    *EVAL-FUNCTION*) (*EXEC-PROMPT* *EXEC-PROMPT*) (*DEBUGGER-PROMPT*
    *DEBUGGER-PROMPT*)) 

Mostly I'm content to union the LISP symbols in your list with ours. We
probably ought to have *EVALHOOK* and *APPLYHOOK* in our list anyway,
for example.

The issue of *, **, ***, etc. is an unclear one. I think our users prefer that
the values not be rebound, so they can abort out a level and still refer back
to a value they got in a breakpoint.

    I don't think this will fly, because it seems to be too dependent on one
    particular style of debugger.

I could weaken the restriction on the debugger to say it's only a mechanism for
programs to communicate such info with debuggers that can make use of it.
I'm not interested in restricting debugger styles so much as acknowledging that
many are like this and that many people have programs that would be happy to
give the debugger hints if only they knew how.