tomr at cnri.reston.va.us
Wed Nov 24 13:29:05 CET 1999
Nick Trout wrote:
> How do you write large/complicated applications in Lisp, the syntax with all
> those brackets drives me mad!
I can't resist this one: From someone who had written a few, much easier
than you might think. Lisp programmers have always enjoyed rich
programming environments, hosting features that are still lacking in
many so-called modern languages. Good type checking,
syntax/language-directed editors, tightly coupled debuggers, etc., were
available before the first CADR (gasp!) machines in the eighties. In
fact, Lisp is syntactically regular making it less taxing than C++ or
even Python (still haven't got the hang of when to use ":"'s and
backspaces) for extended efforts. Finally, most modern Lisp dialects
provide a rich (meta)object substrate as well as GUIs.
> I've never heard of this clever type checking. It sounds like a very good
> idea. It would be nice to be able to choose whether to have typing on or
> off. I know you can run a Lint checker over Python but whats a compiler
To keep you honest, and to allow you to design the algorithm independent
of machine or micro(source level) optimization concerns.
> "Patrick Tufts" <zippy at cs.brandeis.edu> wrote in message
> news:221119992150405215%zippy at cs.brandeis.edu...
> | In article <38397696 at news.xtml.co.uk>, Nick Trout
> | <nick at spam_me_notvideosystem.co.uk> wrote:
> | > | Basically, I'd be really interested to learn: what _don't_ people like
> | > | about Python
> | >
> | > The lack of typing is a problem sometimes but a real bonus when writing
> | > stuff quickly. I think speed of execution is my main complaint but I
> | > that is being addressed in the next version (ie. a jump table for
> | > execution was mentioned etc.).
> | Python could follow the Common Lisp model where variables can be typed
> | or not, and the compiler is welcome to actually use the information if
> | it feels like it.
> | The best current implementation of Common Lisp for type-declarations
> | and doing smart things with them is CMU Common Lisp. CMU CL has a
> | compiler called ... Python ... which does some amazing things with both
> | explicit and IMPLICIT type declarations.
> | For the latter, the compiler can often prove what the type must be even
> | where there are no declarations, and then use the type-specific numeric
> | operators to improve the efficiency of the code while maintaining
> | complete code safety.
> | Here's an example:
> | (defun foo (x) (mod x 4)) ; return x mod 4, always an integer
> | (defun bar (x) (^ 2 x)) ; return 2^x, always an integer
> | (defun baz (a b) (+ (foo a) (bar b))) ; foo(a) + bar(b)
> | The compiler determines that an in BAZ, an integer add can be used
> | instead of the general, type-checking add. The compiler increases the
> | speed of the code by eliminating the type-check, and minimizes the
> | memory used by choosing the integer representation for numbers instead
> | of a general numeric representation.
> | If the Python language is going to be extended to allow for type info,
> | I would love to see as much as possible borrowed from the CMU CL Python
> | compiler, as it's one of the finest intelligent compilers I know of.
> | And it has a cool name.
> | More info on CMU CL: http://www.cons.org/cmucl/
> | And a bit on the CMU Python compiler's type-checking (chap 4.5.2 of the
> | CMU CL User Manual by Robert A. MacLachlan, CMU tech report
> | CMU-CS-92-161):
> | http://www.mindspring.com/~rtoy/software/cmu-user/node98.html#SECTION005
> | 52000000000000000
> | --Pat
> | * foo bar and baz can also return bignums. I'm ignoring this case to
> | make the example clearer.
More information about the Python-list