On Feb 24, 9:30 pm, Stuart Halloway <stuart.hallo...@gmail.com> wrote:
> I am wrestling the sequences chapter of the book into conformance with
> the new laziness, and I am finding it tricky to infer accurate
> definitions of the words sequence, seq (noun), seq (function), and
> ISeq from the variety of extant documentation, code, email chats, and
> IRC logs. I would appreciate comments and corrections to the following
> statements.
>
> (1) The book currently claims that "sequence" and "seq" are synonyms.
> This is consistent withhttp://clojure.org/sequences, but not with
> recent threads here. Is it more accurate to say that a sequence is a
> seq-able collection?
>
> (2) Is it correct to say that seq (noun) and ISeq are synonyms? I take
> this fromhttp://clojure.org/lazy:"seqs can be empty * always an ISeq"
>
Here's how I think about it:
A sequence is a logical collection of items accessible in order, with
linear time access to the nth item (in contrast with vectors, which
are also sequential but not sequences). It might be empty.
An ISeq is a node in a singly-linked chain forming a sequence. Often
you can and do think of the ISeq as representing the sequence itself.
This is the big difference between Lisp lists and typical List
collection classes, where a single entity encapsulates the chain. In
Lisp we can grab any piece of the chain and treat the chain from there
on as its own "collection". In reality, all we ever have a handle on
is a link/node.
All sequences are represented by (chains of) (possibly lazy) seqs, of
type ISeq. So yes, sequence/seq(noun)/ISeq are technically synonyms,
but [1]
seq? tests for ISeq
seq, the verb/fn, returns a seq on the first item (of many types of
collections), or nothing (nil) if there isn't a first item. Also, if
the thing passed to seq was a lazy-seq, it will be forced, and in that
case seq will not return the same ISeq it was passed. Note by forced I
don't mean the entire chain is realized, only that the node is. The
thing seq returns is a fixed-point.
user=> (def x (lazy-seq [1]))
#'user/x
user=> (identical? x (seq x))
false
user=> (identical? (seq x) (seq (seq x)))
true
user=> x
nil is not a seq, nor a sequence, i.e. nil is no more a seq[uence]
than it is a vector or a string. It is nothing.
[1] In practice, a sequence fn (like map et al) may return an empty
sequence, while seq/next will instead return a (forced) thing with a
first, or nil, and I'd use the terms sequence for the former and seq
for the latter.
I'm sure the doc strings could use an audit for consistency in this.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
