On Jan 5, 8:55 am, Toralf Wittner <toralf.witt...@gmail.com> wrote:
> Hmm. I confess I'm a bit puzzled by this whole boolean thing. I like theYou can't simply look at one facet of a language in isolation. nil,
> Scheme way of having #t for true and #f for false. Since in Clojure nil
> is used to represent false and null it seems to me that treating nil as
> a boolean is only logical ;-) So expecting (new Boolean nil) to resolve
> to the boolean overload follows directly from nil denoting boolean
> falsity. On the other hand the need to typecast nil to boolean looks
> weird to me. I wonder what's the advantage of having nil meaning false
> and null? Wouldn't it be better to copy Scheme and having a dedicated
> false value, e.g. :f which leaves nil for null?
Java null, conditionals and sequences all interact.
Please read this message, if you haven't yet:
Scheme #t is almost completely meaningless, as Scheme conditionals
I realize that people coming from Scheme might not see the value, but
I recommend everyone try to understand why Clojure is the way it is
I am happy to continue to explain how Clojure works and why, and am
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.