| 1 |
[This is a brief tutorial on Arc. It's intended for readers with little programming experience and no Lisp experience. It is thus also an introduction to Lisp.] Arc programs consist of expressions. The simplest expressions are things like numbers and strings, which evaluate to themselves. arc> 25 25 arc> "foo" "foo" Several expressions enclosed within parentheses are also an expression. These are called lists. |
| 2 |
When a list is evaluated, the elements are evaluated from left to right, and the value of the first (presumably a function) is passed the values of the rest. Whatever it returns is returned as the value of the expression. arc> (+ 1 2) 3 Here's what just happened. First +, 1, and 2 were evaluated, returning the plus function, 1, and 2 respectively. 1 and 2 were then passed to the plus function, which returned 3, which was returned as the value of the whole expression. |
| 3 |
(Macros introduce a twist, because they transform lists before they're evaluated. We'll get to them later.) Since expression and evaluation are both defined recursively, programs can be as complex as you want: arc> (+ (+ 1 2) (+ 3 (+ 4 5))) 15 Putting the + before the numbers looks odd when you're used to writing "1 + 2," but it has the advantage that + can now take any number of arguments, not just two: arc> (+) 0 arc> (+ 1) 1 arc> (+ 1 2) 3 arc> (+ 1 2 3) 6 This turns out to be a convenient property, especially when generating code, which is a common thing to do in Lisp. |
| 4 |
Lisp dialects like Arc have a data type most languages don't: symbols. We've already seen one: + is a symbol. Symbols don't evaluate to themselves the way numbers and strings do. They return whatever value they've been assigned. If we give foo the value 13, it will return 13 when evaluated: arc> (= foo 13) 13 arc> foo 13 You can turn off evaluation by putting a single quote character before an expression. |
| 5 |
So 'foo returns the symbol foo. arc> 'foo foo Particularly observant readers may be wondering how we got away with using foo as the first argument to =. If the arguments are evaluated left to right, why didn't this cause an error when foo was evaluated? There are some operators that violate the usual evaluation rule, and = is one of them. Its first argument isn't evaluated. If you quote a list, you get back the list itself. |
| 6 |
arc> (+ 1 2) 3 arc> '(+ 1 2) (+ 1 2) The first expression returns the number 3. The second, because it was quoted, returns a list consisting of the symbol + and the numbers 1 and 2. You can build up lists with cons, which returns a list with a new element on the front: arc> (cons 'f '(a b)) (f a b) It doesn't change the original list: arc> (= x '(a b)) (a b) arc> (cons 'f x) (f a b) arc> x (a b) The empty list is represented by the symbol nil, which is defined to evaluate to itself. |
| 7 |
So to make a list of one element you say: arc> (cons 'a nil) (a) You can take lists apart with car and cdr, which return the first element and everything but the first element respectively: arc> (car '(a b c)) a arc> (cdr '(a b c)) (b c) To create a list with many elements use list, which does a series of conses: arc> (list 'a 1 "foo" '(b)) (a 1 "foo" (b)) arc> (cons 'a (cons 1 (cons "foo" (cons '(b) nil)))) (a 1 "foo" (b)) Notice that lists can contain elements of any type. |
| 8 |
There are 4 parentheses at the end of that call to cons. How do Lisp programmers deal with this? They don't. You could add or subtract a right paren from that expression and most wouldn't notice. Lisp programmers don't count parens. They read code by indentation, not parens, and when writing code they let the editor match parens (use :set sm in vi, M-x lisp-mode in Emacs). Like Common Lisp assignment, Arc's = is not just for variables, but can reach inside structures. |
| 9 |
So you can use it to modify lists: arc> x (a b) arc> (= (car x) 'z) z arc> x (z b) Lists are useful in exploratory programming because they're so flexible. You don't have to commit in advance to exactly what a list represents. For example, you can use a list of two numbers to represent a point on a plane. Some would think it more proper to define a point object with two fields, x and y. But if you use lists to represent points, then when you expand your program to deal with n dimensions, all you have to do is make the new code default to zero for missing coordinates, and any remaining planar code will continue to work. |
| 10 |
Or if you decide to expand in another direction and allow partially evaluated points, you can start using symbols representing variables as components of points, and once again, all the existing code will continue to work. In exploratory programming, it's as important to avoid premature specification as premature optimization. The most exciting thing lists can represent is code. The lists you build with cons are the same things programs are made out of. |
| |
… |
Комментарии