swannodette / mori Goto Github PK

I think the documentation is wrong. When I create a set (mori.set()) the resulting object doesn't include a .conj function

s.toString()
"#{"bird" "cat" "dog"}"
s.conj
undefined
mori.conj(s, "kangaroo").toString()
"#{"bird" "cat" "dog" "kangaroo"}"

The docs mention this. I ran across this a few weeks ago but I'm not actively using Mori and forgot about it until the HN post yesterday. Quick patch I've been using for convenience:

(extend-type js/String
  IFn
  (-invoke
    ([s coll]
     (get coll (.toString s)))
    ([s coll not-found]
      (get coll (.toString s) not-found))))

Hi,

I've just started using mori and it's great!

I called take on a vector and noticed that calling conj on the returned collection added the elements to the beginning. It seems that my vector is converted to a list when using take. Is this the expected behaviour?

Thanks
Frank

Right now it's impossible (as far as I can tell) to tell mori.sorted_set what the comparator function should be, meaning it's really only useful for primitive types because objects have no useful comparison operators built-in.

I have no idea how hard/easy this would be to implement, but it would be really great if you could add this.

Taken from the docs (and converted to JS):

    var bob = m.hash_map("first", "Bob", "last", "Smith"),
      mary = m.hash_map("first", "Mary", "last", "Jane"),
      result = m.map("first", m.vector(bob, mary));

    console.log(result); // throws exception "TypeError: undefined is not a function"
    expect(m.clj_to_js(result)).to.eql(["Bob", "Mary"]); // converting to JS also throws

It also fails if you map over a plain [bob, mary] as in the docs.

For now, I'll just use a function (val) { return m.get("first"); } function as a workaround, just wanted to let you know the docs are inaccurate.

It would be great to be able to easily include mori as a leiningen dependency in ClojureScript projects. Why?

• a better JS interface for the browser console
• a better JS interface for polyglot projects
• more potential for building libraries in ClojureScript that can be pleasantly used from any JS-hosted language

Of course it is already possible to include mori as a dependency—it just isn't officially published anywhere that I can see.

I was just playing around with your ClojureScript 101 tutorial and found my way into a nice mori-powered browser console by lein installing mori locally and then requiring it in my core.cljs. Would be nice if the lein install weren't necessary :)

Is there an efficient way to randomly sample a large set? I tried using nth but it was too slow for large sets. Thanks.

This is probably an issue for the upstream ClojureScript project. But I wanted to post this to see if anyone knows of a workaround.

I am working on a blog post on Mori with some examples of lazy evaluation. Here is what I have at the moment:

// With no arguments, `range` returns a lazy sequence of all whole
// numbers from zero up.
var non_neg_ints = mori.range();

// Dropping the first element, zero, results in a sequence of all of
// the natural numbers.
var nats = mori.drop(1, non_neg_ints);

// Let's take just the powers of 2.
var ln_2   = function(n) { return Math.log(n) / Math.LN2; };
var pows_2 = mori.filter(function(n) { return ln_2(n) % 1 === 0; }, nats);

// What are the first 10 powers of 2?
console.log(
    mori.take(10, pows_2)
);

// Outputs:
// > (1 2 4 8 16 32 64 128 256 512)

That works nicely. But if I change the number of evaluated sequence elements from 10 to 15 (in the node repl) I get a stack overflow exception:

> mori.take(15, pows_2);

/home/jesse/tmp/node_modules/mori/mori.js:26
b?this.Ca===b.Ca:l};Ub.prototype.toString=m("Ca");function D(a){if(a==j)return
                                                                    ^
RangeError: Maximum call stack size exceeded

I have just changed project.clj to use :whitespace optimizations in the dev build configuration but compiled file triggers the following error when loaded:

Uncaught TypeError: Cannot set property 'Unicode' of undefined

The error occurs when goog.string.Unicode is assigned.
Here the differences between simple build and whitespace one:

--- mori.simple.js     2014-02-24 11:47:13.732407538 +0100
+++ mori.whitespace.js        2014-02-24 11:47:11.904409281 +0100
-goog.string = {};
+goog.provide("goog.string");
+goog.provide("goog.string.Unicode");
 goog.string.Unicode = {NBSP:"\u00a0"};

I don't know it it is related to mori or to the ClojureScript compiler.

First of all, many thanks for this library! For those of us who are forced to work in plain Javascript/Coffeescript, having access to well-designed and efficient persistent data structures is incredibly valuable.

What I've been missing so far is a way to create a custom lazy sequence similar to how one would use lazy-seq in Clojure. Obviously, we couldn't get a syntax quite as nice since we don't have macros. But I think a function, say lazy-cons(head, tail-fn), should be fine for most cases.

I can write such a function in JS, but I can't make it participate in the sequence protocol. I've also tried, with partial success, to implement it via mapcat. I get a sequence, and I get laziness, but apparently, I can't manage to let go of the head. This may of course just be my inability.

At any rate, some built-in support for this kind of thing would be great. I'm willing to get my hands dirty and try to implement this feature myself if you think it could be useful and don't have the time to add it.

Hi,
thanks for this awesome lib :)
I'm not a Clojure programmer and didn't look at the clojurescript implementation yet.

Given a vector, I want to get a new vector expect some of its first elements (for now, just the tail of the vector) then replace (or insert on head ) the first element of this new vector.
Here is a failing sample:

var v1 = _.vector(4, 5); 
var v2 = _.rest(v1); // option1
var v2 = _.drop(1, v1);    // option2
var v3 = _.assoc(v2, 0, 'b');

I get a "No protocol method IAssociative.-assoc defined for type object: (5)"

Is this normal, how can I do what I intended to do ?

Thanks a lot,
Best,
Simon

In your opinion, is mori still a viable approach for providing persistent data structures to JavaScript?

I tried building after cloning the library and updating project.clj to the latest cljsbuild, but the mori.node.js file that gets created is throwing exceptions related to goog.string.

Rather than spending a bunch of time hunting that down, I thought it might be wise to first ask ask if you still think mori is viable and/or worthwhile, i.e perhaps ClojureScript developments in the last year+ have changed the landscape.

Thank you.

Find should be able to take a function as its second argument.

Steps to reproduce:

1. Open http://swannodette.github.io/mori/
2. Activate Firefox responsive mode or Chrome mobile emulation (set to, say, iPhone 5)

The menu eats up the majority of the width instead of going away, and horizontal scrolling doesn't work (the menu starts overlapping the content).

Are there equivalent functions somewhere to determine if something is a plain js object vs a mori collection?

Useful for libraries that interoperate with vanilla javascript like underscore.

I was interested in trying out mori.js in a vanilla javascript/Coffeescript browser application (non-clojurescript), but couldn't find an easy way to directly download it. Sure I can probably download the repo and build it myself, but it would be far easier if there were a release somewhere (maybe I'm just missing it)?

Also, there is no mention of mori.js's size. That is important for those that are considering using it for a browser app (because if it is too big, that's a non-starter).

From the api docs

var s = mori.vector("cat", "dog", "bird", "zebra");
s.subvec(1,2); // => ["dog", "bird"]

subvec isn't a method on mori.vector(), and the indices are half-open, not closed, so subvec(v, 1, 2) returns one element, like so

var s = mori.vector("cat", "dog", "bird", "zebra");
mori.subvec(s,1,2); // => ["dog",]

It would be useful to be able to create keywords from JavaScript by calling

    mori.keyword("foo");

so that one can use it in a hash-map, for instance

    mori.hash_map(mori.keyword("foo"),"bar");

I can issue a pull request exporting keyword, is_keyword and adding the keywordize option to js->clj, if you're ok with it.

mori is a lovely library, and I'm glad it exists. Since ClojureScript supports transients, would it be possible for mori's API to support them too?

Hi,
a quick glance at the source of mori and the GPL leads me to believe that it is not possible to use mori in GPL-licensed code, whereas using the same data-structures from GPL-licensed code written in ClosureScript is no problem at all.

I'm assuming that using the same license (EPL) both for mori and for ClojureScript with opposite outcomes was not intentional.

As I understand it (IANAL), using standard ClojureScript data-structures is not a problem, as they are accessed through a "Standard Interface" as defined by the GPL:
http://www.gnu.org/licenses/gpl-3.0.en.html

A “Standard Interface” means an interface that either is an official standard defined by a
recognized standards body, or, in the case of interfaces specified for a particular
programming language, one that is widely used among developers working in that
language.

While the fact that ClojureScript is implemented in a GPL-incompatible license is not a problem, this does not appear to apply to mori.

Unless I'm missing something, mori is just a library under a GPL-incompatible license and as such not usable in work licensed under the GPL.

I was able to build a mori.js file as instructed; however, I prefer during development to have a development version of the code that is not obfuscated/minimized. Is that available?

I'm just starting with mori, so this might be my own ignorance, but the documentation for mori.range says:

range mori.range(start, [end], [step])
Construct a lazy range of values. If not given an end will produce an infinite lazy sequence. A step may be specified.

Reading that, I would expect mori.range( 3 ); to return an infinite lazy sequence starting at 3, where it actually gives me a sequence ending with 3 elements: (0 1 2).

I see the Clojure documentation specifies that there is no way to specify start without also specifying end. May I suggest something like following?

range mori.range([start], [end], [step])
mori.range()
mori.range( end )
mori.range( start, end )
mori.range( start, end, step )
Returns a lazy sequence of nums from start (inclusive) to end (exclusive), by step. If only end is specified, start defaults to 0. If step is not specified, it defaults to 1. If no parameters are specified, an infinite sequence with step 1 starting at 0.

If you'd like a pull request, I'm happy to do that—is the documentation on the gh-pages branch the source, or is that generated from somewhere?

CoffeeScript version 1.6.3
Node v0.10.24
mori 0.2.6.

This is happening in the browser as well.

One example is when passing an array to a mori function we return an ISeqable error.

s = mori.set(["cat", "dog", "bird"])
Error: cat,dog,birdis not ISeqable
    at Error (<anonymous>)
    at C (/Users/hcnewsom/node_modules/mori/mori.js:27:196)
    at Object.set (/Users/hcnewsom/node_modules/mori/mori.js:312:111)
    at repl:3:14
    at REPLServer.replDefaults.eval (/usr/local/lib/node_modules/coffee-script/lib/coffee-script/repl.js:33:28)
    at repl.js:239:12
    at Interface.<anonymous> (/usr/local/lib/node_modules/coffee-script/lib/coffee-script/repl.js:62:9)
    at Interface.EventEmitter.emit (events.js:117:20)
    at Interface._onLine (readline.js:202:10)
    at Interface._line (readline.js:531:8)
    at Interface._ttyWrite (readline.js:760:14)
    at ReadStream.onkeypress (readline.js:99:10)
    at ReadStream.EventEmitter.emit (events.js:117:20)
    at emitKey (readline.js:1095:12)
    at ReadStream.onData (readline.js:840:14)
    at ReadStream.EventEmitter.emit (events.js:95:17)
    at ReadStream.<anonymous> (_stream_readable.js:746:14)
    at ReadStream.EventEmitter.emit (events.js:92:17)
    at emitReadable_ (_stream_readable.js:408:10)
    at emitReadable (_stream_readable.js:404:5)
    at readableAddChunk (_stream_readable.js:165:9)
    at ReadStream.Readable.push (_stream_readable.js:127:10)
    at TTY.onread (net.js:526:21)

In my web application I have a function that returns an object. When attempting to assoc_in to this object I have to explicitly wrap it in mori.hash_map in order to prevent an IAssociative error.

Could you add the link to the docs in the "website" slot for the project:

looks to be included in the latest source per d7a5e98 but I am having trouble building - any chance of updating the npm package or prebuilt version? Of course I could just be missing something...thanks in advance

I've found myself writing things like this quite a lot:

m = require('mori');
var getName = m.curry(m.get, "name")

var names = m.map(getName, collection_of_hash_maps);

In real clojure, we'd use keywords for this case, but that's trickier in mori - is this something other people are running into as well?

I'm not sure what a good name for this would be, some suggestions are below

m.key("name")
m.get_key("name")
m.partial_key("name")
m.curry_get("name")
m.getter("name")

Some brief testing indicates that mori collections will sort consistently the way I'd expect. For instance, from the Node REPL:

> m.vector( 1, 1 ) < m.vector( 1, 2 );
true

Is that a behavior that I can rely on, or is that just coincidental? Is there a better way to do this sort of thing?

The docs say that these functions are supposed to provide lazy sequences, which is exciting, but it seems like they're being eager:

> require('mori').repeat(2)
FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory
Abort trap: 6

(range() behaved similarly but I didn't wait long enough for node to run out of memory.)

I'm on node 0.10.26.

Am I doing something wrong?

I use mori for an application, that calculates similarities between words and stores a selection of similar words for each item. I dependent a lot on mori's set operations for it (which are awesome btw). Sometimes mori.union exceeds the call stack size and throws a RangeError exception. The code piece that throws the error looks like this:

generateAll = (items) ->
  mori.reduce((memo, word) ->
    mori.union(memo, generateOptions(word, items))
  , mori.set(), items)

generateOptions calculates the similarity on 2 categories, picks some options (using mori.take and returns a union of options of those 2 categories.

So with some input data this error is thrown but I can't see anything out of the ordinary regarding the data. I can reproduce the error in generateAll with some specific input data and it occurs twice out of 1049 iterations. The count of memo when the error occurs is 80355 and 136968. generateOptions returns on average 150 options.

Is there any size limit for set operations in mori/cljs? I assume the error happens upstream? But unfortunately I'm not competent enough with clojurescript to actually look it up or confirm this.

I just spent the morning integrating mori into a project I'm working on, which has let me delete a lot of one-off data structures I had lying around. Next up, maybe port it to ClojureScript, which looks pretty appealing right now. =)

Meanwhile, it'd be nice to see a useful inspect on vector/hash_map/etc, so that working in the REPL is less tiresome. I tried to investigate doing this myself, but without prior ClojureScript experience, it was unclear how to approach it.

Take a hashmap as an example:

> h = m.hash_map(1, {some: 'object'}, 2, {another: 'object'})
{ k: null,
  j: 2,
  root: { w: {}, z: 6, g: [ 1, [Object], 2, [Object], , , ,  ] },
  Q: false,
  U: null,
  o: null,
  t: 4,
  n: 16123663 }

Daunting.

With a minimal inspect function attached, we could have:

> h.inspect = function(d) { return this.toString(); }
[Function]
> h
{1 #<[object Object]>, 2 #<[object Object]>}

And in node 0.11.2 (devel release), thanks to nodejs/node-v0.x-archive@66280de, we could even have:

> h.inspect = function(d) { return m.clj_to_js(this); }
[Function]
> h
{ '1': { some: 'object' }, '2': { another: 'object' } }

If this seems reasonable (well, the 0.10.x version, for now), and you could give me a hint where to implement this, I'd be happy to try my hand at it.

Issues arise if multiple instances of mori are require'd independently with node - which happens quite frequently with the module lookup algorithm and different semver requirements in various packages.

var mori = require('./mori.js');
var mori2 = require('./mori2.js');

var x = mori.js_to_clj({key: 'val'});
mori2.is_map(x); // false
mori2.keys(x) // Error: {"key" "val"} is not ISeqable

I'm guessing this isn't an issue with cljs as you wouldn't ever have multiple copies of the core language, but this will end up being a deal-breaker for being able to use this reliably within libraries / node.

Not sure whether a bit of duck-type rather than instanceof checking will work here or if it's a more systemic issue. Setting the library as a global would solve these issues, but it'd be great if there was a way to allow interop between the data structures in different copies of the library (even if it meant setting the core data structures as globals).

Wish I could help more but I'm just starting to try and get up to speed with clojure myself.

Is there a way that I can build a readable mori.js source file without obfuscation?

Are the docs checked in anywhere to be read or contributed to, as the ones at http://swannodette.github.io/mori are out of date.

Thanks a lot.

The documentation for into follows:

into mori.into(coll, from)

Add all the items in the second collection to the first one as if calling mori.conj repeatedly.

var l = mori.list(2,3)
var v = mori.vector(1,2)

mori.into(l, v) // => (2 1 2 3)
mori.into(l, l) // => (3 2 2 3)
mori.into(v, l) // => (1 2 2 3)
mori.into(v, v) // => (1 2 1 2)

For the last two mori.into calls, the result is a vector not a list:

$ node
> var mori = require('mori')
undefined
> var l = mori.list(2,3)
undefined
> var v = mori.vector(1,2)
undefined
> mori.into(l, v)
(2 1 2 3)
> mori.into(l, l)
(3 2 2 3)
> mori.into(v, l)
[1 2 2 3]
> mori.into(v, v)
[1 2 1 2]

... but this appears to be true. I'm completely stymied as to how this behaviour is even possible, and it's obviously difficult to write a test case for it, but here's my shell session so others can attempt to reproduce it:

$ git log -1 --oneline
0f825ab js highlighting
$ node -v
v0.10.4
$ node
> var mori = require('mori')
undefined
> mori.js_to_clj([1, 2, 3])
[1 2 3]
> mori.js_to_clj({x: 1})
{"x" 1}
>

So far so good, we call js_to_clj, we get nice vectors and maps back, lets try CoffeeScript:

$ coffee -v
CoffeeScript version 1.6.3
$ coffee
coffee> mori = require './'
{ count: [Function: O],
  empty: [Function],
... and so on and so forth ...
coffee> mori.js_to_clj([1, 2, 3])
[ 1, 2, 3 ]
coffee> mori.js_to_clj({x: 1})
{ x: 1 }
coffee> mori.js_to_clj({x: 1}).constructor
[Function: Object]

So, that's pretty weird right? maybe some bug in the CS compiler (somehow...) but here's where my brain melts:

$ cat coffee-test.coffee
mori = require './'
myvec = console.log(mori.js_to_clj([1, 2, 3]))
console.log(myvec.constructor)
mymap = console.log(mori.js_to_clj({x: 1}))
console.log(mymap.constructor)
$ coffee coffee-test.coffee
[1 2 3]
[Function: Yg]
{"x" 1}
[Function: Eh]

Any ideas?

We should expose an API to these ClojureScript vars to make interacting with infinite sequences more friendly at the JavaScript console.

I'm not sure if this is a bug or not. The following two vectors of vectors are producing equal hashes.

console.log(m.hash(m.vector(m.vector(13, 5), m.vector(13, 4))))
// => 803955717
console.log(m.hash(m.vector(m.vector(13, 4), m.vector(12, 4))))
// => 803955717

They do not equal, just the hashes.

I noticed the issue when using m.hash as a react component key (duplicate key errors). I put in an m.set to remove duplicates and still got the issue:

segments = m.set(m.map(m.vector, this.state.path, m.rest(this.state.path)))
console.log(m.clj_to_js(m.partition_by(m.hash, segments)))
// produces partitions with count > 1

I can produce several different combinations that duplicate hashes (e.g. [[7, 7], [7, 6]], [[7, 6], [6, 6]] // => 804048423).

version of Mori is 0.2.5

Hi,

Just a heads up that the docs at http://swannodette.github.io/mori/#distinct are up to date with master, but are ahead of the latest tagged release.
#63 introduced the docs for distict, and has been published.
#62 introduced the functionality, but has yet to be included in a tagged release.

Cheers,
Mark.

This is a total bikeshedding issue (see Wadler's Law), so feel free to close this, but I was curious why you didn't use standard JavaScript function/method naming conventions with the mori API. I searched the open and closed issues and found nothing.

For example, why mori.is_list instead of mori.isList? It follows neither a normal JavaScript naming convention (camelCase) nor the Clojure function naming convention (kebab-case) (because that syntax would not accessible via dot notation). Is this the result of a default in the clojurescript compiler?

I can't help but imagine the gut reaction my colleagues would have to seeing snake_case appearing over any shared codebase I contribute to. Obviously this isn't going to stop me from experimenting and using mori, because it looks like an excellent library, but it's really funky to have all your code and all your libraries use the same naming conventions as ECMA-262, except for one.

Given that mori.js is transpiled from clojurescript code to JavaScript, I reckon it should be possible to define which naming convention you want used in the generated code. Is this already possible with the clojurescript compiler? I looked at the sample options for lein-cljsbuild and didn't see anything there for defining the naming convention (https://github.com/emezeske/lein-cljsbuild/blob/1.0.3/sample.project.clj)

When adapting your README examples into a basic test suite, I found that the "non-destructive updates" example didn't work as expected.

In the README you have:

var v1 = mori.vector(1,2,3);
var v2 = mori.conj(v1, 4);
v1.toString(); // => '[1 2 3]'
v2.toString(); // => '[1 2 3 4]'

But in fact, v1.toString() returns the string '[object Object]', as does v2.toString().

The same things happens when you call .toString on mori hash_map values, list values, etc.

Is toString for mori values supposed to return a Clojure literal?

Hello, Sir. First of all, I like what I see in my experimentation with mori. I have been looking for some means of experimenting with immutable data structures in javascript and mori is the best library I have found.

What I am wondering is how immutables stack up against mutables from a performance perspective. I have been running benchmark.js to contrast operations in underscore and operations in mori and I have been finding that underscore is the faster in scenarios I've tested with against a vector -- both read and write.

I am not knowledgeable enough about what scenarios might slant things in favor of immutable structures. I am going to suppose that the overhead of constructing a vector is the culprit. I am also wondering if this is just something that is symptomatic of JavaScript and if in Clojure (or any functional language that includes mutables) this might not always be the case, that mutables would offer comparable performance.

This is not just a curiosity. I have been trying to find a library for a project I am working on and I'm taking performance into consideration. I am not necessarily just going to choose the faster unless the difference is by a huge order of magnitude. The reason being, is the app I am working on loads datasets into memory for user manipulation. I'm not talking monster size datasets, but something that could be in the several thousands of records.

The documentation for is_associative states:

Test if something is associative - i.e. vectors, maps, and sets.

which directly contradicts this:

> mori.is_associative(mori.hash_map(1, 2))
true
> mori.is_associative(mori.vector(1, 2))
true
> mori.is_associative(mori.set([1, 2]))
false
> mori.is_associative(mori.sorted_set(1, 2))
false

Am I missing something?

My thought is that the build system for mori can still be improved a bit. I don't mean lein cljsbuild needs improvement; rather, it seems the setup in project.clj, package.json, and the various .sh scripts in scripts/ could be tightened up a bit.

Rather than go put a bunch of hours into experimental revisions, I figured I would inquire about your preferred direction for this aspect of mori.

A couple of points:

1.   In project.clj, the only difference between the "tmp" build and the "release" build is that the latter is not pretty printed. Yet mori.js, which is made from the "tmp" build, seems destined for production use in, say, browsers. That is, the README doesn't seem to market mori.js as being a development build, so why not have the "tmp" build spit out minified JavaScript? And in that case, it would be identical to the "release" build. If both builds were identical with respect to lein cljsbuild, the build routines that generate mori.node.js and mori.js could be combined and simplified.

2.   If you take a look at a project like Q promises, you'll see it's quite possible to ship a production (and/or development) .js file that is suitable for consumption by Node.js, browsers and other JavaScript environments; that is, depending on the nature of the library, you don't necessarily need separate .js files for each environment. It seems to me that mori could take a similar approach. I would be willing to take a crack at adapting Q's "wrapper" for use with mori, but I wonder if that's something you feel is worthwhile and would be willing to accept into the master branch?

Hello, I'm experimenting with using mori with react, it would be very handy to have the select-keys function available to return subsets of hash-maps.

I have this CoffeeScript usage of mori.flatten:

m = require "mori"

console.log m.flatten([1, [2], 3])

The flatten example in the documentation shows it needs its argument to be converted with js_to_clj first--are there any plans to make flatten work with native arrays?

Thanks,

Stu

It appears to use string as if they were keyword functions, but this doesn't work.

I'd send in a PR, but I don't want to clash with #85

First off, thanks for creating Mori. I am making use of it in a long-term project and it appears to be a good fit for my needs.

I am wondering if it would be possible to port the JavaScript splice method into Mori. It would effectively allow removal and/or insert into sequences where item order is pertinent. Currently, conj seems limiting as it allows no flexibility as to where an item is added. Maybe subvec could play a part in this?

When you consider for example that sometimes order is a significant thing in the real world, it makes sense to allow for the ordering of data even in persistent data structures. For example, a user creates a vector of todos, adding one after the other and then occasionally prioritizes them, moving the more important ones up the list.

Currently, when I manipulate the order, it requires that I first call into_array, perform the reordering, and then reconstitute the vector. I am hoping that existing internal data structures can be reused in allowing for the same operation with greater efficiency.

In another use case, it is possible that a todo is completed and thus removed from the list from somewhere in the middle. I realize there is a remove method that could be used but I wonder about efficiency. When your GUI is already aware of the index of a given item, it seems that this fact would allow for a more efficient operation. For example when you remove an item from a list of hundreds of items and you already know the index that must be better than having to filter it out via remove. It would also probably be useful if one could retrieve the position of an item in a sequence (i.e. indexOf) as this would go hand in hand with splice and even nth. At the very least, providing splice would provide a familiar and immensely useful api.

Obviously, I could add these methods myself, but I think I'd end up with something that internally was as inefficient as the workarounds I'm already utilizing.

Hi,
I've just discovered your library, and I think it's pretty amazing. One question: much of what's in clojure (and clojurescript) is not exported to Mori (Example: the distinct function).

Was mori intended to be a small subset of available clojure/clojurescript functions, or was this an oversight? From looking at the source code it appears that it's just a matter of exporting the function from clojurescript.

When we discussed Travis CI integration in IRC the day before last, I forgot to mention that in addition to doing the passthrough login to GitHub, you would need to click on your name near the top right of the main Travis page, then find your mori repo in the list that appears below, and click the toggle switch on the right to change it from "off" to "on".

It's apparent that you did the Travis login, as the build badge in the README went from being a broken image link to indicating build | unknown. But the "unknown" status usually indicates the toggle hasn't been set to "on" for a repo.

Anyway, it could be you've already toggled it and something else is wrong, but that's my best guess as to why your latest pushes to master didn't result in an auto build-test on Travis.