Python syntax in Lisp and Scheme

[Alexander Schmolck]

Peter Seibel <peter at javamonkey.com> writes:

> If for some reason you believe that macros will have a different
> effect--perhaps decreasing simplicity, clarity, and directness then
> I'm not surprised you disapprove of them. But I'm not sure why you'd
> think they have that effect.

Well, maybe he's seen things like IF*, MVB, RECEIVE, AIF, (or as far as
simplicity is concerned LOOP)...?

I'm not saying that macros always have ill-effects, but the actual examples
above demonstrate that they *are* clearly used to by people to create
idiosyncratic versions of standard functionality. Do you really think clarity,
interoperability or expressiveness is served if person A writes
MULTIPLE-VALUE-BIND, person B MVB and person C RECEIVE?

>   (deftest foo-tests ()
>     (check
>      (= (foo 1 2 3) 42)
>      (= (foo 4 5 6) 99)))
> 
> Note that this is all about the problem domain, namely testing.

I think the example isn't a bad one, in principle, in practice however I guess
you could handle this superiorly in python.

I develop my testing code like this:

    # like python's unittest.TestCase, only that it doesn't "disarm"
    # exceptions
    TestCase = awmstest.PermeableTestCase
    #TestCase = unittest.TestCase

    class BarTest(TestCase):
       ...
       def test_foos(self):
           assert foo(1,2,3) = 42
           assert foo(4,5,6) = 99

Now if you run this in emacs/ipython with '@pdb on' a failure will raise an
Exception, the debugger is entered and emacs automatically will jump to the
right source file and line of code (I am not mistaken in thinking that you
can't achieve this using emacs/CL, right?) and I can interactively inspect the
stackframes and objects that were involved in the failure.

I find this *very* handy (much handier than having the wrong result printed
out, because in many cases I'm dealing with objects such as large arrays wich
are not easily visualized).

Once the code and test code works I can easily switch to mere reporting
behavior (as described by andrew dalke) by uncommenting unittest.TestCase back
in.


'as