Re: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Sunday, March 5, 2017 at 6:51:57 PM UTC-6, Alex Miller wrote:
>
> I would really appreciate seeing the ns declaration that caused the 
> original error. I have not been able to exactly reproduce what you are 
> describing. If you can't share it publicly, you can send it to me at 
> alex@cognitect.com .
>
> Thanks,
> Alex
>

Thanks--sure, I am willing to make public the ... bad things I am doing in 
my code.  I have to explain that the ns declaration is very large; it's 
generated by a macro that creates a lot of code.  I wrote it to ease 
interop with a useful but not entirely Clojure-friendly Java library I'm 
using.  This required violating some standard, useful coding guidelines.

This file 

 
contains pretty-printed output from macroexpand-1 (made with Clojure 
1.8.0--the offending macro call is in an aot-compiled file, so it would 
have been harder to start the repl with 1.9.0).  There are actually two ns 
declarations (a trick to avoid some cyclic references).  The code that 
caused the errors begins at line 66 in the second ns.

The macro call in my source is here 
on
 
line 29, and the macro definition is at the bottom of this file 
.
  
Both of those links are to the code just before the commit in which I added 
apostrophes to the instances of java.lang.Object (at line 210 of the macro 
definition file).  This got rid of the errors, and the application seems to 
run correctly.

(If you look at the current version of the code, you'll see that I recently 
changed the project name from free-agent to pasta; 'lein uberjar' didn't 
like the hyphen.)

If you need me to make a minimal example, I can probably do that.

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

Users of the Commander Pattern?

[Daniel Compton]

At work, we’re looking at using the Commander Pattern
 for our applications.
The reference
implementation

is in Clojure, but could be written in anything that can read and write to
Kafka. Has anyone else adopted the Commander Pattern or a similar CQRS +
Kafka architecture? If so, could you talk about your experience and
pros/cons?
-- 

Daniel

-- 
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: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Alex Miller]

I would really appreciate seeing the ns declaration that caused the 
original error. I have not been able to exactly reproduce what you are 
describing. If you can't share it publicly, you can send it to me at 
alex.mil...@cognitect.com.

Thanks,
Alex

On Saturday, March 4, 2017 at 8:10:35 AM UTC-6, Mars0i wrote:
>
> On Saturday, March 4, 2017 at 7:58:38 AM UTC-6, Mars0i wrote:
>>
>> On Saturday, March 4, 2017 at 7:24:05 AM UTC-6, Alex Miller wrote:
>>>
>>> This is definitely related to the gen-class spec, but I'm not at a 
>>> computer to look at enough stuff to say if the bug is your code or the 
>>> spec. 
>>>
>>> You might try quoting rhe class name in case it's getting resolved to a 
>>> class instance? Might be crazy talk.
>>>
>>
>> That produced pretty much the same error:
>>
>> In: [3 :methods 32 2] val: "java.lang.Object" fails spec: 
>> :clojure.core.specs/method at: [:args :clauses :gen-class :options :methods 
>> :return-type] predicate: simple-symbol?
>>
>>  
> Oh--sorry.  You  probably meant the other kind of quoting, i.e. with 
> apostrophe, the Clojure special form quote.  That fixed it.  Thanks very 
> much.
>
>

-- 
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: What makes Clojure Clojure?

[Alex Miller]

cljc is (nothing more than) a file extension (the extra c stands for "common") 
indicating a file that can be read in more than one Clojure platform.

cljc files also support reader conditionals by default on read (but they are of 
course not required if not needed).

-- 
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: Contribute Specter to Clojure core?

[John Newman]

The "language" Specter introduces "specific"ally navigates the "domain" of
Clojure data structures. Regexes also provide a DSL that navigate or
operate over the string/text domain and that's often considered a large,
generic, unstructured domain. What matters is the semantic surface area the
library introduces and how idiomatic those semantics are to the language.
Core.async is arguably as idiomatic as it can be, but it has a large enough
surface area that it hasn't even been folded into clojure.core. And
core.async was created by the core team.

I agree though that given the difficulty of editing deeply nested
structures in Clojure, Specter does at least make a good _candidate_ for
discussing inclusion - Nathan is asking a question that many of us ask when
we're introduced to the awesome powers of Specter, "Why can't something
like this be in core?" It's a real, ubiquitous problem in Clojure that
Specter solves, where not a lot of other solutions yet exist. But given the
core team's decision to not include core.async in core, it's hard to
imagine them including Specter's idiosyncrasies IMO.

But hey, if in a year or two some majority of all new Clojure projects on
GitHub are using Specter - and the semantics have become normalized and
idiosyncratic - then I think we could argue that maybe Specter is the Right
way. Either way, I'll be using Specter when necessary.

On Sun, Mar 5, 2017 at 3:19 PM Gregg Reynolds  wrote:

>
>
> On Mar 5, 2017 2:10 PM, "Gregg Reynolds"  wrote:
>
> see the section titled "deftype and defrecord?" at
> https://clojure.org/reference/datatypes
>
> Specter traffics in abstractions, afaik, just like clojure. it does not
> depend in any way on application concepts like "bank account", so i think
> it's a little unfair to call it x-specific for any x; that makes it sound
> less general than clojure itself, which i do not believe is the case. so it
> is indeed a good _candidate_ for core.  but since i think there are many
> unexplored ways to do the same thing, its too soon.  Not to mention the
> aesthetic question of whether all the UPPER CASE stuff is a good idea.
> Personally i find it a little too magical and opaque.
>
> gregg
>
>
> ps. just as food for thought, what xslt does for xml trees is very similar
> to what specter does for clojure structures. if you're familiar with xslt
> it's not that hard to imagine sth similar in idiomatic clojure that would
> solve the same problems with a very different vocab.
>
> g
>
> --
> 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: Contribute Specter to Clojure core?

[Gregg Reynolds]

On Mar 5, 2017 2:10 PM, "Gregg Reynolds"  wrote:

see the section titled "deftype and defrecord?" at https://clojure.org/
reference/datatypes

Specter traffics in abstractions, afaik, just like clojure. it does not
depend in any way on application concepts like "bank account", so i think
it's a little unfair to call it x-specific for any x; that makes it sound
less general than clojure itself, which i do not believe is the case. so it
is indeed a good _candidate_ for core.  but since i think there are many
unexplored ways to do the same thing, its too soon.  Not to mention the
aesthetic question of whether all the UPPER CASE stuff is a good idea.
Personally i find it a little too magical and opaque.

gregg


ps. just as food for thought, what xslt does for xml trees is very similar
to what specter does for clojure structures. if you're familiar with xslt
it's not that hard to imagine sth similar in idiomatic clojure that would
solve the same problems with a very different vocab.

g

-- 
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: Contribute Specter to Clojure core?

[Gregg Reynolds]

see the section titled "deftype and defrecord?" at
https://clojure.org/reference/datatypes

Specter traffics in abstractions, afaik, just like clojure. it does not
depend in any way on application concepts like "bank account", so i think
it's a little unfair to call it x-specific for any x; that makes it sound
less general than clojure itself, which i do not believe is the case. so it
is indeed a good _candidate_ for core.  but since i think there are many
unexplored ways to do the same thing, its too soon.  Not to mention the
aesthetic question of whether all the UPPER CASE stuff is a good idea.
Personally i find it a little too magical and opaque.

gregg

On Mar 5, 2017 1:40 PM, "John Newman"  wrote:

Okay, let's call it a Context Specific Vocabulary (CSV) ;)

Every function is at least a mini DSL, IMO. And as promising as Spec
sounds, I still haven't trained up on it because of the size of the new
vocabulary (or DSL or whatever you want to call it) it introduces. Adding
semantics is expensive for users.

-- 
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: Contribute Specter to Clojure core?

[John Newman]

Okay, let's call it a Context Specific Vocabulary (CSV) ;)

Every function is at least a mini DSL, IMO. And as promising as Spec
sounds, I still haven't trained up on it because of the size of the new
vocabulary (or DSL or whatever you want to call it) it introduces. Adding
semantics is expensive for users.

Just wondering here, but would it be impossible for a Specter like system
to piggyback on Specs operators for it's navigator vocabulary? Or are the
semantics between the operators and navigators too different?

On Sun, Mar 5, 2017, 2:16 PM Gregg Reynolds  wrote:

>
>
> On Mar 5, 2017 1:04 PM, "Timothy Baldridge"  wrote:
>
> >>  Specter is not a DSL.
>
> Specter implements a set of terms (navigators) specific to the library
> that are interpreted by the library (the transform function) to accomplish
> some task for a specific domain (manipulating data structures). In the same
> way, `update-in` is a DSL. Both Specter and `update-in` support certain
> operators and have certain behaviors under difference occasions. Specter
> may compile down to composed functions, or Clojure code, while `update-in`
> is always interpreted, but the net effect is still the same. They both are
> languages specific to a certain domain.
>
>
> sure, but so is + and every other operator; every op is specific to a
> computational domain (e.g. arithmetic). to me DSL means specific to an
> application domain. since Specter is not tied to any such domain, i think
> it's fair for Nathan to claim it is not a DSL. on the other hand, its
> vocabulary is quite idiosyncratic, imo.
>
> gregg
>
>
> There's noting inherently wrong with using a DSL, they have their places.
> The value of the DSL will different for each project and programmer. In
> some cases the added cognitive overhead of learning the caveats of a new
> DSL may be worth it when compared to the simplification the DSL offers.
> Other times not so much, depends on the context.
>
> Timothy
>
> On Sun, Mar 5, 2017 at 7:14 AM, Nathan Marz  wrote:
>
> To answer a few comments/misconceptions on this thread:
>
> - Specter is not a DSL. Things like ALL and MAP-VALS are first class
> objects that implement the underlying navigator interface. Specter's core
> is a high-performance method of composing implementations of that
> interface. It makes zero assumptions about what kinds of data it will be
> used for. I think any DSL for this problem would ultimately either not be
> generic enough or would be overly complex.
> - If you want to use a number as a navigator, then extend the ImplicitNav
> protocol on numbers and return (nthpath this).
> - Zippers are an advanced form of navigation, and Specter integrates them
> fully in the com.rpl.specter.zipper namespace. However, zippers add
> significant overhead and indirection, and 99.9% of the time you don't need
> them (but they do have the occasional use).
> - I wrote at length about why I think Specter fills a major hole in
> Clojure: http://nathanmarz.com/blog/clojures-missing-piece.html
>
>
> On Saturday, March 4, 2017 at 9:55:49 PM UTC-5, Herwig Hochleitner wrote:
>
> 2017-03-05 0:25 GMT+01:00 Didier :
> > I'm not too sure what the contribs are. Are they simply packages
> maintained
> > by the Clojure team itself, or are they actually part of the standard
> > library?
>
> As I understand it, they aren't any more sanctioned than any
> third-party library, but the goal is to provide a stock of clojure
> libraries under the same license as clojure itself. Also they provide
> a common CI and path into maven central.
>
> 2017-03-04 22:52 GMT+01:00 Gregg Reynolds :
> > it's easy to imagine a more xsl-like (or even css-like) syntax with the
> same
> > functionality
>
> I don't know how it squares up against specter in terms of
> performance, but I've always been fond of the selector-engine in
> enlive, from an engineering elegance POV, as an interface for tree
> query and update.
> It utilizes zippers, but only ever does a single pass (save for some
> weird selectors). Can specter substantially improve on zippers for
> this workload?
> Is there an underlying abstraction, that could sit next to clojure.zip
> or clojure.data.zip?
>
> --
> 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: Contribute Specter to Clojure core?

[Gregg Reynolds]

On Mar 5, 2017 1:04 PM, "Timothy Baldridge"  wrote:

>>  Specter is not a DSL.

Specter implements a set of terms (navigators) specific to the library that
are interpreted by the library (the transform function) to accomplish some
task for a specific domain (manipulating data structures). In the same way,
`update-in` is a DSL. Both Specter and `update-in` support certain
operators and have certain behaviors under difference occasions. Specter
may compile down to composed functions, or Clojure code, while `update-in`
is always interpreted, but the net effect is still the same. They both are
languages specific to a certain domain.


sure, but so is + and every other operator; every op is specific to a
computational domain (e.g. arithmetic). to me DSL means specific to an
application domain. since Specter is not tied to any such domain, i think
it's fair for Nathan to claim it is not a DSL. on the other hand, its
vocabulary is quite idiosyncratic, imo.

gregg


There's noting inherently wrong with using a DSL, they have their places.
The value of the DSL will different for each project and programmer. In
some cases the added cognitive overhead of learning the caveats of a new
DSL may be worth it when compared to the simplification the DSL offers.
Other times not so much, depends on the context.

Timothy

On Sun, Mar 5, 2017 at 7:14 AM, Nathan Marz  wrote:

> To answer a few comments/misconceptions on this thread:
>
> - Specter is not a DSL. Things like ALL and MAP-VALS are first class
> objects that implement the underlying navigator interface. Specter's core
> is a high-performance method of composing implementations of that
> interface. It makes zero assumptions about what kinds of data it will be
> used for. I think any DSL for this problem would ultimately either not be
> generic enough or would be overly complex.
> - If you want to use a number as a navigator, then extend the ImplicitNav
> protocol on numbers and return (nthpath this).
> - Zippers are an advanced form of navigation, and Specter integrates them
> fully in the com.rpl.specter.zipper namespace. However, zippers add
> significant overhead and indirection, and 99.9% of the time you don't need
> them (but they do have the occasional use).
> - I wrote at length about why I think Specter fills a major hole in
> Clojure: http://nathanmarz.com/blog/clojures-missing-piece.html
>
>
> On Saturday, March 4, 2017 at 9:55:49 PM UTC-5, Herwig Hochleitner wrote:
>>
>> 2017-03-05 0:25 GMT+01:00 Didier :
>> > I'm not too sure what the contribs are. Are they simply packages
>> maintained
>> > by the Clojure team itself, or are they actually part of the standard
>> > library?
>>
>> As I understand it, they aren't any more sanctioned than any
>> third-party library, but the goal is to provide a stock of clojure
>> libraries under the same license as clojure itself. Also they provide
>> a common CI and path into maven central.
>>
>> 2017-03-04 22:52 GMT+01:00 Gregg Reynolds :
>> > it's easy to imagine a more xsl-like (or even css-like) syntax with the
>> same
>> > functionality
>>
>> I don't know how it squares up against specter in terms of
>> performance, but I've always been fond of the selector-engine in
>> enlive, from an engineering elegance POV, as an interface for tree
>> query and update.
>> It utilizes zippers, but only ever does a single pass (save for some
>> weird selectors). Can specter substantially improve on zippers for
>> this workload?
>> Is there an underlying abstraction, that could sit next to clojure.zip
>> or clojure.data.zip?
>>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: Contribute Specter to Clojure core?

[Timothy Baldridge]

>>  Specter is not a DSL.

Specter implements a set of terms (navigators) specific to the library that
are interpreted by the library (the transform function) to accomplish some
task for a specific domain (manipulating data structures). In the same way,
`update-in` is a DSL. Both Specter and `update-in` support certain
operators and have certain behaviors under difference occasions. Specter
may compile down to composed functions, or Clojure code, while `update-in`
is always interpreted, but the net effect is still the same. They both are
languages specific to a certain domain.

There's noting inherently wrong with using a DSL, they have their places.
The value of the DSL will different for each project and programmer. In
some cases the added cognitive overhead of learning the caveats of a new
DSL may be worth it when compared to the simplification the DSL offers.
Other times not so much, depends on the context.

Timothy

On Sun, Mar 5, 2017 at 7:14 AM, Nathan Marz  wrote:

> To answer a few comments/misconceptions on this thread:
>
> - Specter is not a DSL. Things like ALL and MAP-VALS are first class
> objects that implement the underlying navigator interface. Specter's core
> is a high-performance method of composing implementations of that
> interface. It makes zero assumptions about what kinds of data it will be
> used for. I think any DSL for this problem would ultimately either not be
> generic enough or would be overly complex.
> - If you want to use a number as a navigator, then extend the ImplicitNav
> protocol on numbers and return (nthpath this).
> - Zippers are an advanced form of navigation, and Specter integrates them
> fully in the com.rpl.specter.zipper namespace. However, zippers add
> significant overhead and indirection, and 99.9% of the time you don't need
> them (but they do have the occasional use).
> - I wrote at length about why I think Specter fills a major hole in
> Clojure: http://nathanmarz.com/blog/clojures-missing-piece.html
>
>
> On Saturday, March 4, 2017 at 9:55:49 PM UTC-5, Herwig Hochleitner wrote:
>>
>> 2017-03-05 0:25 GMT+01:00 Didier :
>> > I'm not too sure what the contribs are. Are they simply packages
>> maintained
>> > by the Clojure team itself, or are they actually part of the standard
>> > library?
>>
>> As I understand it, they aren't any more sanctioned than any
>> third-party library, but the goal is to provide a stock of clojure
>> libraries under the same license as clojure itself. Also they provide
>> a common CI and path into maven central.
>>
>> 2017-03-04 22:52 GMT+01:00 Gregg Reynolds :
>> > it's easy to imagine a more xsl-like (or even css-like) syntax with the
>> same
>> > functionality
>>
>> I don't know how it squares up against specter in terms of
>> performance, but I've always been fond of the selector-engine in
>> enlive, from an engineering elegance POV, as an interface for tree
>> query and update.
>> It utilizes zippers, but only ever does a single pass (save for some
>> weird selectors). Can specter substantially improve on zippers for
>> this workload?
>> Is there an underlying abstraction, that could sit next to clojure.zip
>> or clojure.data.zip?
>>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: What makes Clojure Clojure?

[Colin Yates]

cljs = ClojureScript
clr = Clojure on the Common Language Runtime (aka .NET)
cljc = Something that can be interpreted in either clj and cljs (and
clr I assume?) using Clojure conditionals.

For more info on the excellent cljc read
https://clojure.org/guides/reader_conditionals.

If you haven't yet experienced an app with Clojure on the backend,
ClojureScript on the front end and the messaging logic using cljc,
transit and EDN then you should treat yourself and try it :-).

On 5 March 2017 at 16:44, Kevin Baldor  wrote:
> I feel like it should be obvious, but what are the acronyms (initialisms?)
> clj and cljc?
>
> I'm assuming that cljs is ClojureScript.
>
> Sent from my iPhone
>
> On Mar 4, 2017, at 6:46 PM, John Newman  wrote:
>
> Yeah, only Rich can really answer that question, right? :) But for me,
> Clojure is increasingly becoming cljc. When a library advertises
> compatibility in both clj and cljs, it just looks shinier to me. Feels like
> a trend for Clojure libraries in general. And if agents and STM were on
> cljs, I'd probably reach of those tools more often on both platforms.
>
> On that note, if some Clojure concurrency magician would implement a
> lightweight threading library in cljc, which worked on both single-threaded
> cljs (offloading to webworkers where available) and JVM/CLR, allowing for
> STM on cljc... Hell, I'd throw down on a bounty for that. It would really
> bring cljs and clj into closer parity. And it would make cljs even more
> appetizing to js programmers. And it would reunite cljs with one of clj's
> original selling points - how immutability and persistent structures allow
> for unparalleled (lol) concurrency solutions.
>
> I almost got a rudimentary pmap thing working in cljs on core.async with
> webworkers by using a binding-hack macro I found online somewhere. I
> couldn't find great docs out there though on how to implement a lightweight
> threading library.
>
> On Sat, Mar 4, 2017 at 6:51 PM Didier  wrote:
>>
>> The Specter post about if it should be made into core or not got me
>> wondering what makes Clojure Clojure.
>>
>> I'm trying to wrap my head around what is the most minimal set of things
>> that uniquely make up Clojure.
>>
>> Right now, in that set I've got:
>>
>> The Clojure syntax and its semantics
>> The Clojure special forms and their semantics
>> The Clojure core libraries and their semantics
>>
>> So if I implemented a compiler that worked with the above set, it would be
>> a valid Clojure compiler.
>>
>> Now, ClojureScript appears to me like it is not Clojure, but a dialect of
>> it. I say that because it breaks some of the syntax semantics of Clojure,
>> like not allowing macros in the same namespace as functions. It also breaks
>> some of the core semantics, like def creating standard JS vars and not
>> Clojure Vars. In this respect, a language like hy-lang is also a Clojure
>> dialect, granted it shares even less of the Clojure set.
>>
>> Is ClojureCLR a dialect of Clojure, or is it a true Clojure
>> implementation?
>>
>> One last thing that is interesting about Clojure versus other languages is
>> that it does not provide standard IO. These two things make it so that it is
>> kind of dependent on its host to complete its offering as a programming
>> language, which means any Clojure compiler will need to provide a mechanism
>> for IO. Those would always differ from Clojures to Clojures, so I don't
>> think that's part of what makes Clojure Clojure.
>>
>> What are others thoughts on this?
>>
>> P.S.: There's no point to this thread, its mostly curiosity.
>>
>> --
>> 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 

Re: What makes Clojure Clojure?

[Kevin Baldor]

I feel like it should be obvious, but what are the acronyms (initialisms?) clj 
and cljc?

I'm assuming that cljs is ClojureScript.

Sent from my iPhone

> On Mar 4, 2017, at 6:46 PM, John Newman  wrote:
> 
> Yeah, only Rich can really answer that question, right? :) But for me, 
> Clojure is increasingly becoming cljc. When a library advertises 
> compatibility in both clj and cljs, it just looks shinier to me. Feels like a 
> trend for Clojure libraries in general. And if agents and STM were on cljs, 
> I'd probably reach of those tools more often on both platforms. 
> 
> On that note, if some Clojure concurrency magician would implement a 
> lightweight threading library in cljc, which worked on both single-threaded 
> cljs (offloading to webworkers where available) and JVM/CLR, allowing for STM 
> on cljc... Hell, I'd throw down on a bounty for that. It would really bring 
> cljs and clj into closer parity. And it would make cljs even more appetizing 
> to js programmers. And it would reunite cljs with one of clj's original 
> selling points - how immutability and persistent structures allow for 
> unparalleled (lol) concurrency solutions.
> 
> I almost got a rudimentary pmap thing working in cljs on core.async with 
> webworkers by using a binding-hack macro I found online somewhere. I couldn't 
> find great docs out there though on how to implement a lightweight threading 
> library.
> 
> On Sat, Mar 4, 2017 at 6:51 PM Didier  wrote:
>> The Specter post about if it should be made into core or not got me 
>> wondering what makes Clojure Clojure.
>> 
>> I'm trying to wrap my head around what is the most minimal set of things 
>> that uniquely make up Clojure.
>> 
>> Right now, in that set I've got:
>> The Clojure syntax and its semantics
>> The Clojure special forms and their semantics
>> The Clojure core libraries and their semantics
>> So if I implemented a compiler that worked with the above set, it would be a 
>> valid Clojure compiler.
>> 
>> Now, ClojureScript appears to me like it is not Clojure, but a dialect of 
>> it. I say that because it breaks some of the syntax semantics of Clojure, 
>> like not allowing macros in the same namespace as functions. It also breaks 
>> some of the core semantics, like def creating standard JS vars and not 
>> Clojure Vars. In this respect, a language like hy-lang is also a Clojure 
>> dialect, granted it shares even less of the Clojure set.
>> 
>> Is ClojureCLR a dialect of Clojure, or is it a true Clojure implementation?
>> 
>> One last thing that is interesting about Clojure versus other languages is 
>> that it does not provide standard IO. These two things make it so that it is 
>> kind of dependent on its host to complete its offering as a programming 
>> language, which means any Clojure compiler will need to provide a mechanism 
>> for IO. Those would always differ from Clojures to Clojures, so I don't 
>> think that's part of what makes Clojure Clojure.
>> 
>> What are others thoughts on this?
>> 
>> P.S.: There's no point to this thread, its mostly curiosity.
>> -- 
>> 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.

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

Re: Contribute Specter to Clojure core?

[Nathan Marz]

To answer a few comments/misconceptions on this thread:

- Specter is not a DSL. Things like ALL and MAP-VALS are first class 
objects that implement the underlying navigator interface. Specter's core 
is a high-performance method of composing implementations of that 
interface. It makes zero assumptions about what kinds of data it will be 
used for. I think any DSL for this problem would ultimately either not be 
generic enough or would be overly complex. 
- If you want to use a number as a navigator, then extend the ImplicitNav 
protocol on numbers and return (nthpath this).
- Zippers are an advanced form of navigation, and Specter integrates them 
fully in the com.rpl.specter.zipper namespace. However, zippers add 
significant overhead and indirection, and 99.9% of the time you don't need 
them (but they do have the occasional use).
- I wrote at length about why I think Specter fills a major hole in 
Clojure: http://nathanmarz.com/blog/clojures-missing-piece.html


On Saturday, March 4, 2017 at 9:55:49 PM UTC-5, Herwig Hochleitner wrote:
>
> 2017-03-05 0:25 GMT+01:00 Didier : 
> > I'm not too sure what the contribs are. Are they simply packages 
> maintained 
> > by the Clojure team itself, or are they actually part of the standard 
> > library? 
>
> As I understand it, they aren't any more sanctioned than any 
> third-party library, but the goal is to provide a stock of clojure 
> libraries under the same license as clojure itself. Also they provide 
> a common CI and path into maven central. 
>
> 2017-03-04 22:52 GMT+01:00 Gregg Reynolds  >: 
> > it's easy to imagine a more xsl-like (or even css-like) syntax with the 
> same 
> > functionality 
>
> I don't know how it squares up against specter in terms of 
> performance, but I've always been fond of the selector-engine in 
> enlive, from an engineering elegance POV, as an interface for tree 
> query and update. 
> It utilizes zippers, but only ever does a single pass (save for some 
> weird selectors). Can specter substantially improve on zippers for 
> this workload? 
> Is there an underlying abstraction, that could sit next to clojure.zip 
> or clojure.data.zip? 
>

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