-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 04.09.2011 19:04, schrieb Luc Prefontaine: > 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
no. i am trying to use the function "subvec" to get what would be a sublist in java. but subvec doesn't work on sequences, and what i need to quickly solve the problem would be a function that takes a sequence and returns a vector. or i could use a vector the whole time and not use a sequence at all. 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: > > 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/ iQIcBAEBAgAGBQJOY8fIAAoJENRtux+h35aG2gMP/jzVMY49ug+42Ya3f4oLHvqT /FasCnkZqVv8jnzHOO8cJ4c0zuHC8XPWFzprlhXKakg+dTiCkeRWIEg/yISSjaYO aBb+iD3/ZMnvgBxGrHak89rNSEHGKBIdmJmWdQUd+9EK+I4sg1fjy1YQAg0jgFqo xTnynRDgUWbfRcPrPaYW4/u2BmAMD3ITl24nPthS2A8ZiXsiwLPZxux5XlIC4s0/ ZJwmDovoxzUrt2I236E9erq2e+msdXrXO0vvhfkILsSHDrES7e9eC0JPZS+9a6nm JE1IaaJ/ZbR96KjtkcQjyc0o0PGPRbT7KnorFUh8SY2nU48AFXki/RRhSq/Rs+tj 5hVwmTI+mTgZjJhDDxCAKBh3RNBumyFjK4BuulPFZ2Qd7HfPwVDAVWYF5GYfn7Zb PKkGA27H8oFhOfNxwCouq93ks/lo2DB1SGiJ73JLabYb/0L3Prb61hmQrbksmsF4 w7ORXs+jfhtndiTkCKaQ6cKL+5oBEtk/c/RtBoS79Zn7boNqpJv5qvlaWh96/RvM 8mWNswtGU8PexK2cofFDJYQk4NDXnul2dHUSAcuQPOwgIcOcac5+wKs1dNQzX8W/ VmtzitUNFA63iwbWSKpfjVlbW8EIh0a3i5N6Z2tOGo948y054TbN0LdVBLeTwO/d DzSsWcIbTzR2a0R0FFOf =mYVl -----END PGP SIGNATURE----- -- 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
