

Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros - spion
http://jeditoolkit.com/try-wisp/

======
snprbob86
As somebody who contributes to ClojureScript, I genuinely do not understand
the purpose of this project.

If you want a JavaScript with Lispy syntax, there are a few things like
<http://lispyscript.com/> \-- Spiritually similar to CoffeeScript. But if you
want Clojure semantics, there is ClojureScript: Very different than a simple
transpiler like CoffeeScript. ClojureScript includes a standard library of
rich data structures and utility functions.

But why would you want Clojure syntax without Clojure semantics? Especially
since Clojure syntax implies several data types that JavaScript can't provide
natively. It just doesn't make sense...

~~~
elangoc
I agree. The comments here make me think that the commenters don't know all of
the extra ideas that Clojure brings besides a "different syntax" to Lisp. Even
just for the immutable, persistent data structures that support value
semantics (& distinguishing state from identity), ClojureScript ought to go a
long way to helping write better code.

~~~
gozala
Note that most functions exposed by wisp do not mutate existing data
structures and match clojure in behavior, it's just they use array's instead
of vectors and dictionaries instead of maps. My hope is that it will imply
same immutable style even if underlying data types remain mutable.

------
goldfeld
Wonderful, one more language for me to consider in addition to Roy and
Parenscript. I guess there's also Whalesong for Racket, but I don't know how
clean the cross compilation to JS is. I've always been drawn to Clojure but
the JVM kept me at bay. The fact that it's not "Lisp all the way down" also
clouds my decision for it. I guess Wisp would be highly compatible with
Lighttable?

~~~
pnathan
Parenscript seems pretty cool. I tried Clojurescript about 2 months ago and
the build process was disturbingly frustrating. :-/ I will take a swing at
Parenscript next time I get on that particular project.

~~~
mike_ivanov
> build process was disturbingly frustrating

that pretty much sums up my experience with ClojureSctipt as well.

~~~
TheHydroImpulse
Same here, and also the use of Google Closure was pretty disappointing.

~~~
fogus
Can you clarify?

------
dhamidi
What is the benefit of having three ways to write strings?

    
    
            \a  ;; compiles to "a"
    	:a  ;; compiles to "a"
    	"a" ;; compiles to "a"
    

This is not meant as destructive criticism; I'm genuinely interested in the
motivation for that.

~~~
notb
Seems like a disadvantage to me. It's mostly just confusing and the only thing
it affords is the ability to use :keywords as functions (:like so) which is
just sugar for property access, so["like"]. This is broken, though.

The coolest thing about :keywords in Clojure is that they really are functions
and you can do things like (map :keywords ontoSomething) to extract the same
property out of many things. It don't work in Wisp.

~~~
elangoc
What you're not realizing, though, is that each time you use the string "like"
as a key for a map/dictionary, you're allocating a new object on the heap. So
what if you have many keys, and they're all strings? What if you have many
maps that share the same keys? That's a lot of memory to allocate, and strings
are an extremely inefficient way to implement what is essentially a unique
identifier to address map values. Instead, use an integer as a unique
identifier.

That's basically what keywords do -- they are human-readable and compile down
(prob. using some hash) into some integer, and the integer is stored globally
only once. The biggest savings in memory comes when using maps, and that's how
& why keywords get their name.

~~~
asynchrony
Javascript strings are immutable and literals are almost certainly
preallocated and stored in a table of constants. Why should using a string
keys cause heap allocations?

~~~
arohner
If you have a VM where strings are immutable and interned, you're right. Java
doesn't guarantee that strings are interned (though you can ask the VM to
intern it), so Clojure treats them differently.

Also, Java declared java.lang.String as final, so Strings can't be extended to
implement clojure interfaces to get nice behavior, like IFn and
IKeywordLookup.

------
ktusznio
This is really cool. I've always been a fan of lisps, but not to the point of
picking them up. Building for the web using a lisp has always seemed difficult
due to (perceived?) lack of tooling, documentation, and community. JavaScript
is for the web like no other language, and Wisp looks like it makes building
web projects in a lisp a reality. Kudos!

~~~
owenjones
If you're interested in building for the web in a Lisp, you should seriously
give Clojure a try!

------
mmgutz
This is the first lisp dialect which I can make sense of with just light
reading. It's simple enough that I actually tried it and liked it. The output
is fairly clean JavaScript which helps in learning and reduces barriers.

As a non-lisp guy who doesn't know any better (me), good job.

------
agentultra
This reminds me of ParenScript <http://common-lisp.net/project/parenscript/>

Which is basically a subset of common-lisp that compiles to human-readable
javascript. It's a good idea.

------
djtriptych
One idea: \- A major drawback to using generated javascript is that line
numbers in error messages don't relate to your original source files. Perhaps
a debug option to add line number comments in the generated code?

~~~
jmgrosen
Or even better, source maps support.

~~~
gozala
Adding source maps support to wisp is my no 1st priority for wisp.

------
essdee1
Does Wisp have any facility for namespaces - I didn't see anything about that
in the link?

~~~
TheHydroImpulse
It appears like it does: [https://github.com/Gozala/try-wisp/blob/gh-
pages/src/main.wi...](https://github.com/Gozala/try-wisp/blob/gh-
pages/src/main.wisp)

------
TylerE
Personally, I'd rather see lisp with JS syntax (CoffeeScript would be even
better)

~~~
cgag
What does that even mean?

~~~
pjmlp
Dylan

