Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

jeditoolkit.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#41

Post by josteink »

notb wrote: post #11
dhamidi wrote: post #4

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.

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 wor…

The coolest thing about :keywords in Clojure ... don't work in Wisp.

Ok. That sucks. So pretty much anyone already a bit serious about Clojure wont be enticed by this then.

Edit: From the page:

    ;;    Keywords can be invoked as functions, that desugars to plain
    ;;    associated value access in JS
    (:bar foo) ;; => foo["bar"]
That seems pretty close to what's expected though, doesn't it?

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#42

Post by grayrest »

josteink wrote: post #41
notb wrote: post #11

Earlier quoted context omitted.

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 wor…

The coolest thing about :keywords in Clojure ... don't work in Wisp. Ok. That sucks. So pretty much anyone already a bit serious about Clojure wont be enticed by this then. Edit: From the page: ;; Keywords can be invoked as functions, that desugars to plain ;; associated value access in JS (:bar foo) ;; => foo["bar"] That seems pretty close to what's expected though, doesn't it?

I'd expect `(:bar foo)` to desugar to `foo["bar"]()` since the keyword is being used as a function. Property access in clojurescript uses the ugly `(.-bar foo)` syntax.

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#43

Post by fogus »

TheHydroImpulse wrote: post #33
mike_ivanov wrote: post #16

Earlier quoted context omitted.

> build process was disturbingly frustrating that pretty much sums up my experience with ClojureSctipt as well.

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

Can you clarify?

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#44

Post by piranha »

grayrest wrote: post #42
josteink wrote: post #41

Earlier quoted context omitted.

The coolest thing about :keywords in Clojure ... don't work in Wisp. Ok. That sucks. So pretty much anyone already a bit serious about Clojure wont be enticed by this then. Edit: From the page: ;; Keywords can be invoked as functions, that desugars to plain ;; associated value access in JS (:bar foo) ;; => foo["bar"] That seems pretty close to what's expected though, doesn't it?

I'd expect `(:bar foo)` to desugar to `foo["bar"]()` since the keyword is being used as a function. Property access in clojurescript uses the ugly `(.-bar foo)` syntax.

No, to get foo["bar"]() in CLJS you write ((:bar foo)). :bar in this case is a function, which returns a value by a key ":bar" from "foo", it's not a property.

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#45

Post by [deleted] »

grayrest wrote: post #42
josteink wrote: post #41

Earlier quoted context omitted.

The coolest thing about :keywords in Clojure ... don't work in Wisp. Ok. That sucks. So pretty much anyone already a bit serious about Clojure wont be enticed by this then. Edit: From the page: ;; Keywords can be invoked as functions, that desugars to plain ;; associated value access in JS (:bar foo) ;; => foo["bar"] That seems pretty close to what's expected though, doesn't it?

I'd expect `(:bar foo)` to desugar to `foo["bar"]()` since the keyword is being used as a function. Property access in clojurescript uses the ugly `(.-bar foo)` syntax.

[deleted]

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#46

Post by arohner »

asynchrony wrote: post #37
elangoc wrote: post #30

Earlier quoted context omitted.

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.…

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?

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.

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#47

Post by gozala »

snprbob86 wrote: post #6

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 struct…

I've tried to elaborate my reasoning in the readme actually:

> Unlike clojurescript, wisp does not depends on JVM and is completely self-hosted. It compromises clojure's awesome data structures and embraces native JS data structures to be a better at cooperation with JS. Goal of wisp is to present a subset of clojure(script) language such that packages written in wisp can be consumed natively by wisp, clojure(script) and JS when compiled, without data marshalling or any code changes.

While I do like clojure(script) a lot I don't think it makes too hard to consume data structures from JS land and makes consuming data produced by clojure(script) awkward for consumption on the JS side. That is a the reasonable compromise for a great power, it's just I think I'd rather leverage JS data structures in immutable manner directly and provide more clojure like data structures in form of libraries. This would allow users to make best (or maybe worst) choices based on their constraints.

As of lispyscript it's nice project and as a matter of fact wisp is just a fork that never got merged in to upstream. I was convinced that clojure (or any other known lisp) syntax was better option than yet another new lisp. In addition I wanted full macros that unlike wisp lispyscript does not has. Also lispyscript has no lists, instead it uses arrays and I can continue this list over and over...

> 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...

JS can do it otherwise clojurescript won't be possible, I just think these data types can be exposed via optional libraries as they have associated cost in terms of performance overhead and learning curve.

And to be quite honest I do hope that a lot of wisp parts will find it's way to clojurescript, it's just contributing to clojurescript turned out to be harder than bootstraping own version, since even pull requests for travis-ci integration tests require lot's of justification.

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#48

Post by gozala »

elangoc wrote: post #31
snprbob86 wrote: post #6

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 struct…

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.

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.

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#49

Post by gozala »

jmgrosen wrote: post #19
djtriptych wrote: post #17

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?

Or even better, source maps support.

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

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#50

Post by gozala »

dhamidi wrote: post #4

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.

In clojurescript strings are just sequences of characters where characters are expressed as \a and strings as "foo". In JS single char string is an equivalent of a character, as a side effect \a and "a" compiles to a same thing, which BTW matches behavior of clojurescript as well. Main reason for \a like character types existence is clojure(script) compatibility and nothing more.

As of :a keyword it's a different story. As a matter of fact actual (quoted) keyword ':a does not compiles to "a" string, but general references do. That is because in JS constant string literals like "load", "DOMContentLoaded" are used in cases where idiomatic Clojure(script) would have used :load :DOMContentLoaded keywords, there for it made sense to just compile those keywords to semantical analogues in JS, same as `foo-bar` lisp naming convention compiles to adequate `fooBar` naming in JS.

Post reply on HN