8 ms·
To understand Lisp is to understand interpreters. With that understanding you can create domain specific languages which is extremely powerful. But I wouldn't
by jon6 14y ago
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.
- p4bl0 14y agoCommon Lisp != Lisp. You mean Common Lisp, Lisp is the family of languages (which also includes the Scheme sub-family, Racket, Clojure, Arc, Kernel…).
- jon6 14y agoIts disingenuous to call scheme and racket lisps. They have parenthesis and first class functions but the similarities stop there. So yes I equate Lisp with common lisp. I didn't read the entire article (far too long) but he does mention 'defmacro' which is in Common Lisp.
- deleted 14y ago[deleted]
- mattdeboard 14y agoSo, homoiconicity is a trifling, meaningless similarity? "Sure, it may be homoiconic, use prefix notation, have first-class functions (in additional to all the other usual functional paradigms that aren't unique to lisps) but it's not a lisp." Big ok to that one. This must be pedantry of the highest caliber, not ignorance.
- jon6 14y agoThey are not homoiconic. The underlying datastructure for many schemes, and racket, is not a list. It is a syntax object. Of course you can still do metaprogramming with syntax objects but I wouldn't call it the same thing.
- lucian1900 14y agoHomoiconicity doesn't refer to lists, but to syntax being represented in the data structures of the language.
- elibarzilay 14y agoYou should be careful here, and not lump together "many Schemes" and "Racket" (or other specific Scheme implementations). The thing is that Scheme standards have traditionally avoided tying the language with a macro system that requires some specific representation for syntax -- giving you only the simple rewrite rules system means that you don't actually need to know that representation. In Racket, OTOH, there are definitely syntax objects with enough functionality to write code that handles them, and I suspect that you know that. The question is whether this should be considered "homoiconic" or not, but this is a kind of a subjective issue, since at an extreme, I can say that all languages that have strings are homoiconic. Perhaps you need more from the language to make it so, maybe eval, or maybe actually require it to have compile-time procedural macros? In any case, Racket will have all of the features that CL does, so it is arguably at least "as homoiconic" as CL is. But in fact, it has more than just s-expressions: these syntax objects are basically sexprs + a bunch of stuff like source location and lexical context, so in fact they represent more than what lists in CL do. Should I then conclude that Racket is more homoiconic than CL? And this is not a tongue-in-cheek argument: in fact, many CL implementations are aware of the limits of sexprs as good representation for code, and add things like source location via a backdoor, like a hash table that maps pair objects to additional properties. Racket does that in its basic syntax representation so IMO it's fine to indeed consider it more homoiconic. And I also say that for the addition of lexical context information -- that's something that is not only included in the Racket syntax object, it's something that you just cannot get in CL, so if homoiconicity is being able to have a high-level representation of code (unlike raw strings), then this is another point where Racket wins the pissing context. Finally, it's not that all "many Schemes" are limited as described above -- there are many of them that have their own macro systems with similar syntax values, and that includes Schemes that follow R6RS since that dictates syntax-case which comes with them. It just happens that Racket is has been traditionally running at the front lines, so it's more advanced.
- orthecreedence 14y agoYou are right, but I disagree. I almost always call "Common Lisp" "Lisp." Scheme is Scheme, Clojure is Clojure, etc etc. I don't care about the family vs language distinction. I think it hurts Common Lisp's adoption. I'd sooner call Common Lisp, Scheme, Clojure, etc part of the "Lisp family" instead of just "Lisp," and leave "Lisp" to mean "Common Lisp."
- eblume 14y agoI am admittedly still a Lisp (et. al.) rookie, but isn't the entire point of Scheme that it introduces hygienic macros? Or are you referring to some other (perhaps sarcastic) notion of macro hygiene?
- snprbob86 14y agoThat's one design characteristic of Scheme, but I wouldn't call it "the entire point".
- projectileboy 14y agoYou 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.
- jon6 14y agoYou can still do anaphoric macros with hygienic macros. http://blog.racket-lang.org/2008/02/dirty-looking-hygiene.html http://blog.racket-lang.org/2008/02/dirty-looking-hygiene.ht... <edit> And http://blog.racket-lang.org/2011/04/writing-syntax-case-macros.html http://blog.racket-lang.org/2011/04/writing-syntax-case-macr...
- deleted 14y ago[deleted]
- brudgers 14y ago[Most of] Let Over Lambda as free HTML: http://letoverlambda.com/textmode.cl/guest/toc http://letoverlambda.com/textmode.cl/guest/toc Graham's On Lisp as free PDF: http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf
- vseloved 14y agothen, here's an old classic for you: https://groups.google.com/forum/?fromgroups#!msg/comp.lang.lisp/y2etNGix8Z0/x87gXWQVuQcJ https://groups.google.com/forum/?fromgroups#!msg/comp.lang.l... ;)