Have a look at reduce: (reduce conj [] (take 9 (cycle [0])))
take returns a lazy seq. but reduce will return you a vector. Looks like you try to translate as if you were using a language that allows mutations but you use functions to hold values that you redefine since mutation is restricted to refs and atoms. I suggest you look at atoms to hold values if they can mutate globally or at recur if you need to implement some recursion and rebind new values within a function's body. Luc P. On Sun, 04 Sep 2011 18:55:12 +0200 Dennis Haupt <d.haup...@googlemail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > solved my last problem, and now i'm stucker than before: > > (def open 0) > (def p1 1) > (def p2 2) > (def emptyfield [open open open open open open open open open]) > > (defn updated [seq index replacement] > (concat > (take index seq) > [replacement] > (drop (inc index) seq))) > > (defn indexOf [x y] (+ x (* y 3))) > > (defn withmove [x,y,player,field] > (updated field (indexOf x y) player)) > > (defn winner [field] > (defn winPred [player] > (defn rowwin [row] > (let [beginIndex (indexOf 0 row) > currow (subvec (force field) beginIndex (+ 3 beginIndex))] > (defn ownedByPlayer [value]) > every? ownedByPlayer currow)) > (defn colwin [col] > (let [beginIndex (indexOf col 0) > curcol (take-nth 3 (drop beginIndex field))] > (defn ownedByPlayer [value]) > every? ownedByPlayer curcol)) > (loop [cnt 0] > (if (= cnt 3) false (or (rowwin cnt) (colwin cnt) (recur (inc > cnt)))))) > > (let [winnerIfExists (filter winPred [p1 p2])] > (if (empty? winnerIfExists) open (first winnerIfExists)))) > > (let [moves [[0 0 p1] [1 0 p1] [2 0 p1]]] > (defn fold [field nextmove] > (withmove (nth nextmove 0) (nth nextmove 1) (nth nextmove 2) > field)) (let [endstate (reduce fold emptyfield moves)] > (println endstate) > (println (winner endstate))) > ) > > > how to convert a lazy seq into a persistent vector? > > > Am 03.09.2011 23:38, schrieb Luc Prefontaine: > > On Sat, 3 Sep 2011 13:43:42 -0700 (PDT) HamsterofDeath > > <d.haup...@googlemail.com> wrote: > > > >> this might seem like a stupid question, but for me, not knowing > >> the type of something is like being stuck in a dead end for > >> anything non trivial. > > > > It's not stupid, it's normal :) > > > > In functional programming, most of the time you would like to write > > functions that do not need to know their arguments too intimately. > > You would like to work on collections, maps, ... > > > > Of course at some point you will need to write functions that will > > look closer to their arguments. > > > > You can pass functions to generic ones and isolate that type > > knowledge within them. No need to spread this everywhere. > > > >> i've made a few little experiments with clojure (not much, just > >> testing some features) and i see how powerful clojure can be - > >> for small to medium sized problems with simple input and output - > >> a*- pathfinding, for example. > >> > >> but how would i port a complex object graph (let's say 15 > >> different classes with 3-7 fields each - person, contacts, > >> orders, shipping details) to clojure? how would i handle it? > > > > defrecord might help you a bit here. It may feel a bit "like > > home". defrecord fields can be referenced as map entries > > (:field-name ...). > > > > You can also define protocols that associated with defrecord and > > may ease your pain by implementing familiar functions to navigate > > in the hierarchy. > > > > Not sure if using a library written by someone else to handle these > > things is the proper thing to do right now. I feel you need to > > break your teeth a bit :) (It took me three months to get used to > > immutability :)) > > > >> the main problems i see are: * do i have to actually remember the > >> complete structure and field names and the exact spelling? using > >> statically types languages like java or scala, the ide > >> autocomplete features really help here. > > > > If you use obvious names that match the problem domain this should > > be easy to overcome. Protocols could help you here by hiding some > > complex navigation but please refrain implementing "getters" for > > all individual fields :)) > > > >> * what about renaming a field or method? > > > > Yep of course you will not have this nice refactoring feature where > > you type in place the new name and get the IDE to fix this > > everywhere for you. But on the other hand you should have at least > > 10 times less code compared to java and less side effects to > > debug. It should not be too hard to do this using a standard text > > search. I use Eclipse and the straight "file" search. I would never > > exchange Clojure for Java and the automated "Refactoring" > > commands. > > > > If you encapsulate frequently exposed fields in functions you > > should be able to reduce the footprint of the code where these > > things are exposed. Hence the name changes would be easy to > > implement. You would confine these functions in a specific name > > space which decrease the like hood of missing a change. > > > >> * if a function needs an instance of the root class of the > >> complex graph above as a parameter - how do i know this at all? > >> am i lost without good documentation of this function? in java, i > >> just know what a method needs because it has a signature. > >> > > Use the doc string when defining a fn: > > > > (defn blbl "Returns the meaningful "blblblbl..." string. It expects > > a single parameter, the length of the returned string" [length] > > ...) > > > > You can describe the expected inputs and the result, ... Do the > > same thing with your name space definitions, protocols. ... > > > > It's easy, fits with your programming flow and is non-obtrusive. > > > > > > > - -- > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJOY61vAAoJENRtux+h35aG3ToQALfT3XdikxD5OrzaTwXC5Hbo > e1oymb0MZoKpHjStrjpHPgvhEB5jt04TTIcGoPfyZoOhT56PrZLMtjD5ItZFVJvi > 41JvhrMb1DMs+4jwOwkCvjlmB7ZhZEeQE7T1nWIoJYDNm1NTNZCYoCiIs9VISt+9 > 7vNCXg10sbWV8plIJNqLtdWRxNzY7B0wP77G7h3+2H91V/sYqLBjfrVkSOL0zoYo > QUIAWDWihUWk0cvVRBPe5dKd8Hu1z74frhAm6TsGnfXMXEFhXpQ9WoUkwhYgz9Ap > ZJFxsRgEQtX+gkD/fku3hMGIjR6zvLuHbbrx1kBVxfeHWgOFc5htEq1kIy+vUOVZ > 5xuBEMSukMIvYM4O9Kschv2joUuy8bcXVhuVlSMJRk0jhiwggxNIcx2kE0ug47Dh > iGaOEYoezkXXwuEsQ568P4Gfd309TujKrvC1YHSNBf1QiayXkZ54uoCwBqBrZ8FJ > dea/vJdaFpyrkuhABBD7XqwTzoGwT6JTmD+csRwIRXAKCbXq1ZopzKzuAMyCOs8A > o8fPa0A4vJxjLj5Bh1WKzB3nIfIjagT3SGMiMDweMW+ydGPMDc8xCJz5+W/nC1pU > oQfYJYl5VNWadsQyHRylQhCoKvgrcijy23EnrYdf9sSKM53+Nig5Iff0UOz0YCoL > v1iG1P5NqhUVNXgnDT65 > =X2Q3 > -----END PGP SIGNATURE----- > -- Luc P. ================ The rabid Muppet -- 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
