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

The Nature of Lisp

defmacro.org

Post reply on HN
Print view View original

51–60 of 82 posts

Re: The Nature of Lisp

#51

Post by Ingaz »

bitops wrote: post #9

Very good article, though I doubt it'll convince the usual mass of unbelievers. (I love Lisp, for the record, though my primary exposure has been through Emacs Lisp - so shoot me). A really great book that helps you get appreciate the concepts in Lisp, without really talking about Lisp directly too much, is "Patterns of Software" by Peter Gabriel. http://amzn.to/TxDKGG I found it to be a very enlightening read. Defin…

>>the concepts in Lisp, without really talking about Lisp directly too much

The book with the same feature is "ANTLR definitive guide".

When I read it I was like: "Ha! It sounds like LISP!", "Ha! It sounds like FORTH!", "Ha! It sounds like Prolog!"

And Terence Parr mentioned none of them.

Amazing!

Re: The Nature of Lisp

#52

Post by brudgers »

bitops wrote: post #9

Very good article, though I doubt it'll convince the usual mass of unbelievers. (I love Lisp, for the record, though my primary exposure has been through Emacs Lisp - so shoot me). A really great book that helps you get appreciate the concepts in Lisp, without really talking about Lisp directly too much, is "Patterns of Software" by Peter Gabriel. http://amzn.to/TxDKGG I found it to be a very enlightening read. Defin…

Patterns of Software is available as a free PDF directly from Gabriel's website: http://dreamsongs.net/Files/PatternsOfSoftware.pdf

Re: The Nature of Lisp

#53

Post by brudgers »

dschiptsov wrote: post #46

Replacing XML with YAML will make it much more clear and much more shorter. Concept of bindings (of symbols to values) and lexical scope (frames of the environment) must be described. DSLs must be introduced to show how a list structure and uniform function application syntax glue everything together. The much better advice - read SICP for Christ's sake .) People who wrote it spend much more time thinking what ideas…

Graham's On Lisp as free PDF: http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf

Structure and Interpretation of Computer Programs as free HTML: http://mitpress.mit.edu/sicp/full-text/book/book.html

Re: The Nature of Lisp

#54

Post by brudgers »

projectileboy wrote: post #10
jon6 wrote: post #3

To understand Lisp is to understand interpreters. With that understanding you can create domain specific languages which is extremely powerful. But I wouldn't recommend using Lisp itself.. macros in particular are unhygienic.

You can do cool stuff with unhygienic macros, however, like anaphoric macros. Interested readers should check out On Lisp by Paul Graham, as well as Let Over Lambda by Doug Hoyte.

[Most of] Let Over Lambda as free HTML: http://letoverlambda.com/textmode.cl/guest/toc

Graham's On Lisp as free PDF: http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf

Re: The Nature of Lisp

#55

Post by qznc »

ChuckMcM wrote: post #35
sjmulder wrote: post #32

It would seem to me that some variety of Lisp would be the ideal candidate as a sort of runs-everywhere language, a thin portable base language that runs on top of different runtimes, offering easy integration with whichever it is running on. Basically, something like a minimalist Clojure but not just for Java. It would be able to run atop the CLR, JavaScript or the Objective-C runtime as well. The interface with the…

Forth. Constructing the basic machine is trivial, then the rest just comes along with it.

Though Forth is only really elegant, when implemented in assembly. Forth requires to generate code on the fly. For something like the JVM, this means to implement your own bytecode interpreter or hijack the class loader. Neither solution comes close to the simplicity of writing some machine code into memory and jump into it.

Re: The Nature of Lisp

#56

Post by qznc »

hasenj wrote: post #43

I passionately hate XML so this could not possibly resonate with me. I never had the enlightenment he talks about. Actually I think that learning Lisp/Scheme might have made me a bit of a worse programmer in a way. It made me "dread" repetitive code so much to the point that I almost could not do anything with any language that's not highly dynamic. Anyways. I had 2 epiphanies with lisp. 1. Macros. Very powerful conc…

1. Macros. The Common Lisp version has this problems, but the Racket guys have hygenic macros, which are much better. I have probably not fully understood them, but the most important thing is imho to use lexical binding even inside macros.

2. Continuations. Higher level than closures? The real understand of continuations comes from the implementation imho. You implement your stack frames as a garbage collected tree data structure, instead of the C-way of a memory blob.

Re: The Nature of Lisp

#57

Post by bad_user »

merijnv wrote: post #49
nnq wrote: post #48

...a bit offtopic, but I was wondering while reading the example of using C itself as the C preprocessor language: why don't languages provide the ability to do this kind of thing automagically, I mean marking some code to be executed at compile time and act as a code generation feature? (I know, it's easy enough to write a small preprocessor that does it, and it's just primitive string based macros, but having a sta…

> why don't languages provide the ability to do this kind of thing automagically, I mean marking some code to be executed at compile time and act as a code generation feature? There's certainly already languages that do this type of thing. Haskell has Template Haskell which lets you execute Haskell code at compile time to generate code. I'm pretty sure multiple ML's also have similar meta-programming features. It wor…

Scala 2.10 will have it too.

There is a distinction to be made. In non-homoiconic languages writing macros takes a lot of effort, while in Lisp it's very natural.

On the other hand I don't feel that's an advantage for Lisp, because macros are not composable as functions are and you have to really grok Lisp in order to write macros effectively and also recognize instances where they are appropriate.

Re: The Nature of Lisp

#58

Post by dschiptsov »

brudgers wrote: post #53
dschiptsov wrote: post #46

Replacing XML with YAML will make it much more clear and much more shorter. Concept of bindings (of symbols to values) and lexical scope (frames of the environment) must be described. DSLs must be introduced to show how a list structure and uniform function application syntax glue everything together. The much better advice - read SICP for Christ's sake .) People who wrote it spend much more time thinking what ideas…

Graham's On Lisp as free PDF: http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf Structure and Interpretation of Computer Programs as free HTML: http://mitpress.mit.edu/sicp/full-text/book/book.html

Movies - http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussma... ,)

Re: The Nature of Lisp

#59

Post by bitdiddle »

sjmulder wrote: post #32

It would seem to me that some variety of Lisp would be the ideal candidate as a sort of runs-everywhere language, a thin portable base language that runs on top of different runtimes, offering easy integration with whichever it is running on. Basically, something like a minimalist Clojure but not just for Java. It would be able to run atop the CLR, JavaScript or the Objective-C runtime as well. The interface with the…

scheme

Re: The Nature of Lisp

#60

Post by gliese1337 »

Reading the related article on writing a Lisp interpreter in Haskell (http://news.ycombinator.com/item?id=4764088) reminded me of my second blinding moment of enlightenment- understanding vau expressions. Things that can't be implemented as functions are typically things that require controlling the evaluation of arguments (conditionals, assignment, short-circuiting boolean operators, etc.), and additional language features (built-in special forms or macros for writing your own) are included to handle those. But if you have something that allows you to control the evaluation of arguments, simply choosing to evaluate all your arguments gives the equivalent of a function. Implement that thing, and your compiler/interpreter no longer needs to know about the difference between functions and macros and built-in forms; they're all the same thing!

There's not a lot of practical use for that kind of thing that I am aware of (implementing run-time macros is one, being able to pass short-circuiting boolean operators to map, reduce, etc. is another), but I strongly suspect that's just because we don't have 30 years of collective experience figuring out all of the great things about vau expressions like we have with Lisp and anonymous functions. The only language (discounting toy projects) I know of that actually implements them is Kernel (http://web.cs.wpi.edu/~jshutt/kernel.html).

Post reply on HN