On Feb 17, 10:52 pm, Mark Engelberg mark.engelb...@gmail.com wrote:
Since there is no canonical empty sequence, this makes me wonder
whether one particular empty sequence might have some kind of
performance benefit over another.
For example, if I were going to give a name to one empty
On Feb 16, 2009, at 20:23, Rich Hickey wrote:
It seems the Sequence/ISeq dichotomy was a sticking point for many.
After some tweaking, I've been able to get rid of Sequence entirely,
SVN 1284+ in lazy branch. This is source compatible with 1282 (first/
rest/next), except that sequence? no
On Feb 17, 2009, at 4:40 AM, Konrad Hinsen wrote:
On Feb 16, 2009, at 20:23, Rich Hickey wrote:
It seems the Sequence/ISeq dichotomy was a sticking point for many.
After some tweaking, I've been able to get rid of Sequence entirely,
SVN 1284+ in lazy branch. This is source compatible with
On Mon, Feb 16, 2009 at 12:05 PM, Perry Trolard trol...@gmail.com wrote:
I agree with the majority of posters that the breaking changes in the
service of optimal names is the right way to go.
I found the explanation recipe for porting at clojure.org/lazier
clear easy to follow. I didn't
On Feb 16, 2009, at 3:44, Rich Hickey wrote:
There will need to be good descriptions of these, but the similarity
is more in names than anything else - seqs are what they always were -
cursors, and sequences are just collections.
That distinction is quite clear, the problem is indeed just in
On Feb 15, 5:18 pm, Rich Hickey richhic...@gmail.com wrote:
The second option is to choose the best possible names, and deal with
some short term pain in porting and confusion. I think the best names
are:
;item
(first x)
;collection of remaining items, possibly empty
(rest x)
;seq on
Hi,
Rich Hickey a écrit :
I am looking for feedback from people willing to read and understand
the linked-to documentation and the fully lazy model, and especially
from those trying the lazy branch code and porting some of your own.
I just ported Enlive
I'm all for breaking bad habits and names and I love it that you give
good design considerations precedence over heritage, but here I think
using the first/rest/next combo is confusing, and will continue to be
confusing in the long-term.
rest is expected to be a sequence by Lispers, and next is
I'd vote for the breaking changes. We don't have so much code written that
it cannot be fixed.
However, this depends on the book in production. Having _Programming
Clojure_ come out with incompatible code would be a big blow, I think.
On Mon, Feb 16, 2009 at 9:22 AM, Mibu mibu.cloj...@gmail.com
While I'm fairly new to clojure, and with apologies to Stewart
Halloway for complicating his job on the book, (which is excellent so
far, btw) I think it would be worth while to chose the optimum naming
convention, if it can be done fast enough to update the book.
Consider how long some warts had
If we're going to be making name changes that break code anyway, I'll
make another appeal to make the function naming convention more
consistent. Most multi-word function names have a hyphen between the
words, but the following do not.
butlast, doall, dorun, doseq, dosync, dotimes, doto, fnseq,
On Mon, Feb 16, 2009 at 10:10 AM, Mark Volkmann
r.mark.volkm...@gmail.comwrote:
If we're going to be making name changes that break code anyway, I'll
make another appeal to make the function naming convention more
consistent. Most multi-word function names have a hyphen between the
words,
butlast, doall, dorun, doseq, dosync, dotimes, doto, fnseq, gensym,
macroexpand, macroexpand-1, mapcat, nthrest
-1
Because they are similar to other Lisps I assume. The same reason for
println vs print-line. Changing these are a bad idea in IMHO.
Breaking the meaning of rest with Common
On Feb 16, 2009, at 11:25 AM, David Nolen wrote:
butlast, doall, dorun, doseq, dosync, dotimes, doto, fnseq, gensym,
macroexpand, macroexpand-1, mapcat, nthrest
-1
Because they are similar to other Lisps I assume. The same reason
for println vs print-line. Changing these are a bad
Regarding Programming Clojure:
I think that placing the burden of book vs actual incompatibility
upon Rich is misplaced. If anything, pressure from the Clojure
community should be placed on the Pragmatic Programmers to allow
Stuart to do the right thing regarding when the book is released,
viz.,
I agree with the majority of posters that the breaking changes in the
service of optimal names is the right way to go.
I found the explanation recipe for porting at clojure.org/lazier
clear easy to follow. I didn't do full ports of any projects, but I
did some selective porting found it to be
You're right, of course, but in life compromises must happen. If Rich
proceeds *with no regard* for Pragmatic's needs, they have a recourse which
is simply no Clojure book. Or a Clojure book that has broken examples.
On Mon, Feb 16, 2009 at 11:34 AM, wlr geeked...@gmail.com wrote:
Regarding
cursor moving to the next item rather than the abstracted rest of
the coll (where you think about a cursor).
Correction: where you *don't* think about a cursor...
Perry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
On Feb 16, 12:06 pm, Jeffrey Straszheim straszheimjeff...@gmail.com
wrote:
You're right, of course, but in life compromises must happen. If Rich
proceeds *with no regard* for Pragmatic's needs, they have a recourse which
is simply no Clojure book. Or a Clojure book that has broken examples.
Thanks Rich! :-)
, 2009, at 11:25 AM, David Nolen wrote:
butlast, doall, dorun, doseq, dosync, dotimes, doto, fnseq, gensym,
macroexpand, macroexpand-1, mapcat, nthrest
-1
Because they are similar to other Lisps I assume. The same reason
for println vs print-line. Changing these are
I agree with Walt, and there is no need to pressure the Prags, we are
on it! :-)
That said, it would be *very* helpful to me if we could get the
lazyness thing settled this week...
Stuart
Regarding Programming Clojure:
I think that placing the burden of book vs actual incompatibility
On Feb 15, 12:18 pm, Rich Hickey richhic...@gmail.com wrote:
I'm pretty much finished with the fully-lazy implementation and am
happy so far with the results. I think this will be an important
addition to Clojure and am planning to add it.
Thanks all for the feedback!
It seems the
On Feb 16, 2:22 pm, Mibu mibu.cloj...@gmail.com wrote:
rest is expected to be a sequence by Lispers, and next is expected to
be an item by Java-ers.
I actually think next is pretty close to the next method on Java
iterators. In java.util.Iterator, the next method evaluates the next
item,
We are in production and we fully agree, this thing should be settled
now.
In fact if it's done within 10 days, that would fit our current plans.
For reasons out of our control we have been postponing an update to
prod., we still
have a window to get this change out.
It's feasible to do the code
On Feb 16, 2009, at 3:56 PM, Stephen C. Gilardi wrote:
On Feb 16, 2009, at 2:23 PM, Rich Hickey wrote:
New docs here:
http://clojure.org/lazy
In the html doc:
rest... returns a possibly empty seq, never nil
then later
never returns nil
- currently not
How about e-rest, for the empty set returning version?
Perry Trolard wrote:
If it's the case that rest will almost exclusively appear in the
context of constructing lazy-seqs
(lazy-seq
(cons [something] (rest [something]))
next will appear all over, it makes sense to me to
Browsing the source code for LazySeq, I noticed that isEmpty is
implemented as follows:
public boolean isEmpty() {
return count() == 0;
}
Since count realizes the whole list, this seems like a bad way to test
for empty on a lazy sequence.
On Feb 16, 2009, at 5:35 PM, Mark Engelberg wrote:
Browsing the source code for LazySeq, I noticed that isEmpty is
implemented as follows:
public boolean isEmpty() {
return count() == 0;
}
Since count realizes the whole list, this seems like a bad way to test
for empty on
I definitely support your second option; first / rest / next. In my
mind, rest means collection of remaining items and should return a
collection, and next will also do exactly what I would expect it to
do. Clojure is sufficiently different from Common Lisp already that
breaking the compatibilty
On 15.02.2009, at 20:48, Vincent Foley wrote:
I'll play around with the lazy branch this week, and this is just a
name suggestion: what do you think of first/tail/rest where (rest s)
== (seq (tail s))? tail is already used in other functional languages
such as Haskell and OCaml to represent
It would also break the compatibility of rest with Common Lisp's
This is of mild concern to me, but I think if there was a prominent
warning on clojure.org, I could get over it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
On Feb 15, 2009, at 12:18 PM, Rich Hickey wrote:
I am looking for feedback from people willing to read and understand
the linked-to documentation and the fully lazy model, and especially
from those trying the lazy branch code and porting some of your own.
I'm trying svn rev 1282 with the
On Feb 15, 2009, at 4:30 PM, Stephen C. Gilardi wrote:
- This seems like an opportunity for me to use a Java debugger with
Clojure for the first time. Has anyone written about using JSwat or
another debugger with Clojure?
:-) clojure.org Getting Started page.
--Steve
smime.p7s
On Feb 15, 4:30 pm, Stephen C. Gilardi squee...@mac.com wrote:
On Feb 15, 2009, at 12:18 PM, Rich Hickey wrote:
I am looking for feedback from people willing to read and understand
the linked-to documentation and the fully lazy model, and especially
from those trying the lazy branch
Here's an example of what I think will be the worst kind of breakage
resulting from changing the meaning of rest from
seq-on-the-next-item-if-any-else-nil to
possibly-empty-collection-of-the-remaining-items:
(defn my-interpose [x coll]
(loop [v [x] coll coll]
(if coll
(recur (- v
On Sun, Feb 15, 2009 at 4:30 PM, Stephen C. Gilardi squee...@mac.com wrote:
I'm trying svn rev 1282 with the following test (which depends on javadb,
(derby)):
user= (use 'clojure.contrib.sql.test)
nil
user= (db-write)
It hangs there. This works on the trunk.
I just
On Feb 15, 2009, at 4:40 PM, Rich Hickey wrote:
Are you burning cycles while hung, or just blocked?
One core is pinned.
--Steve
smime.p7s
Description: S/MIME cryptographic signature
On 15.02.2009, at 18:18, Rich Hickey wrote:
I've been working on this for a few months, in lieu of more
interesting things, because I knew it would be a breaking change and
we're trying to get the biggest of those behind us. I appreciate any
effort you spend in trying to provide informed
On Feb 15, 2009, at 4:52 PM, Chouser wrote:
I just tried this on 1282 lazy branch with assert-if-lazy-seq, and I
get no exception and no hang:
user= (time (db-write))
Elapsed time: 802.020886 msecs
I wonder what's different?
Based on it working for you, the current theory I'm working to
On Feb 15, 2009, at 5:03 PM, Stephen C. Gilardi wrote:
Based on it working for you, the current theory I'm working to
verify is that this was caused by a clojure-contrib.jar compiled
with trunk interacting with a clojure.jar from lazy 1282.
I've confirmed this. Thanks for the help. The
On Feb 15, 2009, at 4:44 PM, Chouser wrote:
Here's an example of what I think will be the worst kind of breakage
resulting from changing the meaning of rest from
seq-on-the-next-item-if-any-else-nil to
possibly-empty-collection-of-the-remaining-items:
(defn my-interpose [x coll]
(loop
On Feb 15, 2009, at 5:01 PM, Mark Engelberg wrote:
On Sun, Feb 15, 2009 at 1:44 PM, Chouser chou...@gmail.com wrote:
(defn my-interpose [x coll]
(loop [v [x] coll coll]
(if (seq coll) ; Don't assume coll is a seq-or-nil
(recur (- v (conj (first coll)) (conj x)) (rest coll))
On Sun, Feb 15, 2009 at 5:03 PM, Stephen C. Gilardi squee...@mac.com wrote:
Should we branch contrib and do the fixups on a lazy branch? Chouser, have
you already fixed it enough to compile with clojure contrib's build.xml?
I don't ever compile clojure-contrib, I just put its src dir in my
On Feb 15, 2009, at 5:09 PM, Konrad Hinsen wrote:
On 15.02.2009, at 23:00, Konrad Hinsen wrote:
For those who want to play with this without keeping two versions of
their source code files, I have added a new macro lazy-and-standard-
branch to clojure.contrib.macros. Here is an example of
I prefer first/rest/next.
Because of where the book is in the production cycle, it will be
difficult for me to change the prose. But if this gets decided (and
clojure-contrib updated) in the next week or two I think I can get the
book printed with the changes incorporated throughout.
Rich Hickey wrote:
..
The second option is to choose the best possible names, and deal with
some short term pain in porting and confusion. I think the best names
are:
;item
(first x)
;collection of remaining items, possibly empty
(rest x)
;seq on next item, or nil if none
(next x)
At the risk of over-complicating things, perhaps there should be a
macro/function to require a specific version of Clojure? In this
way, a script written for the new naming could prevent itself from
executing incorrectly using the old naming. Something like Python's
from future concept.
On
How about next-seq or rest-seq?
On Sun, Feb 15, 2009 at 3:34 PM, James G. Sack (jim) jgs...@san.rr.com wrote:
Rich Hickey wrote:
..
The second option is to choose the best possible names, and deal with
some short term pain in porting and confusion. I think the best names
are:
;item
While it's not the most important issue, I agree with CuppoJava about
Sequence vs Seq, while we're talking about names. This pair of
terms seems sort of arbitrary, and will probably cause a little
semantic pain and confusion to newcomers in the future. Is there a
better term than Sequence and Seq
On Feb 15, 6:34 pm, James G. Sack (jim) jgs...@san.rr.com wrote:
Rich Hickey wrote:
..
The second option is to choose the best possible names, and deal with
some short term pain in porting and confusion. I think the best names
are:
;item
(first x)
;collection of remaining items,
My thoughts so far:
1. It always troubled me that filter, when written in the most
natural way, had a hang on to the head problem when skipping over
large numbers of items. I think this is something worth solving, and
I'm glad that while developing the lazier branch, you came up with a
On Feb 15, 2009, at 8:22 PM, Mark Engelberg wrote:
My thoughts so far:
4. The new model is definitely more complicated to understand than
the previous model. There was already a certain degree of mental
overlap between collections and the seq interface. Now, there is also
the subtle
I tried to migrate swank-clojure to lazy branch rev1282. Here are
steps I did.
1) search and replace rest to next
2) search and replace seq? to sequence?
3) change lazy-cons to lazy-seq following the recipe
4) fixed if LazySeq exceptions
see attached diff at the end.
Code loads fine. However,
On Feb 15, 11:46 pm, Feng hou...@gmail.com wrote:
I tried to migrate swank-clojure to lazy branch rev1282. Here are
steps I did.
1) search and replace rest to next
2) search and replace seq? to sequence?
3) change lazy-cons to lazy-seq following the recipe
4) fixed if LazySeq exceptions
On Sun, Feb 15, 2009 at 6:44 PM, Rich Hickey richhic...@gmail.com wrote:
I realize you are focused on filter, but that point of the fully lazy
branch is full laziness, which would not fall out of what you
describe. lazy-cons requires the lazy sequence function do all the
work that precedes
At first I found this kind of confusing, but after reading Chouser's
article and the help. It makes a lot of sense. I found it easiest to
understand when I thought about it as two pairs of related names. The
first/rest pair and the seq/more pair.
56 matches
Mail list logo
