Re: NullPointerException when creating protocol in macro

2013-06-07 Thread Vincent
Thanks everyone for your answers. I must say I'm quite mystified as to why Stuart's version works. I ended up defining a function that has the same signature as the protocol, and whose first argument wraps a function that contains the appropriate code. Vincent On Wednesday, 5 June 2013

NullPointerException when creating protocol in macro

2013-06-05 Thread Vincent
I’m trying to write a macro that defines a protocol and a function that, when called, returns an implementation of that protocol. I’ve reduced the code to the following example: (defmacro create-protocol [protocol implementation] (let [[protocol-name signature] protocol] `(do

Re: NullPointerException when creating protocol in macro

2013-06-05 Thread Stuart Sierra
Hi Vincent, `defprotocol` is a top-level form, not really meant to be mixed with value-returning expressions like `fn`. Protocols are always global because of how they compile into Java interfaces. Here's one way to make it work, by defining a symbol instead of returning a function:

Re: NullPointerException when creating protocol in macro

2013-06-05 Thread Colin Fleming
*`defprotocol` is a top-level form...* This is interesting, and it's something I've wondered about. As far as I can tell, there's really no distinction between top-level forms and other forms, for example this is legal and works: (defn define-my-functions [] (defn test-1 [] 1) (defn

Re: NullPointerException when creating protocol in macro

2013-06-05 Thread Stuart Sierra
On Wed, Jun 5, 2013 at 7:35 PM, Colin Fleming colin.mailingl...@gmail.comwrote: Given this, are there any forms that are genuinely top-level from the compiler's point of view? It's never explicitly enforced, just a consequence of how the compiler creates and loads Java classes. Generally,

Re: NullPointerException when creating protocol in macro

2013-06-05 Thread Softaddicts
Legal but comparable to a hidden side effect with all the pitfalls that can derive from this. It's not a compiler issue, more a discipline issue. Having a helper macro like Stuart suggest is acceptable to me if it's called at top level, it's always done. There's less ambiguity. Using def/defn