Re: warn if not top-level?

"Chris Riesbeck" <criesbeck@xxxxxxxxx> wrote in message
news:criesbeck-2C007A.12325228062005@xxxxxxxxxxxxxxxxx
> In article <wyfwe.63604$wr.56136@clgrps12>,
> "Coby Beck" <cbeck@xxxxxxxxxxxxx> wrote:
>
>> "Chris Riesbeck" <criesbeck@xxxxxxxxx> wrote in message
>> news:criesbeck-B9D9F5.14095027062005@xxxxxxxxxxxxxxxxx
>> >
>> > I would like to warn users that code like
>> >
>> > (DEFUN MY-TESTS () (RUN-TESTS ...))
>> >
>> > may be a mistake, since the code saved in MY-TESTS will
>> > no longer be updated when tests are updated or macros
>> > are redefined.
>>
>> I know "don't do it" is an unsatisfying answer to "how do I do it?" but
>> that
>> is probably mine in this case. The
>> "redefined-macro-mean-recompile-all-uses" rule must be well learned,
>> usually
>> through pain therapy. You might do someone a very small favor with all
>> your
>> contortions but it won't help them with all the cases where the function
>> called by run-tests contains old macro expansions (and may simply delay
>> the
>> learning of the important lesson). Everybody either knows or must soon
>> learn that when you redefine a macro, you must recompile everything that
>> uses it.
>
> While this is certainly true for most code, it goes
> against the central point of test-driven development.

I don't see how? Shouldn't one have the habit of recompiling before running
tests? Also regardless of your methodology, you have to recompile
macro-using functions after updating the definitions, there is no way to
sneak around this.

> For now, I've decided to go the run-time evaluation
> route.
>
> Any comparative pros and cons regarding EVAL, COMPILE
> and COERCE for turning a LAMBDA form into runnable code?
>
> I'm using COERCE, as possibly simpler than EVAL,
> and possibly faster than creating compiled code
> than COMPILE, based on some prior discussions I've found.

One thing I like to do in using a test harness is put tests in closures so I
can use lexical variables. Expanding into an eval would take away this
capability.

eg
(let ((test-data (make-test-data...)))
(loop for arg in test-data
do (run-test arg)))

That kind of thing. I think if you expand in to and (eval '(run-test arg))
you will have unbound variable problems.


--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")


.

Relevant Pages

  • Re: Lisp2Perl - Lisp to perl compiler
    ... > because the foo macro doesn't see the a reference. ... Now at compile time, if you encounter a DEFDYNFUN form, ... At some point, you decide to recompile from scratch, ...
    (comp.lang.lisp)
  • Re: modifying array access syntax
    ... I published recent speculation on the ARRAY ... > are in fact remnants of the property lists of these Lisp-N ... these that were meaningful at compile time (FEXPR, FSUBR, and MACRO ...
    (comp.lang.lisp)
  • RE: Code Execution Interrupted ??
    ... memory dumps. ... The big macro that calls the function below has been running well ... this time on the If Not Arg stmt. ... Dim Arg As Range, WhoOrPrt ...
    (microsoft.public.excel.programming)
  • Code Execution Interrupted ??
    ... Just got my first 'code execution iterrupted message'. ... The big macro that calls the function below has been running well ... this time on the If Not Arg stmt. ... Dim Arg As Range, WhoOrPrt ...
    (microsoft.public.excel.programming)
  • Re: DISFAVORED Was: name for 3 PICK finally?
    ... complexity is reduced by reducing the phases of execution to keep ... outside happens when the word containing the macro executes. ... LITERAL COMPILE, .... ... ``GET LITERAL @ LITERAL `EXECUTE COMPILE,'' ...
    (comp.lang.forth)