5 ms·

I know this is probably said pretty often, but there's nothing stopping you from creating a new syntax for Lisp so long as it can easily be translated into the

by noamsml 16y ago

I know this is probably said pretty often, but there's nothing stopping you from creating a new syntax for Lisp so long as it can easily be translated into the abstract form of S-Expression. That's what M-Expressions (http://en.wikipedia.org/wiki/M-expression http://en.wikipedia.org/wiki/M-expression) tried to do.

Zak 16y ago
Somebody tries making an alternate syntax every few years. Usually, it's an experienced Lisper who wants to increase the popularity of Lisp. These never catch on, and never will. I think there are two problems. First, people who are prone to "get" Lisp are open-minded enough not to be put off by the syntax. People who can't get past the syntax won't grasp the other advantages. Second, homoiconicity is Lisp's last remaining real advantage[0] over other dynamic languages. Most Lisps are faster than Python or Ruby, but not Lua, especially LuaJIT. An alternate syntax makes that advantage harder to access. [0] I'm pretty sure CLOS and the condition system could be replicated in Lua, though I'm not sure anybody has.
- psykotic 16y ago
  > These never catch on, and never will. Though I'm no great fan of Mr. Wolfram, I would have to say Mathematica has caught on quite well. Mathematica isn't a Lisp (its semantics are based on term rewriting) but it freely intermixes S-expressions and M-expressions. For example, the M-expression a + b parses into the S-expression Plus[a, b].
  - Zak 16y ago
    Most languages parse in to a parse tree that looks something like S-expressions, but that parse tree isn't always made of the language's own data structures nor available to the user at runtime.
    - psykotic 16y ago
      Of course. Why is that remark relevant here? Mathematica does make its S-expressions available to the user at runtime. They are in fact much more available to the user at runtime than in Lisp because of Mathematica's term rewriting semantics. Furthermore, the transformation from M-expressions into S-expressions isn't a one-way street. By default the notebook interface will render an S-expression as its M-expression equivalent when such exists.
- draegtun 16y ago
  I'm pretty sure CLOS and the condition system could be replicated in Lua, though I'm not sure anybody has re: CLOS - There have at least been two projects to replicate Perl's Moose (http://moose.perl.org http://moose.perl.org) in Lua: * http://lua-coat.luaforge.net/ http://lua-coat.luaforge.net/ * http://code.google.com/p/loose/ http://code.google.com/p/loose/
- rwl 16y ago
  > These never catch on, and never will. Another possible counterexample is Logo, though perhaps you didn't mean "Lispy languages with fewer parentheses will never catch on," but "Front-ends for Common Lisp that use fewer parentheses will never catch on." I can't speak to the latter. The folks who make Racket have also implemented a variety of non-Lisp languages (e.g., Scribble, Algol[1]) that I believe are parsed to s-expressions and then compiled by Racket. Not sure how many people use these implementations for "serious" programming, but they're there. [1] http://docs.racket-lang.org/algol60/index.html http://docs.racket-lang.org/algol60/index.html
  - Zak 16y ago
    I don't mean to imply that Lispy languages with non-sexp syntax won't catch on. Python, Ruby and Lua seem to have pretty Lispy semantics, for example. I also do not mean to imply that DSLs or implementations of existing language standards that compile to sexps and get passed to a Lisp runtime to execute won't catch on. I believe Maxima is such a DSL. What I do mean is that a general-purpose replacement syntax for existing Lisps that isn't mainly written in terms of data structure literals won't catch on. Note that I didn't say lists there; Clojure has added vectors and maps to its syntax, but retains a very Lispy overall syntax. I'm not sure if a new language explicitly designed to be a Lisp in everything but front-end syntax will catch on. New languages usually catch on when they present a good solution to a problem lots of people have on a silver platter. They're a lot like startups in that regard.
p4bl0 16y ago
In fact M-exp where intended for Lisp code before S-exp (which were originally meant to represent data only). IIRC, the story is data S-exp were used for code temporarily because it was easier this way, and then they find it usable enough.

by noamsml 16y ago

Zak 16y ago

Somebody tries making an alternate syntax every few years. Usually, it's an experienced Lisper who wants to increase the popularity of Lisp. These never catch on, and never will. I think there are two problems. First, people who are prone to "get" Lisp are open-minded enough not to be put off by the syntax. People who can't get past the syntax won't grasp the other advantages. Second, homoiconicity is Lisp's last remaining real advantage[0] over other dynamic languages. Most Lisps are faster than Python or Ruby, but not Lua, especially LuaJIT. An alternate syntax makes that advantage harder to access. [0] I'm pretty sure CLOS and the condition system could be replicated in Lua, though I'm not sure anybody has.

psykotic 16y ago
> These never catch on, and never will. Though I'm no great fan of Mr. Wolfram, I would have to say Mathematica has caught on quite well. Mathematica isn't a Lisp (its semantics are based on term rewriting) but it freely intermixes S-expressions and M-expressions. For example, the M-expression a + b parses into the S-expression Plus[a, b].
- Zak 16y ago
  Most languages parse in to a parse tree that looks something like S-expressions, but that parse tree isn't always made of the language's own data structures nor available to the user at runtime.
  - psykotic 16y ago
    Of course. Why is that remark relevant here? Mathematica does make its S-expressions available to the user at runtime. They are in fact much more available to the user at runtime than in Lisp because of Mathematica's term rewriting semantics. Furthermore, the transformation from M-expressions into S-expressions isn't a one-way street. By default the notebook interface will render an S-expression as its M-expression equivalent when such exists.
draegtun 16y ago
I'm pretty sure CLOS and the condition system could be replicated in Lua, though I'm not sure anybody has re: CLOS - There have at least been two projects to replicate Perl's Moose (http://moose.perl.org http://moose.perl.org) in Lua: * http://lua-coat.luaforge.net/ http://lua-coat.luaforge.net/ * http://code.google.com/p/loose/ http://code.google.com/p/loose/
rwl 16y ago
> These never catch on, and never will. Another possible counterexample is Logo, though perhaps you didn't mean "Lispy languages with fewer parentheses will never catch on," but "Front-ends for Common Lisp that use fewer parentheses will never catch on." I can't speak to the latter. The folks who make Racket have also implemented a variety of non-Lisp languages (e.g., Scribble, Algol[1]) that I believe are parsed to s-expressions and then compiled by Racket. Not sure how many people use these implementations for "serious" programming, but they're there. [1] http://docs.racket-lang.org/algol60/index.html http://docs.racket-lang.org/algol60/index.html
- Zak 16y ago
  I don't mean to imply that Lispy languages with non-sexp syntax won't catch on. Python, Ruby and Lua seem to have pretty Lispy semantics, for example. I also do not mean to imply that DSLs or implementations of existing language standards that compile to sexps and get passed to a Lisp runtime to execute won't catch on. I believe Maxima is such a DSL. What I do mean is that a general-purpose replacement syntax for existing Lisps that isn't mainly written in terms of data structure literals won't catch on. Note that I didn't say lists there; Clojure has added vectors and maps to its syntax, but retains a very Lispy overall syntax. I'm not sure if a new language explicitly designed to be a Lisp in everything but front-end syntax will catch on. New languages usually catch on when they present a good solution to a problem lots of people have on a silver platter. They're a lot like startups in that regard.

p4bl0 16y ago

In fact M-exp where intended for Lisp code before S-exp (which were originally meant to represent data only). IIRC, the story is data S-exp were used for code temporarily because it was easier this way, and then they find it usable enough.