Python syntax in Lisp and Scheme

[Alexander Schmolck]

Peter Seibel <peter at javamonkey.com> writes:

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

The reason it's different is that people apparently engage in the former (we
seem to agree undesirable) behavior, but not in the latter. I suppose this is
because programmers generally feel that wasting CPU cycles is a bad thing (I
know you could DECLAIM INLINE the above in CL). Also, you can't do things like
AIF as a function.

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

I guess so much everyone agrees on:)

The point that the lisp side seems to under-appreciate is that (even powerful)
abstractions have their limitations and also come at a cost. This cost should
be carefully analyzed because it is not always worth paying (and even if it
is, as is surely the case for macros in CL, awareness of the downside might
help minimize it).

Unfortunately, I'm pretty worn out by this thread now and have to catch up
with my work, so I won't go into detail.

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

Depends on the *implementation* of those constructs themselves and *which*
features (e.g. multiple inheritance). I'd forgo C++ for some saner language
without built-in OO anytime.

> It really is the same thing.

Would you like to see continuations in CL? If not, note that your argument
would be equally applicable.


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

It would be less a question of faith, but more an incorrect conclusion.

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

Yep, I'm aware.

> to figure out what went wrong including jumping to the code in
> question

OK, I was under the maybe mistaken impression that this wasn't generally
possible (if by "jumping to the code" you mean actually jumping to *the line*
where the error occured, in your editor window).

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

Yes, restarts sure are handy for interactive development (and absent in
python).

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

Nope, not to my knowledge (if anyone knows how to do this with pdb, I'd love
to hear about it).

> Yup. That's really handy. I agree.
> 
> So, in all sincere curiosity, why did you assume that this couldn't be
> done in Lisp. 

Well, basically because I tried to get some reasonable debugging environment
working (with ilisp/cmucl or clisp) and failed miserably (and googling didn't
help much further either). That macros (esp. reader macros) wouldn't interact
all that well with source level debugging also didn't seem like the most
unreasonable assumption.

Any suggestions how to get something like the following to source debug with
emacs/ilisp/cmucl?

;;test-debug.lisp
(declaim (optimize (debug 3)))
(defun buggy-defun ()
  (loop with bar = 10
        for i below 30
        collect (/ i (- i  bar)))) ;<= I'd like to start stepping here in emacs
(buggy-defun)


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

Good idea. I think it would also be worthwhile to have a good luck at close
competitors like python in order to do so effectively.

> Feel free to email me directly if you consider that too far offtopic for
> c.l.python.
> 
> -Peter

'as