Rich,
My apologies that what I have said about nil punning came across
as criticism directed at you. That was not intentional. I have
the highest respect for your design work. You're doing an amazing
job and I continue to learn from you.
I understand the lazy vs empty issue and I think you made a good
tradeoff. I'm just bemoaning the fact that nil-punning is really
vital in keeping data-type issues out of my lisp life and that
won't work in Clojure.
Ultimately this is cured by deep learning of the language semantics.
I still have a way to go.
Tim Daly
Literate Software
On Fri, 2011-10-21 at 17:03 -0400, Rich Hickey wrote:
> This message is not specifically in reply to Tim, but to the thread in
> general.
>
> It can be very difficult to enumerate (or even remember :) all of the
> contending tradeoffs around something like Clojure's nil handling.
>
> The is no doubt nil punning is a form of complecting. But you don't
> completely remove all issues merely by using empty collections and empty?,
> you need something like Maybe and then things get really gross (IMO, for a
> concise dynamic language).
>
> I like nil punning, and find it to be a great source of generalization and
> reduction of edge cases overall, while admitting the introduction of edges in
> specific cases. I am with Tim in preferring CL's approach over Scheme's, and
> will admit to personal bias and a certain comfort level with its (albeit
> small) complexity.
>
> However, it couldn't be retained everywhere. In particular, two things
> conspire against it. One is laziness. You can't actually return nil on rest
> without forcing ahead. Clojure old timers will remember when this was
> different and the problems it caused. I disagree with Mark that this is
> remains significantly complected, nil is not an empty collection, nil is
> nothing.
>
> Second, unlike in CL where the only 'type' of empty collection is nil and
> cons is not polymorphic, in Clojure conj *is* polymorphic and there can only
> be one data type created for (conj nil ...), thus we have [], {}, and empty?.
> Were data structures to collapse to nil on emptying, they could not be
> refilled and retain type.
>
> At this point, this discussion is academic as nothing could possibly change
> in this area.
>
> The easiest way to think about is is that nil means nothing, and an empty
> collection is not nothing. The sequence functions are functions of collection
> to (possibly lazy) collection, and seq/next is forcing out of laziness. No
> one is stopping you from using rest and empty?, nor your friend from using
> next and conditionals. Peace!
>
> Rich
>
> On Oct 21, 2011, at 4:25 PM, daly wrote:
>
> > On Fri, 2011-10-21 at 15:41 -0400, David Nolen wrote:
> >> Just because we have dynamic types does not give us the freedom to not
> >> consider them.
> >
> > If all of these dynamics types and all of the tests "respected nil"
> > in its many meanings then
> > (when s ...,
> > (when (seq s)...,
> > (when (empty? s)...,
> > would not be an issue. (when s...) would "just work".
> >
> >>
> >>
> >> Clearly express a consideration about the types at play.
> >
> > Clojure was supposed to transparently substitute things like sequences
> > and vectors everywhere that lisp used lists. That would be true if nil
> > was respected but is not true now and this complicates the code without
> > apparent benefit, in my opinion.
> >
> > In lisp you can ask what the type is (e.g. by calling consp, vectorp,
> > etc) but these type-specific predicates are relatively rarely used.
> > In fact, when they are used then you are struggling with data-level
> > issue that could probably be abstracted away (e.g. a code smell).
> >
> > Clojure is a great language but the nil handling is, in my opinion,
> > a design flaw. It forces the introduction of (empty?...) and an
> > awareness of the data types into view unnecessarily.
> >
> > Tim Daly
> > Literate Software
> >
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to [email protected]
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > [email protected]
> > 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 post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
