
LispyScript: A JavaScript With Lispy Syntax And Macros - friggeri
http://lispyscript.com
======
aufreak3
Some time back, I tried to take JSON as the AST and see if I can build a
Scheme-like programming language with it. I did it just for kicks, but if it
interests anyone .. [1].

It's lacking in docs, but this might be of interest - you get a Scheme-like
language (without tail recursion), keyword arguments, lambda, macro, quote &
quasi-quote, let expression, where clauses, generators, and some degree of
code isolation. The compiler is a very simple one and is written in "stream of
thought" style [2] and so might be quite easy to follow.

[1] <http://github.com/srikumarks/jexpr> [2]
<http://srikumarks.github.com/jexpr/>

------
jhrobert
Add "SweetExpressions" and I wonder how far from coffeescript it would get.

"SweetExpressions" is probably the best method so far to get rid of excessive
parentheses in lisp. See <http://readable.sourceforge.net/>

~~~
Homunculiheaded
As someone who has done a fair bit of lisp hacking I'll never really
understand the paren-hate. Yes it's weird the first few times but I have never
met anyone who has coded a significant amount of lisp who sees them as
anything but an asset.

In lisp you're essentially hacking at the AST level, this is precisely where a
huge chunk of lisp's power comes from, and parens are an incredibly natural
and concise way to express this structure.

I have also written a lot of Python and I can honestly say significant white
space as been an issue for me far more often than parens in Lisp (and I don't
find significant white space to be an issue at all).

~~~
rtfeldman
Sadly, the vast majority of coders never make it to "a significant amount of
Lisp". Most who do tend to be very positive about Lisp, so it's not that the
language veterans give it a bad word-of-mouth reputation. Quite the opposite.

There is clearly an "approachability problem" to Lisp, and it seems worth
trying to solve. (If nothing else, the more popular a language gets, the more
opportunities you will have to get paid to write in it for a living.)

Parens come up every single time the word Lisp is mentioned in "mixed company"
--that is, both Lispers and non-Lispers. It's not just the most common
complaint about the language, but the _dominant_ complaint. (Thought
experiment: What's the #2 complaint newbies make about Lisp? And how much
longer did it take you to answer that question than #1?)

Originally John McCarthy had intended to use M-Expressions for Lisp, e.g.
"car[cons[(A . B); x]]", but programmers preferred the parens-and-whitespace
of S-Expressions instead, so they became the default.

There's no reason to dismiss the possibility of another such evolution, again
based on nothing more than programmer preference.

No matter how familiar or useful you might find the existing approach, it's
always possible that it can be improved.

~~~
ScottBurson
There have been many attempts to solve the approachability problem by creating
alternate syntaxes. Vaughan Pratt's CGOL, written almost 40 years ago, was
perhaps one of the best.

Although these alternate syntaxes may be helpful to newcomers, they have never
caught on. Expert users actually prefer the parenthesized form; so anyone
working in Lisp for very long has to learn to deal with it -- and usually,
once they do, they find it preferable.

You said it yourself: programmers preferred S-expressions, so they became the
default.

The other important point here is that the non-Lispers are right, in a sense:
editing Lisp without a paren-counting editor is just as tedious as one would
expect. But with a paren-counting editor -- and even better, with something
like Paredit that keeps the parens balanced at all times -- editing actually
becomes easier, more fluid, and more pleasant than in other languages.

That is why expert Lisp users prefer the parens.

~~~
erichocean
_editing Lisp without a paren-counting editor is just as tedious as one would
expect_

That's the real barrier, IMO. Who wants to switch editors just to learn a new
language with an (apparently) impoverished syntax?

~~~
ScottBurson
Hmm. How many editors people actually use these days don't have a usable Lisp
mode? I don't think your choices are limited to Emacs anymore. I'm fairly sure
Vim has one; I don't know for sure, but would be very surprised if Eclipse
didn't; not sure what else people are using.

If it really is the case that all Lisp needs to really take off is editor
plugins for IntelliJ IDEA and Visual Studio -- hmm -- maybe we should do that.

------
cheez
I prefer Parenscript <http://common-lisp.net/project/parenscript/>

~~~
irfn
have you tried clojurescript

~~~
klibertp
I did - I don't like Clojure (because I much, much prefer Scheme to CL) but it
seemed very interesting. However, it felt very heavy, almost like GWT. There
is something very similar for Racket[1], but even though it's Scheme it still
feels much to heavyweight and I couldn't bring myself to use it.

[1] <http://hashcollision.org/whalesong/>

~~~
ynniv
I was very disappointed by whalesong. Instead of a source->source translator
like parenscript, whalesong generates a bytecode level VM inside the browser.
Doing so provides support for any racket language, but it does so at the cost
of immense quantities of "pre-obfuscated" JavaScript.

The genesis of whalesong was to support "World"[1] games on the web, and to
that end it seems successful. I don't think it makes a good general purpose
tool. Perhaps someone wants to port parenscript to scheme?

[1 | <http://world.cs.brown.edu/>]

~~~
batgaijin
How slow is whalesong though? I know people like to say that js is slow, but
it's really only the DOM manipulation that makes it so.

~~~
ynniv
Well, it's a 700k interpreter and runtime. It isn't slow for simple things,
but only because JS is really fast now. Interpreters are usually 5 to 10 times
slower than whatever they are running in.

[http://hashcollision.org/whalesong/examples/raphael-
demo/rap...](http://hashcollision.org/whalesong/examples/raphael-demo/raphael-
demo.html) isn't bad

<http://hashcollision.org/whalesong/examples/boid/boid.html> is a little slow
compared to
[http://graphics.cs.wisc.edu/Courses/Games12/Tutorial1/Phase1...](http://graphics.cs.wisc.edu/Courses/Games12/Tutorial1/Phase13/)

Some of the low framerate could be frame timing (whalesong could be using
setTimeout poorly), but they seem to use about the same CPU.

~~~
batgaijin
Huh, didn't know that. For some reason I thought it compiled to JS.

------
postfuturist
This is just a light lisp-like syntactic layer, as the docs say "LispyScript
is not a dialect of Lisp. There is no list processing in LispyScript ." It's
just enough to allow nice macros, which adds quite a bit, IMO. There's no
CONS, etc. It adds a couple nice things, like an "each" function that does the
right thing, and (= foo bar) becomes foo === bar.

------
ajanuary
Cool, but could do with shortening the 'function' keyword. It's just too long
for the amount it's used.

~~~
stevelosh
Agreed. Luckily you have macros, so go ahead and do it:

<http://i.imgur.com/wl2Q5.png>

~~~
klibertp
Right, I think "you have macros" is a definite answer to any and all syntax-
related issues :)

------
Xurinos
I experience a kind of jolt when I read lispy syntax mixed with constructs
like [1, 2, 3]. It shouldn't be a big step to make a syntax for #(1 2 3) or
(make-array 1 2 3) instead. Get rid of that infix comma syntax! Then there is
the record syntax... {foo: 3, bar: 4}... Infix commas and colons! How about
(make-object foo 3 bar 4) or #O(foo 3 bar 4)? Or support reader macros so that
you can override []s and {}s to do something a little prettier.

~~~
postfuturist
According to the docs, (array 1 2 3) and (object "foo" 3 "bar" 4) works, too.

~~~
Kjeldahl
That's great, but unless someone proves me wrong, it lacks the "list"-style
flexibility to do things like "create an object from my list": (object (array
"foo" 3 "bar" 4)). Javascript's Array apply method could probably be used to
do similar stuff, but that doesn't feel very lispy. FWIW Coffeescript lacks
this kind of "object comprehension" as well (which Livescript has BTW).

------
wes-exp
Why the dependency on node?

~~~
mistercow
The obvious reason would be that to make it work nicely as a compiler, they
wanted to make it pull in files and compile them. It shouldn't be terribly
difficult, though, to patch it and make it compile in-browser like
CoffeeScript does with special script tags.

~~~
stevelosh
According to the docs it's pretty close to that already:
<http://lispyscript.com/docs/#browser>

You'd just need to make it find the special script tags and eval them.

EDIT: Yeah actually it's already in there:
[https://github.com/santoshrajan/lispyscript/blob/master/src/...](https://github.com/santoshrajan/lispyscript/blob/master/src/browser.ls#L34)

~~~
mistercow
Actually, it turns out it's already implemented:
[https://github.com/santoshrajan/lispyscript/blob/da6602126eb...](https://github.com/santoshrajan/lispyscript/blob/da6602126eb0707c886c88f6ef6627f7c3882dec/src/browser.ls)

So any script with type "application/lispyscript" will automatically be parsed
and run. The only requirements appear to be RequireJS and underscore.

