Show HN: ClojureScript REPL within Excel | Hacker News Reader

Show HN: ClojureScript REPL within Excel

github.com

83 pointstheocs10 comments

This reminds me of one of the points pg makes in What Made Lisp Different [1], under #9:

  "compiling at runtime is the basis of Lisp's use as an extension language in programs like Emacs"

This Excel capability is an extremely cool demonstration of where ClojureScript's self-hosting capability can take us. Seems like there's no stopping it. Kudos to Christian Felde!

[1] http://www.paulgraham.com/diff.html

Awesome! Now I'm dreaming of a world where people would learn ClojureScript instead of writing VBA macros :)

I love the idea of this, but then started to wonder what this would let me do. Can I take data from an arbitrary set of input cells, pass them through a sequence of clojurescript functions, then output the result(s) back to the spreadsheet?

I would hope that would be the ultimate goal. However, that might not be possible without at least some VBA work. Experimentation will have to be undertaken.

The real question is how do you sell the ClojureScript "macro" to an end user that, ultimately, doesn't care how the answer in the spreadsheet is arrived at, so long as it is correct.

Glad you like it :)

You can bind to arbitrary data regions using named items. For example:

cljs.user=> (add-binding-named-item "A1:B2" "binding-id" println)

nil

{:rc 2, :cc 2, :type matrix, :id binding-id}

cljs.user=> (get-binding-data "binding-id" println)

nil

{:rc 2, :cc 2, :type matrix, :id binding-id, :data [[1 2] [3 4]]}

cljs.user=> (set-binding-data! "binding-id" [[2 3] [4 5]])

why use continuation functions (... println) instead of returning values ? Is it because of the underlying JS API is async ? Maybe use something like chans to pipe async values ? Just doesn't seem clojureish to me :D

Author of cljs-ajax here, I'd always favour a straight callback. The async stuff is so easy to add on top it doesn't really seem worth it to add the dependency to the library and complicate matters for people that don't want it.

I guess that's true - core.async adds a lot of stuff you don't want for something as simple as futures/promises.

I wish ClojureScript guys would abstract 'go' macro from core.async in to the clojurescript core, provide well documented protocols that it uses and include implementation for JS Promises by default (then leave core.async to expose chans for those who need channels trough those protocols).

Hell if I knew they wouldn't be against doing this I might even do it my self in a few weeks.

Considering the async nature of JS it makes sense to provide such a construct as a part of language/standard library.

You're right about the underlying JS API being async, and that's why those functions are as well.

I wouldn't mind adding a blocking variant of these functions, and use async internally to make that happen. But, not there yet.

Very cool. Looks like a promising project

Reply on news.ycombinator.com