Is is very bad form to use local mutable state to solve problems like :
https://www.4clojure.com/problem/114
i.e.
(fn [n f xs] (let [c (atom 0)] (take-while #(if (f %) (> n (swap! c inc))
true) xs)))
If so, what is the strongest reason to reject this kind of code? Since its
a local atom
I suggest using proteus https://github.com/ztellman/proteus for performant
local mutation.
On Thursday, March 20, 2014 3:34:20 PM UTC-4, Andy Smith wrote:
>
>
> Is is very bad form to use local mutable state to solve problems like :
>
> https://www.4clojure.com/problem/114
>
&g
s
On 20 March 2014 19:34, Andy Smith wrote:
>
> Is is very bad form to use local mutable state to solve problems like :
>
> https://www.4clojure.com/problem/114
>
> i.e.
>
> (fn [n f xs] (let [c (atom 0)] (take-while #(if (f %) (> n (swap! c inc))
> true) xs)))
>
es
>
>
> On 20 March 2014 19:34, Andy Smith wrote:
>
>>
>> Is is very bad form to use local mutable state to solve problems like :
>>
>> https://www.4clojure.com/problem/114
>>
>> i.e.
>>
>> (fn [n f xs] (let [c (atom 0)] (take-while #(if (f %) (
Also from the proteus link, i read 'these variables cannot escape the local
scope; if passed into a function or closed over', which is a problem with
code such as in my example I suppose.
I wasnt trying to avoid the functional approach but just being devils
advocate. Thanks for your comments.
You can use proteus with a while loop and be as imperative as you like,
however, I think the point of 4clojure is to learn the functional approach
to solving problems(I do not really advocate one over the other honestly;
multiparadigm ftw)
On Thursday, March 20, 2014 4:35:14 PM UTC-4, Andy Smit
Hi Andy,
I think Mr. Reeves gave you some excellent reasons to avoid using local
mutable state, especially when trying to learn functional programming. If
you're interested in seeing a spoiler for 114 you can look at one approach
below (if you don't want a spoiler, then close thi
Im also interested as to why the mutable state approach would be less
performant? In the single thread case the locks would be optimized out
right?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googleg
Excellent point... thanks for the insight
On Thursday, 20 March 2014 20:34:47 UTC, tbc++ wrote:
>
> Not to mention that this isn't local mutation. You are handing the atom to
> a closure that then gets wrapped by lazy-seq and returned. So the atom may
> actually sit around for some time.
>
--
On 3/21/14, 5:44 AM, Andy Smith wrote:
Im also interested as to why the mutable state approach would be less
performant? In the single thread case the locks would be optimized out
right?
No locks are used when using atoms, only compare-and-swap (CAS)
operations. While CAS operations are fast y
Also, you can use straight up java as well inside of loops. I, sometimes,
will write a static method, dump the clojure data strcuture over to java,
mutate like a crazy man, then slap it back into clojure. I find that loop
recur are not as elegant as imperative styles of looping(an opinion of
Hi,
Currently, I am in the process of writing a client to server API which is
not trivial to consume. In particular it needs a 3-step authentication
process: login with user name and password, get an authentication token,
open a session with the token and finally consume the API with the
ses
If you can model the authentication process as a state machine, have a pure
function which accepts auth-state and data and returns either a new state
or an operation to get new data to determine the next state.
E.g. (next-auth-state {:stage :not-authed :login "login" :password "pass"}
nil) => {
Hi Francis,
Thanks for taking the time to thoroughly explain your approach. I find it
interesting and was not yet aware of it. Need to wrap my head around it a
bit.
Best,
Stefan
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this g
One thing you can do is use 'reify', which will allow you to implement a
protocol but also have your state atom hidden in a closure. You'll still be
passing an 'object' to all of the protocol methods (obviously), but it
won't be the atom itself.
--
You received this message because you are su
Good point, Paul. Thanks.
Best,
stefan
--
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 unsub
16 matches
Mail list logo
