Write For Us

Submit Tips

Subscribe to Print Edition

Search

HOME

REVIEWS

HOW-TOS

CODING

INTERVIEWS

FEATURES

OVERVIEW

BLOGS

SERIES

IT ADMIN

Lisp: Tears of Joy, Part 3

By Vivek Shangari on August 1, 2011 in Coding, Developers 1 Comment

Search for:

Search

LISP has been hailed as the worlds most powerful programming language. But only the top percentile of programmers use it, because of its cryptic syntax and academic reputation. This is rather unfortunate, since LISP isnt that hard to grasp. If you want to be among the crme de la crme, this series is for you. This is the third article in the series that began in the June 2011.

Get Connected RSS Feed Twitter

Genesis
By now, most of us agree that LISP is the worlds greatest programming language. For those of you who still disagree, and think it probably stands for Lots of Irritating Superfluous Parentheses, my suggestion would be to read this article with a few bottles of strong beer (for the hacker types) or wine (for the high brow literary elite). Guy L Steele Jr and Richard P Gabriel, in their paper The Evolution of LISP [PDF], say that the origin of LISP was guided more by institutional rivalry, one-upmanship, and the glee born of technical cleverness that is characteristic of the hacker culture, than by a sober assessment of technical requirements. How did it all start? Early thoughts about a language that eventually became LISP started in 1956, when John McCarthy attended the Dartmouth Summer Research Project on Artificial Intelligence. Actual implementation began in the fall of 1958. These are excerpts from the essay Revenge of the Nerds by Paul Graham:

LISP was not really designed to be a programming language, at least not in the sense we mean today, which is something we use to tell a computer what to do. McCarthy did eventually intend to develop a programming language in this sense, but the LISP that we actually ended up with was based on something separate that he did as a theoretical exercisean effort to define a more convenient alternative to the Turing Machine. As McCarthy said later, Another way to show that LISP was neater than Turing machines was to write a universal LISP function, and show that it is briefer and more comprehensible than the description of a universal Turing machine. This was the LISP function eval, which computes the value of a LISP expression Writing eval required inventing a notation representing LISP functions as LISP data, and such a notation was devised for the purposes of the paper, with no thought that it would be used to express LISP programs in practice.
Some time in late 1958, Steve Russell, one of McCarthys graduate students, looked at this definition of e v a land realised that if he translated it into machine language, the result would be a LISP interpreter.

LINUX For You on

Follow

+2,497

This was a big surprise at the time. Here is what McCarthy said about it later in an interview:

Find us on Facebook

Steve Russell said, Look, why dont I program this eval, and I said to him, Ho, ho, youre confusing theory with practice; this eval is intended for reading, not for computing. But he went ahead and did it. That is, he compiled the eval in my paper into [IBM] 704 machine code, fixing bugs, and then advertised this as a LISP interpreter, which it certainly was. So at that point LISP had essentially the form that it has today
Suddenly, in a matter of weeks, I think, McCarthy found his theoretical exercise transformed into an actual programming language and a more powerful one than he had intended. (Read the complete essay here.)

Open Source For You

Like 252,940 people like Open Source For You.

F acebook social plugin

Now, despite how much I love LISP and think that all the pages of LINUX For You should be dedicated to it, I also know that if I want to keep writing for this magazine, I need to stick to the word limit. So, as interesting as the origin of LISP is, we should now move on to the real task at hand (and for those whove lost the plot, it is learning LISP).

Popular

Comments

Tag cloud

August 13, 2013 13 Comments Diksha P Gupta

Defining local variables in LISP

To define a local variable, use the l e tcommand. A l e texpression has two parts; the first is a list of variable declarations, where we can declare one or more local variables valid within the body of the l e t . The second is the body of the l e t , where we can use these variables. The expressions in the body are evaluated in order. Heres an example:
>( l e t(( x1 8 ) ( y1 3 ) ( z1 5 ) ) ( +xyz ) ) 4 6

India has immense under-utilised talent in the cloud security space

May 6, 2013 6 Comments Priyanka Sarkar

PHP Development: A Smart Career Move

June 20, 2013 3 Comments sophie-samuel

New and amazing features of Linux

June 20, 2013 3 Comments Priyanka Sarkar

What it Takes to be an Open Source Expert

May 6, 2013 1 Comments Deepti Sharma

A Simple guide to building your own Linux Kernel

Here, I have defined three local variables x ,y , and z , and assigned them values of 18, 13 and 15, respectively. Each pair of local variable names and values assigned to them need to be surrounded by a set of parentheses. Also, the indentation, white-space, and line breaks are discretionary and therefore, you can stack up the variables and their values in a l e t expression to resemble a table. This is why I have placed ydirectly underneath xand zdirectly below y . Figure 1 identifies the parts of the l e t .

Figure 1: 'let' expression

Defining local functions in LISP

To define a local function, use the f l e tcommand. This, too, has two parts: (1) function declaration; and (2) the f l e tbody, where the function may be called. The function declaration itself consists of a function name, the arguments to that function, and the function body, where we put the functions code. As with l e t , we can define one or more functions within the scope of the f l e t . But remember that these are local functions visible only in the body they may not call one another, and so cannot be recursive. Heres an example:
>( f l e t(( f o o ( n ) ( +n5 ) ) ( b a r ( n ) ( +n1 0 ) ) ) ( b a r( f o o2 ) ) ) 1 7

Here, I have declared two functions: f o oand b a r . In this code example, the body of the f l e t first calls f o owith 2 as its argument, to return a value of 7; it then calls b a rto add 10 to this value, leading to 17 as the final value of the whole f l e texpression. See Figure 2.

Figure 2: 'flet' expression

Lets see what happens when bar tries to call f o oin its function body:
>( f l e t(( f o o ( n ) ( +n5 ) ) ( b a r ( n ) ( +( f o o2 )n ) ) ) ( b a r1 0 ) ) * * *-E V A L :u n d e f i n e df u n c t i o nF O O T h ef o l l o w i n gr e s t a r t sa r ea v a i l a b l e : U S E V A L U E : R 1 I n p u tav a l u et ob eu s e di n s t e a do f( F D E F I N I T I O N' F O O ) . R E T R Y : R 2 R e t r y S T O R E V A L U E: R 3 I n p u tan e wv a l u ef o r( F D E F I N I T I O N' F O O ) . A B O R T : R 4 A b o r tm a i nl o o p >

Thats right! You get slapped in the face with an error (Figure 3). The f l e tcommand creates local functions, which are invisible inside another function body.

Figure 3: Error

To define recursive local functions, use l a b e l s . Local functions defined by a labels expression can refer to any other functions defined there, including themselves. This is identical in its basic structure to the f l e tcommand. Heres the preceding code, written with l a b e l s :

>( l a b e l s(( f o o ( n ) ( +n5 ) ) ( b a r ( n ) ( +( f o o2 )n ) ) ) ( b a r1 0 ) ) 1 7

In this code example, the body of the l a b e l sexpression calls the local function b a r . Since l a b e l sallows local functions to see each other, the b a rfunction calls another local function (from inside its body). That is f o o , which adds 2 to 5, resulting in a value of 7, which in turn is added to 10 the argument of the b a rfunction, resulting in a final value of 17.

This is where I have to leave you this month (as I have run out of space!) but before I go, I would like to thank everybody who wrote in to provide feedback about the article last month.

Related Posts:
Lisp: Tears of Joy, Part 6 Lisp: Tears of Joy, Part 5 Lisp: Tears of Joy, Part 10 Lisp: Tears of Joy, Part 7 Lisp: Tears of Joy, Part 2
Tags: Artificial Intelligence, Common Lisp, Guy L Steele Jr, IBM, John McCarthy, LFY August 2011, Lisp, lisp function, LISP interpreter, Lisp: Tears of Joy series, Paul Graham, Programming Language, Richard P Gabriel, Steve Russell

Article written by:

Vivek Shangari
The author is a hard-core hacker, if there ever was one. He always thinks programs, and holds a piece of code in his head all the time. His favourite past-time is to stop random strangers on the street and start talking about the benefits of open source over proprietary software, till they agree to switch sides, or threaten to jump off the nearest building. Connect with him: Website

Previous Post

Next Post

Build Android Apps Using HTML with PhoneGap

Let's Hook a Library Function

AROUND THE WEB

ALSO ON LINUX FOR YOU

What's this?

Pastor Mocked For His "Biblical Money Code" Moneynews The first six months - 3 things to consider in your new job Kelly OCG Mechanic Wrecks Super Rare Mercedes-Benz 300 SL First To Know Egg Rolls in Your Kitchen? Here's the Recipe FOODIE

India has immense under-utilised talent in the cloud 13 comments Getting Your First Job Code Sport
1 comment 1 comment

File Systems A Semester Project-II, Part-19 6 comments

1 comment Leave a message...

Newest S id Community

Share

2 years ago

I have been following the Lisp article in LFY since the first edition. It's damn good. Written in a very humorous style. My wife keeps asking me how can I laugh so much reading a technology article. Thanks a lot for including this in the magazine.
Reply Share

C o m m e n t fe e d

Su b s cri b e vi a e m a i l

Reviews

How-Tos

Coding

Interviews

Features

Overview

Blogs

Search
Popular tags
Linux , ubuntu, Java, MySQL, Google, python, Fedora, Android, PHP, C, html, w eb applications , India, Microsoft, unix , Window s , Red Hat, Oracle, Security , Apache, xml, LFY April 2012, FOSS, GNOME, http, JavaScript, LFY June 2011, open source, RAM, operating systems

For You & Me Developers Sysadmins Open Gurus CXOs Columns

All published articles are released under Creative Commons Attribution-NonCommercial 3.0 Unported License, unless otherw ise noted. LINUX For You is pow ered by WordPress, w hich gladly sits on top of a CentOS-based LEMP stack.