Re: How define alias for .indexOf? (def somealias .indexOf) does not work.

[Didier]

The memfn docstring says it can be type hinted to avoid reflection. Any reason 
why it would still be slower then wrapping it in a type hinted function?

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [ANN] Clojure 1.10.0-alpha5

[Sean Corfield]

Progress so far… with Alpha 6.

I’ve encountered a number of (random) JVM SEGV fatal errors running our Boot 
build pipeline and if I don’t hit any of those, I hit an exception like this 
fairly reliably:

https://gist.github.com/seancorfield/f29bdb948a2a533c14a07ff6ffd6548a

(the missing class seems to vary from run to run but the exception is always in 
the same place)

It _seems_ to be an interaction between something new in Alpha 5 and Boot’s pod 
machinery since all of the failures I’m encountering seem to have when Boot is 
attempting to refresh pods in its pool of pods. We rely heavily on pods to 
isolate various parts of our build pipeline (since we load in different sets of 
dependencies for different sets of tests).

Ghadi suggested I update my local JDK to a more recent version and try again so 
that’s next on my list.

Narrowing this down is going to be hard: if I run the build pipeline in 
separate “chunks” – which means less interaction between pods – each chunk 
always passes.

So, overall, no failures from our test suite itself for any of our application 
components (good). Just random failures within the build tool itself ☹

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: Sean Corfield 
Sent: Thursday, July 19, 2018 1:08:33 PM
To: clojure@googlegroups.com
Subject: RE: [ANN] Clojure 1.10.0-alpha5


Yes, which allowed us to actually _try_ to run our build pipeline – so the 
problems we’re seeing are fallout from the big changes in Alpha 5… I just 
haven’t nailed them down yet  Everything works fine on Alpha 4.



Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood




From: clojure@googlegroups.com  on behalf of Alex 
Miller 
Sent: Wednesday, July 18, 2018 10:50:59 AM
To: Clojure
Subject: 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 
first post.
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
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Renzo Borgatti]

> On 19 Jul 2018, at 21:17, Andy Fingerhut  wrote:
> 
> 
> If you wish for the Clojure core team to provide that style of documentation 
> for you, I expect your wish will not be fulfilled.  It is not technically 
> difficult to replace all Clojure doc strings with more verbose variants.  It 
> _is_ a lot of work to write documentation like that and maintain it over 
> time.  For example, here is a whole bunch of stuff I wrote on the behavior of 
> clojure.core/= and clojure.core/hash.  It took way more hours than I care to 
> admit: 
> https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/equality.md
> 
> I believe someone wrote a book aiming to be a reference to all Clojure 
> functions, but don't recall the name or author at the moment, nor have I read 
> it.

Apologies for not resisting the plug: 
https://www.manning.com/books/clojure-standard-library

It should be completed very soon. Also sympathetic with the complexities of 
equality: I still can't believe how much there is to say.

Cheers
Renzo

> 
> Andy
> 
>  
> 
> 
> On Thu, Jul 19, 2018 at 11:04 AM Benoît Fleury  wrote:
> I agree with Alex. It is important to understand the rationale behind the
> behavior of conj. conj is for adding an element to a collection. It doesn't
> say anything about ordering. It has been chosen as an operation, as
> opposed to append/prepend, because it can be implemented with the
> same time complexity for a lot of data structures.
> 
> To convince myself that time complexity mattered in programming, I take
> the example of a stack. If you give me an implementation of a stack that
> push and pop items in linear time, I will write very inefficient programs 
> very quickly. To the point of not working at all. So it makes sense to me 
> that space/time complexity should be part of the signature of an operation.
> 
> Now, I think the problem here comes from the fact that we have a tendency
> to infer the semantic of an operation from its behavior on certain types. We
> see that (conj [1 2] 3) returns [1 2 3] so we conclude that conj is for adding
> an item at the end of a collection. And then we get surprised when the
> behavior is "different" for other types. As Clojure programmers, it is 
> something
> we need to be careful about and make sure we understand the actual
> semantic of the operations.
> 
> However, I think it is easier said than done. I would be ready to bet that a
> lot of Clojure programs rely on the fact that conj *appends* to a vector or
> *prepends* to a list. I agree that it is problematic. First, it makes the
> understanding of the code harder because you need to remember the behavior
> of conj on each type. And it prevents the implementation of conj to change
> because so many programs rely on implementation details. But to all expert
> Clojure programmers here, can you honestly think about what mental model you
> use when using conj on vectors and lists? Are you really thinking: I'm adding
> this element to this collection. I don't really care where it ends up :) ?
> 
> So my questions are:
> 
> 1. Am I wrong in thinking that most Clojure programmers use append/prepend
> as mental models for the different implementations of conj?
> 
> 2. Am I wrong in thinking that they shouldn't?
> 
> 3. And if I'm not wrong, how could we make it easier for programmers to make
> sure they code against the semantic of an operation and not its implementation
> details? Is there methods, tools or tests that could help us with that?
> 
> 
> On Thu, Jul 19, 2018 at 3:20 AM Didier  wrote:
> Hey Alan,
> 
> Nice job on Tupelo by the way. I do find it a bit bloated though, and that's 
> why I never use it. Any reason why all the different namespace are still 
> mixed together? Seem like they could each be an independent lib, like how the 
> datomic namespace was split out.
> 
> On Wednesday, 18 July 2018 13:16:15 UTC-7, Alan Thompson wrote:
> There is also a function `glue` for combining like collections:
> 
> -
> Gluing Together Like Collections
> 
> The concat function can sometimes have rather surprising results:
> 
> (concat {:a 1} {:b 2} {:c 3
> } )
> 
> ;=>   ( [:a 1] [:b 2] [:c 3] )
> In this example, the user probably meant to merge the 3 maps into one. 
> Instead, the three maps were mysteriously converted into length-2 vectors, 
> which were then nested inside another sequence.
> 
> The conj function can also surprise the user:
> 
> (conj [1 2] [3 4
> ] )
> 
> ;=>   [1 2  [3 4] ]
> Here the user probably wanted to get [1 2 3 4] back, but instead got a nested 
> vector by mistake.
> 
> Instead of having to wonder if the items to be combined will be merged, 
> nested, or converted into another data type, we provide the glue function to 
> always combine like collections together into a result collection of the same 
> type:
> 
> ; Glue together like collections:
> 
> (
> is (= (glue [ 1 2] '(3 4) [ 5 6] )   [ 1 2 3 4 

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

[Benoît Fleury]

Sorry if if it was not clear. I was not asking for more documentation. I
understand that the documentation of `conj` should not say anything about
how the different implementations work since it is only about adding an
element to a collection in constant time. And you can always have future
implementations of the operation that will behave differently. So the conj
function has the right documentation in my opinion. It describes its
semantic.

My question is about having implementations "extend" the semantic of conj.
By extending the semantic I mean that it allows the user to have more
expectations about the behavior of the operation. If we use conj on a
vector, we expect the element to be added at the end. Our programs rely on
this property. In this sense, we extend the semantic of conj in my opinion.
With operations like prepend/append, the semantic is in a way complete. The
different sorted collection implementations will always behave the same
when prepending or appending an element (except for the time complexity of
course :)). I'm trying to find other examples in Clojure and other
programming languages where implementations of an abstraction extend the
semantic of the abstraction.

And to be completely clear, I'm not complaining about the design decision
in Clojure. I'm just trying to really understand what the design is, what
are the trade-offs and where the confusion might come from.







On Thu, Jul 19, 2018 at 4:18 PM Andy Fingerhut 
wrote:

>
>
> On Thu, Jul 19, 2018 at 1:04 PM Benoît Fleury  wrote:
>
>> Replying to myself ... :)
>>
>> 1. Am I wrong in thinking that most Clojure programmers use append/prepend
>> as mental models for the different implementations of conj?
>>
>> No.
>>
>> 2. Am I wrong in thinking that they shouldn't?
>>
>> Yes.
>>
>> Clojure developers need to know the behavior of conj for vectors and
>> lists. This is even what often drives the choice between the two data
>> structures.
>>
>> And I think that's where a lot of confusion comes from. I think I
>> (and maybe others) expect that the complete semantic of a function
>>  be described in its documentation. I don't know whether this
>>  expectation is justified or not :)
>>
>
> You are not alone in wishing for more details in documentation of Clojure
> functions.  That is one of the reasons ClojureDocs.org exists, for example,
> and its first few examples make explicit the different behavior of conj for
> lists vs. vectors: http://clojuredocs.org/clojure.core/conj
>
> If you wish for the Clojure core team to provide that style of
> documentation for you, I expect your wish will not be fulfilled.  It is not
> technically difficult to replace all Clojure doc strings with more verbose
> variants.  It _is_ a lot of work to write documentation like that and
> maintain it over time.  For example, here is a whole bunch of stuff I wrote
> on the behavior of clojure.core/= and clojure.core/hash.  It took way more
> hours than I care to admit:
> https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/equality.md
>
> I believe someone wrote a book aiming to be a reference to all Clojure
> functions, but don't recall the name or author at the moment, nor have I
> read it.
>
> Andy
>
>
>
>>
>>
>> On Thu, Jul 19, 2018 at 11:04 AM Benoît Fleury  wrote:
>>
>>> I agree with Alex. It is important to understand the rationale behind the
>>> behavior of conj. conj is for adding an element to a collection. It
>>> doesn't
>>> say anything about ordering. It has been chosen as an operation, as
>>> opposed to append/prepend, because it can be implemented with the
>>> same time complexity for a lot of data structures.
>>>
>>> To convince myself that time complexity mattered in programming, I take
>>> the example of a stack. If you give me an implementation of a stack that
>>> push and pop items in linear time, I will write very inefficient
>>> programs
>>> very quickly. To the point of not working at all. So it makes sense to
>>> me
>>> that space/time complexity should be part of the signature of an
>>> operation.
>>>
>>> Now, I think the problem here comes from the fact that we have a tendency
>>> to infer the semantic of an operation from its behavior on certain
>>> types. We
>>> see that (conj [1 2] 3) returns [1 2 3] so we conclude that conj is for
>>> adding
>>> an item at the end of a collection. And then we get surprised when the
>>> behavior is "different" for other types. As Clojure programmers, it is
>>> something
>>> we need to be careful about and make sure we understand the actual
>>> semantic of the operations.
>>>
>>> However, I think it is easier said than done. I would be ready to bet
>>> that a
>>> lot of Clojure programs rely on the fact that conj *appends* to a vector
>>> or
>>> *prepends* to a list. I agree that it is problematic. First, it makes the
>>> understanding of the code harder because you need to remember the
>>> behavior
>>> of conj on each type. And it prevents the implementation of conj to
>>> change

Re: [ANN] Clojure 1.10.0-alpha5

[Alex Miller]

Gotcha. Let us know...

> On Jul 19, 2018, at 3:08 PM, Sean Corfield  wrote:
> 
> Yes, which allowed us to actually _try_ to run our build pipeline – so the 
> problems we’re seeing are fallout from the big changes in Alpha 5… I just 
> haven’t nailed them down yet  Everything works fine on Alpha 4.
>  
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> 
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>  
> From: clojure@googlegroups.com  on behalf of Alex 
> Miller 
> Sent: Wednesday, July 18, 2018 10:50:59 AM
> To: Clojure
> Subject: 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 
> first post.
> 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
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> -- 
> 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 
> first post.
> 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
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/ESNrjIr0JUE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Andy Fingerhut]

On Thu, Jul 19, 2018 at 1:04 PM Benoît Fleury  wrote:

> Replying to myself ... :)
>
> 1. Am I wrong in thinking that most Clojure programmers use append/prepend
> as mental models for the different implementations of conj?
>
> No.
>
> 2. Am I wrong in thinking that they shouldn't?
>
> Yes.
>
> Clojure developers need to know the behavior of conj for vectors and
> lists. This is even what often drives the choice between the two data
> structures.
>
> And I think that's where a lot of confusion comes from. I think I
> (and maybe others) expect that the complete semantic of a function
>  be described in its documentation. I don't know whether this
>  expectation is justified or not :)
>

You are not alone in wishing for more details in documentation of Clojure
functions.  That is one of the reasons ClojureDocs.org exists, for example,
and its first few examples make explicit the different behavior of conj for
lists vs. vectors: http://clojuredocs.org/clojure.core/conj

If you wish for the Clojure core team to provide that style of
documentation for you, I expect your wish will not be fulfilled.  It is not
technically difficult to replace all Clojure doc strings with more verbose
variants.  It _is_ a lot of work to write documentation like that and
maintain it over time.  For example, here is a whole bunch of stuff I wrote
on the behavior of clojure.core/= and clojure.core/hash.  It took way more
hours than I care to admit:
https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/equality.md

I believe someone wrote a book aiming to be a reference to all Clojure
functions, but don't recall the name or author at the moment, nor have I
read it.

Andy



>
>
> On Thu, Jul 19, 2018 at 11:04 AM Benoît Fleury  wrote:
>
>> I agree with Alex. It is important to understand the rationale behind the
>> behavior of conj. conj is for adding an element to a collection. It
>> doesn't
>> say anything about ordering. It has been chosen as an operation, as
>> opposed to append/prepend, because it can be implemented with the
>> same time complexity for a lot of data structures.
>>
>> To convince myself that time complexity mattered in programming, I take
>> the example of a stack. If you give me an implementation of a stack that
>> push and pop items in linear time, I will write very inefficient programs
>> very quickly. To the point of not working at all. So it makes sense to me
>> that space/time complexity should be part of the signature of an
>> operation.
>>
>> Now, I think the problem here comes from the fact that we have a tendency
>> to infer the semantic of an operation from its behavior on certain types.
>> We
>> see that (conj [1 2] 3) returns [1 2 3] so we conclude that conj is for
>> adding
>> an item at the end of a collection. And then we get surprised when the
>> behavior is "different" for other types. As Clojure programmers, it is
>> something
>> we need to be careful about and make sure we understand the actual
>> semantic of the operations.
>>
>> However, I think it is easier said than done. I would be ready to bet
>> that a
>> lot of Clojure programs rely on the fact that conj *appends* to a vector
>> or
>> *prepends* to a list. I agree that it is problematic. First, it makes the
>> understanding of the code harder because you need to remember the behavior
>> of conj on each type. And it prevents the implementation of conj to change
>> because so many programs rely on implementation details. But to all expert
>> Clojure programmers here, can you honestly think about what mental model
>> you
>> use when using conj on vectors and lists? Are you really thinking: I'm
>> adding
>> this element to this collection. I don't really care where it ends up :) ?
>>
>> So my questions are:
>>
>> 1. Am I wrong in thinking that most Clojure programmers use append/prepend
>> as mental models for the different implementations of conj?
>>
>> 2. Am I wrong in thinking that they shouldn't?
>>
>> 3. And if I'm not wrong, how could we make it easier for programmers to
>> make
>> sure they code against the semantic of an operation and not its
>> implementation
>> details? Is there methods, tools or tests that could help us with that?
>>
>>
>> On Thu, Jul 19, 2018 at 3:20 AM Didier  wrote:
>>
>>> Hey Alan,
>>>
>>> Nice job on Tupelo by the way. I do find it a bit bloated though, and
>>> that's why I never use it. Any reason why all the different namespace are
>>> still mixed together? Seem like they could each be an independent lib, like
>>> how the datomic namespace was split out.
>>>
>>> On Wednesday, 18 July 2018 13:16:15 UTC-7, Alan Thompson wrote:

 There is also a function `glue`
 
 for combining like collections:


 -
 Gluing Together Like Collections

 The concat function can sometimes have rather surprising results:

 

RE: [ANN] Clojure 1.10.0-alpha5

[Sean Corfield]

Yes, which allowed us to actually _try_ to run our build pipeline – so the 
problems we’re seeing are fallout from the big changes in Alpha 5… I just 
haven’t nailed them down yet  Everything works fine on Alpha 4.



Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood




From: clojure@googlegroups.com  on behalf of Alex 
Miller 
Sent: Wednesday, July 18, 2018 10:50:59 AM
To: Clojure
Subject: 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 
first post.
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
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Benoît Fleury]

Replying to myself ... :)

1. Am I wrong in thinking that most Clojure programmers use append/prepend
as mental models for the different implementations of conj?

No.

2. Am I wrong in thinking that they shouldn't?

Yes.

Clojure developers need to know the behavior of conj for vectors and
lists. This is even what often drives the choice between the two data
structures.

And I think that's where a lot of confusion comes from. I think I
(and maybe others) expect that the complete semantic of a function
 be described in its documentation. I don't know whether this
 expectation is justified or not :)


On Thu, Jul 19, 2018 at 11:04 AM Benoît Fleury  wrote:

> I agree with Alex. It is important to understand the rationale behind the
> behavior of conj. conj is for adding an element to a collection. It doesn't
> say anything about ordering. It has been chosen as an operation, as
> opposed to append/prepend, because it can be implemented with the
> same time complexity for a lot of data structures.
>
> To convince myself that time complexity mattered in programming, I take
> the example of a stack. If you give me an implementation of a stack that
> push and pop items in linear time, I will write very inefficient programs
> very quickly. To the point of not working at all. So it makes sense to me
> that space/time complexity should be part of the signature of an operation.
>
> Now, I think the problem here comes from the fact that we have a tendency
> to infer the semantic of an operation from its behavior on certain types.
> We
> see that (conj [1 2] 3) returns [1 2 3] so we conclude that conj is for
> adding
> an item at the end of a collection. And then we get surprised when the
> behavior is "different" for other types. As Clojure programmers, it is
> something
> we need to be careful about and make sure we understand the actual
> semantic of the operations.
>
> However, I think it is easier said than done. I would be ready to bet that
> a
> lot of Clojure programs rely on the fact that conj *appends* to a vector or
> *prepends* to a list. I agree that it is problematic. First, it makes the
> understanding of the code harder because you need to remember the behavior
> of conj on each type. And it prevents the implementation of conj to change
> because so many programs rely on implementation details. But to all expert
> Clojure programmers here, can you honestly think about what mental model
> you
> use when using conj on vectors and lists? Are you really thinking: I'm
> adding
> this element to this collection. I don't really care where it ends up :) ?
>
> So my questions are:
>
> 1. Am I wrong in thinking that most Clojure programmers use append/prepend
> as mental models for the different implementations of conj?
>
> 2. Am I wrong in thinking that they shouldn't?
>
> 3. And if I'm not wrong, how could we make it easier for programmers to
> make
> sure they code against the semantic of an operation and not its
> implementation
> details? Is there methods, tools or tests that could help us with that?
>
>
> On Thu, Jul 19, 2018 at 3:20 AM Didier  wrote:
>
>> Hey Alan,
>>
>> Nice job on Tupelo by the way. I do find it a bit bloated though, and
>> that's why I never use it. Any reason why all the different namespace are
>> still mixed together? Seem like they could each be an independent lib, like
>> how the datomic namespace was split out.
>>
>> On Wednesday, 18 July 2018 13:16:15 UTC-7, Alan Thompson wrote:
>>>
>>> There is also a function `glue`
>>> 
>>> for combining like collections:
>>>
>>>
>>> -
>>> Gluing Together Like Collections
>>>
>>> The concat function can sometimes have rather surprising results:
>>>
>>> (concat {:a 1} {:b 2} {:c 3} );=>   ( [:a 1] [:b 2] [:c 3] )
>>>
>>> In this example, the user probably meant to merge the 3 maps into one.
>>> Instead, the three maps were mysteriously converted into length-2 vectors,
>>> which were then nested inside another sequence.
>>>
>>> The conj function can also surprise the user:
>>>
>>> (conj [1 2] [3 4] );=>   [1 2  [3 4] ]
>>>
>>> Here the user probably wanted to get [1 2 3 4] back, but instead got a
>>> nested vector by mistake.
>>>
>>> Instead of having to wonder if the items to be combined will be merged,
>>> nested, or converted into another data type, we provide the glue function
>>> to *always* combine like collections together into a result collection
>>> of the same type:
>>>
>>> ; Glue together like collections:
>>> (is (= (glue [ 1 2] '(3 4) [ 5 6] )   [ 1 2 3 4 5 6 ]  ))   ; all 
>>> sequential (vectors & lists)
>>> (is (= (glue {:a 1} {:b 2} {:c 3} )   {:a 1 :c 3 :b 2} ))   ; all maps
>>> (is (= (glue #{1 2} #{3 4} #{6 5} )  #{ 1 2 6 5 3 4 }  ))   ; all sets
>>> (is (= (glue "I" " like " \a " nap!" )   "I like a nap!"   ))   ; all text 
>>> (strings & chars)
>>> ; If you want to 

Re: How define alias for .indexOf? (def somealias .indexOf) does not work.

[Laurens Van Houtven]

I expect you're asking generally and James already gave the correct answer
for that, but index-of specifically is defined in clojure.string :)

On Thu, Jul 19, 2018 at 12:45 PM, James Reeves 
wrote:

> You'd need to wrap it in a function, like:
>
> (defn index-of [^String haystack ^String needle]
>   (.indexOf haystack needle))
>
> On Thu, 19 Jul 2018 at 18:33, Christian Seberino 
> wrote:
>
>> How define alias for .indexOf?
>>
>>  (def somealias .indexOf) does not work.
>>
>> cs
>>
>> --
>> 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 first post.
>> 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
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> James Reeves
> booleanknot.com
>
> --
> 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 first post.
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How define alias for .indexOf? (def somealias .indexOf) does not work.

[James Reeves]

You'd need to wrap it in a function, like:

(defn index-of [^String haystack ^String needle]
  (.indexOf haystack needle))

On Thu, 19 Jul 2018 at 18:33, Christian Seberino 
wrote:

> How define alias for .indexOf?
>
>  (def somealias .indexOf) does not work.
>
> cs
>
> --
> 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 first post.
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
James Reeves
booleanknot.com

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How define alias for .indexOf? (def somealias .indexOf) does not work.

[Gary Trakhman]

memfn will do this for you https://clojuredocs.org/clojure.core/memfn

But it's usually the wrong thing.  Wrt reflection-perf/warnings, you'd be
better off with an anonymous function and typehint most of the time.


On Thu, Jul 19, 2018 at 1:33 PM Christian Seberino 
wrote:

> How define alias for .indexOf?
>
>  (def somealias .indexOf) does not work.
>
> cs
>
> --
> 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 first post.
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How define alias for .indexOf? (def somealias .indexOf) does not work.

[Christian Seberino]

How define alias for .indexOf? 

 (def somealias .indexOf) does not work.

cs

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: command line tool clojure raises java.lang.ClassNotFoundException: clojure.main

[Johannes]

Now, I've found the source of the problem. I'd got an "old" alias named clojure 
in my .profile. Now all works fine.

Johannes

Am Donnerstag, 19. Juli 2018 16:28:04 UTC+2 schrieb Johannes:
>
> I suppose I have installed the command line tools on my Mac with
>
> brew install clojure
>
> as described in the Getting Started Guide.
>
> If I try clj I get
>
> Clojure 1.9.0
>
> user=> 
> fine!
>
> If I try clojure I get
>
> Fehler: Hauptklasse clojure.main konnte nicht gefunden oder geladen werden
>
> Ursache: java.lang.ClassNotFoundException: clojure.main
>
> Any hints, what is going wrong?
>
> Johannes
>

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: command line tool clojure raises java.lang.ClassNotFoundException: clojure.main

[Johannes]

Am Donnerstag, 19. Juli 2018 16:41:24 UTC+2 schrieb Alex Miller:
>
> It might be good to check that `clojure` actually points to what you think 
> it points to. Check `which clj` and `which clojure` to make sure they are 
> coming out of the same directory.
>
I think they do:

JohMBAir:~ johannes$ which clj

/usr/local/bin/clj

JohMBAir:~ johannes$ which clojure

/usr/local/bin/clojure

JohMBAir:~ johannes$ 
 

>
> On Thursday, July 19, 2018 at 9:28:04 AM UTC-5, Johannes wrote:
>>
>> I suppose I have installed the command line tools on my Mac with
>>
>> brew install clojure
>>
>> as described in the Getting Started Guide.
>>
>> If I try clj I get
>>
>> Clojure 1.9.0
>>
>> user=> 
>> fine!
>>
>> If I try clojure I get
>>
>> Fehler: Hauptklasse clojure.main konnte nicht gefunden oder geladen werden
>>
>> Ursache: java.lang.ClassNotFoundException: clojure.main
>>
>> Any hints, what is going wrong?
>>
>> Johannes
>>
>

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JOB] Clojure(Script) jobs at Reify Health | U.S Remote or Boston

[Ripu Gupta]

Hi Gaberial,
How are you? Did you find any clojure developer for your requirement?

On Monday, April 9, 2018 at 11:17:25 PM UTC-4, cldwalker wrote:
>
> Hi,
>   Reify Health is building clinical trial software using Clojure and 
> ClojureScript. We are looking for experienced developers who are 
> knowledgeable in our stack or eager to learn it. We care about building 
> meaningful products, providing delightful user experiences 
>  and actively listening 
> to our users with the goal of continuous improvement. We actively use, 
> contribute 
> to  
> and author open source libraries 
> . We've been early adopters 
> of clojure.spec and have applications in re-frame and om.next.
>
> For more details and to apply, see the frontend developer position 
> 
>  and backend developer position 
> .
>  
> If you have any questions, feel free to email me at engineering-hiring at 
> reifyhealth.com.
>
> *Cheers,*
> *Gabriel*
>
>
>

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] tools.deps.alpha 0.5.442, clj 1.9.0.391

[Alex Miller]

Just a few minor bug fixes.

Now available:

   - tools.deps.alpha 0.5.442
   - clj 1.9.0.391
  - Mac: brew upgrade clojure
  - Linux: see https://clojure.org/guides/getting_started
  - Windows: working on it! 
   
Changelog:

   - Throw error if unknown aliases are used (TDEPS-85)
   - Fix bad break character in rlwrap (TDEPS-77)
   - Use non-0 exit code in clj if rlwrap doesn't exist (TDEPS-86 - thanks 
   Martin Klepsch!)
   - Change wording for -Sdeps in help and man for clarity (TDEPS-87)
   
   

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Joe R . Smith]

Building off of something Benoit mentioned about conj not being about order, 
but about adding to a collection, consider conj’s behavior when adding a 
map-entry to a hash-map: 

(conj (hash-map :a 4 :c 1) [:b 3])
=> {:c 1, :b 3, :a 4}

conj is an interface for adding– not to be conflated with order.




On Jul 19, 2018, at 10:23 AM, Christian Seberino mailto:cseber...@gmail.com> > wrote:

Thanks.  I caught that yesterday.  Like I said, I'm definitely a beginner. ;)

On Thursday, July 19, 2018 at 2:05:20 AM UTC-5, Vladimir Bokov wrote:
First of all, def in a fn body is antipattern (use let), then do into on a 
itself

(defn concat_ [a b]
  (if (vector? a)
    (into a b)
    (concat a b)))

четверг, 19 июля 2018 г., 4:07:46 UTC+7 пользователь Christian Seberino написал:
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)
          (into [] c)
          c))

(concat_ [1 2] [3 4]) => [1 2 3 4]

(concat_ '(1 2) '(3 4)) => (1 2 3 4)

(concat_ [1] [2 3]) => [1 2 3]

Lists return lists and vectors return vectors.  Simple.
Yes yes I know it is slow.  I also know I need to expand concat_ to handle 
other data structures.

In my little newbie world, this "feels" like the ultimate "right" solution.

Chris


-- 
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 
first post.
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 
 
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com 
 .
For more options, visit https://groups.google.com/d/optout.

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Christian Seberino]

On Thursday, July 19, 2018 at 10:04:39 AM UTC-5, Benoît Fleury wrote:
>
> I agree with Alex. It is important to understand the rationale behind the
> behavior of conj. conj is for adding an element to a collection. It doesn't
> say anything about ordering. It has been chosen as an operation, as
> opposed to append/prepend, because it can be implemented with the
> same time complexity for a lot of data structures.
>
>
Yes and that's important for real hardcore work.  But beginners don't 
necessarily need to be burdened with complexity
concerns immediately.  Eventually yes but not immediately.  And it really 
does has to be hardcore before
that matters...otherwise Python wouldn't be taking over the world and 
running strong for 20+ years.
 

> To convince myself that time complexity mattered in programming, I take
> the example of a stack. If you give me an implementation of a stack that
> push and pop items in linear time, I will write very inefficient programs 
> very quickly. To the point of not working at all. So it makes sense to me 
> that space/time complexity should be part of the signature of an operation.
>

See above.
 

>
> Now, I think the problem here comes from the fact that we have a tendency
> to infer the semantic of an operation from its behavior on certain types. 
> We
> see that (conj [1 2] 3) returns [1 2 3] so we conclude that conj is for 
> adding
> an item at the end of a collection. And then we get surprised when the
> behavior is "different" for other types. As Clojure programmers, it is 
> something
> we need to be careful about and make sure we understand the actual
> semantic of the operations.
>
> However, I think it is easier said than done. I would be ready to bet that 
> a
> lot of Clojure programs rely on the fact that conj *appends* to a vector or
> *prepends* to a list. I agree that it is problematic. First, it makes the
> understanding of the code harder because you need to remember the behavior
> of conj on each type. And it prevents the implementation of conj to change
> because so many programs rely on implementation details. But to all expert
> Clojure programmers here, can you honestly think about what mental model 
> you
> use when using conj on vectors and lists? Are you really thinking: I'm 
> adding
> this element to this collection. I don't really care where it ends up :) ?
>
> So my questions are:
>
> 1. Am I wrong in thinking that most Clojure programmers use append/prepend
> as mental models for the different implementations of conj?
>
> 2. Am I wrong in thinking that they shouldn't?
>
> 3. And if I'm not wrong, how could we make it easier for programmers to 
> make
> sure they code against the semantic of an operation and not its 
> implementation
> details? Is there methods, tools or tests that could help us with that?
>
>>
>>
My suggestion is to just use the natural polymorphic comb-ining function 
below until performance
is an issue.  At that point students will be motivated to learn about 
complexity

(defn comb [& args]
  (let [comb_ (apply concat args)]
   (cond (string? (first args)) (apply str comb_)
 (vector? (first args)) (into  []  comb_)
 (list?   (first args))comb_)))

(prn (comb [1 2]   [3 4]))
(prn (comb '(1 2) '(3 4)))
(prn (comb [1 2]   [3 4] '(5 6)))
(prn (comb '(1 2) '(3 4) [5 6]))
(prn (comb "abc"   "def" "ghi"))

gives this...

[1 2 3 4]
(1 2 3 4)
[1 2 3 4 5 6]
(1 2 3 4 5 6)
"abcdefghi"

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Christian Seberino]

Thanks.  I caught that yesterday.  Like I said, I'm definitely a beginner. 
;)

On Thursday, July 19, 2018 at 2:05:20 AM UTC-5, Vladimir Bokov wrote:
>
> First of all, def in a fn body is antipattern (use let), then do into on a 
> itself
>
> (defn concat_ [a b]
>   (if (vector? a)
> (into a b)
> (concat a b)))
>
> четверг, 19 июля 2018 г., 4:07:46 UTC+7 пользователь Christian Seberino 
> написал:
>>
>> 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)
>>   (into [] c)
>>   c))
>>
>> (concat_ [1 2] [3 4]) => [1 2 3 4]
>>
>> (concat_ '(1 2) '(3 4)) => (1 2 3 4)
>>
>> (concat_ [1] [2 3]) => [1 2 3]
>>
>> Lists return lists and vectors return vectors.  Simple.
>> Yes yes I know it is slow.  I also know I need to expand concat_ to 
>> handle other data structures.
>>
>> In my little newbie world, this "feels" like the ultimate "right" 
>> solution.
>>
>> Chris
>>
>>

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Christian Seberino]

>
>  - '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'
>

Combining objects of type X should give a result that is of type X.  That 
seems the most natural to me.
 

>  - doesn't Python, in all its teachability, just throw a TypeError if you 
> try and concatenate differently typed collections, even in trivial cases 
> (e.g. (1,) + [2])?  Is there a way to do that in Python which doesn't 
> involve writing a concat function w/ a bunch of type checks
>

Whether to allow vectors and lists to combine is something that can be 
discussed.  Seems like may be a good idea and an improvement over Python.
 

>  - runtime list construction in Clojure is comparatively rare.  I'm not a 
> teacher, but in a practical educational setting I would focus on vectors as 
> the general-purpose ordered collection type - esp. if i were interested in 
> appending to them.
>

I like below.  It also takes over the str command.  Basically a single 
function to do all basic combinations.  Notice whether run time list 
construction is a good idea or not does not
have to be decided by me.  I just make the ability available.
 


(defn comb [& args]
  (let [comb_ (apply concat args)]
   (cond (string? (first args)) (apply str comb_)
 (vector? (first args)) (into  []  comb_)
 (list?   (first args))comb_)))





 

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Benoît Fleury]

I agree with Alex. It is important to understand the rationale behind the
behavior of conj. conj is for adding an element to a collection. It doesn't
say anything about ordering. It has been chosen as an operation, as
opposed to append/prepend, because it can be implemented with the
same time complexity for a lot of data structures.

To convince myself that time complexity mattered in programming, I take
the example of a stack. If you give me an implementation of a stack that
push and pop items in linear time, I will write very inefficient programs
very quickly. To the point of not working at all. So it makes sense to me
that space/time complexity should be part of the signature of an operation.

Now, I think the problem here comes from the fact that we have a tendency
to infer the semantic of an operation from its behavior on certain types. We
see that (conj [1 2] 3) returns [1 2 3] so we conclude that conj is for
adding
an item at the end of a collection. And then we get surprised when the
behavior is "different" for other types. As Clojure programmers, it is
something
we need to be careful about and make sure we understand the actual
semantic of the operations.

However, I think it is easier said than done. I would be ready to bet that a
lot of Clojure programs rely on the fact that conj *appends* to a vector or
*prepends* to a list. I agree that it is problematic. First, it makes the
understanding of the code harder because you need to remember the behavior
of conj on each type. And it prevents the implementation of conj to change
because so many programs rely on implementation details. But to all expert
Clojure programmers here, can you honestly think about what mental model you
use when using conj on vectors and lists? Are you really thinking: I'm
adding
this element to this collection. I don't really care where it ends up :) ?

So my questions are:

1. Am I wrong in thinking that most Clojure programmers use append/prepend
as mental models for the different implementations of conj?

2. Am I wrong in thinking that they shouldn't?

3. And if I'm not wrong, how could we make it easier for programmers to make
sure they code against the semantic of an operation and not its
implementation
details? Is there methods, tools or tests that could help us with that?


On Thu, Jul 19, 2018 at 3:20 AM Didier  wrote:

> Hey Alan,
>
> Nice job on Tupelo by the way. I do find it a bit bloated though, and
> that's why I never use it. Any reason why all the different namespace are
> still mixed together? Seem like they could each be an independent lib, like
> how the datomic namespace was split out.
>
> On Wednesday, 18 July 2018 13:16:15 UTC-7, Alan Thompson wrote:
>>
>> There is also a function `glue`
>> 
>> for combining like collections:
>>
>>
>> -
>> Gluing Together Like Collections
>>
>> The concat function can sometimes have rather surprising results:
>>
>> (concat {:a 1} {:b 2} {:c 3} );=>   ( [:a 1] [:b 2] [:c 3] )
>>
>> In this example, the user probably meant to merge the 3 maps into one.
>> Instead, the three maps were mysteriously converted into length-2 vectors,
>> which were then nested inside another sequence.
>>
>> The conj function can also surprise the user:
>>
>> (conj [1 2] [3 4] );=>   [1 2  [3 4] ]
>>
>> Here the user probably wanted to get [1 2 3 4] back, but instead got a
>> nested vector by mistake.
>>
>> Instead of having to wonder if the items to be combined will be merged,
>> nested, or converted into another data type, we provide the glue function
>> to *always* combine like collections together into a result collection
>> of the same type:
>>
>> ; Glue together like collections:
>> (is (= (glue [ 1 2] '(3 4) [ 5 6] )   [ 1 2 3 4 5 6 ]  ))   ; all 
>> sequential (vectors & lists)
>> (is (= (glue {:a 1} {:b 2} {:c 3} )   {:a 1 :c 3 :b 2} ))   ; all maps
>> (is (= (glue #{1 2} #{3 4} #{6 5} )  #{ 1 2 6 5 3 4 }  ))   ; all sets
>> (is (= (glue "I" " like " \a " nap!" )   "I like a nap!"   ))   ; all text 
>> (strings & chars)
>> ; If you want to convert to a sorted set or map, just put an empty one first:
>> (is (= (glue (sorted-map) {:a 1} {:b 2} {:c 3})   {:a 1 :b 2 :c 3} ))
>> (is (= (glue (sorted-set) #{1 2} #{3 4} #{6 5})  #{ 1 2 3 4 5 6  } ))
>>
>> An Exception will be thrown if the collections to be 'glued' are not all
>> of the same type. The allowable input types are:
>>
>>-
>>
>>all sequential: any mix of lists & vectors (vector result)
>>-
>>
>>all maps (sorted or not)
>>-
>>
>>all sets (sorted or not)
>>-
>>
>>all text: any mix of strings & characters (string result)
>>
>>
>>
>> On Wed, Jul 18, 2018 at 1:13 PM, Alan Thompson  wrote:
>>
>>> As someone mentioned, the functions `prepend` and `append` exist in the
>>> Tupelo library
>>> 

Re: command line tool clojure raises java.lang.ClassNotFoundException: clojure.main

[Alex Miller]

It might be good to check that `clojure` actually points to what you think 
it points to. Check `which clj` and `which clojure` to make sure they are 
coming out of the same directory.

On Thursday, July 19, 2018 at 9:28:04 AM UTC-5, Johannes wrote:
>
> I suppose I have installed the command line tools on my Mac with
>
> brew install clojure
>
> as described in the Getting Started Guide.
>
> If I try clj I get
>
> Clojure 1.9.0
>
> user=> 
> fine!
>
> If I try clojure I get
>
> Fehler: Hauptklasse clojure.main konnte nicht gefunden oder geladen werden
>
> Ursache: java.lang.ClassNotFoundException: clojure.main
>
> Any hints, what is going wrong?
>
> Johannes
>

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

command line tool clojure raises java.lang.ClassNotFoundException: clojure.main

[Johannes]

I suppose I have installed the command line tools on my Mac with

brew install clojure

as described in the Getting Started Guide.

If I try clj I get

Clojure 1.9.0

user=> 
fine!

If I try clojure I get

Fehler: Hauptklasse clojure.main konnte nicht gefunden oder geladen werden

Ursache: java.lang.ClassNotFoundException: clojure.main

Any hints, what is going wrong?

Johannes

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Change platform for reader conditionals

[Alex Miller]

With read-string in Clojure, the :clj platform feature is always active but 
it is possible to add additional features like :cljs:

(read-string {:read-cond :allow, :features #{:cljs}} "#?(:clj 1 :cljs 2)")

In this case, both :clj and :cljs features will be active, so it will 
return 1 because the read-cond checks in order. If you put the :cljs choice 
first, it would be taken. 

With tools.reader, you will not have this issue - you can use tools.reader 
to read with only the :cljs platform feature active.

(require '[clojure.tools.reader :as r])
(r/read-string {:read-cond :allow, :features #{:cljs}} "#?(:clj 1 :cljs 
2)")  ;; 2

And this is exactly how ClojureScript reads (using tools.reader).


On Thursday, July 19, 2018 at 12:44:57 AM UTC-5, Nikita Beloglazov wrote:
>
> 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 clj:
>
> (read-string {:read-cond :allow} "#?(:clj 1 :cljs 2)")
>
> then I get 1. But I want to get 2. Is there a way to do it in Clojure 
> somehow or maybe using tools.reader? 
>
> Thanks,
> Nikita
>

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Didier]

Hey Alan,

Nice job on Tupelo by the way. I do find it a bit bloated though, and 
that's why I never use it. Any reason why all the different namespace are 
still mixed together? Seem like they could each be an independent lib, like 
how the datomic namespace was split out.

On Wednesday, 18 July 2018 13:16:15 UTC-7, Alan Thompson wrote:
>
> There is also a function `glue` 
>  for 
> combining like collections:
>
>
> -
> Gluing Together Like Collections
>
> The concat function can sometimes have rather surprising results:
>
> (concat {:a 1} {:b 2} {:c 3} );=>   ( [:a 1] [:b 2] [:c 3] )
>
> In this example, the user probably meant to merge the 3 maps into one. 
> Instead, the three maps were mysteriously converted into length-2 vectors, 
> which were then nested inside another sequence.
>
> The conj function can also surprise the user:
>
> (conj [1 2] [3 4] );=>   [1 2  [3 4] ]
>
> Here the user probably wanted to get [1 2 3 4] back, but instead got a 
> nested vector by mistake.
>
> Instead of having to wonder if the items to be combined will be merged, 
> nested, or converted into another data type, we provide the glue function 
> to *always* combine like collections together into a result collection of 
> the same type:
>
> ; Glue together like collections:
> (is (= (glue [ 1 2] '(3 4) [ 5 6] )   [ 1 2 3 4 5 6 ]  ))   ; all 
> sequential (vectors & lists)
> (is (= (glue {:a 1} {:b 2} {:c 3} )   {:a 1 :c 3 :b 2} ))   ; all maps
> (is (= (glue #{1 2} #{3 4} #{6 5} )  #{ 1 2 6 5 3 4 }  ))   ; all sets
> (is (= (glue "I" " like " \a " nap!" )   "I like a nap!"   ))   ; all text 
> (strings & chars)
> ; If you want to convert to a sorted set or map, just put an empty one first:
> (is (= (glue (sorted-map) {:a 1} {:b 2} {:c 3})   {:a 1 :b 2 :c 3} ))
> (is (= (glue (sorted-set) #{1 2} #{3 4} #{6 5})  #{ 1 2 3 4 5 6  } ))
>
> An Exception will be thrown if the collections to be 'glued' are not all 
> of the same type. The allowable input types are:
>
>- 
>
>all sequential: any mix of lists & vectors (vector result)
>- 
>
>all maps (sorted or not)
>- 
>
>all sets (sorted or not)
>- 
>
>all text: any mix of strings & characters (string result)
>
>
>
> On Wed, Jul 18, 2018 at 1:13 PM, Alan Thompson  > wrote:
>
>> As someone mentioned, the functions `prepend` and `append` exist in the 
>> Tupelo library 
>> 
>>  
>> to prevent this kind of confusion:
>>
>> from the README:
>>
>> 
>> Adding Values to the Beginning or End of a Sequence
>>
>> Clojure has the cons, conj, and concat functions, but it is not obvious 
>> how they should be used to add a new value to the beginning of a vector or 
>> list:
>>
>> ; Add to the end
>> > (concat [1 2] 3);=> IllegalArgumentException
>> > (cons   [1 2] 3);=> IllegalArgumentException
>> > (conj   [1 2] 3);=> [1 2 3]
>> > (conj   [1 2] 3 4)  ;=> [1 2 3 4]
>> > (conj  '(1 2) 3);=> (3 1 2)   ; oops
>> > (conj  '(1 2) 3 4)  ;=> (4 3 1 2) ; oops
>> ; Add to the beginning
>> > (conj 1  [2 3] ) ;=> ClassCastException
>> > (concat   1  [2 3] ) ;=> IllegalArgumentException
>> > (cons 1  [2 3] ) ;=> (1 2 3)
>> > (cons   1 2  [3 4] ) ;=> ArityException
>> > (cons 1 '(2 3) ) ;=> (1 2 3)
>> > (cons   1 2 '(3 4) ) ;=> ArityException
>>
>> Do you know what conj does when you pass it nil instead of a sequence? 
>> It silently replaces it with an empty list: (conj nil 5) ⇒ (5) This can 
>> cause you to accumulate items in reverse order if you aren’t aware of the 
>> default behavior:
>>
>> (-> nil
>>   (conj 1)
>>   (conj 2)
>>   (conj 3));=> (3 2 1)
>>
>> These failures are irritating and unproductive, and the error messages 
>> don’t make it obvious what went wrong. Instead, use the simple prepend 
>> and append functions to add new elements to the beginning or end of a 
>> sequence, respectively:
>>
>> (append [1 2] 3  )   ;=> [1 2 3  ]
>> (append [1 2] 3 4)   ;=> [1 2 3 4]
>>
>> (prepend   3 [2 1])  ;=> [  3 2 1]
>> (prepend 4 3 [2 1])  ;=> [4 3 2 1]
>>
>> Both > style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation
>>
>

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and 

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

[Vladimir Bokov]

First of all, def in a fn body is antipattern (use let), then do into on a 
itself

(defn concat_ [a b]
  (if (vector? a)
(into a b)
(concat a b)))

четверг, 19 июля 2018 г., 4:07:46 UTC+7 пользователь Christian Seberino 
написал:
>
> 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)
>   (into [] c)
>   c))
>
> (concat_ [1 2] [3 4]) => [1 2 3 4]
>
> (concat_ '(1 2) '(3 4)) => (1 2 3 4)
>
> (concat_ [1] [2 3]) => [1 2 3]
>
> Lists return lists and vectors return vectors.  Simple.
> Yes yes I know it is slow.  I also know I need to expand concat_ to handle 
> other data structures.
>
> In my little newbie world, this "feels" like the ultimate "right" solution.
>
> Chris
>
>

-- 
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 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.