3}))
>> :a
>> user> (key (nth {:a 1 :b 2 :c 3} 0))
>> ; Evaluation aborted.
>>
>> java.lang.UnsupportedOperationException: nth not supported on this
>> type: PersistentArrayMap (NO_SOURCE_FILE:0)
>> [Thrown class clojure.lang.Compiler$CompilerException]
>&
I/O, but I think it is a strategy that you can use.
Yes, thanks very much for this tip! I have to admit I didn't (don't)
understand the agent concept. I've been avoiding the subject I guess.
Going to have a look now...
>
> On Apr 5, 2:11 pm, Hugh Winkler wrote:
>>
Hi all,
>From http://clojure.org/refs : "I/O and other activities with
side-effects should be avoided in transactions, since transactions
will be retried. The io! macro can be used to prevent the use of an
impure function in a transaction."
Isn't it OK to do I/O in a transaction as long as doing
On Tue, Jan 20, 2009 at 3:54 PM, Hugh Winkler wrote:
> On Tue, Jan 20, 2009 at 3:06 PM, Stuart Halloway
> wrote:
>>
>> Hi Hugh,
>>
>> I don't see how this would work in general, which is why a I suggested
>> a special-purpose macro before. Surely you
ate forcing doall
>> or let?
>>
>> I'm understanding better. The caller can also do
>>
>> (binding [*num* 1024] (doall (f1)))
>>
>> The caller doesn't necessarily know he's getting a lazy sequence back,
>> but this would be a boiler
On Tue, Jan 20, 2009 at 12:53 AM, Timothy Pratley
wrote:
>
>
>> How would one go about fixing f1 (or b1)?
>
> Depends what you want to achieve... here are two possible 'fixes':
>
> ; don't use lazy evaluation
> (defn f1 []
> (doall (map (fn [x] *num* ) [1])))
>
> ; use lazy evaluation, but pres
On Tue, Jan 20, 2009 at 11:45 AM, Stuart Halloway
wrote:
>
>> OK, good, thanks for the explanation.
>>
>> Is it desirable behavior? Is there some case where a programmer wants
>> this behavior?
>>
>> It's pretty scary to have to consider these hidden effects. Sort of
>> the opposite of FP.
>
> If
On Mon, Jan 19, 2009 at 11:01 PM, Stuart Halloway
wrote:
>
> Lazy evaluation is a harsh mistress.
>
> user=> (def b1 (binding [*num* 1024] (f1)))
> #'user/b1
> user=> (def b2 (binding [*num* 1024] (f1)))
> #'user/b2
> user=> b1
> (16)
> user=> b2
> (16)
>
> The difference between the example abov
Hi all. Is this a bug or a feature? When I bind the var *num* to a new
value, in one case it appears the lambda uses the original value, not
the newly bound one.
(def *num* 16)
(defn f1 []
( map (fn [x] *num* ) [1]))
(defn f2 [] ;; same as f1 but calls first on the map
(first
(
nction you passed in to the arguments. the
> function
> you passed in takes no arguments so you get the " Wrong number of args
> passed to"
> exception.
>
> On Jan 15, 11:12 am, "Hugh Winkler" wrote:
>> I just encountered a surprise attempting to retur
I just encountered a surprise attempting to return a function from a
function. In the below case, if the function parameter is named "fn",
then calling the function throws an exception. If the function
parameter is named "f", no problem. (Using svn as of yesterday)
(defn no-problem[f]
(fn [] (a
>From http://clojure.org/java_interop#toc27 :
"Clojure supports the creation, reading and modification of Java arrays.
It is recommended that you limit use of arrays to interop with Java
libraries that require them as arguments or use them as return values."
What are the reasons for this caveat?
I hesitate to extend this unpleasant thread, but here's a relevant
post that definitely takes a stand on the commenting issue:
http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
As usual with Steve, it's a funny post, so I hope nobody takes it too
seriously :)
Hugh
On Wed, Dec 31,
13 matches
Mail list logo
