search

wisp-lang / wisp

A little Clojure-like LISP in JavaScript
https://gozala.github.io/wisp/
Other
982 stars 68 forks source link

Documentation on best way to get "standard library" functions #110

Open PaulMorris opened 9 years ago

PaulMorris commented 9 years ago

I was looking for documentation on the best way to get basic "standard library" functions (like map, filter, reduce, etc.), but I didn't find it... Is the idea that you would use js libraries (like underscore.js), or clojure(script) libraries, or should either work equally well? I see that some of these functions are defined in the wisp source, but it seems they aren't intended for use as a library.

BTW, I'm really glad I found wisp! I like clojurescript, but it's really targeted for those already using clojure (so they don't have to use javascript), and not for those using javascript (who would like something similar but better). The overhead of clojurescript (JVM, google closure compiler, immutable data, complex javascript interoperability, etc.) is a bit much for my needs. Wisp is just what I was looking for, a lisp (with nice clojure syntax) that's "just javascript". So thanks for wisp!

Gozala commented 9 years ago

I was looking for documentation on the best way to get basic "standard library" functions (like map, filter, reduce, etc.), but I didn't find it...

That is a good point. I am not sure it makes sense to dump everything into readme but maybe adding a wiki page explaining this would be a good move ? Would you be interested in doing it ?

Is the idea that you would use js libraries (like underscore.js), or clojure(script) libraries, or should either work equally well?

You could use underscore.js, I'm afraid wisp does not quite has all of the clojure(script) features (at least yet) so using libraries from there will likely fail, although I would like to get wisp to a state where reuse of clojure(script) libraries will be possible.

I see that some of these functions are defined in the wisp source, but it seems they aren't intended for use as a library.

Quite the contrary, most modules present in wisp are intended to fulfill the role of standard library, but unlike clojure(script) they are not included by default & it's up to user to decide what they want to include.

PaulMorris commented 9 years ago

Thanks for the clarification. I could work on a wiki page once I understand this better. I see now that you would import modules using (ns ...) which then compiles to js like this:

var wisp_sequence = require('wisp/sequence'); var car = wisp_sequence.first;

So this is the commonjs module syntax, for use with node.js, right? How would things work for client-side code? Would you need to use something like browserify? Maybe "hello world" examples for client-side and for server-side would help spell it all out?

tillarnold commented 9 years ago

How would things work for client-side code? Would you need to use something like browserify?

Yes you'll have to use browserify (or an other bundler) to use wisp for client-side code. There's already a browserify transform for wisp: https://www.npmjs.org/package/wispify

maybe "hello world" examples for client-side and for server-side would help spell it all out?

I agree some examples is the repo would be nice.

robjens commented 9 years ago

edit: I should read better

Anyway I've thought a bit about this and the 'expectancy' of having e.g. map or first readily available. But I've come to the conclusion, looking at code I've written, that hardly there are cases where I need all of them, or even any. The use of the functions seems to diminish as they're not readily accessible perhaps, or maybe I'm just working on specialized components too much atm. Either way, having a 'core' wisp loaded at run time the way it is done in Clojure, comes with a price. I think I like it this way a lot better (and not touch global/wrapping scopes).