Earlier quoted context omitted.
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.
You can still do anaphoric macros with hygienic macros. http://blog.racket-lang.org/2008/02/dirty-looking-hygiene.ht... And http://blog.racket-lang.org/2011/04/writing-syntax-case-macr...
The Nature of Lisp
41–50 of 82 posts
Re: The Nature of Lisp
#42Very 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…
Re: The Nature of Lisp
#43I 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 concept, but in practice difficult to use properly in your code. It's too difficult to reason about what's going on, like say, if you're maintaining or modifying a set of macros. I think it's more useful not as a construct that you would often use in your own code, but as a construct that's very useful for making libraries.
2. Continuations. This is not really related to lisp itself, and can be done in other languages, like javascript[0]. Understanding a continuation as an even higher level construct than closures .. and the fact that scheme had it built-in was very mind blowing for me.
It makes sense though that a lisp language must have it built-in. It's a concept that's very fundamental to the theory of computation, but in most programming languages it's not explicit at all.
Before continuations, I thought no lisp language can ever have equivalents of "break", "return", or "continue". After understanding continuations, I see that these constructs can built using continuations as a basic building block.
So this to me suggests that the concept of "continuation" is a very basic and fundamental concept that all students of Computer Science should be familiar with. Unfortunately I was never taught about it in University.
Re: The Nature of Lisp
#44It 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…
Re: The Nature of Lisp
#45I 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…
Re: The Nature of Lisp
#46Concept 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 to illustrate, in which order and why.
Then watch the Lectures, to feel the bliss.)
The true piece of mind comes after you finish reading On Lisp and then the contents of arc3.tar
Before that it is still just as being blinded and puzzled by a sudden flash of premature enlightenment.)
Re: The Nature of Lisp
#47It 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…
So something like Clojure, but that runs on the CLR and Javascript as well? CLR - https://github.com/richhickey/clojure-clr JS - https://github.com/clojure/clojurescript Python - https://github.com/halgari/clojure-py Lua - https://github.com/raph-amiard/clojurescript-lua C - https://github.com/schani/clojurec (Sorry, couldn't resist.)
Re: The Nature of Lisp
#48Re: The Nature of Lisp
#49...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…
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 works rather nice, actually.
Re: The Nature of Lisp
#50Replacing 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…
1. To the beginners, we need to explain; why code/data unity opens up broad possibilities and separation is simplistic. Otherwise some people claim that the best LISP DSL you ll write, will end up separating your data from your code, and tell you the virtues of von Neumann architecture.
2. Also the macro expansion time, and run time separation for non-interpreted LISP seems to be a restriction; mainly if all macros are to be defined at design time and expanded at macro expansion time, the advantages of macros seem to be limited against languages without macros. Namely, macros seem to be a way to modularize code by generalizing, and simpler languages may do it with text editing and module/source code organization features.