Introduction why lisp

Home Explore Login Signup. Successfully reported this slideshow. We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime. LISP: Introduction to lisp. Upcoming SlideShare. Like this presentation? Why not share! Embed Size px. Start on. Show related SlideShares at end. WordPress Shortcode. Next SlideShares. Technology , Education. DataminingTools Inc Follow. Introduction To Lisp. Terminology Machine Learning.

Techniques Machine Learning. Machine learning Introduction. Areas of machine leanring. This allowed Lisp programmers to gain actual experience with the facilities it provided before it was officially incorporated into the language. Whatever new paradigm comes down the pike next, it's extremely likely that Common Lisp will be able to absorb it without requiring any changes to the core language. Lisp circa was designed for "symbolic data processing" 7 and derived its name from one of the things it was quite good at: LISt Processing.

How is this possible? What on Earth would provoke the evolution of such a well-equipped language? Well, McCarthy was and still is an artificial intelligence AI researcher, and many of the features he built into his initial version of the language made it an excellent language for AI programming.

During the AI boom of the s, Lisp remained a favorite tool for programmers writing software to solve hard problems such as automated theorem proving, planning and scheduling, and computer vision. These were problems that required a lot of hard-to-write software; to make a dent in them, AI programmers needed a powerful language, and they grew Lisp into the language they needed. And the Cold War helped--as the Pentagon poured money into the Defense Advanced Research Projects Agency DARPA , a lot of it went to folks working on problems such as large-scale battlefield simulations, automated planning, and natural language interfaces.

These folks also used Lisp and continued pushing it to do what they needed. The same forces that drove Lisp's feature evolution also pushed the envelope along other dimensions--big AI problems eat up a lot of computing resources however you code them, and if you run Moore's law in reverse for 20 years, you can imagine how scarce computing resources were on circas hardware.

The Lisp guys had to find all kinds of ways to squeeze performance out of their implementations. Modern Common Lisp implementations are the heirs to those early efforts and often include quite sophisticated, native machine code-generating compilers. While today, thanks to Moore's law, it's possible to get usable performance from a purely interpreted language, that's no longer an issue for Common Lisp. As I'll show in Chapter 32, with proper optional declarations, a good Lisp compiler can generate machine code quite similar to what might be generated by a C compiler.

The s were also the era of the Lisp Machines, with several companies, most famously Symbolics, producing computers that ran Lisp natively from the chips up. Thus, Lisp became a systems programming language, used for writing the operating system, editors, compilers, and pretty much everything else that ran on the Lisp Machines.

In fact, by the early s, with various AI labs and the Lisp machine vendors all providing their own Lisp implementations, there was such a proliferation of Lisp systems and dialects that the folks at DARPA began to express concern about the Lisp community splintering. To address this concern, a grassroots group of Lisp hackers got together in and began the process of standardizing a new language called Common Lisp that combined the best features from the existing Lisp dialects.

By the first Common Lisp implementations were available, and the writing was on the wall for the dialects it was intended to replace. These days Common Lisp is evolving much like other open-source languages--the folks who use it write the libraries they need and often make them available to others.

In the last few years, in particular, there has been a spurt of activity in open-source Lisp libraries. So, on one hand, Lisp is one of computer science's "classical" languages, based on ideas that have stood the test of time.

The only downside of Lisp's "classical" heritage is that lots of folks are still walking around with ideas about Lisp based on some particular flavor of Lisp they were exposed to at some particular time in the nearly half century since McCarthy invented Lisp. If someone tells you Lisp is only interpreted, that it's slow, or that you have to use recursion for everything, ask them what dialect of Lisp they're talking about and whether people were wearing bell-bottoms when they learned it.

If you've used Lisp in the past, you may have ideas about what "Lisp" is that have little to do with Common Lisp. While Common Lisp supplanted most of the dialects it's descended from, it isn't the only remaining Lisp dialect, and depending on where and when you were exposed to Lisp, you may very well have learned one of these other dialects. Other than Common Lisp, the one general-purpose Lisp dialect that still has an active user community is Scheme.

Common Lisp borrowed a few important features from Scheme but never intended to replace it. Originally designed at M. In particular, Scheme's designers have focused on keeping the core language as small and as simple as possible. This has obvious benefits for a teaching language and also for programming language researchers who like to be able to formally prove things about languages. It also has the benefit of making it relatively easy to understand the whole language as specified in the standard.

But, it does so at the cost of omitting many useful features that are standardized in Common Lisp. Individual Scheme implementations may provide these features in implementation-specific ways, but their omission from the standard makes it harder to write portable Scheme code than to write portable Common Lisp code. Scheme also emphasizes a functional programming style and the use of recursion much more than Common Lisp does. If you studied Lisp in college and came away with the impression that it was only an academic language with no real-world application, chances are you learned Scheme.

This isn't to say that's a particularly fair characterization of Scheme, but it's even less applicable to Common Lisp, which was expressly designed to be a real-world engineering language rather than a theoretically "pure" language. If you've learned Scheme, you should also be aware that a number of subtle differences between Scheme and Common Lisp may trip you up. These differences are also the basis for several perennial religious wars between the hotheads in the Common Lisp and Scheme communities.

I'll try to point out some of the more important differences as we go along. Two other Lisp dialects still in widespread use are Elisp, the extension language for the Emacs editor, and Autolisp, the extension language for Autodesk's AutoCAD computer-aided design tool. Although it's possible more lines of Elisp and Autolisp have been written than of any other dialect of Lisp, neither can be used outside their host application, and both are quite old-fashioned Lisps compared to either Scheme or Common Lisp.

If you've used one of these dialects, prepare to hop in the Lisp time machine and jump forward several decades. This book is for you if you're curious about Common Lisp, regardless of whether you're already convinced you want to use it or if you just want to know what all the fuss is about.

If you've learned some Lisp already but have had trouble making the leap from academic exercises to real programs, this book should get you on your way.

Nearly all Lisp dialects support both floating-point arithmetic and integers of varying size not limited to the size of a machine word. The Lisp programmer who tries to calculate 47! While these other data types have been important to the practical success of the language, they are not central to the theoretical character of the language.

But symbols and lists are essential. Symbols serve as identifiers when used in Lisp programs, but they have a deeper existence as data structures of the language for example, their names are available at run time. A list is a sequence of Lisp data objects, notated by notating its elements within parentheses and separated by spaces. Thus michelangelo artist born died is a list of four items; the first two are symbols, and the last two are lists, each containing a symbol and an integer.

The list is empty, containing zero items; is a list of two empty lists. Most dialects of Lisp are not case-sensitive. Input is usually shown in lowercase, output in uppercase. Lisp lists serve as generic, all-purpose, heterogeneous aggregate data structures. Lisp defines a standard representation for programs as Lisp data structures.

The definition of append shown above actually is a Lisp list, whose first element is the symbol define; whose second element is the list of the three items append,x, and y; and so on.

This makes Lisp a congenial environment for writing prograrns that manipulate the source code of other programs. When a Lisp data structure is regarded as a program, symbols serve as identifiers naming variables.