(λove (print (eval (read))))

Re:(λove (print (eval (read)))) by bmf on Monday September 09, 2013 @05:57PM (#6356543)

Richard Gabriel did a great write-up of the trade-offs during the ANSI Common Lisp standardization process:

http://www.nhplace.com/kent/Papers/Technical-Issues.html

What I took away from it was that macros get more tricky to write when you have possible variable capture for functions, which we humans seem to be a little more blind to than for values.

Item 18 contains the compatibility concerns for existing code, which the guys writing the standard seemed to think critical to keep the various vendors on board.

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by vseloved on Monday September 09, 2013 @10:27PM (#6357739)

Lisp-2 is much saner. What it adds is just funcall, and it's not such a big deal in practice, because most of the times in the situations of higher-order function you would use apply, reduce or map, which likewise should be used in Lisp-1. What it brings instead is that you have to worry about name clashes much much less. The classic is list vs lst.

What I personally like is that you always know what are you referring to in a higher-order function call: a variable name or a function name. So it just removes the need for some additional intellectual effort of remembering this (i.e. #' is a nice annotation)

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by ruricolist on Monday September 09, 2013 @10:18PM (#6357698)

Interestingly, the Ur-Lisp (Lisp 1.5) actually had both. There were two ways to define a function. There was one form, LABEL (the ancestor of CL's LABELS), which bound a function like a variable, and another form, DEFINE, that put the function on the symbol's property list. APPLY would check the property list first, then look for a variable binding.

From the Lisp 1.5 manual (1962):

"In actual practice, LABEL is seldom used. It is usually more convenient to attach the name to the definition in a uniform manner... The fact that most functions are constants defined by the programmer, and not variables that are modified by the program, is not due to any weakness of the system. On the contrary, it indicates a richness of the system which we do not know how to exploit very well."

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by kinghajj on Monday September 09, 2013 @05:29PM (#6356363)

It also encourages one to separate data and code, which is completely (in my mind) counter to Lisp's great achievement in combining the two.

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by pcwalton on Monday September 09, 2013 @06:52PM (#6356829)

Erik Naggum had an impassioned defense of Lisp-2: https://groups.google.com/forum/#!msg/comp.lang.lisp/04rR3_j...

I don't buy it, but I can understand the reasoning.

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by moomin on Monday September 09, 2013 @07:29PM (#6357014)

I find the reasoning specious. In particular, files and programs are the same in MS-DOS and Unix. You can, for instance, ls the ls command or cat the cat command. He's also completely ignoring the superiority of the file system's namespacing (by directory) to just having two global buckets like in elisp.

The execute bit comparison is especially specious. If I try to execute a non-executable file, it fails. It doesn't go look for an executable file with the same name. Same as if I try to invoke 0 in Clojure. e.g. (0)

He's right that the symbol resolution of the first entry has different rules but ignores the fact that the shell isn't very good at higher order commands. Which is probably okay for a shell but not much use for a modern programming language.

Finally, he's right that multiple namespaces are a good idea, but that's Accepted Truth these days. It's just that we think namespacing should be under the control of the dev, not dependent on the type of the variable.

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by Theriac25 on Tuesday September 10, 2013 @04:22AM (#6358841)

> In particular, files and programs are the same in MS-DOS and Unix. You can, for instance, ls the ls command or cat the cat command.

Uh, no you cant:

  $ ls ls
  ls: cannot access ls: No such file or directory
  $ cat cat
  cat: cat: No such file or directory

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by euccastro on Tuesday September 10, 2013 @05:11AM (#6358962)

    $ ls $(which ls)
    $ cat $(which cat)

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by vseloved on Tuesday September 10, 2013 @07:42AM (#6359409)

looks just like (funcall #'funcall ... ;)

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by Avshalom on Tuesday September 10, 2013 @01:22PM (#6361453)

Its more like

  ls /bin/ls

you can simply cat cat or ls ls by cd-ing to /bin first... with the caveat that some distros have moved them to /usr/bin or somewhere, hence the 'which'

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by moomin on Wednesday September 11, 2013 @04:41PM (#6369917)

Exactly. File systems resemble modern namespaces, not namespacing by type. You can put an executable and a data file in the same directory, or not. Your choice.

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by moomin on Monday September 09, 2013 @05:42PM (#6356446)

I have much the same reaction. My theory is that it comes from an extinct Lisp tribe. Those who think like that these days use different languages (Java?). We can only really hunt for someone who dates from that time and remembers what they were thinking. Maybe Richard Stallman? :)

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by ScottBurson on Tuesday September 10, 2013 @02:22AM (#6358486)

I've used both Lisp-1 and Lisp-2, and really, this is a tempest in a teapot. It makes zero difference to how I think about code and very little difference to how I write it.

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by leoc on Tuesday September 10, 2013 @08:26AM (#6359538)

The paper that coined the term http://www.nhplace.com/kent/Papers/Technical-Issues.html lists arguments on both sides. IIRC the main argument in favour of Lisp-2 is that it makes CL-style macros easier to write by making it easier to avoid some kinds of variable capture.

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by e40 on Monday September 09, 2013 @07:20PM (#6356962)

Purist vs pragmatist. It's that simple. There were existing Lisp programs that would break. Big ones.

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by samatman on Monday September 09, 2013 @07:17PM (#6356950)

I like it. I don't think it would have arisen if English doesn't routinely verb nouns. But it does.

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by fogus on Monday September 09, 2013 @05:32PM (#6356385)

I won't argue for the aesthetics, but I am curious what you mean by "loss of generality."

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by breckinloggins on Monday September 09, 2013 @05:50PM (#6356500)

Perhaps that was worded wrong, but what I meant was the idea that you have names that map to things, and that you have an evaluation order for those things. So that if you see

(foo a b c) and it isn't quoted, we know that foo will be resolved and evaluated, so will a, b, and c, and then the objects to which a, b, and c resolved will be applied to the object to which foo was resolved.

So, if I then type (a foo b c), we get the same behavior with different object resolutions.

And that should work everywhere, all the time.

[ Parent | on HN ]

Re:(λove (print (eval (read)))) by brudgers on Monday September 09, 2013 @09:31PM (#6357473)

Hmm...one symbol that points to both values and methods...maybe that could be the foundation upon which some types of useful abstractions could be built...nah, it would never be successful.

[ Parent | on HN ]