OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

It's never a good idea to use the wrong data structure for the job. And thus Clojure takes the stance that it won't make bad ideas easy for you to use. Yet, it will never prevent you from doing anything. If you want to do something bad, you'll need to get your own hands dirty. That's why slow d

concat and mapcat not sufficiently lazy

I'm kind of surprised I haven't run across this before, but tonight I was debugging a function that was doing an explosion of computation to return the first value of a lazy sequence, and I was able to reduce the problem down to this example: > (first (apply concat (map #(do (println %) [%]) (list

Re: concat and mapcat not sufficiently lazy

This behaviour is known and there are a couple of tickets about it : https://dev.clojure.org/jira/browse/CLJ-1583 https://dev.clojure.org/jira/browse/CLJ-1218 On Wed, 18 Jul 2018, 08:28 Mark Engelberg, wrote: > I'm kind of surprised I haven't run across this before, but tonight I was > debuggin

Re: concat and mapcat not sufficiently lazy

Thanks, I hadn't seen those issues. https://dev.clojure.org/jira/browse/CLJ-1218 talks about mapcat, and https://dev.clojure.org/jira/browse/CLJ-1583 talks about apply. Those are aspects of the problem, for sure, but fixing those two issues would not solve the problem with (apply concat ...), I don

Re: Complete Web Development Setup Using Clojure CLI Tools

for additional inspiration, i suggest looking at https://github.com/juxt/edge On Monday, 9 July 2018 17:14:22 UTC+1, Gary Johnson wrote: > > Howdy Clojurians, > > I recently started developing a new Clojure+Clojurescript web application, > and I wanted to see if I could set up my development env

Re: concat and mapcat not sufficiently lazy

Yes, you’re right that neither directly handles `concat`, however CLJ-1583 improves the behaviour of both your examples and is _necessary_ to fix any `apply` related laziness issues user=> (first (apply concat (map #(do (println %) [%]) (list 1 2 3 4 5 1 2 3 1 user=> (first (mapcat #(do (pr

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

Concat does the job except for keeping the input collection type. It will seq anything you throw at it. There's a general trade-off here. When I started working in ocaml recently I was taken aback that the List.map call we used constantly would have to build the new list backwards in linear time,

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

On Tue, Jul 17, 2018 at 3:48 PM, Tomasz Sulej wrote: > > > W dniu wtorek, 17 lipca 2018 22:44:27 UTC+2 użytkownik Christian Seberino > napisał: >> >> >> data are functions and vice-versa >>> >> >> What do you mean? e.g. How is the [1 2 3] a "function"? >> >> Also take a look in https://github.com

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

> But like others have said, that ship sailed in 2008. > Well depends what ship you are talking about. Using prepend and append only requires two new function definitions. That is still easily done in 2018. -- You received this message because you are subscribed to the Google Groups "Clojure"

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

> > > Anyways, my advice is to teach them concat. It's even nicer then > append/prepend. You just give it the arguments where you want them to go. > > (concat [1] [2 3]) > > (concat [1 2] [3]) Thanks. This is perfect. I'm surprised it didn't up earlier in the conversation. concat is a single c

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

Actually I was just kicked out of paradise. concat always returns a list and does NOT return a vector for this (concat [1 2] [3 4]) sadly. cs ___ Christian Seberino, Ph.D. Phone: (936) 235-1139 Email: cseber...@gmail.com __

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

Well, actually, concat returns a seq, not a list. For all practical purposes, it looks like a list, but it isn't one. Practically, the difference is laziness, which is a whole thing on its own. Also the count operation is linear when lists just keep track of their length, and can do it in constant

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

If you want to be able to arbitrarily manipulate your data structures, you should look at Specter. I recommend reading my introductory blog post on it: http://nathanmarz.com/blog/clojures-missing-piece.html The `BEFORE-ELEM` and `AFTER-ELEM` navigators are what you use for prepending/appending.

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

Ironically, concat is one of the few operations in Clojure that actually very likely to cause you performance headaches that actually will matter. Concatting is extremely slow. I think there's a Bagwell functional data structure (RRB ?) that addresses the performance issues with concat, but to my

RE: [ANN] Clojure 1.10.0-alpha5

Just FYI, we ran into all sorts of strange errors (class not found exceptions from Boot pods etc) trying Alpha 6 at work but I was about to head out of the country for two weeks vacation so I didn’t have time to dig into that. I’m back now and will try again shortly and see if I can repro outsid

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

I should have done even 30 seconds of research before sending that last message. RRB has been available in Clojure since 2014 https://github.com/clojure/core.rrb-vector/blob/master/README.md If you use that data structure instead of the normal vector, then concats will perform better. On Wed, Jul

RE: [ANN] Clojure 1.10.0-alpha5

The only change in alpha6 was the asm fix (your patch!) :) -- 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 Note that posts from new members are moderated - please be patient with your

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

On Tue, Jul 17, 2018, 4:11 PM James Reeves wrote: > On Tue, 17 Jul 2018 at 21:06, Christian Seberino > wrote: > >> >> Clojure, on the other hand, takes great care to ensure that its data can >>> always be represented as literals. For data that isn't a standard >>> collection type, there are tagg

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

On Wed, 18 Jul 2018 at 19:38, Gregg Reynolds wrote: > > On Tue, Jul 17, 2018, 4:11 PM James Reeves wrote: > >> >> A data literal evaluates to itself. So for example, `2` is a literal, >> because we only need to read it to know its value, whereas `(+ 1 1)` >> isn't a literal, because we also need

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

On Wed, Jul 18, 2018, 1:55 PM James Reeves wrote: > On Wed, 18 Jul 2018 at 19:38, Gregg Reynolds wrote: > >> >> On Tue, Jul 17, 2018, 4:11 PM James Reeves wrote: >> >>> >>> A data literal evaluates to itself. So for example, `2` is a literal, >>> because we only need to read it to know its valu

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

> Of course you have to "evaluate" to know that, but you also have to evaluate "2" in the same way to know what it means. I think you're missing the point. 2 is literal because you read it, eval it, print it, and 2 (the result of evaluation) as printed is the same as the original input. A functio

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

On Wed, Jul 18, 2018, 2:25 PM Robert Levy wrote: > > Of course you have to "evaluate" to know that, but you also have to > evaluate "2" in the same way to know what it means. > > I think you're missing the point. > I think maybe we're talking about different things. 2 is literal because you rea

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

On Wed, Jul 18, 2018, 2:40 PM Gregg Reynolds wrote: > > > On Wed, Jul 18, 2018, 2:25 PM Robert Levy wrote: > >> > Of course you have to "evaluate" to know that, but you also have to >> evaluate "2" in the same way to know what it means. >> >> I think you're missing the point. >> > > I think mayb

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

On Wed, 18 Jul 2018 at 20:19, Gregg Reynolds wrote: > > On Wed, Jul 18, 2018, 1:55 PM James Reeves wrote: > >> >> Function expressions don't evaluate to themselves. >> > > To me that means either the definition is wrong or your literal? is > rigged. Probably the latter; "literal" is meta, it can

Re: concat and mapcat not sufficiently lazy

I have added this to the Tupelo library as `tupelo.lazy/join`: API docs:http://cloojure.github.io/doc/tupelo/tupelo.lazy.html source: (defn join "Lazily concatenates a sequence-of-sequences into a flat sequence." [sequences] (la

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

On Wed, 18 Jul 2018 at 20:40, Gregg Reynolds wrote: > > On Wed, Jul 18, 2018, 2:25 PM Robert Levy wrote: > >> Literals can be persisted to strings and read back in with no problem, >> whereas non-literals can't. >> > > That's a different definition of "literal", no? James talked about > evaluati

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

As someone mentioned, the functions `prepend` and `append` exist in the Tupelo library to prevent this kind of confusion: from the README: --

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

There is also a function `glue` for combining like collections: - Gluing Together Like Collections The concat function can sometimes have rather su

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

I'm just a Clojure beginner but it seems that the Lisp Way(TM) is to append and prepend one or more elements with a single command if possible. The logical name for this command seems to be concat which led to this.. (defn concat_ [a b] (def c (concat a b)) (if (vector? a) (

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

Christian, Nice to have you here. I guess a couple of things are being discussed in parallel - a few trivial points: - 'you always get back a value of the concrete type you supplied for argument X' isn't obviously less cognitively burdensome than 'you always get back a sequence' - doesn't Pyth

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

> > Concat does the job except for keeping the input collection type. It will > seq anything you throw at it. > But that should not matter to a beginner. I mean, if you are at the point where you are teaching people the differences between the data structures, than teach them the difference b

Change platform for reader conditionals

Hi Is it possible to read a string containing reader conditionals using a platform different from "current". In particular in from clojure I want to read a string that contains :cljs reader conditionals and evaluate them as if current platform is cljs. Example: if I run the following code from cl