Bug: (list? (cons 4 '(1 2 3))) returns false!
Handkea fumosa
true
user=> (list? (cons 4 '(1 2 3)))
false
Stephen C. Gilardi
user=> (doc cons)
-------------------------
clojure.core/cons
([x seq])
Returns a new seq where x is the first element and seq is
the rest.
nil
user=> (cons 4 '(1 2 3))
(4 1 2 3)
user=> (seq? (cons 4 '(1 2 3)))
true
user=> (first (cons 4 '(1 2 3)))
4
user=> (rest (cons 4 '(1 2 3)))
(1 2 3)
user=> (list? (rest (cons 4 '(1 2 3))))
true
user=>
cons is acting according to its documentation.
Some of the roles played by lists in other Lisps are played by seqs in
Clojure. Also, in Clojure a list is not a linked list of cons cells.
Roughly speaking, a Clojure list is a linked list of lists:
user=> (list? (rest (rest (rest '(1 2 3 4 5 6 7)))))
true
--Steve
Handkea fumosa
> Some of the roles played by lists in other Lisps are played by seqs in
> Clojure. Also, in Clojure a list is not a linked list of cons cells.
> Roughly speaking, a Clojure list is a linked list of lists:
>
> user=> (list? (rest (rest (rest '(1 2 3 4 5 6 7)))))
> true
(defn fixed-list? [obj]
(and (sequential? obj) (not (vector? obj))))
This gives me the desired semantics: it's a list if it's a ()
collection rather than a [], {}, or #{} collection.
Richard Newman
>
> It's list? that isn't.
That's not strictly true:
user=> (doc list?)
-------------------------
clojure.core/list?
([x])
Returns true if x implements IPersistentList
nil
user=> (cons 5 '(1 2 3))
(5 1 2 3)
user=> (ancestors (type *1))
#{clojure.lang.IMeta java.lang.Iterable java.util.Collection
clojure.lang.ISeq java.util.List clojure.lang.Seqable clojure.lang.Obj
clojure.lang.IObj java.lang.Object clojure.lang.Sequential
clojure.lang.IPersistentCollection clojure.lang.Streamable
clojure.lang.ASeq}
... the result of cons does not implement IPersistentList, so list? is
acting according to its documentation.
Is there a reason why you are testing for listiness rather than for
some other property, like Sequential? It's generally considered good
form in Clojure to program against the native abstractions (such as
sequences) rather than particular concrete types.
-R
Meikel Brandmeyer
Am 28.06.2009 um 07:45 schrieb Handkea fumosa:
> It's list? that isn't.
No. list? is not broken. Every list is a seq, but not
every seq is a list.
Consider: (cons 0 (iterate inc 1))
This is no list! It's a sequence. Why should list?
return true?
In Clojure there is no such thing as a cons cell.
There is only an abstraction of a cons cell where
the second part must implement again the
sequence abstraction.
If you need a cons cell, use a two-element vector
or a two-element list.
Please: If you want to program CL in Clojure...
Don't do it. Clojure is different. Claiming parts
of Clojure are broken because they don't behave
like something is else doesn't make sense and
hence leads nowhere.
If you want to try Clojure, make up your mind
and learn Clojure's environment. Thinking
Python/Perl/CL/whatever in Clojure will only
hinder your progress with Clojure.
If you find a bug, where a function violates its
documented contract, please report it.
Sincerely
Meikel
PS: This is no Clojure specific issue. Trying to
learn Python and program it like one would in
Clojure, also doesn't work...
Rich Hickey
> Hi,
>
> Am 28.06.2009 um 07:45 schrieb Handkea fumosa:
>
>> It's list? that isn't.
>
> No. list? is not broken. Every list is a seq, but not
> every seq is a list.
>
> Consider: (cons 0 (iterate inc 1))
>
> This is no list! It's a sequence. Why should list?
> return true?
>
> In Clojure there is no such thing as a cons cell.
> There is only an abstraction of a cons cell where
> the second part must implement again the
> sequence abstraction.
>
> If you need a cons cell, use a two-element vector
> or a two-element list.
>
This is overstating things. There certainly is a cons cell, it's
called Cons, and cons produces one. It differs from CL cons cell in
not being an arbitrary pair (i.e. the rest must be a sequence or nil).
> Please: If you want to program CL in Clojure...
> Don't do it. Clojure is different. Claiming parts
> of Clojure are broken because they don't behave
> like something is else doesn't make sense and
> hence leads nowhere.
>
This too is a bit much. The OP wasn't trying to use cons as a pair,
just expecting list? to be more similar to listp. It's a reasonable
mistake, please be gentle.
Because Clojure supports a seq abstraction, there is heterogeneity in
the implementations. In fact there are two cons-cell-like data
structures:
user=> (class (cons 4 '(1 2 3)))
clojure.lang.Cons
user=> (counted? (cons 4 '(1 2 3)))
false
user=> (class (conj '(1 2 3) 4))
clojure.lang.PersistentList
user=> (counted? (conj '(1 2 3) 4))
true
So, list? is more specific because seqs are more general. seq? is
probably what is desired.
cons onto an IPersistentList could be made to return another
IPersistentList, but currently doesn't.
Rich
Handkea fumosa
> >> cons is acting according to its documentation.
>
> > It's list? that isn't.
>
> That's not strictly true
> Is there a reason why you are testing for listiness rather than for
> some other property, like Sequential? It's generally considered good
> form in Clojure to program against the native abstractions (such as
> sequences) rather than particular concrete types.
differently from [] ones, in particular. I note that sequential?
returns true for vectors.
While it starts with inputs like '(foo bar (baz quux)) it takes those
apart and puts them back together again in various ways, sometimes
using cons to prepend an item. It also sometimes uses map, whose
return values also fail list?.
If you don't think list? should be true for all () collections, or at
least all finite ones, perhaps the core should contain a function that
is? We have set?, vector?, and map? for [], #{}, and {} collections
respectively that exactly distinguish them from others. But for ()
collections we only seem to have #(and (sequential? %) (not (vector?
%))).
Rich Hickey
Rich
Handkea fumosa
> This too is a bit much. The OP wasn't trying to use cons as a pair,
> just expecting list? to be more similar to listp. It's a reasonable
> mistake, please be gentle.
expect that there'd be a correspondence between (1 2 3), [1 2 3], #{1
2 3), {:one 1 :two 2 :three 3} and list?, vector?, set?, and map?
> Because Clojure supports a seq abstraction, there is heterogeneity in
> the implementations.
The major way in which a seq could fail to be list-like is if it were
infinite. Unfortunately there doesn't seem at present to be an
efficient infinite? predicate. (Actually, for custom uses of lazy-seq
that might run afoul of the so-called halting problem. Perhaps a
possibly-infinite? predicate which could return true for the results
of lazy-seq, repeatedly, iterate, and their ilk, false for the results
of take, list, and the like, and the same value as for the input seq
in the case of map, cons, and the like; for for, it would be true if
any of the input colls was possibly-infinite? and for interleave,
false if any were not. Then a test for "listiness" could check for
sequential?, not vector?, and not possibly-infinite?.
Implementing the above would require adding an isPossiblyInfinite
method to some of the clojure.lang interfaces and classes, and in some
cases a field for this to return, with code to compute its value in
the constructor.
> So, list? is more specific because seqs are more general. seq? is
> probably what is desired.
threw at it, including a quoted list, a cons, and a map output.
Is it equivalent to "is a () coll"?
Richard Newman
>>
>> That's not strictly true
>
> Are you calling me a liar?
Not a liar; just misinformed, as I hope I demonstrated by citing the
docs. I don't see any value in continuing this thread of the
discussion, but I wanted to clear that up.
> If you don't think list? should be true for all () collections, or at
> least all finite ones, perhaps the core should contain a function that
> is? We have set?, vector?, and map? for [], #{}, and {} collections
> respectively that exactly distinguish them from others. But for ()
> collections we only seem to have #(and (sequential? %) (not (vector?
> %))).
As Rich pointed out, seq? is what you want.
user=> (seq? [])
false
user=> (cons 5 [])
(5)
user=> (seq? *1)
true
Handkea fumosa
> >>> It's list? that isn't.
>
> >> That's not strictly true
>
> > Are you calling me a liar?
>
> Not a liar; just misinformed