Am 05.05.2011 02:01, schrieb Ken Wesson:
(There's an ugly workaround
involving explicitly calling intern; you create a dummy namespace with
a var holding the object, and then eval code that refers to that var
by fully-qualified name in order to retrieve the object.)
Yes, this is what I current
Hello Ken, thanks for your explanations. It seems that you basically
outlined a strategy that can be used to implement that feature.
Very good! :-)
Am 05.05.2011 02:21, schrieb Ken Wesson:
As for concerns that this kind of extension might mask common macro
errors, adding some *warn-on-foo* optio
On Wed, May 4, 2011 at 8:01 PM, Ken Wesson wrote:
> Note that instantiating the class with 4 gives us an add-4-to function
> instead of the original add-3-to function here. To actually convert
> that particular closure into code that reproduces it, the array of
> constructor arguments needs to be
On Wed, May 4, 2011 at 8:16 PM, Ken Wesson wrote:
> Closures, including ones whose arguments can't be known until runtime,
> can easily be slapped with "implements Serializable" if they haven't
> been already. Indeed, an "extends Serializable" on IFn, on top of the
> above compiler modification to
On Wed, May 4, 2011 at 8:01 PM, Ken Wesson wrote:
> Note that instantiating the class with 4 gives us an add-4-to function
> instead of the original add-3-to function here. To actually convert
> that particular closure into code that reproduces it, the array of
> constructor arguments needs to be
On Wed, May 4, 2011 at 7:03 PM, Simon Katz wrote:
> It is not possible to write out a function object (something returned
> by lambda, Common Lisp's equivalent of fn) to a compiled file. No mix
> of eval-when, separating functions and macros, and load order can
> change that.
The same is not tru
On May 4, 11:31 pm, André Thieme wrote:
> Am 04.05.2011 14:50, schrieb Simon Katz:
>
> >> For example Common Lisp does support this.
>
> > That's not true, or at least it's only partly true.
>
> > Here's a translation of your example into Common Lisp (I added a use
> > of a# in the macro to avoid
On Wed, May 4, 2011 at 6:31 PM, André Thieme wrote:
> You need to wrap it into eval-when or separate functions and macros from
> their use into different files and make sure the right load order is
> used. Then this will work in CL.
Which are probably some of the reasons Clojure chose not to sup
Am 04.05.2011 14:50, schrieb Simon Katz:
For example Common Lisp does support this.
That's not true, or at least it's only partly true.
Here's a translation of your example into Common Lisp (I added a use
of a# in the macro to avoid compiler optimization making the problem
go away):
(defun
Alessio Stalla writes:
> The key point is that in Lisp "code" does not mean "text" [1]. Code is
> made of data structures - lists, symbols, vectors, numbers, ... - and
> macros are just functions that operate on those data structures.
Hmm, interesting. One of the things that's drawn me to learn
On May 4, 8:50 am, Simon Katz wrote:
> > For example Common Lisp does support this.
>
> That's not true, or at least it's only partly true.
>
> Here's a translation of your example into Common Lisp (I added a use
> of a# in the macro to avoid compiler optimization making the problem
> go away):
>
On May 3, 5:22 pm, André Thieme wrote:
> Am 02.05.2011 23:14, schrieb David Nolen:
>
> > The relevant clojure-dev thread.
> >http://groups.google.com/group/clojure-dev/browse_thread/thread/f4907...
>
> > It's not clear whether the core team and the various contributors are
> > interested in suppor
On 4 Mag, 16:29, "Marshall T. Vandegrift" wrote:
> André Thieme writes:
> > Please try this minimal example in your REPL:
> > (defn f [x] (fn [] x)) ; the closure factory
> > (def foo (f 0)) ; a useful instance
> > (defmacro bar [] `(let [a# ~foo]))
> > and then call (bar)
>
> I'm new to Clojure
> 3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)]))
>
> All three calls fail, (x) and (y) and (z).
> I see no plausible reason why it *should* be that way.
As it's been pointed out, the compiler won't re-compile compiled
code.
Those macros work if you don't unquote the expressions:
(defmacr
André Thieme writes:
> Please try this minimal example in your REPL:
> (defn f [x] (fn [] x)) ; the closure factory
> (def foo (f 0)) ; a useful instance
> (defmacro bar [] `(let [a# ~foo]))
> and then call (bar)
I'm new to Clojure and don't have much experience with Lisps in general,
but trying
> For example Common Lisp does support this.
That's not true, or at least it's only partly true.
Here's a translation of your example into Common Lisp (I added a use
of a# in the macro to avoid compiler optimization making the problem
go away):
(defun f (x) (lambda () x))
(defparameter foo (
On 4 Mag, 01:34, Chris Perkins wrote:
> On May 3, 5:22 pm, André Thieme wrote:
>
> > Some of the limitations:
> > 1. (defmacro x [] `(let [a# ~(atom 0)]))
>
> > 2. (defmacro y [] `(let [a# ~(comp inc inc)])) ; from that link
>
> > 3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)]))
>
> > All
On May 3, 5:22 pm, André Thieme wrote:
> Some of the limitations:
> 1. (defmacro x [] `(let [a# ~(atom 0)]))
>
> 2. (defmacro y [] `(let [a# ~(comp inc inc)])) ; from that link
>
> 3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)]))
>
> All three calls fail, (x) and (y) and (z).
> I see no pl
Am 02.05.2011 23:14, schrieb David Nolen:
The relevant clojure-dev thread.
http://groups.google.com/group/clojure-dev/browse_thread/thread/f4907ebca8ef6e11
It's not clear whether the core team and the various contributors are
interested in supporting the behavior you want. It's also not clear
w
On Mon, May 2, 2011 at 4:49 PM, André Thieme wrote:
> I am not interested in the answers of religious fanatics who defend any
> behaviour that the current implementation has, even if it obviously
> limits the expressiveness.
>
>
> Regards,
> André
>
The relevant clojure-dev thread.
http://groups.
On Mon, May 2, 2011 at 4:49 PM, André Thieme wrote:
> Maybe there are good reasons why closures should not be real first class
> objects, as it is the case in other programming languages that support
> them. If that is the case I would really like to hear it.
>
> I am not interested in the answers
p” Paul Graham wrote:
“With macros, closures, and run-time typing, Lisp transcends object-
oriented programming.”
A modern Lisp like Clojure should indeed support closures in macros.
Instead, return code that will be evaluated in the expansion context
and have the effect you want.
The idea about
On May 1, 4:42 pm, André Thieme wrote:
> I am currently writing a neat logging lib and want it to support dynamic
> and static logging. When I activate (static-logging!) then the log macro
> (log :warn "message") will check during macro expansion time which log
> level is currently set and decides
I am currently writing a neat logging lib and want it to support dynamic
and static logging. When I activate (static-logging!) then the log macro
(log :warn "message") will check during macro expansion time which log
level is currently set and decides based on that if code will be
generated that l
24 matches
Mail list logo
