5 ms·
Not a lisp user myself, so I can't speak firsthand, but Paul Graham has several essays about it. http://www.paulgraham.com/lisp.html http://www.paulgraham.com/l
by squeaky-clean 11y ago
Not a lisp user myself, so I can't speak firsthand, but Paul Graham has several essays about it. http://www.paulgraham.com/lisp.html http://www.paulgraham.com/lisp.html
- k__ 11y agoCan languages with other syntax have the same properties?
- sklogic 11y agoAny language with a compile-time metaprogramming would do.
- TeMPOraL 11y agoTcl I heard has string-based homoiconicity. Otherwise, I'm yet to see a proof you can get an actual, usable and not incredibly annoying macro system working without turning your language into a Lisp. People keep trying, but it's always some inelegant subset bolted onto the core syntax.
- sklogic 11y agoTake a look at Converge, Nemerle, TH and many other similar languages - they're doing just fine without any homoiconicity. All you need is a decent quasiquotation.
- TeMPOraL 11y agoThanks for the pointers, I never heard of those languages before. I am actually looking at the Converge documentation on macros now, and I found the perfect quote to highlight the problem I see with those approaches: Quasi-quotes allow ITree's to be built using Converge's normal concrete syntax. Essentially a quasi-quoted expression evaluates to the ITree which represents the expression inside it. For example, whilst the raw Converge expression 4 + 2 prints 6 when evaluated, [| 4 + 2 |] evaluates to an ITree which prints out as 4 + 2. Thus the quasi-quote mechanism constructs an ITree directly from the users' input - the exact nature of the ITree is of immaterial to the casual ITree user, who need not know that the resulting ITree is structured along the lines of add(int(4), int(2)). That is, quasi-quotes take some code and turn it into a tree object. This tree object can then somehow get compiled into actual code later. Compare that with Lisp approach, in which code is data. You don't think about the code as something separate from the tree that represents it. The code is the tree. There is no ITree object. It may seem like just "semantics", but I find this to be a significant cognitive difference.
- sklogic 11y ago> Compare that with Lisp approach, in which code is data. It's not any different. It does not matter if your `(,a ,b) is compiled into (list a b), or your ` \a\ = \b\` is compiled into make_binary('=',a,b) - both are constructors, essentially. Take a look at what I'm doing with just a quasiquotation here: https://github.com/combinatorylogic/clike https://github.com/combinatorylogic/clike
- pjmlp 11y agoDylan? Then again it is a Lisp with Algol syntax.
- stray 11y agoI believe Dylan used to be a Lisp with Lisp syntax.
- pjmlp 11y agohttp://opendylan.org/documentation/intro-dylan/index.html http://opendylan.org/documentation/intro-dylan/index.html
- stray 11y agoThanks for the link. The page on that site that gives the history including the original lispy syntax is here: http://opendylan.org/history/index.html http://opendylan.org/history/index.html
- BruceM 11y agoWe talk sometimes about having an additional reader to support another syntax ... but so far, it isn't something where someone's actually volunteered to step up and help. It'd be interesting to play with some ideas from David Moon's PLOT as well ...
- leephillips 11y agoJulia is homoiconic and, of course, has lisp-style macros. It has a syntax similar to something like array fortran. http://julialang.org/ http://julialang.org/
- kkylin 11y agoI love using Julia, but for me writing Julia macros came with a steeper learning curve than in Lisp / Scheme, due in part to the syntax. I kept wishing Julia was a layer on top of a Lisp, and that I can just write Lisp macros. (I know the parser is currently in Scheme, but you can't exploit that easily.)
- grayclhn 11y agoThe obvious solution is to write a julia macro that implements lisp macros as a DSL ;)
- KenoFischer 11y agoNo need, Julia comes with a builtin lisp.
- ihnorton 11y agoI tend to end up writing `Expr` objects directly when I'm building larger macros as I find them much easier to reason about. It's clearly not as convenient/clean as Lisp though. (David Moon actually sent a PR last year to make hygiene much easier.. unfortunately it got stuck for a while, but the PR was recently rebased and hopefully will be merged eventually). Regarding the learning curve: we rewrote the first half of the Metaprogramming section of the manual a few months ago to try to provide a more gradual introduction, especially for people without a Lisp background. Objectively I don't know if the change has helped, but I tell myself that the number of macro-related questions has gone down :) We would really like to make these tools accessible to people both with and without a formal CS background (probably the majority of Julia users will fall in the latter category). So, if you have any suggestions for doc/pedagogy improvements in this area, I would be very happy to hear them!
- PuercoPop 11y agoYes, take a look at Dylan. But they almost never do.
- maaku 11y agoDylan's approach works because it has lisp at its core.
- chadzawistowski 11y agoOther languages can technically have homoiconicity, but there's something to be said for the simplicity of Lisp forms.
- cwp 11y agoYes. See Smalltalk for a language with object-oriented homoiconicity.
- stray 11y agoThat's not really homoiconicity though, is it? Smalltalk source code does not appear to be expressed in terms of a Smalltalk data structure. Whereas Lisp source code is expressed as lists of lists.
- cwp 11y agoSure it is. All parts of a Smalltalk program are present as objects that can be manipulated by sending them messages. Classes, methods, variable bindings, closures, stack frames, even individual messages are objects. As a practical matter, methods also have a textual representation, but that's not strictly necessary. Ten or fifteen years ago, the Squeak method browser had a mode where you could write Smalltalk code using tiles, kind of like in Etoys, no parsing necessary. That was a hassle to use, though, so people stuck with writing methods using text. By the way, Lisp has the same sort of "impurity". S-expressions are very simple, but they are syntax. It's surely possible to create a tool that would let one construct cons cells in memory directly, but that would be a hassle. Instead we use parentheses.
- stray 11y agoThe 'iconicity' part of homoiconicity refers to the textual representation.
- deleted 11y ago[deleted]
- rakoo 11y agoMaybe not the same, but I feel like nim (http://nim-lang.org/docs/manual.html#templates http://nim-lang.org/docs/manual.html#templates) can have a comparable power ot redefining itself. But I'm absolutely not an expert neither in any lisp nor in nim so I can't really tell.
- ArtB 11y agoThe property of homoiconicity is shared by all Lisps, Forths, and Prolog amongst others: https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Homoiconicity