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
Am 02.05.2011 02:26, schrieb Alan:
You can't embed a function in code as a raw function object
Can anyone give explanations why this is so?
I understand that it may sound provocative, but this sounds to me like
a major bug.
- you need to return code that will result in that function. That it
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
23 matches
Mail list logo
