Land of Lisp Chp 4

Chapter 4 covers exclusively boolean operations. It starts with a discussion of the only false data value in Lisp which is the empty set '(). This differs from Scheme, though the details of that aren't discussed as they're clearly outside the scope of the book. Note that it is represented in data mode because it is a data value, not a form.

To complicate matters (which seems to happen a lot in this chapter) '() isn't the only way to represent falsehood. This is a careful distinction which I'll come back to. The following are all false in Lisp

The first is just the empty list. The second resolves to an empty list due to the way Lisp parses forms. nil is actually a constant that resolves to 'nil and part of the Common Lisp spec is that 'nil and '() are equivalent. Why are all 4 deliberately set up this way? The book doesn't say. I suspect backwards or cross-dialect compatibility, but to be honest I don't really care right now. It is what it is, as my boss is fond of saying. The important thing is that an empty list is false, and any list that is not empty is true by definition (though in practice the 'nil can present some gotchas that will come up later). This lends Lisp to easy recursive processing of lists like so.

The above recursively cdrs to the end of the list and adds 1 for each symbol; the false branch of the if form returns 0 for the empty list at the end

Next up is if. Which has already been used but not discussed. It's hard to talk about boolean operations without 'if' in seemingly any language. Lisp's if is a bit stunted compared to something like a dialect of C. if only does one thing. Because of the way the command is structured

you can only evaluate one list. Which is a tad misleading since that one list could be a function form that does a million things or, as the book suggests, a call to progn which is glossed over here but apparently behaves similarly to an eval function. Still, it's an important thing to remember and it would tend to reinforce functional programming if that's your thing.

A key feature of if is that, like many other languages, it performs short circuit evaluation. The book spends a lot of ink on this, but I shan't bother except to say that if can do this because it is a special form as opposed to other forms which evaluate all their parameters. This is glossed over here as well as macros which are apparently similar. This will come up again in chapter 16 it seems.

There are a number of alternatives to if. when and unless are mirror siblings.

when executes its commands if {boolean} is true and, as might be guessed, unless executes its commands if {boolean} is false. These each will take an command list of arbitrary length. Both return nil and do nothing if {boolean} is not the correct value.

Finally there are 2 conditional functions that are fully flexible. I almost said functional but while the prior conditionals have been somewhat less flexible than the conditionals of other languages it's worth noting that they're easy to understand and read, and are largely self documenting. These two, on the other hand, are more like another language's switch/case statement, are complex to read (lots of syntax which, in Lisp, is parentheses and hard for an unpracticed human eye to track) and not very self-obvious. They can be formatted to be easier to read and written to be, or the surrounding code architected to be, easier to grok but there's a limit to how much that can accomplish. The book mentions none of that and perhaps I'm just suffering from a neophyte's inadequacies; it is mentioned that seasoned Lispers prefer cond because of it's generality. I don't know, but without further ado however here is the cond and case functions.

Clearly these two can quickly become hard to read. Nevertheless they're probably called for in some circumstances. cond takes a what is basically a list of when forms. The first matching {boolean} is executed and the remainder ignored. As one might expect the final {boolean} is often a true value to drive default behavior. case is nearly a C style switch statement. It takes a {symbol} which it will compare to the various {value}s defined in its body using (specifically) the eq function (this will have more meaning in a minute) and executes only the matching branch. It isn't stated explicitly but the otherwise branch is default behavior.

There are 2 boolean operator functions of note. and ... and... or. These each take a list of parameters and return a boolean based on the boolean evaluation of those parameters much like you would expect. There is an interesting side effect of the short circuit operation of these functions. Take the following example (ripped straight from the book).

In the above form the 3 parameters are fed to and. You could imagine this being called when an editing program is closed. First the *file-modified* variable is tested and if it's false and immediately returns nil. If it's true then the function (ask-user-about-saving) is tested. Presumably this takes input from the user. If the user inputs a value that is evaluated to true then the (save-file) function is executed. In theory this would return a success/failure variable which would then determine whether and returns nil or true. All of that in one little line. That's some pretty dense semantics. It might be better to use a more verbose if structure if the code needs to be maintained by neophytes since all of the relies on some subtle effects. Personally, I like the density and this case isn't terribly difficult to figure out. Maybe it's just because I grok short circuit evaluation, I dunno.

In a slight tangent the book interjects that one subtlety of the Lisp definition of false is that functions get a freebie return value. Anywhere that a function could return truth or falsehood it would be better to find some more useful value to return than just true; if you're testing whether a variable is defined you might as well return the value (unless it's nil!) since it will be evaluated as true regardless of the actual value. The book uses the member and find-if functions to discuss this but I'm not going to get into them since this is already long and I want to move on to chapter 5.

Finally we come to the equality functions. The book discusses 6 commonly used equality functions. Yes, 6! equal, eql, eq, =, string-equal, and equalp. The rule of thumb is to use eq to compare symbols (it's fast, efficient, and doesn't work well on things that aren't symbols) and to use equal for everything else. I don't have the gumption to dig far into equality comparison right now but will point out that equalp will handle case insensitive string comparisons as well as comparing integers to floating point values.

Land of Lisp Chp3 Summary

In the chapter 2 summary I started digging into the language based on vague remembrances from trying to learn Lisp a few years ago. It didn't work out back then, for various personal and (probably) psychological reasons but we're moving forward this time. Anyway. I might as well have waited (I'm glad I didn't though) because chapter 3 fulfills.

I must begin with the parts I find boring because an understanding of them makes the remainder of the summary more clear and easier to write about. So syntax in Lisp is composed entirely of parentheses. You have a (, a series of symbols, and a ). The () bounds lists and lists compose the semantics of Lisp.

So what kind of data types are recognized by the interpreter? Symbols are composed of alphanumerics and certain symbolic characters ( +,-,=,_,/,*, &etc). I don't know the exhaustive list of allowed characters, that's what google is for. Symbols are case insensitive (though apparently common practice is to avoid capitals).

There are two kinds of numbers, integers and floating points. Lisp handles these pretty much silently, like new interpreted languages, converting ints into floats anytime they're calculated together. However unlike newer languages (that I'm aware of) uneven division of integers does not generate a floating point. (/ 4 6) yields [2/3] not 0.66666666... . Of course [( / 4.0 6)] gets 0.6666667 as one would expect (presumably to the precision defined in code or the default precision of the interpreter). The book also assures me that 2/3 is handled appropriately by the interpreter going forward.

A corollary to the above is that it suggests that one could input rational fractions directly into the interpreter and expect them to be handled properly rather than needing to convert them to irrational numbers first (or have the code do, which will invariably end up creating a float eventually when what you really want is an int, but I digress).

Moving right along, finally we have strings. Quite conventional, they're anything in double quotes and honor the usual escapism with \'s.

An important point is knowing how to tell Lisp when you're entering data instead of code. By default the interpreter treats input as code. Using a single quote you can instead have it treated as data.

This is called quoting, appropriately enough, and causes the interpreter not to evaluate the quoted block. This is largely glossed over here, possibly to be expounded upon later.

Earlier I stated that everything in Lisp is a list. This is only part of the truth. First a little vocabulary correction. I started calling commands like ash and let, and function names keywords. It seems that these are more properly called symbols as discussed above. Groovy. It's just a word, but it should be self-evident that in languages words are of the utmost import. To move on with the point the list is only the second most important structure in Lisp. In fact I think one could say that there are structures in Lisp that are not lists. These are the things that lists are made out of. While it is clearly possible to have a list of lists one must assume that at some point a list must contain something other than another list. Otherwise you might as well say that you have an unending progression of nested boxes each containing yet more boxes. Fascinating mental simulation and yet quite pointless. At some point you reach data which is composed of multiple points which are not themselves a list. This sentence for example is a list of words, and formatting characters. Each word is a list of letters. Each letter is indivisible (semantically, the pixels constructing the letter onscreen have no semantic meaning). Thus the letters in a sentence are the data points.

Ugh. Let me dig myself out of that rabbit hole. I go rather far afield sometimes trying to find and shape a good metaphor. Moving right along. Similarly, each list in Lisp must be composed of something besides lists eventually. That something is the cons. Earlier in chapter 2 I called the second list in a let statement a list of tuples. While this may be strictly accurate my understanding now is that they are handled internally as conses. A cons consists of pointers to precisely two items. I immediately leap ahead and start thinking 'linked list!' which is good, but I have to restrain myself. I'm getting to that. Before I get any further let me elaborate on the command structure. Every command in Lisp follows a specific structure in it's list. A command list is called a form and consists of a special command symbol (generally a builtin or function) followed by a list which will be presented to the special command as parameters. This works the same for builtins and user defined functions.

So the second item in the let syntax is a list of conses to be presented to let as a parameter (yes, singular, it's only one list). Now here's the interesting thing. The the items in a cons can be a pointer to another cons. Here is where linked lists come in. Every list in Lisp is a collection of linked conses.

Now. To create a cons one simply uses the cons command. Brilliant innit?

Don't ask me how to use that syntax to reference an existing cons in an existing list. I haven't got that far yet. So now we have 3 ways to create a list. We can cons it together from constituent parts

We can explicitly declare a list

Or we can imply a list in data mode and let the interpreter sort it out

Is one way better than the other? Hell if I know, but it seems to me that explicitly using list would be less prone to human error than the consing method and less susceptible to interpreter shennanigans than implying one in data mode. But then again I'm a neophyte. What do I know?

There are two primary means of manipulating a list by its conses. Those are car and cdr. car gets the first element. For a variable, the name; for a function, the symbol of the special command. cdr gets the second element.For a variable, the value; for a list the second element of a cons is the pointer to the next cons in the chain so what you get is the original list minus the first element (instant stack behavior). These two can be combined to access arbitrary elements of lists; to parse it you have to read the symbol right to left. For example cadr gets you the first element of the second element of the original list. For example the cadr of ("coffee cup", "mouse", "laptop", "phone") is "mouse". The cddr of it is ("laptop", "phone").

These combinations are implemented as builtins up to 4 layers deep however I suspect how deep they go is at least partly implementation-specific even if that isn't stated explicitly. Nevertheless it's easy enough to define them yourself. cadr is equivalent to saying


Chapter 4 is... you know what? I can't be bothered to manually do a linked list out of these. Just hit the land of lisp tag and be done with it.

On a Tuesday morning

I'm behind schedule on Lisp now so I burnt the schedule. I have a partial summary of chapter 3 but it seems at this point I'm going to have to skim back through it again to get the final draft finished. Should have done that this morning but I played file manager with my trio of HDDs instead.

Edit: Pandora is being quite apropo. "Complete the motion if you stumble" ~ Red Hot Chili Peppers, Can't Stop

I'll be glad to trade my cobbled, bunch-of-single-drives configuration for a decent, roomy storage drive. That's delayed so the kids can get tablets, which is wholly worthwhile, but it's still on the horizon I think. My accountant can chime in here if she wants.

Last night we had the youth pastor's family over for dinner. I thought it went well, and the kids both plan to walk down on Father's Day which will be very nice.

Land of Lisp Chp1 Summary

It strikes me that I never formally summarized chatper 1.
It's basically just an overview of the Lisp language as an idea. History, why it's worth understanding, and getting an interpreter installed.

Surely all very useful, but, not terribly meaty. It'd be like summarizing the review papers before taking a test.

Chapter 2 is much more interesting.

I've decided that I can't be bothered to manually do a linked list out of these. Just hit the land of lisp tag and be done with it.

Land of Lisp Chp2 Summary

Alright. I'm late. Story of my life. Moving right along.
Chapter 1 covered fluffery like history, why learn Lisp, and getting an interpreter set up.
Chapter 2 covered some programming basics.

• Setting up variables 
• Global with defparameter, which is probably intended to 'define' the operating 'parameters' of the code set. Whether this should actually be used to store operating variables I'm uncertain, certainly globals are probably better avoided at any rate.
• Static global with defvar, though I'm sure I'm misunderstanding this one, it was only glossed over.
• In a local context with let. A more traditional variable. An interesting point is that let literally defines the scope of the variables using the () syntax. In a and b only exist within the {code body} of the outer set of brackets.

setf was glossed over but can, apparently, be used to assign a value to a global defined with defparameter though presumably not defvar, though this isn't explicitly stated (in fact, calling defvar a static may be incorrect, all that is stated explicitly is that it cannot be redefined to a different value using another defvar call whereas defparameter can be).


Then the simple arithmetic shift function which binary shifts {value} by {int}. Binary math is one of the basics I need to work on. Defining ash is simple, grokking it takes some effort.

Finally we have function definitions.

Creates a global (I think?) function. This is the 2nd chapter, things like scope and the subtleties of variable definition aren't being explicitly stated. Anyway. {name} is, clearly, the name you'd use to call this function later. {parameter names} is simply a list of variable names for the function's parameters. {function list} is the code that will be executed. So.

Anytime you call sna it will add foo and bar, the result of which will be implicitly returned to the calling context (either the function call it was used within or to output if it was called directly from the REPL. Which reminds me, the REPL is the basic interface to the Lisp interpreter. It stands for Read Eval Print Loop. It does precisely what it says.


Moving along, there's local function definitions with flet. The syntax is slightly different.

Once again, there's a {name}, {parameter names}, and {function code} however they're enclosed in double ()s. No idea why, yet. That took me a second. The addition of ellipsis indicates that you can define multiple functions for the {code body} in the same way as let. Finally there's the {code body} which contains the code where {name} is in scope.


And the last function definition method covered was labels. labels, apparently, is a window into recursion. It allows functions to be called within other functions defined in the same labels form. I think the book actually has a typo in its example here. First because it won't pass the interpreter and second because the listed example doesn't make sense for Lisp. And the parentheses don't match. Oh, and the proposed output doesn't even make sense.
The book:

That doesn't interpret. It blows chunks because the function 'b' isn't defined. Which makes sense visually. Here's my rewriting which passes the interpreter test:

I laid it out slightly differently too, makes it easier for me to read. To be honest I don't care if it breaks convention (I don't even know what they are yet), I'm not used to reading all those parentheses and I'm not writing code for the perusal of others so I'm going to write it however makes it easiest to read. Moving right along. Here's the generic syntax, assuming I'm right and the book is not:

Condensed like that it's hard to read, but again it's very much the same syntax as flet it just allows each {name} in the function list to reference any other functions in the list. 


Here's an interesting point. LisP is short for List Processor. As the name implies everything in LisP is a list. (I'm pulling this from an aborted attempt to plow through another book on ANSI Common Lisp from a few years ago) Even the functions. The basic syntax is always

where keyword is a builtin command or defined function name, and list is the parameters for the keyword to operate on. Using that nomenclature you can rewrite all of the above. I'm going to make some guesses down here about the underpinnings of the language. I'll probably be wrong, but hey. Grokking it piece by piece.

let takes as parameters a list of tuples for variables and an arbitrary list of additional commands to be parsed. The action that the keyword let performs is basically to replace the occurrences of the keyword with the value each time it sees one of its tuples in the command list.

defun takes a keyword , a list of keywords, and an arbitrary list of commands. The first keyword is taken for a label, or name, or reference, or something. I'm not sure how it's handled or what it's called in the guts of the interpreter. Then you have, basically, which looks a lot like let, doesn't it? I presume the interpreter does something like applying let to each item in {list of keywords} on each function call and then parsing the {list} in that context. flet and labelscan be similarly rewritten by assuming flet to apply defun to each item in {list of functions} which then would apply let to each {list of keywords} within the defuns etc etc ad nauseum. That's why we let the interpreter do it. But in the end it always ends up in a flat list which it processes based on the interpreter's builtins and passes the results back up the stack all the way to, eventually, the REPL. I'm not quite sure how labels works to implement recursion, I assume there's different kinds of internal names? Anyway, that will come later.

I've decided that I can't be bothered to manually do a linked list out of these. Just hit the land of lisp tag and be done with it.

Edit: I went through and crammed all the code bits into gists. It isn't perfect and may not be the best solution, but it'll do.

Morning coding

This lisp study first thing in the morning might work out alright. We'll see. Just completed chp2 this morning covering some basics. I'll summarize after we get back from the beach this afternoon. That should allow me to implement some of the latest understanding of learning, namely that recovering material after a short break is a highly effective strategy.

Work is for the birds

This is what I saw coming in to work this morning.



Not something I'm used to seeing.

In other news, my listed goals below aren't making much progress. Part of me wants to claim that being a father is, at least partly, to blame. Getting everyone settled for the evening is very tiring. A more... grown up? part of me says this is nonsense and I just need to put nose to stone and crank. Not sure which me I like better. Either way I'm making miniscule progress on goal 4, and goal 1 seems to be progressing well enough. Take this as evidence.

Goal 2 is, I think, an important habit I need to develop. I've been blogging and blogging is one of the lines on my chart. Yet my chart remains largely empty. Go figure. To be fair, as long as the proposed productivity is occurring then the chart is largely meaningless except as a petty drip-fed neurochemical trigger. Still, if I can't get in the habit of using it then it comes down entirely to self discipline which isn't something that is constant in my life. I suspect I'll need that petty drip feed when discipline ebbs. At any rate, I've got CLISP installed. Next step on goal 4 is setting up a GIT repo for the code (which will involve digging up my long unused GIT credentials and refamiliarizing myself with it) and then plowing into it.

I nearly set up a Lisp IDE in Eclipse but I couildn't get it all to install and integrate cleanly. Considering I really know buggerall about Eclipse to begin with that probably wasn't the best first step. I'll be using Ultraedit and setting up a script or action or whatever UE calls it to run the interpreter from a CLI window. Maybe I'll dig into Eclipse/CUSP/SBCL et al and make them all play nice together later when/if I'm entrenched in Lisp. Or better yet maybe Light Table will be available by then. At the current rate of progress it may well be 2.0 :P

Oh. And tinkering with the blog's template/layout/&etc is blasted time consuming. Going to have to play with it later.