2010/11/18 Meikel Brandmeyer m...@kotka.de
Salut Laurent,
On 17 Nov., 16:53, Laurent PETIT laurent.pe...@gmail.com wrote:
while a good description of how things work in 1.2
It doesn't even do that. This is exactly *not* the way it works in
1.2, because self-references don't go through
Alyssa Kwan alyssa.c.k...@gmail.com writes:
In any case, I am using Github master and I thought I was using 1.2.
1.2 has self-references lexically bound, as David Sletten points out,
which I agree is the correct behavior. But something has happened on
1.3 alpha that has changed that. I
In 1.2, functions were always looked up through their vars. While this is a
low-cost operation, it does not allow maximum performance.
In 1.3, function calls are compiled through their vars. If function a calls
function c inside its body, there is no runtime lookup of the var c. However,
each
2010/11/17 Stuart Halloway stuart.hallo...@gmail.com
In 1.2, functions were always looked up through their vars. While this is a
low-cost operation, it does not allow maximum performance.
In 1.3, function calls are compiled through their vars. If function a
calls function c inside its body,
In 1.3, function calls are compiled through their vars. If function a calls
function c inside its body, there is no runtime lookup of the var c. However,
each function makes a (very low cost) check on entry to see if anything has
been recompiled. If so, the function is recompiled. This
2010/11/17 Laurent PETIT laurent.pe...@gmail.com
2010/11/17 Stuart Halloway stuart.hallo...@gmail.com
In 1.2, functions were always looked up through their vars. While this is a
low-cost operation, it does not allow maximum performance.
In 1.3, function calls are compiled through their
The issue here is not with b pointing to a. It's that b should point
to b but doesn't. This *can't* be seen to be correct.
Thanks,
Alyssa Kwan
On Nov 17, 9:22 am, Stuart Halloway stuart.hallo...@gmail.com wrote:
In 1.2, functions were always looked up through their vars. While this is a
On Nov 17, 2010, at 9:22 AM, Stuart Halloway wrote:
In 1.2, functions were always looked up through their vars. While this is a
low-cost operation, it does not allow maximum performance.
In 1.3, function calls are compiled through their vars. If function a calls
function c inside its
Hi,
On 17 Nov., 16:29, David Sletten da...@bosatsu.net wrote:
= (defn a
([x] x)
([x y] (+ (a x) (a y
#'user/a
= (a 1 2)
3
= (def b a)
#'user/b
= (b 1 2)
3
= (defn a [x]
(- x))
#'user/a
= (b 1 2)
-3
Let's call the original function assigned to 'a' a0
Meikel,
while a good description of how things work in 1.2, it's not accurate for
1.3, and my point was that Stu's description of how 1.3 works (by using
words like the function is recompiled) does not match with my own
knowledge of what had been done in 1.3 the days just before the conj.
Since
I am wrong, there was a bug here, and Rich just fixed it.
https://github.com/clojure/clojure/commit/8225407032ea643cbe3db7f35ef97b1230fc65b8
Please retry against master, and sorry for inflicting more confusion.
Stu
Meikel,
while a good description of how things work in 1.2, it's not
Thanks everyone!
Alyssa Kwan
On Nov 17, 11:10 am, Stuart Halloway stuart.hallo...@gmail.com
wrote:
I am wrong, there was a bug here, and Rich just fixed it.
https://github.com/clojure/clojure/commit/8225407032ea643cbe3db7f35ef...
Please retry against master, and sorry for inflicting more
Salut Laurent,
On 17 Nov., 16:53, Laurent PETIT laurent.pe...@gmail.com wrote:
while a good description of how things work in 1.2
It doesn't even do that. This is exactly *not* the way it works in
1.2, because self-references don't go through the Var. I'd be curious
to know, why calling the
I ran into this while working on making functions durable. Here's a
contrived example:
= (defn a
([x] x)
([x y] (+ (a x) (a y
#'user/a
= (a 1 2)
3
= (def b a)
#'user/b
= (b 1 2)
3
= (defn a [x]
(- x))
#'user/a
= (b 1 2)
-3
Is this what people expect? I would think that
On Nov 16, 2010, at 5:26 PM, Alyssa Kwan wrote:
Is this what people expect? I would think that the original
definition of a, which is self-referencing, should point to itself no
matter what it's named, not get resolved at invoke-time to see what
the var is currently resolving to.
I'm
But that would destroy one of the most useful features Lisp has to offer,
interactive coding.
Live coding would be impossible w/o this behavior as you would need to find
and update all callers. Yuk.
David
On Tue, Nov 16, 2010 at 5:26 PM, Alyssa Kwan alyssa.c.k...@gmail.comwrote:
I ran into
On Nov 16, 2010, at 5:26 PM, Alyssa Kwan wrote:
I ran into this while working on making functions durable. Here's a
contrived example:
= (defn a
([x] x)
([x y] (+ (a x) (a y
#'user/a
= (a 1 2)
3
= (def b a)
#'user/b
= (b 1 2)
3
= (defn a [x]
(- x))
Notice that when I redefined a, I only included one arity. If b were
updated with the fn that a was redefined to, then (b 1 2) should have
thrown an exception. Instead, it used the old definition of a but
within that definition pointed to the new definition of a. This is
internally
On Tue, Nov 16, 2010 at 10:52 PM, Alyssa Kwan alyssa.c.k...@gmail.comwrote:
In any case, I am using Github master and I thought I was using 1.2.
1.2 has self-references lexically bound, as David Sletten points out,
which I agree is the correct behavior. But something has happened on
1.3
Ok, now I get it. The results you included weren't a hypothetical example, you
were simply using a different version of Clojure. So in your 1.3 version, the
second (b 1 2) does return -3?
Are the macro expansions of 'defn' different?
Have all good days,
David Sletten
On Nov 16, 2010, at
20 matches
Mail list logo
