Re: testing for nil may not be enough

[AtKaaZ]

On Tue, Apr 30, 2013 at 10:51 AM, Tassilo Horn  wrote:

> "Jim - FooBar();"  writes:
>
> > funny you should mention that!!! that is exactly what I meant by 'my
> > fault'...I've come to realise that dynamic scope is almost evil, thus
> > I go to great lengths to avoid it completely...in the rare cases where
> > I do use it I always make sure it is bound to a init/default value :)
>
> I do exactly the opposite when I use dynamic vars, that is, I define no
> default value.  For example, there's a function foo that uses a dynamic
> var, and that must be bound and well-defined.  Therefore, I provide a
> macro to initially set it up, so that you write
>
>   (with-bar (foo bla))
>
> and with-bar takes care of the proper initialization of that dynamic var
> (which is not even visible to the user).  When foo explodes because of
> the var being Unbound, then it's obvious that the function was called
> outside a with-bar macro and thus is a user error.  A default value
>
the thing is, that it may not always explode if not used with with-bar,
depending on the implementation of the function, as if when used in an
(cond (nil? thevar) ... )  or (str thevar)
If you ask me, I'd allow the var to be unbound and code everywhere for
cases where the var could be unbound - which there should be many ie. any
function; so I can understand why people would want to take the
easy/workaround way and set a default value instead.

=> (defn decorate [input]
 (str "prefix:" input ":suffix")
 )
#'jme3test1.x1/decorate
=> (def ^:dynamic *y*)
#'jme3test1.x1/*y*

assume I forget to use with-bar here:
=> (decorate *y*)
"prefix:Unbound: #'jme3test1.x1/*y*:suffix"
didn't explode
or here:
=> (defn do-smth-with [input]
 (when (not (nil? input))
   (str "doing something with " input))
 )
#'jme3test1.x1/do-smth-with
=> (do-smth-with *y*)
"doing something with Unbound: #'jme3test1.x1/*y*"

=> (do-smth-with *x*)
"doing something with 2"
=> (decorate *x*)
"prefix:2:suffix"
=> (do-smth-with nil)
nil

I guess what I was trying to say all along is that it's too easy to fall
into this by mistake because maybe most don't check for unbound and it may
not explode

would shadow such an error.
>
> A real-world example of this design are many database query libs, where
> you frequently have code like
>
>   (with-db-connection (make-me-a-db-connection url)
> (select :from "foo" :where ...))
>
> Bye,
> Tassilo
>
> --
> --
> 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
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: testing for nil may not be enough

[AtKaaZ]

On Tue, Apr 30, 2013 at 11:00 AM, Tassilo Horn  wrote:

> Gary Trakhman  writes:
>
> > If you're passing the var itself, I don't see why you'd need a macro.
> > If you want to check the namespace for a var matching an unquoted
> > symbol, you could do that in a macro.
>
> In case you really don't have the var itself but just its value, then
> "unbound" is a value, too, and you could check for it using
>
>   (instance? clojure.lang.Var$Unbound *x*)
>   ;=> true
>
> nice one, thanks!

I was thinking just in case any of these "clojure.lang.Var$Unbound" change
in the future, maybe I'd do something like this:

=>* (def uniqsym (gensym))*
#'jme3test1.x1/uniqsym

=> *uniqsym*
G__1603

=>* (defmacro defus [] `(def ~uniqsym))*
#'jme3test1.x1/defus

=> *(defus)*
#'jme3test1.x1/G__1603

=> *(class (eval uniqsym))*
clojure.lang.Var$Unbound

=> *(def unbound-class (class (eval uniqsym)))*
#'jme3test1.x1/unbound-class

=>* unbound-class*
clojure.lang.Var$Unbound

=> *(def ^:dynamic *x*)*
#'jme3test1.x1/*x*

=>* (instance? unbound-class *x*)*
true

=>* (binding [*x* 1]
 (instance? unbound-class *x*)
 )*
false

=>* (def ^:dynamic *x* 2)*
#'jme3test1.x1/*x*
=>* (binding [*x* 1]
 (instance? unbound-class *x*)
 )*
false


instead of
>
>   (not (bound? #'*x*))
>
> Bye,
> Tassilo
>
> --
> --
> 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
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: testing for nil may not be enough

[Tassilo Horn]

Gary Trakhman  writes:

> If you're passing the var itself, I don't see why you'd need a macro.
> If you want to check the namespace for a var matching an unquoted
> symbol, you could do that in a macro.

In case you really don't have the var itself but just its value, then
"unbound" is a value, too, and you could check for it using

  (instance? clojure.lang.Var$Unbound *x*)
  ;=> true

instead of

  (not (bound? #'*x*))

Bye,
Tassilo

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: testing for nil may not be enough

[Tassilo Horn]

AtKaaZ  writes:

> Seems like a good idea to have the root binding be nil. How would you
> make it check for bound inside the function? do we need some kind of
> macro?

If the var has a root binding of nil, then you can't distinguish the
cases "explicitly bound to nil" and "root binding", so I think in most
cases having no root binding is preferrable.

A counter example is *out*, where it makes sense that the root binding
is a PrintWriter to standard out.

Bye,
Tassilo

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: testing for nil may not be enough

[Tassilo Horn]

"Jim - FooBar();"  writes:

> funny you should mention that!!! that is exactly what I meant by 'my
> fault'...I've come to realise that dynamic scope is almost evil, thus
> I go to great lengths to avoid it completely...in the rare cases where
> I do use it I always make sure it is bound to a init/default value :)

I do exactly the opposite when I use dynamic vars, that is, I define no
default value.  For example, there's a function foo that uses a dynamic
var, and that must be bound and well-defined.  Therefore, I provide a
macro to initially set it up, so that you write

  (with-bar (foo bla))

and with-bar takes care of the proper initialization of that dynamic var
(which is not even visible to the user).  When foo explodes because of
the var being Unbound, then it's obvious that the function was called
outside a with-bar macro and thus is a user error.  A default value
would shadow such an error.

A real-world example of this design are many database query libs, where
you frequently have code like

  (with-db-connection (make-me-a-db-connection url)
(select :from "foo" :where ...))

Bye,
Tassilo

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: testing for nil may not be enough

[John D. Hume]

On Apr 29, 2013 1:07 PM, "Jonathan Fischer Friberg" 
wrote:
>
> If you don't want to set the initial value to nil, set it to ::unbound or
similar. Should be very
> hard to accidentally bind the same value.

Please take Jonathan's advice if nil is a valid value for a user to bind;
use nil as the initial value if it's not.

It is non-idiomatic to leave the var unbound for exactly the reason you're
running into: unbound vars are annoying to deal with.

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: testing for nil may not be enough

[Jonathan Fischer Friberg]

If you don't want to set the initial value to nil, set it to ::unbound or
similar. Should be very
hard to accidentally bind the same value.

Jonathan


On Mon, Apr 29, 2013 at 8:04 PM, AtKaaZ  wrote:

> the pain with that is that it wouldn't work inside a function where a
> would be the function parameter, ok it would work in a macro but inside a
> function... that would be interesting to see
>
>
> On Mon, Apr 29, 2013 at 9:01 PM, Sean Corfield wrote:
>
>> Try this:
>>
>> user=> (def a)
>> #'user/a
>> user=> (bound? (var a))
>> false
>> user=> (def a nil)
>> #'user/a
>> user=> (bound? (var a))
>> true
>>
>> Sean
>>
>> On Mon, Apr 29, 2013 at 8:32 AM, AtKaaZ  wrote:
>> > How do you guys handle the cases when the var is unbound? I mean
>> > specifically in the cases where you just test if the var is nil.
>> >
>> > => (def a)
>> > #'clojurewerkz.titanium.graph-test/a
>> >
>> > => a
>> > #
>> >
>> > => (nil? a)
>> > false
>> >
>> > => (bound? a)
>> > ClassCastException clojure.lang.Var$Unbound cannot be cast to
>> > clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)
>> >
>> > => (bound? #'a)
>> > false
>> >
>> > ok imagine the following sample :))
>> >
>> > => (defn decorate [input]
>> >  (when (not (nil? input)) (str "prefix:" input ":suffix")))
>> > #'clojurewerkz.titanium.graph-test/decorate
>> >
>> > => (decorate "1")
>> > "prefix:1:suffix"
>> >
>> > => (decorate a)
>> > "prefix:Unbound: #'clojurewerkz.titanium.graph-test/a:suffix"
>> >
>> > so... fix?
>> >  but more importantly does anyone need to add checks for
>> is-the-var-bound in
>> > their code where they checked for nil ?
>> >
>> > --
>> > --
>> > 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
>> your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to clojure+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>>
>>
>> --
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>> World Singles, LLC. -- http://worldsingles.com/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>> --
>> --
>> 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
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>  --
> --
> 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
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: testing for nil may not be enough

[AtKaaZ]

the pain with that is that it wouldn't work inside a function where a would
be the function parameter, ok it would work in a macro but inside a
function... that would be interesting to see


On Mon, Apr 29, 2013 at 9:01 PM, Sean Corfield wrote:

> Try this:
>
> user=> (def a)
> #'user/a
> user=> (bound? (var a))
> false
> user=> (def a nil)
> #'user/a
> user=> (bound? (var a))
> true
>
> Sean
>
> On Mon, Apr 29, 2013 at 8:32 AM, AtKaaZ  wrote:
> > How do you guys handle the cases when the var is unbound? I mean
> > specifically in the cases where you just test if the var is nil.
> >
> > => (def a)
> > #'clojurewerkz.titanium.graph-test/a
> >
> > => a
> > #
> >
> > => (nil? a)
> > false
> >
> > => (bound? a)
> > ClassCastException clojure.lang.Var$Unbound cannot be cast to
> > clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)
> >
> > => (bound? #'a)
> > false
> >
> > ok imagine the following sample :))
> >
> > => (defn decorate [input]
> >  (when (not (nil? input)) (str "prefix:" input ":suffix")))
> > #'clojurewerkz.titanium.graph-test/decorate
> >
> > => (decorate "1")
> > "prefix:1:suffix"
> >
> > => (decorate a)
> > "prefix:Unbound: #'clojurewerkz.titanium.graph-test/a:suffix"
> >
> > so... fix?
> >  but more importantly does anyone need to add checks for
> is-the-var-bound in
> > their code where they checked for nil ?
> >
> > --
> > --
> > 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
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> 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
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: testing for nil may not be enough

[Sean Corfield]

Try this:

user=> (def a)
#'user/a
user=> (bound? (var a))
false
user=> (def a nil)
#'user/a
user=> (bound? (var a))
true

Sean

On Mon, Apr 29, 2013 at 8:32 AM, AtKaaZ  wrote:
> How do you guys handle the cases when the var is unbound? I mean
> specifically in the cases where you just test if the var is nil.
>
> => (def a)
> #'clojurewerkz.titanium.graph-test/a
>
> => a
> #
>
> => (nil? a)
> false
>
> => (bound? a)
> ClassCastException clojure.lang.Var$Unbound cannot be cast to
> clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)
>
> => (bound? #'a)
> false
>
> ok imagine the following sample :))
>
> => (defn decorate [input]
>  (when (not (nil? input)) (str "prefix:" input ":suffix")))
> #'clojurewerkz.titanium.graph-test/decorate
>
> => (decorate "1")
> "prefix:1:suffix"
>
> => (decorate a)
> "prefix:Unbound: #'clojurewerkz.titanium.graph-test/a:suffix"
>
> so... fix?
>  but more importantly does anyone need to add checks for is-the-var-bound in
> their code where they checked for nil ?
>
> --
> --
> 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 your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: testing for nil may not be enough

[AtKaaZ]

thank you, I'll look into protocols


On Mon, Apr 29, 2013 at 7:54 PM, Gary Trakhman wrote:

> You would only need a macro if you want to pass in 'a' and mean #'a.
>  Syntactic abstraction.  Like I said, I'd make the implementation
> polymorphic on that value via a protocol so you're not special-casing it
> within the function itself.  Protocols are open for extension so someone
> else could come along and provide an implementation for something you
> haven't thought of doing.
>
>
> On Mon, Apr 29, 2013 at 12:44 PM, AtKaaZ  wrote:
>
>> oh right, you mean that I should pass the var like (decorate #'a), I
>> didn't get that when I first read it. But suppose I'm just passing the
>> whatever-that-is (value?) like (decorate a) do I need to use a macro inside
>> the decorate function to check if the passed thing is an unbound var?
>>
>>
>> On Mon, Apr 29, 2013 at 7:31 PM, Gary Trakhman 
>> wrote:
>>
>>> If you're passing the var itself, I don't see why you'd need a macro.
>>>  If you want to check the namespace for a var matching an unquoted symbol,
>>> you could do that in a macro.
>>>
>>>
>>> On Mon, Apr 29, 2013 at 12:29 PM, AtKaaZ  wrote:
>>>
 Seems like a good idea to have the root binding be nil. How would you
 make it check for bound inside the function? do we need some kind of macro?


 On Mon, Apr 29, 2013 at 7:23 PM, Gary Trakhman >>> > wrote:

> Why not make the root binding nil?  If your decorate function is
> supposed to handle all vars, then they have to deal with the unbound case
> as that's part of the contract of vars.
>
> If it's a generic thing, then maybe make a multimethod or protocol for
> it.
>
>
> On Mon, Apr 29, 2013 at 12:17 PM, AtKaaZ  wrote:
>
>> I'm thinking something like (def ^:dynamic *a*) where it would make
>> more sense that it's unbound at first
>>
>>
>> On Mon, Apr 29, 2013 at 7:00 PM, Jim - FooBar(); <
>> jimpil1...@gmail.com> wrote:
>>
>>> I 've found that whenever I get a var-unbound exception it is almost
>>> always my fault and my fault only...why would you do (def a) anyway?
>>>
>>> Jim
>>>
>>>
>>>
>>> On 29/04/13 16:32, AtKaaZ wrote:
>>>
 How do you guys handle the cases when the var is unbound? I mean
 specifically in the cases where you just test if the var is nil.

 => (def a)
 #'clojurewerkz.titanium.graph-**test/a

 => a
 #

 => (nil? a)
 false

 => (bound? a)
 ClassCastException clojure.lang.Var$Unbound cannot be cast to
 clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)

 => (bound? #'a)
 false

 ok imagine the following sample :))

 => (defn decorate [input]
  (when (not (nil? input)) (str "prefix:" input ":suffix")))
 #'clojurewerkz.titanium.graph-**test/decorate

 => (decorate "1")
 "prefix:1:suffix"

 => (decorate a)
 "prefix:Unbound: #'clojurewerkz.titanium.graph-**test/a:suffix"

 so... fix?
  but more importantly does anyone need to add checks for
 is-the-var-bound in their code where they checked for nil ?

 --
 --
 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 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscribe@**googlegroups.com
 For more options, visit this group at
 http://groups.google.com/**group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it,
 send an email to 
 clojure+unsubscribe@**googlegroups.com
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_out
 .



>>> --
>>> --
>>> 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 your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscribe@**googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/**group/clojure?hl=en
>>> --- You received this message because you are subscribed to the
>>> Google Groups "Clo

Re: testing for nil may not be enough

[Gary Trakhman]

You would only need a macro if you want to pass in 'a' and mean #'a.
 Syntactic abstraction.  Like I said, I'd make the implementation
polymorphic on that value via a protocol so you're not special-casing it
within the function itself.  Protocols are open for extension so someone
else could come along and provide an implementation for something you
haven't thought of doing.


On Mon, Apr 29, 2013 at 12:44 PM, AtKaaZ  wrote:

> oh right, you mean that I should pass the var like (decorate #'a), I
> didn't get that when I first read it. But suppose I'm just passing the
> whatever-that-is (value?) like (decorate a) do I need to use a macro inside
> the decorate function to check if the passed thing is an unbound var?
>
>
> On Mon, Apr 29, 2013 at 7:31 PM, Gary Trakhman wrote:
>
>> If you're passing the var itself, I don't see why you'd need a macro.  If
>> you want to check the namespace for a var matching an unquoted symbol, you
>> could do that in a macro.
>>
>>
>> On Mon, Apr 29, 2013 at 12:29 PM, AtKaaZ  wrote:
>>
>>> Seems like a good idea to have the root binding be nil. How would you
>>> make it check for bound inside the function? do we need some kind of macro?
>>>
>>>
>>> On Mon, Apr 29, 2013 at 7:23 PM, Gary Trakhman 
>>> wrote:
>>>
 Why not make the root binding nil?  If your decorate function is
 supposed to handle all vars, then they have to deal with the unbound case
 as that's part of the contract of vars.

 If it's a generic thing, then maybe make a multimethod or protocol for
 it.


 On Mon, Apr 29, 2013 at 12:17 PM, AtKaaZ  wrote:

> I'm thinking something like (def ^:dynamic *a*) where it would make
> more sense that it's unbound at first
>
>
> On Mon, Apr 29, 2013 at 7:00 PM, Jim - FooBar();  > wrote:
>
>> I 've found that whenever I get a var-unbound exception it is almost
>> always my fault and my fault only...why would you do (def a) anyway?
>>
>> Jim
>>
>>
>>
>> On 29/04/13 16:32, AtKaaZ wrote:
>>
>>> How do you guys handle the cases when the var is unbound? I mean
>>> specifically in the cases where you just test if the var is nil.
>>>
>>> => (def a)
>>> #'clojurewerkz.titanium.graph-**test/a
>>>
>>> => a
>>> #
>>>
>>> => (nil? a)
>>> false
>>>
>>> => (bound? a)
>>> ClassCastException clojure.lang.Var$Unbound cannot be cast to
>>> clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)
>>>
>>> => (bound? #'a)
>>> false
>>>
>>> ok imagine the following sample :))
>>>
>>> => (defn decorate [input]
>>>  (when (not (nil? input)) (str "prefix:" input ":suffix")))
>>> #'clojurewerkz.titanium.graph-**test/decorate
>>>
>>> => (decorate "1")
>>> "prefix:1:suffix"
>>>
>>> => (decorate a)
>>> "prefix:Unbound: #'clojurewerkz.titanium.graph-**test/a:suffix"
>>>
>>> so... fix?
>>>  but more importantly does anyone need to add checks for
>>> is-the-var-bound in their code where they checked for nil ?
>>>
>>> --
>>> --
>>> 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 your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscribe@**googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/**group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to 
>>> clojure+unsubscribe@**googlegroups.com
>>> .
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>>
>>>
>> --
>> --
>> 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 your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscribe@**googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/**group/clojure?hl=en
>> --- You received this message because you are subscribed to the
>> Google Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to 
>> clojure+unsubscribe@**googlegroups.com
>> .
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out

Re: testing for nil may not be enough

[AtKaaZ]

oh right, you mean that I should pass the var like (decorate #'a), I didn't
get that when I first read it. But suppose I'm just passing the
whatever-that-is (value?) like (decorate a) do I need to use a macro inside
the decorate function to check if the passed thing is an unbound var?


On Mon, Apr 29, 2013 at 7:31 PM, Gary Trakhman wrote:

> If you're passing the var itself, I don't see why you'd need a macro.  If
> you want to check the namespace for a var matching an unquoted symbol, you
> could do that in a macro.
>
>
> On Mon, Apr 29, 2013 at 12:29 PM, AtKaaZ  wrote:
>
>> Seems like a good idea to have the root binding be nil. How would you
>> make it check for bound inside the function? do we need some kind of macro?
>>
>>
>> On Mon, Apr 29, 2013 at 7:23 PM, Gary Trakhman 
>> wrote:
>>
>>> Why not make the root binding nil?  If your decorate function is
>>> supposed to handle all vars, then they have to deal with the unbound case
>>> as that's part of the contract of vars.
>>>
>>> If it's a generic thing, then maybe make a multimethod or protocol for
>>> it.
>>>
>>>
>>> On Mon, Apr 29, 2013 at 12:17 PM, AtKaaZ  wrote:
>>>
 I'm thinking something like (def ^:dynamic *a*) where it would make
 more sense that it's unbound at first


 On Mon, Apr 29, 2013 at 7:00 PM, Jim - FooBar(); 
 wrote:

> I 've found that whenever I get a var-unbound exception it is almost
> always my fault and my fault only...why would you do (def a) anyway?
>
> Jim
>
>
>
> On 29/04/13 16:32, AtKaaZ wrote:
>
>> How do you guys handle the cases when the var is unbound? I mean
>> specifically in the cases where you just test if the var is nil.
>>
>> => (def a)
>> #'clojurewerkz.titanium.graph-**test/a
>>
>> => a
>> #
>>
>> => (nil? a)
>> false
>>
>> => (bound? a)
>> ClassCastException clojure.lang.Var$Unbound cannot be cast to
>> clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)
>>
>> => (bound? #'a)
>> false
>>
>> ok imagine the following sample :))
>>
>> => (defn decorate [input]
>>  (when (not (nil? input)) (str "prefix:" input ":suffix")))
>> #'clojurewerkz.titanium.graph-**test/decorate
>>
>> => (decorate "1")
>> "prefix:1:suffix"
>>
>> => (decorate a)
>> "prefix:Unbound: #'clojurewerkz.titanium.graph-**test/a:suffix"
>>
>> so... fix?
>>  but more importantly does anyone need to add checks for
>> is-the-var-bound in their code where they checked for nil ?
>>
>> --
>> --
>> 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 your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscribe@**googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/**group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to 
>> clojure+unsubscribe@**googlegroups.com
>> .
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out
>> .
>>
>>
>>
> --
> --
> 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 your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>
  --
 --
 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
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this

Re: testing for nil may not be enough

[AtKaaZ]

I'm thinking of a hacky way of doing it...
(def a nil)
(def b)

=> (defn x [in]
 (when (not (nil? in)) (.v in)))
#'clojurewerkz.titanium.graph-test/x

=> (x b)
#'clojurewerkz.titanium.graph-test/b

=> (x a)
nil



On Mon, Apr 29, 2013 at 7:31 PM, Gary Trakhman wrote:

> If you're passing the var itself, I don't see why you'd need a macro.  If
> you want to check the namespace for a var matching an unquoted symbol, you
> could do that in a macro.
>
>
> On Mon, Apr 29, 2013 at 12:29 PM, AtKaaZ  wrote:
>
>> Seems like a good idea to have the root binding be nil. How would you
>> make it check for bound inside the function? do we need some kind of macro?
>>
>>
>> On Mon, Apr 29, 2013 at 7:23 PM, Gary Trakhman 
>> wrote:
>>
>>> Why not make the root binding nil?  If your decorate function is
>>> supposed to handle all vars, then they have to deal with the unbound case
>>> as that's part of the contract of vars.
>>>
>>> If it's a generic thing, then maybe make a multimethod or protocol for
>>> it.
>>>
>>>
>>> On Mon, Apr 29, 2013 at 12:17 PM, AtKaaZ  wrote:
>>>
 I'm thinking something like (def ^:dynamic *a*) where it would make
 more sense that it's unbound at first


 On Mon, Apr 29, 2013 at 7:00 PM, Jim - FooBar(); 
 wrote:

> I 've found that whenever I get a var-unbound exception it is almost
> always my fault and my fault only...why would you do (def a) anyway?
>
> Jim
>
>
>
> On 29/04/13 16:32, AtKaaZ wrote:
>
>> How do you guys handle the cases when the var is unbound? I mean
>> specifically in the cases where you just test if the var is nil.
>>
>> => (def a)
>> #'clojurewerkz.titanium.graph-**test/a
>>
>> => a
>> #
>>
>> => (nil? a)
>> false
>>
>> => (bound? a)
>> ClassCastException clojure.lang.Var$Unbound cannot be cast to
>> clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)
>>
>> => (bound? #'a)
>> false
>>
>> ok imagine the following sample :))
>>
>> => (defn decorate [input]
>>  (when (not (nil? input)) (str "prefix:" input ":suffix")))
>> #'clojurewerkz.titanium.graph-**test/decorate
>>
>> => (decorate "1")
>> "prefix:1:suffix"
>>
>> => (decorate a)
>> "prefix:Unbound: #'clojurewerkz.titanium.graph-**test/a:suffix"
>>
>> so... fix?
>>  but more importantly does anyone need to add checks for
>> is-the-var-bound in their code where they checked for nil ?
>>
>> --
>> --
>> 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 your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscribe@**googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/**group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to 
>> clojure+unsubscribe@**googlegroups.com
>> .
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out
>> .
>>
>>
>>
> --
> --
> 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 your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>
  --
 --
 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
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups "Clojure

Re: testing for nil may not be enough

[Jim - FooBar();]

funny you should mention that!!! that is exactly what I meant by 'my 
fault'...I've come to realise that dynamic scope is almost evil, thus I 
go to great lengths to avoid it completely...in the rare cases where I 
do use it I always make sure it is bound to a init/default value :)


Jim


On 29/04/13 17:17, AtKaaZ wrote:
I'm thinking something like (def ^:dynamic *a*) where it would make 
more sense that it's unbound at first



On Mon, Apr 29, 2013 at 7:00 PM, Jim - FooBar(); > wrote:


I 've found that whenever I get a var-unbound exception it is
almost always my fault and my fault only...why would you do (def
a) anyway?

Jim



On 29/04/13 16:32, AtKaaZ wrote:

How do you guys handle the cases when the var is unbound? I
mean specifically in the cases where you just test if the var
is nil.

=> (def a)
#'clojurewerkz.titanium.graph-test/a

=> a
#

=> (nil? a)
false

=> (bound? a)
ClassCastException clojure.lang.Var$Unbound cannot be cast to
clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)

=> (bound? #'a)
false

ok imagine the following sample :))

=> (defn decorate [input]
 (when (not (nil? input)) (str "prefix:" input ":suffix")))
#'clojurewerkz.titanium.graph-test/decorate

=> (decorate "1")
"prefix:1:suffix"

=> (decorate a)
"prefix:Unbound: #'clojurewerkz.titanium.graph-test/a:suffix"

so... fix?
 but more importantly does anyone need to add checks for
is-the-var-bound in their code where they checked for nil ?

-- 
-- 
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 your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the
Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to clojure+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.



-- 
-- 
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 your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- You received this message because you are subscribed to the
Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.



--
--
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 your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
--
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/

Re: testing for nil may not be enough

[Gary Trakhman]

If you're passing the var itself, I don't see why you'd need a macro.  If
you want to check the namespace for a var matching an unquoted symbol, you
could do that in a macro.


On Mon, Apr 29, 2013 at 12:29 PM, AtKaaZ  wrote:

> Seems like a good idea to have the root binding be nil. How would you make
> it check for bound inside the function? do we need some kind of macro?
>
>
> On Mon, Apr 29, 2013 at 7:23 PM, Gary Trakhman wrote:
>
>> Why not make the root binding nil?  If your decorate function is supposed
>> to handle all vars, then they have to deal with the unbound case as that's
>> part of the contract of vars.
>>
>> If it's a generic thing, then maybe make a multimethod or protocol for it.
>>
>>
>> On Mon, Apr 29, 2013 at 12:17 PM, AtKaaZ  wrote:
>>
>>> I'm thinking something like (def ^:dynamic *a*) where it would make more
>>> sense that it's unbound at first
>>>
>>>
>>> On Mon, Apr 29, 2013 at 7:00 PM, Jim - FooBar(); 
>>> wrote:
>>>
 I 've found that whenever I get a var-unbound exception it is almost
 always my fault and my fault only...why would you do (def a) anyway?

 Jim



 On 29/04/13 16:32, AtKaaZ wrote:

> How do you guys handle the cases when the var is unbound? I mean
> specifically in the cases where you just test if the var is nil.
>
> => (def a)
> #'clojurewerkz.titanium.graph-**test/a
>
> => a
> #
>
> => (nil? a)
> false
>
> => (bound? a)
> ClassCastException clojure.lang.Var$Unbound cannot be cast to
> clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)
>
> => (bound? #'a)
> false
>
> ok imagine the following sample :))
>
> => (defn decorate [input]
>  (when (not (nil? input)) (str "prefix:" input ":suffix")))
> #'clojurewerkz.titanium.graph-**test/decorate
>
> => (decorate "1")
> "prefix:1:suffix"
>
> => (decorate a)
> "prefix:Unbound: #'clojurewerkz.titanium.graph-**test/a:suffix"
>
> so... fix?
>  but more importantly does anyone need to add checks for
> is-the-var-bound in their code where they checked for nil ?
>
> --
> --
> 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 your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>
 --
 --
 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
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscribe@**googlegroups.com
 For more options, visit this group at
 http://groups.google.com/**group/clojure?hl=en
 --- You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to 
 clojure+unsubscribe@**googlegroups.com
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_out
 .



>>>  --
>>> --
>>> 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
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>  --
>> --
>> 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 fr

Re: testing for nil may not be enough

[AtKaaZ]

Seems like a good idea to have the root binding be nil. How would you make
it check for bound inside the function? do we need some kind of macro?


On Mon, Apr 29, 2013 at 7:23 PM, Gary Trakhman wrote:

> Why not make the root binding nil?  If your decorate function is supposed
> to handle all vars, then they have to deal with the unbound case as that's
> part of the contract of vars.
>
> If it's a generic thing, then maybe make a multimethod or protocol for it.
>
>
> On Mon, Apr 29, 2013 at 12:17 PM, AtKaaZ  wrote:
>
>> I'm thinking something like (def ^:dynamic *a*) where it would make more
>> sense that it's unbound at first
>>
>>
>> On Mon, Apr 29, 2013 at 7:00 PM, Jim - FooBar(); wrote:
>>
>>> I 've found that whenever I get a var-unbound exception it is almost
>>> always my fault and my fault only...why would you do (def a) anyway?
>>>
>>> Jim
>>>
>>>
>>>
>>> On 29/04/13 16:32, AtKaaZ wrote:
>>>
 How do you guys handle the cases when the var is unbound? I mean
 specifically in the cases where you just test if the var is nil.

 => (def a)
 #'clojurewerkz.titanium.graph-**test/a

 => a
 #

 => (nil? a)
 false

 => (bound? a)
 ClassCastException clojure.lang.Var$Unbound cannot be cast to
 clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)

 => (bound? #'a)
 false

 ok imagine the following sample :))

 => (defn decorate [input]
  (when (not (nil? input)) (str "prefix:" input ":suffix")))
 #'clojurewerkz.titanium.graph-**test/decorate

 => (decorate "1")
 "prefix:1:suffix"

 => (decorate a)
 "prefix:Unbound: #'clojurewerkz.titanium.graph-**test/a:suffix"

 so... fix?
  but more importantly does anyone need to add checks for
 is-the-var-bound in their code where they checked for nil ?

 --
 --
 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
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscribe@**googlegroups.com
 For more options, visit this group at
 http://groups.google.com/**group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to 
 clojure+unsubscribe@**googlegroups.com
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_out
 .



>>> --
>>> --
>>> 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
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscribe@**googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/**group/clojure?hl=en
>>> --- You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to 
>>> clojure+unsubscribe@**googlegroups.com
>>> .
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>>
>>>
>>  --
>> --
>> 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
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> 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
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this

Re: testing for nil may not be enough

[Gary Trakhman]

Why not make the root binding nil?  If your decorate function is supposed
to handle all vars, then they have to deal with the unbound case as that's
part of the contract of vars.

If it's a generic thing, then maybe make a multimethod or protocol for it.


On Mon, Apr 29, 2013 at 12:17 PM, AtKaaZ  wrote:

> I'm thinking something like (def ^:dynamic *a*) where it would make more
> sense that it's unbound at first
>
>
> On Mon, Apr 29, 2013 at 7:00 PM, Jim - FooBar(); wrote:
>
>> I 've found that whenever I get a var-unbound exception it is almost
>> always my fault and my fault only...why would you do (def a) anyway?
>>
>> Jim
>>
>>
>>
>> On 29/04/13 16:32, AtKaaZ wrote:
>>
>>> How do you guys handle the cases when the var is unbound? I mean
>>> specifically in the cases where you just test if the var is nil.
>>>
>>> => (def a)
>>> #'clojurewerkz.titanium.graph-**test/a
>>>
>>> => a
>>> #
>>>
>>> => (nil? a)
>>> false
>>>
>>> => (bound? a)
>>> ClassCastException clojure.lang.Var$Unbound cannot be cast to
>>> clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)
>>>
>>> => (bound? #'a)
>>> false
>>>
>>> ok imagine the following sample :))
>>>
>>> => (defn decorate [input]
>>>  (when (not (nil? input)) (str "prefix:" input ":suffix")))
>>> #'clojurewerkz.titanium.graph-**test/decorate
>>>
>>> => (decorate "1")
>>> "prefix:1:suffix"
>>>
>>> => (decorate a)
>>> "prefix:Unbound: #'clojurewerkz.titanium.graph-**test/a:suffix"
>>>
>>> so... fix?
>>>  but more importantly does anyone need to add checks for
>>> is-the-var-bound in their code where they checked for nil ?
>>>
>>> --
>>> --
>>> 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
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscribe@**googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/**group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to 
>>> clojure+unsubscribe@**googlegroups.com
>>> .
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>>
>>>
>> --
>> --
>> 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
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscribe@**googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/**group/clojure?hl=en
>> --- You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to 
>> clojure+unsubscribe@**googlegroups.com
>> .
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out
>> .
>>
>>
>>
>  --
> --
> 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
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: testing for nil may not be enough

[AtKaaZ]

I'm thinking something like (def ^:dynamic *a*) where it would make more
sense that it's unbound at first


On Mon, Apr 29, 2013 at 7:00 PM, Jim - FooBar(); wrote:

> I 've found that whenever I get a var-unbound exception it is almost
> always my fault and my fault only...why would you do (def a) anyway?
>
> Jim
>
>
>
> On 29/04/13 16:32, AtKaaZ wrote:
>
>> How do you guys handle the cases when the var is unbound? I mean
>> specifically in the cases where you just test if the var is nil.
>>
>> => (def a)
>> #'clojurewerkz.titanium.graph-**test/a
>>
>> => a
>> #
>>
>> => (nil? a)
>> false
>>
>> => (bound? a)
>> ClassCastException clojure.lang.Var$Unbound cannot be cast to
>> clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)
>>
>> => (bound? #'a)
>> false
>>
>> ok imagine the following sample :))
>>
>> => (defn decorate [input]
>>  (when (not (nil? input)) (str "prefix:" input ":suffix")))
>> #'clojurewerkz.titanium.graph-**test/decorate
>>
>> => (decorate "1")
>> "prefix:1:suffix"
>>
>> => (decorate a)
>> "prefix:Unbound: #'clojurewerkz.titanium.graph-**test/a:suffix"
>>
>> so... fix?
>>  but more importantly does anyone need to add checks for is-the-var-bound
>> in their code where they checked for nil ?
>>
>> --
>> --
>> 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
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscribe@**googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/**group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to 
>> clojure+unsubscribe@**googlegroups.com
>> .
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out
>> .
>>
>>
>>
> --
> --
> 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
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: testing for nil may not be enough

[Jim - FooBar();]

I 've found that whenever I get a var-unbound exception it is almost 
always my fault and my fault only...why would you do (def a) anyway?


Jim


On 29/04/13 16:32, AtKaaZ wrote:
How do you guys handle the cases when the var is unbound? I mean 
specifically in the cases where you just test if the var is nil.


=> (def a)
#'clojurewerkz.titanium.graph-test/a

=> a
#

=> (nil? a)
false

=> (bound? a)
ClassCastException clojure.lang.Var$Unbound cannot be cast to 
clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)


=> (bound? #'a)
false

ok imagine the following sample :))

=> (defn decorate [input]
 (when (not (nil? input)) (str "prefix:" input ":suffix")))
#'clojurewerkz.titanium.graph-test/decorate

=> (decorate "1")
"prefix:1:suffix"

=> (decorate a)
"prefix:Unbound: #'clojurewerkz.titanium.graph-test/a:suffix"

so... fix?
 but more importantly does anyone need to add checks for 
is-the-var-bound in their code where they checked for nil ?


--
--
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 your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
--
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

testing for nil may not be enough

[AtKaaZ]

How do you guys handle the cases when the var is unbound? I mean
specifically in the cases where you just test if the var is nil.

=> (def a)
#'clojurewerkz.titanium.graph-test/a

=> a
#

=> (nil? a)
false

=> (bound? a)
ClassCastException clojure.lang.Var$Unbound cannot be cast to
clojure.lang.Var  clojure.core/bound?/fn--4837 (core.clj:4954)

=> (bound? #'a)
false

ok imagine the following sample :))

=> (defn decorate [input]
 (when (not (nil? input)) (str "prefix:" input ":suffix")))
#'clojurewerkz.titanium.graph-test/decorate

=> (decorate "1")
"prefix:1:suffix"

=> (decorate a)
"prefix:Unbound: #'clojurewerkz.titanium.graph-test/a:suffix"

so... fix?
 but more importantly does anyone need to add checks for is-the-var-bound
in their code where they checked for nil ?

-- 
-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.