[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New issue: STEP-ENVIRONMENT



Issue:         STEP-ENVIRONMENT

References:    STEP (CLtL p.441)
               TIME (CLtL p.441)

Category:      CLARIFICATION

Edit history:  Version 1, 12-Mar-88, Moon

Problem description:

CLtL does not specify in what lexical environment the form given to STEP
is evaluated.  Some people think it's supposed to be evaluated in the
null environment, others think it is supposed to be evaluated in the
current environment, the one in which the STEP form was evaluated.

The same considerations apply to TIME.

An additional problem is that CLtL says that STEP is a macro.  However,
it is unclear what portable expression the macro could expand into,
especially if STEP evaluates the form in the current environment.  STEP
is really a variation of the Lisp interpreter, which makes it more like
a special form than like a macro.

The interaction of STEP with the compiler is not specified.

Proposal (STEP-ENVIRONMENT:CURRENT):

1. Clarify that STEP and TIME evaluate the form in the current environment.

2. Change STEP from a macro to a special form.

3. Clarify that it is an error to compile a STEP form.

Test Cases/Examples:

;Assuming X is not a special variable
(setq x 1)
(let ((x 2))
  (step (print x)))

This should print and return 2, not 1, when interpreted.

Rationale:

1. It is more useful for the lexical environment to pass transparently
through STEP and TIME than to reset to the null environment.

2. STEP is really a variation of the Lisp interpreter, which makes it more
like a special form than like a macro.

3. As a debugging TOOL, STEP forms do not need to be compiled.  It would
be difficult to specify precisely what should happen when a STEP form is
compiled (which parts of the form are to be executed interpretively), so
it's easier to duck the issue.  Use "is an error" rather than "signals
an error" so that compile-only implementations are permitted to compile
STEP forms.

Current practice:

Symbolics Common Lisp behaves as proposed.

Cost to Implementors:

1 requires passing an environment around, which should be easy.
2 and 3 are just restrictions, so they should cost nothing.

Cost to Users:

None.

Cost of non-adoption:

These debugging tools will continue to have vague specifications.

Benefits:

Slightly more preicse specification of Common Lisp.

Esthetics:

Slightly improved.

Discussion:

None yet.