If you speak German, I have a free book on Clojure ("Funktionale
Programmierung in Clojure") for you:
http://denkspuren.blogspot.de/2013/04/freies-clojure-buch-funktionale.html
Dominikus
--
--
You received this message because you are subscribed to the Google
Groups "Clojure&
ally leads to multimethods.
If you like, enjoy reading my blogpost on "The root of polymorphism: The
Anti-If Campaign". It might be an interesting read for Clojure enthusiasts.
http://denkspuren.blogspot.de/2012/05/root-of-polymorphism-anti-if-campaign.html
Cheers,
Dominikus
-
I got it, guys! Thanks a lot! This non-tailrecursive version works as
intended:
(defn fix2 [f x] (let [y (f x)] (eval ({x x} y (list 'fix2 f y)))))
Dominikus
Am Freitag, 27. April 2012 17:00:52 UTC+2 schrieb Luke VanderHart:
>
> Using a map instead of if means that it is eva
Sure? The semantics of the default value corresponds to a 'if', doesn't it?
>From this viewpoint, the default value is in tail position. And why does
the non-tailrecursive version not run as expected?
Dominikus
Am Freitag, 27. April 2012 16:45:44 UTC+2 schrieb Meikel Br
2 (NO_SOURCE_FILE:44)
Strange, isn't it!?
Dominikus
--
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 you
Thanks for the explanation, Meikel!
I'll wait for the next release which hopefully fixes the bug.
Cheers,
Dominikus
On Sep 8, 2:31 pm, "Meikel Brandmeyer (kotarak)"
wrote:
> Hi,
>
> Am Donnerstag, 8. September 2011 14:21:09 UTC+2 schrieb Dominikus:
>
>
>
>
(fact 22N)
ArithmeticException integer overflow
clojure.lang.Numbers.throwIntOverflow (Num
bers.java:1374)
Weird!
Dominikus
On Sep 8, 2:05 pm, "Meikel Brandmeyer (kotarak)"
wrote:
> Hi,
>
> Am Donnerstag, 8. September 2011 13:57:49 UTC+2 schrieb Dominikus:
>
>
>
> >
=> (type (fact 21))
ArithmeticException integer overflow
clojure.lang.Numbers.throwIntOverflow (Num
bers.java:1374)
The optimization to using Longs seems to be too aggressive. Upgrade
casting in Clojure 1.2 is cool and simple.
Dominikus
On Sep 8, 1:30 pm, Eric Lavigne wrote:
> You have discovered a very recent
a
BigInt, [...].
"""
http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics
However (type (- 2 1N)) results in java.lang.Long and does not seem to
work accordingly. What's going on here?
Cheers,
Dominikus
--
You received this message because you are subscribed to
That's a cool link and an interesting read! Thanks, Stefan!
Dominikus
On Sep 5, 10:23 pm, Stefan Kamphausen wrote:
> Hi,
>
> there is another paper in the wild which very nicely describes, how
> Clojure's implementation of STM works and how it compares to other
>
ng transactions with an earlier timestamp.
That's why the second transaction, which comes later in time, is the
one waiting for the first transaction to complete.
Dominikus
On Aug 30, 9:53 am, Laurent PETIT wrote:
> 2011/8/30 Kevin Downey
>
> > the two threads race to acquire the
in in-transaction before committing them, a
write-lock shouldn't be needed. I'm surprised, that the second
transaction is the one who has to retry 71 times even though the first
transaction hasn't committed anything yet.
Cheers,
Dominikus
P.S.: Thanks for the idea to use 'future'
(BTW, if 'alter' is replaced by
'commute', the REPL does not block.)
What's really going on behind the scenes? What am I missing?
Cheers,
Dominikus
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this gr
hink the issue is to get two functions
> with the same textual representation to compare equal.
>
> Adam
Right, Adam. As Armando pointed out, Clojure 1.3 at least doesn't fail
in the case I brought up. I would be very interested to learn what has
changed in the Clojure 1.3 source cod
Thanks for the pointers to the implementation, Jonathan!
Unfortunately, I couldnt' find out yet, which part of the source code
in Clojure 1.3 is responsible for fixing the misbehavior in 1.2. The
parts you point to haven't changed in 1.3.
Cheers,
Dominikus
On May 5, 4:27 pm, Jonath
Thanks a lot, Armando. Looks like I should switch to Clojure 1.3 asap.
Cheers,
Dominikus
2011/5/5 Armando Blancas :
> In 1.3 the function will (eval) to itself:
>
> Clojure 1.3.0-alpha6
> user=> (defn id [x] (list id x))
> #'user/id
> user=> (id 7)
> (# 7)
>
7)
(# 7)
user=> (eval (id 7))
(# 7)
Consequently, the following comparison leads to false:
user=> (= (id 7) (eval (id 7)))
false
Why is the instance relevant to '='? What is the precise semantics of
two values being equal in Clojure?
Dominikus
(Remark: In Scheme, the use of
expansion?
Maybe that's the issue here. Possibly, some code is missing covering
your case.
Interestingly, macroexpand does not work on your qqq-macro either:
user=> (macroexpand '((qqq) (even? 42) "boo!"))
((qqq) (even? 42) "boo!")
That's weird.
Dominikus
perience (as
described in the previous post), it simply shouldn't be possible to
bind special symbols like 'if' to values at all. I guess that some few
lines in Compiler.java could fix that. I don't know how Lisp treats
this case.
Dominikus
On 14 Mrz., 22:09, Timothy Baldrid
ave
accordingly, shouldn't it?
I come up with this scenario in order to understand the precise
behavior of Clojure's evaluation strategy regarding symbol bindings
and special forms. As I said, I'm fully aware that it's no good idea
to change 'if' or any other special f
retation as a
special form. What is the precise evaluation strategy? (I know, it's
dangerous to redefine special forms. Here, I'm interested in the
evaluation strategy of special forms vs. bound symbols.)
Cheers,
Dominikus
--
You received this message because you are subscribed to t
21 matches
Mail list logo
