Well first, there is a conscious split between collection and sequence functions. Collection functions take a collection and return the same collection (and take the collection first) - things like conj, assoc, dissoc, disj, etc. Those functions are all trait-based and "update" operations are performed on the collection (via those trait interfaces) so the collection has the opportunity to return a new variant of its own type.
For sequences, these take and return sequences (really seqables), which is a logical abstraction. Sequence functions inherently make new sequences and you don't have an opportunity to influence how that happens (they mostly build new lazy seqs from scratch). However, this is exactly the thing that transducer operations do - they let you separate the operation from what happens with the results. So using something `into`, with a transducer chain, from your source collection to your target collection is again, only using collection ops (conj) so you're back in the collection world. Hopefully that confirms/answers what you're thinking through. On Tuesday, January 15, 2019 at 7:58:07 AM UTC-6, plamen...@gmail.com wrote: > > Hello all > > while working on a daily basis where I use Clojure's native vectors/maps I > almost never experience the problem and even if - it is easy fixable with > something like (into [] ...), I have the following problem with custom data > structures and ask here for clarification if my understanding is correct. > > Imagine I try on the one side to represent something like a database table > in memory, while on the other to make it pluggable into all meaningful > sequence and vector/map functions in Clojure. In the most naive > implementation a table is a vector of maps. If i would like to add more > functionality, while trying to remain transparent to Clojure functions I > could implement a custom Record type (IPersistentMap etc.) for the rows > (for a custom storage, for column ordering, type checking etc.) and this > works. I could also implement a custom Table (IPersistentVector etc.) for > the actual collection of records while maintaining internally some indexes, > the schema of the table etc. The point is that if possible to apply let say > (filter.. or (take 2 ..., (sort .. incl. define/apply transducers. or > whatever other Clojure function compatible with these interfaces on the > Table/IPersistentVector/IPersistentCollection and get back a Table. > > What I know: > 1. Clojure's doc actually says that sequence functions return sequences > and say nothing about preserving the original type, the implementations of > the sequence functions do actually as advertised and return usually Cons-es. > 2. monads, yes, but the point is not to force the user to use custom > functions instead of the built in ones. > 3. IPersistentCollection has first/next/more methods which could return a > Table instead of a Record or a collection of them. > 4. IPersistentVector has a cons method, but it is used by Clojure's conj > for example, but not inside the implementations of filter/take etc. which > create actual Cons objects > 5. I could attach table like descriptions to each Record object (be it in > its metadata or else), but then enforcing that all Records share the same > Table data could get penalizing at runtime. > 6. I know how Incanter and core.matrix try to solve some similar problems. > 7. there are some vector functions which return actual vectors back (like > filterv, mapv), but also not the original collection type. > > > So - do I miss something either in my knowledge or in the Clojure's > documentation/implementation and is there a meaningful way to apply > Clojure's and not mine filter/map/take/drop/sort etc. functions on a Table > and to get a Table back, without going the monads/own functions for > everything route or should I take it for granted that I can implement some > custom types, but no way to get them be fully transparent to Clojure? > > With best regards > Plamen > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
