In fact, (doall (take (count t) t)) actually realises t completely. But not
because of the doall or take, but because of the count. The problem is not
take, it's the take-while of split-with, which is the trouble. You know
that the input is 50 items long. take-while does not. It has to check the
After more than a year of exploration of different approaches to get
error handling right in the Erlang sense with core.async, I am finally
confident enough to release it as superv.async. I have tested it a lot
with replikativ in a distributed system, but I wouldn't consider it
production ready yet
Certainly the problem is the realizing the tail sequence of the split-with
before the head sequence, and take shouldn't be trying to solve that. But I
guess I would have thought that (doall (take (count t) t)) would have
realized all of t so the head could be released.
Indeed, the take* formulatio
I think this is not a bug in take, but an unfortunate constellation of
laziness.
The solution you propose is basically making take looking one step ahead,
which is not take's business. It could be actually quite dangerous to do so
in case take's n was carefully calculated based on some external
Cool library! But i just changed to fipp this morning. I think I will try
it much later. fipp is really fast that it succeeded clojure.pprint/write.
On Mon, Oct 24, 2016 at 4:36 PM Thomas Heller wrote:
> Try https://github.com/weavejester/cljfmt
>
> It is specifically written for clj code and no
Try https://github.com/weavejester/cljfmt
It is specifically written for clj code and not general pprinter.
/thomas
On Sunday, October 23, 2016 at 1:28:23 PM UTC+2, Jiyin Yiyong wrote:
>
> I'm using `write` function to generate code very heavily. But small part
> of the code are hard to read.
