On Feb 17, 10:52 pm, Mark Engelberg 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 sequence to
> reuse with
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 sequence to
reuse within my code, would one of these be preferable?:
(def empty
On Mon, Feb 16, 2009 at 12:05 PM, Perry Trolard 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 do full por
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 compati
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
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 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 e
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.
--~--~-~--~~~
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 sacrif
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
>
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 enforced on 3rd party seqs"
In "(doc rest)"
"m
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, 2:22 pm, Mibu 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, increments state the itera
On Feb 15, 12:18 pm, Rich Hickey 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 Sequence/ISeq dichotomy wa
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" incompatibilit
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.
On Feb 16, 12:06 pm, Jeffrey Straszheim
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.
>
Agreed. I'm afraid my
> 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 Googl
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 wrote:
>
> Regarding Programming Clojur
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
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,
vi
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
> 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 Mon, Feb 16, 2009 at 10:10 AM, Mark Volkmann
wrote:
>
> 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 no
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, g
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
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 wrote:
>
> I'm all fo
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 e
On Feb 16, 1:44 pm, Rich Hickey 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
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
(http://github.com/cgrand/enliv
On Feb 15, 5:18 pm, 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,
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
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.
--~--~-~--~~~---~--~---
On Sun, Feb 15, 2009 at 6:44 PM, Rich Hickey 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 the call to lazy-co
On Feb 15, 11:46 pm, Feng 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
>
> see at
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, I
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
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
compil
On Feb 15, 6:34 pm, "James G. Sack (jim)" 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
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" an
How about next-seq or rest-seq?
On Sun, Feb 15, 2009 at 3:34 PM, James G. Sack (jim) 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
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.
O
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
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.
Cheer
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 ex
On Sun, Feb 15, 2009 at 5:03 PM, Stephen C. Gilardi 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
classpath. I've
On Feb 15, 2009, at 5:01 PM, Mark Engelberg wrote:
>
> On Sun, Feb 15, 2009 at 1:44 PM, Chouser 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 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]
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 tes
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 how to use it:
BTW, my library modules in clojure.
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 Sun, Feb 15, 2009 at 1:44 PM, Chouser 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))
> v)))
You know, there is an empty? predicate. Why not wr
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: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 Sun, Feb 15, 2009 at 4:30 PM, Stephen C. Gilardi 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 tried
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 Feb 15, 4:30 pm, "Stephen C. Gilardi" 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 code and p
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
Descript
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 foll
"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 Goog
On Feb 15, 2:48 pm, Vincent Foley wrote:
> Hello Rich,
>
> 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 OC
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 repres
I agree with the op. While the language is still relatively young
please break things so they sit better in the long term. Accurate and
descriptive names are totally valueable, and I'm pretty handy with
find/replace on the editor anyway :p
Aaron
On Feb 15, 2009, at 10:43 AM, CuppoJava
w
Hello Rich,
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 all-but-the-first elements, so
it woul
I also favor the optimal names. We're the pioneers in using clojure,
so we should expect a few arrows. Hopefully, the number of clojure
users in the future will be an order of magnitude greater than where
we are now. For us to take short term hit, we can save a large number
of people a lot of c
One thing I did find confusing though was in regards to the doc.
Is there a way to more clearly differentiate between a seq and a
sequence? Up until now, I've always thought of "seq" as just being
shorthand for "sequence" which isn't the case apparently.
--~--~-~--~~~--
I'm also in support of the optimal names. Clojure is not too widely
used in production code yet, and it would be a shame to start
compromising design decisions for backwards compatibility already.
This is actually one of my (and many other people's) favorite parts
about Clojure, the beauty of Lis
I would vote that you change to the optimum names, but work with Stu
Halloway to ensure that either his book gets updated before it is
printed, or there is a "cheat sheet" on the Clojure site to translate
from his book to any new names.
On Sun, Feb 15, 2009 at 9:18 AM, Rich Hickey wrote:
>
> I'm
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.
Now comes the hard part - names and change. The essence of the fully
lazy seqs is that they will not consume any resou
69 matches
Mail list logo
