This summer, I endeavored to learn Android programming. I did some research, and it seems to be similar in many respects to Java programming, hence my enrollment in that class with Joe. However, I just worked all summer. I want to learn Android because it is a fairly new language, it has a very large consumer backing (this means MONEH), and I have an Android device myself. Thus, it would please me greatly to learn more about this device I carry with me all day every day. Maybe in ten years, I can be working with a company working on putting personal computers in the human brain (instant intuitive Google search = infinite knowledge and wisdom).
I have endeavored to learn lisp. I've read a lot, and I've procrastinated heavily on actually implementing what i have read and learned. I was right about a few things. Lisp makes many things a lot quicker and easier. For example, if I were to use the built-in functions native to Common Lisp, I could have a stack implementation in about 15 lines of code, probably less. The hardest thing about it is changing your thought patterns. I can now say that I can think in functions. Lists are powerful. Even though Lisp is a high-level language and does not let the user play with memory, the explanation of lisp functions (for example, how “car” works) do explain how lisp is using pointers. “Car” even stands for Contents of the Address part of Register number. C code now looks foreign to me, and even as I am programming in Lisp now, I look back on code that isn't even an hour old and think to myself “that is too procedural, it needs to be more functional.” I am sure if I put some of my code on the few and far between lisp forums, I would be shunned because my code must smell an awful lot like script or C. I still can't wield recursion, however (unfortunately). I thought doing everything in lisp would be easier, and in some ways it is. If i have an idea of how the structure of a function should be, I can easily run into syntax issues, not matching datatypes, general miscellaneous fail, etc., though it has usually turned out okay thanks to Google and the experienced and contributing efforts of the lisp community. Here I am, zero hour, in the thick of it, and I can say without a doubt that Lisp is a fucking radical language. I just hope I can finish everything.
Here we go. Lisp is a bit of a strange creature when all you know is C/C++. It is functional where C is procedural. Where C is very low-level, lisp is high-level. It is an interpreted language. Getting your mind into a functional thought pattern is the hardest thing about getting into lisp. The syntax isn't hard to understand at all. Lets look at the following function: (last list) last is a function, list is an argument to that function. What last does is print the last element of the list. Pretty neat, considering that the equivalent C code (barring list-processing libraries and such) would be quite verbose and a bit tedious to write. That said, you could hard code your own last function (even though you wouldn't be able to control pointers and stuff like that), you would just have to name it something other than last, since last is a built-in function and therefore reserved. To conclude this introduction, the very very basic principles of lisp are: (function arguments), lists are the native data-type, and parentheses. To play with lisp on your own, ssh into lab46 and type “clisp” at the prompt. Or, you could do a google search for lisp in a box, which runs out of the emacs text editor. I have been using the emacs method and there are still a few things that I can't quite get right, like how to save a file and load and compile it later to resume work on it. Basically, I've just left my emacs session open and running and have not turned my laptop off at all for a few days, whatever. That's enough of that though, let's get into some fun stuff.
We did a singly linked list implementation in C (maybe in C++). It just so happens that simple lists are singly-linked. Each node has a value and a next pointer. When building lists with the list, append, or cons functions, these pointers are taken care of and sorted out by the interpreter. Take note that list, append, and cons can make different kinds of singly linked lists, i.e., a cons of conses, a list of lists of lists, and it is worth while to learn how they behave and which one is right for which job. My implementation is not as functional (as in the programming paradigm) as I would like them to be. There are parts of my code that are more procedural than I would have liked, but hey, it runs fine. Let's look at the very first function: the list builder.
The point of this function is to ask the user for values to put into a list. Easy. We need an input stream reader (stdin or cin or « (or is it »???)), we need a loop, and we need a list. Lisp can handle all of this easily.
(defun builder () ;; function definition
(setf a (list)) ;; sets a variable A to the value of an empty list. NOTE: '() == NIL == the boolean equivalent of false
(print "give us a num") ;; printing in lisp. to chain strings and variable values together:
;; (prin1 "string ") (prin1 var) (prin1 "string"). there is print, prin1, princ, write, and a few others.
(setf x (read)) ;; declare variable X to value of read. read evaluates the input stream, the value is returned to the setf function.
;; thats functional
(setf a (cons x a)) ;; cons takes two arguments and joins them in a list. the last argument has to be a list, the first argument can be
;; any symbol (number, list, string, object, anything). consing two lists makes a list of lists.
;; (list '(1 2) '(3 4)) ==> (1 2 3 4) whereas
;; (cons '(1 2) '(3 4)) ==> ((1 2) (3 4))
(loop while (/= x -1) do ;; loop is not a function, it is a macro. thats all we know, gentlemen.
(prin1 "enter -1 to quit") ;; prints the sentinel value. try and find the condition statement and figure out what it means.
(setf x (read)) ;; storing a value in a variable to cons it later seems a bit too procedural, I'm sure theres a better way, i just
;; didnt know it at the time.
(setf a (cons x a))) ;; updates the value of the list A. also takes the sentinel value into the list. it is a problem with my
;; loop that i chose to fix with some fancy formatting.
(reverse (cdr a))) ;; fun stuff here. the innermost function, while not evaluated last by the interpreter, is a good place to start
;; when deciphering long nested function calls. we will see a one line append in a bit here shortly. the cdr
;; returns everything but the head of the list. if a stores (1 2 3 4 5), then (cdr a) will return (2 3 4 5). the
;; loop actually makes the list as (-1 5 4 3 2 1) when typing, in order, 1 2 3 4 5 -1.
;; the cdr of (-1 5 4 3 2 1) returns (5 4 3 2 1), which is passed to reverse, which makes it (1 2 3 4 5).
in another function, SLLmainlol (because you dont actually need a main, its just a habit from procedural programming… and a great way to wrap up other function calls), i made an append list in one line. granted, there is a built-in append function, that works as you might expect it does, but i wanted to hard code it.
(print (setf thalist (reverse (cons (read) (reverse thalist)))))
there is a running joke about lisp and parentheses, and for a reason. all functions evaluate to something. lisp will always print out the result of the last evaluation. when running a function inside of another function (for example, this function lives in main, so main is running when it calls the append and builder functions), the evaluation is muted becasue it is not the LAST evaluation, the exit of main is (which, because the while loop in main eventually evaluates to false, the whole entire program returns NIL. humbling, really. i note this because when setf exits, it doesnt just assign a variable to a value and say nothing, it evaluates the value of the variable, and that evaluation is passed to the function calling it, and so on. to append, we put something at the end of the list. so i reversed the list, consed a read value to the front of the reversed list, reversed it back, so that value is now squarely at the end, assigned it to the variable it is being stored in for use by main and her child processes, and is then printed so that while main is running we can actually see the updated value of thalist without calling the display function (which can just be (print thalist), and i hard coded that too).
i feel that that, in a nutshell, is the very very acutely briefest taste of lisp that can be offered, outside of code snippets. should this have sparked an interest, you might find some texts in lab 46, or seek out some of these fine resources:
Practical Common Lisp by Peter Seibel: http://www.gigamonkeys.com/book/ excellent book written by a 2nd generation lisper. read the book to find out exactly what that means.
Land of Lisp by Conrad Barski M.D. almost as good as UNIX for the Beginning Mage, if youre into that sort of thing.
ANSI Common Lisp by Paul Graham common lisp is the most common and frequently used dialects of lisp. other dialects include Scheme and Clojure.
this pointer (C++)