> And alternative syntaxes (Lisps without parens) have faultered since they sacrifice some of Lisp's power that seasoned users aren't willing to part with.
Could Elixer be an example of one of these Lisps without parens? [1] Can anyone give an example of what kinds of Lisp powers are sacrificed in a syntax where the parens are implicit rather than explicit? I can't think of anything off the top of my head.
It seems to me that Parinfer, when working as intended, almost turns a regular Lisp into one of these parenless Lisps, by performing parens manipulation for us, which in turn allows us to treat whatever Lisp we're working with as if it was a parenless Lisp.
I think the author is talking about minor variations on Lisp syntax that include indentation-sensitivity, not about different languages that are homoiconic. Such variant syntaxes include i-expressions (http://srfi.schemers.org/srfi-49/srfi-49.html) and sweet-expressions (http://readable.sourceforge.net/), which the author mentions in the Acknowledgements. For example, here are some sweet-expressions:
define factorial(n)
if {n <= 1}
1
* n factorial(- n 1)
This desugars to:
(define (factorial n)
(if (<= n 1)
1
(* n (factorial (- n 1)))))
I think the Lisp power that the author is referring to is homoiconicity, and the corresponding ease of writing macros. For example, i-expressions sacrifice homoiconicity in some contexts.
But the author seems to have overlooked that sweet-expressions, which were developed later, do not sacrifice homoiconicity. A human reader can still easily understand the AST from reading sweet-expression syntax. The real reasons that sweet-expressions have faltered relate more to the increased difficulty of collaborating with other developers, the lack of editor plugins that highlight sweet-expressions correctly, and incompatibility with Clojure syntax.
Using parens just makes manipulating the AST easier, but doesn't necessarily remove the homoiconocity of a language. I've barely done any lisp programming, though I have done a fair amount of work with AST's and compilers. S-exprs lend to thinking of the structure of the code as data, useful for "lisp-ing".
Personally I don't care to write in lisp since I loose track of parens way too readily. This project might be very handy!
In the meantime I've come to view Julia as my goto lisp. Quite fun to be able to write hygienic macros, but still have a mostly familiar imperative syntax for common tasks. Actually, the disciplined (read limited) usage of macros in Julia is a big draw for me, since I've heard too many horror stories of macro readers and spaghetti code in large lisp projects. Interesting look at elixir, I'll have to play with it sometime.
> And alternative syntaxes (Lisps without parens) have faultered since they sacrifice some of Lisp's power that seasoned users aren't willing to part with.
Could Elixer be an example of one of these Lisps without parens? [1] Can anyone give an example of what kinds of Lisp powers are sacrificed in a syntax where the parens are implicit rather than explicit? I can't think of anything off the top of my head.
It seems to me that Parinfer, when working as intended, almost turns a regular Lisp into one of these parenless Lisps, by performing parens manipulation for us, which in turn allows us to treat whatever Lisp we're working with as if it was a parenless Lisp.
[1]: https://blog.8thlight.com/patrick-gombert/2013/11/26/lispy-e...