Python syntax in Lisp and Scheme

[Peter Seibel]

Alexander Schmolck <a.schmolck at gmx.net> writes:

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

Yes. But that's no different with macros than if someone decided that
they like BEGIN and END better than FIRST and REST (or CAR/CDR) and so wrote:

  (defun begin (list) (first list))
  (defun end (list) (rest list))

As almost everyone who has stuck up for Lisp-style macros has
said--they are just another way of creating abstractions and thus, by
necessity, allow for the possibility of people creating bad
abstractions. But if I come up with examples of bad functional
abstractions or poorly designed classes, are you going to abandon
functions and classes? Probably not. It really is the same thing.


> >   (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.

Well, I admire your faith 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?)

No, you're mistaken. In my test framework, test results are signaled
with "conditions" which are the Common Lisp version of exceptions. Run
in interactive mode, I will be dropped into the debugger at the point
the test case fails where I can use all the facilities of the debugger
to figure out what went wrong including jumping to the code in
question, examining stack framse, and then if I think I've figured out
the problem, I can redefine a function or two and retry the test case
and proceed with the rest of my test run with the fixed code.
(Obviously, after such a run you'd want to re-run the earlier tests to
make sure you hadn't regressed. If I really wanted, I could keep track
of the tests that had been run prior to such a change and offer to
rerun them automatically.)

> and I can interactively inspect the stackframes and objects that
> were involved in the failure.

Yup. Me too. Can you retry the test case and proceed with the rest of
your tests?

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

Yup. That's really handy. I agree.

So, in all sincere curiosity, why did you assume that this couldn't be
done in Lisp. I really am interested as I'm writing a book about
Common Lisp and part of the challenge is dealing with people's
existing ideas about the language. Feel free to email me directly if
you consider that too far offtopic for c.l.python.

-Peter

-- 
Peter Seibel                                      peter at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp