LOGO is already Lisp without parentheses and with infix notation. Recently, doing exercises in LOGO with my kid,he asked: can we put some parentheses around the functions for better clearness? I said: my son, you just discovered Lisp!
>>> def add_one(x):
... return x + 1
...
>>> add_one
<function add_one at 0x7f7504bf2050>
>>> add_one(1)
2
>>> list(map(add_one, [1,2,3]))
[2, 3, 4]
=> (define (add-one x)
(+ x 1))
add-one
=> add-one
#[compound-procedure add-one]
=> (add-one 1)
2
1 ]=> (map add-one (list 1 2 3))
(2 3 4)Say `x` is a function which adds one to a number.
Say `y` is an atom which is not a function—perhaps a list: `(list 1 2 3)`.
If you write just `x`, no parens, you point to the function without executing it. If you do this at your interpreter it will tell you that the value of `x` is “function something something.”
This is important because it’s what makes it possible to pass functions as arguments, and write things like `(map x y)`. Here `x` is not evaluated in place; it’s called later by the `map` function, once for each element of the list, resulting in `(list 2 3 4)`.
Now if you put parentheses around `x`, lisp will try to execute it on the spot. `(x 1)` is what other languages would call `x(1)`, and will return `2`.
You have to be a little careful about this because it means that if you put parens around `y`, which isn’t a function, you’ll get an error. This is why lisp has the ‘quote’ operator, which means “take the next atom as literal data and don’t try to execute it.” So `(quote (1 2 3))` will return `(1 2 3)`. This can also be written `’(1 2 3)`—which is nice, because this is effectively equivalent to `(list 1 2 3)`, and could have saved me some typing when I defined `y` earlier.
e: typo ; also, sorry for the ugly syntax, I forgot there was no inline code formatting on HN
When you write (x) in the Lisp REPL, Lisp will assume you intend to call a function bound to x because x appears first in the list. If you instead wrote (y x), Lisp would never assume x was a function. If the first thing in a list is not bound to a function, Lisp will throw an error.
When you write '(x) [note leading quotation mark], Lisp will simply construct a list that contains the symbol x as its only element.
In my explanation above, I didn't make the distinction about the quotation mark because I assumed the questioner was asking about data structures. Lisp will print "the list containing x" without the quotation mark. But if that's what you mean when you type it, you have to explicitly type the quotation mark.
Writing "(x)" in Lisp is like writing "x()" in JavaScript, that is executing the function which was stored in the variable x.
(defun Foo (x) ...
(let ((x 4))...
It is just that, in lisp, you start a list of data with paren. In other languages, you activate a different part of the parser. It so happens that the default thing the evaluator does to a list is to apply it to a function given in the first spot.
(x) means "a list that contains the symbol whose name is x." Lists are also first-class objects in Lisp, and they are built using cons cells. A cons cell is itself a struct with precisely two fields: a CAR and a CDR. And you can put anything in either field, including a pointer to another cons cell. The x symbol in this example would be pointed to by the CAR of a cons cell, and the symbol NIL (a special global symbol) would be pointed to by its CDR to indicate "the end of the list."
So (x) means a struct whose CAR contains a pointer to the symbol named "x" and whose CDR contains a pointer to the symbol named NIL. Otherwise known as a list with one element.
? run `[print ,[sum 2 3]]
5
But also a very sophisticated way to define functions with many default and within even optional parameters without the need of parentheses. From UCBLogo info:
This version of Logo allows variable numbers of inputs to a procedure. After the procedure name come four kinds of things, in this order:
1. 0 or more REQUIRED inputs :FOO :FROBOZZ
2. 0 or more OPTIONAL inputs [:BAZ 87] [:THINGO 5+9]
3. 0 or 1 REST input [:GARPLY]
4. 0 or 1 DEFAULT number 5You may not want a powerful macro system in those languages, but I personally think it would far preferable to the existing mess of annotations and build-system hacks to generate code.