Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Idea of Lisp

dev.to

Post reply on HN
Print view View original

161–170 of 348 posts

Re: The Idea of Lisp

#161

Post by vram22 »

For anyone interested, John McCarthy's original paper on Lisp is here:

RECURSIVE FUNCTIONS OF SYMBOLIC EXPRESSIONS AND THEIR COMPUTATION BY MACHINE (Part I)

http://www-formal.stanford.edu/jmc/recursive.html

From the page:

"This paper appeared in Communications of the ACM in April 1960. It is the original paper on Lisp."

I had mentioned it in this blog post in which I gave a few examples of doing simple computations recursively in Python (for beginners).

Recursive computation of simple functions:

http://jugad2.blogspot.in/2016/03/recursive-computation-of-s...

Re: The Idea of Lisp

#162

Post by DonaldFisk »

smitherfield wrote: post #131
DonaldFisk wrote: post #83

Earlier quoted context omitted.

(Singly linked) lists are a functional data structure. You can manipulate them efficiently without modifying the lists you started with. You can't do that easily with arrays. So if you base your language around arrays, you're better off making it imperative. Lisp predated level 1 caches. I think it's better to design hardware around the software that runs on it (the Burroughs mainframe/Lisp machine approach), than de…

I would argue that there's no such thing as a "functional data structure." If a data structure maps poorly to existing functional languages, that's a symptom of an insufficiently powerful and generic type system. Say you have (pseudocode) Array(4 16 5 20) What's its type? Array Array Array Array Array(Int Int Int Int) None of these lend themselves easily to paradigms other than imperative, true. But this is because t…

And if you want a new array whose first element is increased by one, you either have to allocate space for the entire array, modify the array, or use a different data structure.

Re: The Idea of Lisp

#163

Post by rntz »

pg314 wrote: post #144
crististm wrote: post #129

Earlier quoted context omitted.

Garbage collection is not necessary for lisp. Garbage collection only provides the illusion of infinite memory. Just like malloc/free.

And the implementation of garbage collection was, on at least two occasions, postponed. Once in the first implementation [1] and a second time in the early MIT Lisp Machines [2] (you just ran the machine until you ran out of memory which could take days or weeks, after which you saved the world to disk and rebooted). [1] http://www-formal.stanford.edu/jmc/history/lisp/node3.html [2] https://www.csee.umbc.edu/courses/…

"saving the world to disk and rebooting" sounds like a primitive form of garbage collection to me :)

Re: The Idea of Lisp

#164

Post by goatlover »

sbov wrote: post #154
clarkd99 wrote: post #55

This great idea of Lisp (the simple syntax of function calls in round brackets) isn't much different than a good macro assembler even back in the 1960's. The only major difference was that more than 1 function could be defined in 1 source code line. (I think that machine code is nothing but a sequence of function calls where the function is the logic encoded in the CPU itself for each opcode.) Is it fair to compare t…

There's a lot here, but this one jumped out at me: > You can indent a Lisp program in any way but the language doesn't require any at all. Off the top of my head, isn't this true of basically all languages? Except one, and it got a lot of criticism for it (Python).

Haskell and Elm use whitespace as well, but I don't recall if they enforce the indentation.

Re: The Idea of Lisp

#165

Post by qwertyuiop924 »

goatlover wrote: post #141
mroll wrote: post #31

Earlier quoted context omitted.

Yeah the level of dynamicness (dynamism?) you can get in tcl is unparalleled as far as I can see. Having no types or syntax and access to the entire runtime at any point in the program opens up all kinds of crazy doors. But you're right, that slows it down. But you might be interested to know there is currently an effort to get Tcl to compile to native/near-native code. Here is a paper on the new techniques being dev…

I believe IO lets you do the same. Everything is a prototype with slots, communicating via messages. I guess Self was the same way. Self & Smalltalk also give you access to the entire runtime.

But TCL actually goes beyond that.

Most languages of this sort, like Smalltalk, Lisp, and especially slower, more liberal implementations like PicoLisp, allow for compile-time and/or runtime AST transformation, and other sorts of metaprogramming.

in TCL, everything is a string. Or at least, everything behaves like a string in the proper context. When you pass code blocks into a command (like if, or while, or whatever), you're not passing code objects: you're passing unevaled strings. This is why expr works in TCL: there's nothing special about expr, it's just actually implementing a DSL (sort of) rather than evaling your code straight up.

The practical upshot of this is that unlike smalltalk (I think: Can an ST user actually answer this?), and to a greater degree than LISP and FORTH (;immediate and readtables are a lot more painful to wrangle), you can not only modify the semantics of the language: you can modify the syntax.

Re: The Idea of Lisp

#166

Post by panic »

kluck wrote: post #3

Lisp was developed because McCarthy needed a tool for experimenting with AI. Found a video of McCarthy talking about AI: https://www.youtube.com/watch?v=Ozipf13jRr4 And if anyone cares, here is nice Shirt with McCarthy on it ;) https://www.teepublic.com/t-shirt/666689-john-mccarthy-lisp-... I think it should be mandatory for CS students to implement their own little Lisp using the building blocks McCarthy described!…

I think it should be mandatory for CS students to implement their own little Lisp using the building blocks McCarthy described!

That used to be part of the intro course at MIT and Berkeley, but they've since switched to Python: https://web.archive.org/web/20091209071455/http://danweinreb...

Re: The Idea of Lisp

#167

Post by qwertyuiop924 »

jhbadger wrote: post #63
qwertyuiop924 wrote: post #26

Earlier quoted context omitted.

TCL, while it has its warts, is a really cool language. I mean, it even basically has fexprs, something most Lisps put by the wayside years ago. When you don't actually care about speed, you can do some pretty cool stuff.

Pity that it became so associated with the Tk GUI toolkit -- half the Linux GUI apps in the 1990s were in Tcl/Tk, and when Tk fell out of favor so did Tcl.

...And with TTK, you can finally have easy-to-write cross-platform UIs that actually look native.

Seriously. If you want a decent cross-platform UI system with minimal effort, which has bindings in just about every language, TK is really worth your time now.

Re: The Idea of Lisp

#168

Post by panic »

crististm wrote: post #129
rntz wrote: post #70

This article has many misstatements in its first half. > John McCarthy wrote 6 easy things in machine code, then combined them to make a programming language. John McCarthy didn't implement Lisp in machine code. Steve Russell did. Implementing Lisp properly in machine code is not easy; you have to write a garbage collector. To do that in the early 60s, you had to first invent garbage collection . Lisp was and is bril…

Garbage collection is not necessary for lisp. Garbage collection only provides the illusion of infinite memory. Just like malloc/free.

It's difficult to use malloc/free memory management in a language that supports closures, since ownership becomes very hard to keep track of statically.

Re: The Idea of Lisp

#169

Post by jjnoakes »

pg314 wrote: post #151
mroll wrote: post #25

Earlier quoted context omitted.

If you like everything being an expression, check out tcl. A lot of ideas from lisp show up in tcl, especially the idea of everything as an expression. Tcl embodies this idea while also having the look of an algol-like language. Funny it can pull this off while having basically no syntax.

Tcl does have a lispy feel to it, but s-expressions in Lisp are much more elegant than strings in Tcl, imho. Greenspun called Tcl the Lisp without a brain[1], which can be taken both as a compliment or an insult. [1] http://philip.greenspun.com/tcl/introduction.adp

Tcl commands are lists, not strings. Or more precisely, they are coercible to strings or lists, but a well-formed Tcl command string is always coercible to a well-formed Tcl list (not all Tcl strings are coercible to lists).

Re: The Idea of Lisp

#170

Post by junke »

kazinator wrote: post #159
junke wrote: post #143

Earlier quoted context omitted.

In Lisp, "def..." macros, like defclass, defun, etc. return the symbol to which is bound the definition. Not essential, but useful at times. I tend to find Lisp is full of details like this.

Well, Common Lisp! In the Scheme language, many imperative forms have an unspecified result. For instance, see R7RS 4.1.6: "the result of the set! expression is unspecified". Also, a related misfeature is that function arguments can be evaluated in any order.

Yes, sorry, Common was implied (not claiming it should always be, but here I wrote it without thinking about others). Scheme's unspecified results are annoying indeed.
Post reply on HN