Re: Cursive and gen-class

[Colin Fleming]

I totally agree that some people are endlessly amazing.

On 23 August 2015 at 03:14, Fluid Dynamics  wrote:

> On Saturday, August 22, 2015 at 8:42:42 PM UTC-4, William la Forge wrote:
>>
>> Loving this. I had uninstalled cursive so I could reinstall. But the
>> download of the plugin fails and when installing from disk it says
>> cursive-14-0.1.60 is not compatible. (I'm running with idea 14.1.4.)
>>
>> Deleted the idea system cache, restarted, still incompatible. :-(
>>
>
> It never ceases to amaze me that people pay for proprietary junk like
> IntelliJ and Windoze that are prone to hose themselves to the point of
> needing a format+reinstall to get them working again, while there are good,
> free alternatives out there like Eclipse/CCW and Linux that Just Work(tm).
>
> --
> 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: Cursive and gen-class

[Colin Fleming]

Hi William,

You have to ensure that you download the version of Cursive that
corresponds to your IntelliJ version - the links are in the getting started
guide here: https://cursiveclojure.com/userguide/. It's unfortunate but
necessary that the versions coincide since the IntelliJ APIs change from
version to version.

Cheers,
Colin

On 23 August 2015 at 03:22, William la Forge  wrote:

> Set the ide to Java 8 and clojure 1.7. And now it works great. Good catch.
> Thanks!
>
> As for Cursive, I'm guessing it is set to be compatible with idea 14.0.x,
> though fortunately when you go to 14.1 the plugins get grandfathered in.
> Which is a bit weird!
>
>
> On Saturday, August 22, 2015 at 8:12:30 PM UTC-4, William la Forge wrote:
>>
>> lean version shows java 8, but the ide sdk is java7. Didn't know they
>> would be connected. :0
>>
>> On Saturday, August 22, 2015 at 6:56:46 PM UTC-4, Colin Fleming wrote:
>>>
>>> That's very strange. I'd need more detailed instructions to try to
>>> reproduce this. But the class it can't find is new in Java 8 so it looks
>>> like you have a JVM version issue. I suspect that this shows up in Cursive
>>> but not in lein because you're using a different JDK version in your
>>> Cursive project than the one that is picked up on the command line.
>>>
>>> I'm guessing that java -version on the command line will show Java 8,
>>> but the one you have configured in your Cursive project (File->Project
>>> Structure->Project->Project SDK and File->Project Structure->Modules->(your
>>> module)->Module SDK) is less than that. Is that the case?
>>>
>>> On 22 August 2015 at 23:58, William la Forge  wrote:
>>>
 Bingo! Everything works when I revert to clojure 1.6.0.


 On Saturday, August 22, 2015 at 5:49:24 PM UTC-4, William la Forge
 wrote:
>
> More weirdness. This works:
>
> (let [^Object aa (.seq a5)]
>   (println (.getClass aa)))
>
>
> But not this:
>
>
> (let [^AASetSequence aa (.seq a5)]
>   (println (.getClass aa
>
>
> Nor, of course, this:
>
>
> (let [^AASetSequence aa (.seq a5)]
>   (println (.count aa)))
>
>
> Here's the error I'm getting now:
>
>
> Information:8/22/2015 5:45 PM - Compilation completed with 1 error and 0 
> warnings in 2s 743ms
> C:\Users\Bill\Documents\GitHub\aa-collections\test\aa_collections\immutable_set_test.clj
> Error:(26, 12) clojure: java.lang.NoClassDefFoundError: 
> java/util/function/UnaryOperator, 
> compiling:(aa_collections/immutable_set_test.clj:26:12)
> java.lang.ClassNotFoundException: java.util.function.UnaryOperator
>  at java.net.URLClassLoader$1.run (URLClassLoader.java:366)
> java.net.URLClassLoader$1.run (URLClassLoader.java:355)
> java.security.AccessController.doPrivileged (AccessController.java:-2)
> java.net.URLClassLoader.findClass (URLClassLoader.java:354)
> java.lang.ClassLoader.loadClass (ClassLoader.java:425)
> java.lang.ClassLoader.loadClass (ClassLoader.java:358)
> java.lang.Class.getDeclaredMethods0 (Class.java:-2)
> java.lang.Class.privateGetDeclaredMethods (Class.java:2570)
> java.lang.Class.privateGetPublicMethods (Class.java:2690)
> java.lang.Class.getMethods (Class.java:1467)
>
>
>
> On Saturday, August 22, 2015 at 5:37:13 PM UTC-4, William la Forge
> wrote:
>>
>> Hi Colin!
>>
>> I've set it up to compile all. No doubt this will be very helpful as
>> I will no longer need to compile using an external `lein compile`. But 
>> run
>> still dies on the call (.getClass x), when x is a gen-class compiled 
>> class
>> instance.
>>
>> On the other hand I still can not credit this as a Cursive bug.
>> Calling methods on gen-class compiled class instances is to basic. But it
>> is likely related to Cursive, as 'lein test' works great.
>>
>> On Saturday, August 22, 2015 at 4:24:40 PM UTC-4, Colin Fleming wrote:
>>>
>>> Hi William,
>>>
>>> Right, you'll need to tell Cursive to compile that namespace in 
>>> *Settings->Build,
>>> Execution, Deployment->Compiler->Clojure Compiler*. Once you've
>>> done that things should work. Cursive doesn't currently pick the set of
>>> namespaces to be compiled up from lein - it probably should.
>>>
>>> Cheers,
>>> Colin
>>>
>>> On 22 August 2015 at 17:17, William la Forge 
>>> wrote:
>>>
 I searched and did not see anything recent on gen-class problems in
 Cursive. I find when I have a reference to a gen-class instance that
 instance? works in Cursive but .getClass does not. (Everything works 
 with
 lein, of course.)

 What I am trying to do is to call the count method via (.count x).
 What I do not want to do is call the clojure count function, (count x).
 Again, no issues wi

Re: How can find something inside heavily nested data structure ?

[henrik42]

OK,  so in this special case you one would just use

(def s
  [{"n" {"id" "a"} "d" 2 "children" [{"n" {"id" "c"} "d" 4 "children" 
nil}]} {"n" {"id" "b"} "d" 3 "children" nil}])

(some
 (fn [x]
   (and (map? x)
(some
 #{{"id" "c"}}
 (vals x
 (tree-seq coll? seq s))

-- 
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: Cursive and gen-class

[William la Forge]

OK. NOW I see support for 14.1. Why I didn't see that before! (hand slaps 
forehead)

On Sunday, August 23, 2015 at 4:00:33 AM UTC-4, Colin Fleming wrote:
>
> Hi William,
>
> You have to ensure that you download the version of Cursive that 
> corresponds to your IntelliJ version - the links are in the getting started 
> guide here: https://cursiveclojure.com/userguide/. It's unfortunate but 
> necessary that the versions coincide since the IntelliJ APIs change from 
> version to version.
>
> Cheers,
> Colin
>
> On 23 August 2015 at 03:22, William la Forge  > wrote:
>
>> Set the ide to Java 8 and clojure 1.7. And now it works great. Good 
>> catch. Thanks!
>>
>> As for Cursive, I'm guessing it is set to be compatible with idea 14.0.x, 
>> though fortunately when you go to 14.1 the plugins get grandfathered in. 
>> Which is a bit weird!
>>
>>
>> On Saturday, August 22, 2015 at 8:12:30 PM UTC-4, William la Forge wrote:
>>>
>>> lean version shows java 8, but the ide sdk is java7. Didn't know they 
>>> would be connected. :0
>>>
>>> On Saturday, August 22, 2015 at 6:56:46 PM UTC-4, Colin Fleming wrote:

 That's very strange. I'd need more detailed instructions to try to 
 reproduce this. But the class it can't find is new in Java 8 so it looks 
 like you have a JVM version issue. I suspect that this shows up in Cursive 
 but not in lein because you're using a different JDK version in your 
 Cursive project than the one that is picked up on the command line. 

 I'm guessing that java -version on the command line will show Java 8, 
 but the one you have configured in your Cursive project (File->Project 
 Structure->Project->Project SDK and File->Project 
 Structure->Modules->(your 
 module)->Module SDK) is less than that. Is that the case?

 On 22 August 2015 at 23:58, William la Forge  wrote:

> Bingo! Everything works when I revert to clojure 1.6.0.
>
>
> On Saturday, August 22, 2015 at 5:49:24 PM UTC-4, William la Forge 
> wrote:
>>
>> More weirdness. This works:
>>
>> (let [^Object aa (.seq a5)]
>>   (println (.getClass aa)))
>>
>>
>> But not this:
>>
>>
>> (let [^AASetSequence aa (.seq a5)]
>>   (println (.getClass aa
>>
>>
>> Nor, of course, this:
>>
>>
>> (let [^AASetSequence aa (.seq a5)]
>>   (println (.count aa)))
>>
>>
>> Here's the error I'm getting now:
>>
>>
>> Information:8/22/2015 5:45 PM - Compilation completed with 1 error and 0 
>> warnings in 2s 743ms
>> C:\Users\Bill\Documents\GitHub\aa-collections\test\aa_collections\immutable_set_test.clj
>> Error:(26, 12) clojure: java.lang.NoClassDefFoundError: 
>> java/util/function/UnaryOperator, 
>> compiling:(aa_collections/immutable_set_test.clj:26:12)
>> java.lang.ClassNotFoundException: java.util.function.UnaryOperator
>>  at java.net.URLClassLoader$1.run (URLClassLoader.java:366)
>> java.net.URLClassLoader$1.run (URLClassLoader.java:355)
>> java.security.AccessController.doPrivileged 
>> (AccessController.java:-2)
>> java.net.URLClassLoader.findClass (URLClassLoader.java:354)
>> java.lang.ClassLoader.loadClass (ClassLoader.java:425)
>> java.lang.ClassLoader.loadClass (ClassLoader.java:358)
>> java.lang.Class.getDeclaredMethods0 (Class.java:-2)
>> java.lang.Class.privateGetDeclaredMethods (Class.java:2570)
>> java.lang.Class.privateGetPublicMethods (Class.java:2690)
>> java.lang.Class.getMethods (Class.java:1467)
>>
>>
>>
>> On Saturday, August 22, 2015 at 5:37:13 PM UTC-4, William la Forge 
>> wrote:
>>>
>>> Hi Colin!
>>>
>>> I've set it up to compile all. No doubt this will be very helpful as 
>>> I will no longer need to compile using an external `lein compile`. But 
>>> run 
>>> still dies on the call (.getClass x), when x is a gen-class compiled 
>>> class 
>>> instance.
>>>
>>> On the other hand I still can not credit this as a Cursive bug. 
>>> Calling methods on gen-class compiled class instances is to basic. But 
>>> it 
>>> is likely related to Cursive, as 'lein test' works great.
>>>
>>> On Saturday, August 22, 2015 at 4:24:40 PM UTC-4, Colin Fleming 
>>> wrote:

 Hi William,

 Right, you'll need to tell Cursive to compile that namespace in 
 *Settings->Build, 
 Execution, Deployment->Compiler->Clojure Compiler*. Once you've 
 done that things should work. Cursive doesn't currently pick the set 
 of 
 namespaces to be compiled up from lein - it probably should.

 Cheers,
 Colin

 On 22 August 2015 at 17:17, William la Forge  
 wrote:

> I searched and did not see anything recent on gen-class problems 
> in Cursive. I find when 

Re: Rabid wild animals in my clojure argument lists, code gets infected.

[Timothy Baldridge]

It's generally considered better practice to pass maps to a function
instead of keyword arguments. This also has the nice side-effect of making
it easier to call programmatically  from other functions. For example:

(my-func 1 2 (assoc default-opts :c 42)) is way cleaner than

(apply my-func 1 2 (mapcat identity (assoc default-opts :c 42)))

So don't do keyword argument, it rarely works out well. Instead accept a
map of options and validate it with asserts, ignoring "extra" data. A map
is a map, it shouldn't matter if it contains extra data.

Timothy

On Sat, Aug 22, 2015 at 7:21 PM, James Reeves  wrote:

> https://github.com/roomkey/annotate is another possibility
>
> - James
>
> On 23 August 2015 at 02:06, Colin Yates  wrote:
>
>> Hi Dave, it _isn't_ an Illegal argument though :-), your destructuring
>> is simply ignoring that parameter.
>>
>> However, I get the pain and solutions might be (in order of 'heavyness'):
>>  - http://blog.fogus.me/2009/12/21/clojures-pre-and-post/
>>  - https://github.com/Prismatic/schema
>>  - http://typedclojure.org/
>>
>> HTH
>>
>> Dave Tenny writes:
>>
>> > I sure wish Clojure would generate "IllegalArgumentException" in the
>> > following sample case:
>> >
>> > (defn foo [a b & {:keys [c d]}] 1)
>> > (foo 1 2 :e 5) ; blithely ignores :e 5
>> >
>> > I understand that Clojure's destructuring things are very nice, and more
>> > powerful than Common Lisp's, and I like
>> > that when I need it.
>> >
>> > However I can't tell you how many times I've been bitten by this. Some
>> > simple typo or other other parameter name error on keyword arguments
>> > with untended and way-too-long-to-debug consequences.
>> >
>> > In my mind, on this subject, Common Lisp lambda lists got this right and
>> > Clojure gets a poor grade.
>> > Something about being doomed to repeat history.  In Common Lisp, if you
>> > really wanted to allow other (arbitrary) keywords you'd
>> > just use &allow-other-keys.
>> >
>> > Maybe clojure should only allow the above case to go
>> un-complained-about if
>> > :as was specified for the map.
>> >
>> > If there's some automatic enforcement I'm missing that comes with 'defn'
>> > please let me know, I'm still learning the language.
>> >
>> > I've thought more that once about making a common lisp DEFUN statement
>> that
>> > maps to DEFN but implements
>> > lambda list semantics (including 'supplied-p' parameters).  I've just
>> been
>> > too lazy to do it.
>> >
>> > It would also likely perform poorly after injecting the additional
>> > checks/rearrangements into the function on top of what Clojure has
>> already
>> > done,
>> > so I suppose it would have to be taken a step further so that it didn't
>> > generate DEFN expressions at all but was implemented at DEFN's level as
>> > a seperately named form.
>> >
>> > Tips welcome.  Just thinking aloud.
>> >
>> > - Dave
>>
>> --
>> Sent with my mu4e
>>
>> --
>> 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.
>



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

Re: Rabid wild animals in my clojure argument lists, code gets infected.

[Dave Tenny]

The point of my colorful title and judgmental post is that in the example,
passing :e for the declared parameters as declared is a pointless operation
at best, and in most practical situations it is also an erroneous
operation.

The language designers have (arguably for the good) chosen to complain
about various actual argument mismatches vs. formal parameters.

If I tried to call foo with only one argument I'd get an error about
missing arguments (or more generally, arity).
Similarly, in this case, calling foo with :e should complain about
superfluous arguments, all assuming that foo is declared as intended.
Without an :as option on the destructuring, there is nothing that can be
done to meaningfully process a keyword to the function named :e.

I am proposing the language should do better in this case. If not now,
perhaps 2.0.


On Sat, Aug 22, 2015 at 9:06 PM, Colin Yates  wrote:

> Hi Dave, it _isn't_ an Illegal argument though :-), your destructuring
> is simply ignoring that parameter.
>
> However, I get the pain and solutions might be (in order of 'heavyness'):
>  - http://blog.fogus.me/2009/12/21/clojures-pre-and-post/
>  - https://github.com/Prismatic/schema
>  - http://typedclojure.org/
>
> HTH
>
> Dave Tenny writes:
>
> > I sure wish Clojure would generate "IllegalArgumentException" in the
> > following sample case:
> >
> > (defn foo [a b & {:keys [c d]}] 1)
> > (foo 1 2 :e 5) ; blithely ignores :e 5
> >
> > I understand that Clojure's destructuring things are very nice, and more
> > powerful than Common Lisp's, and I like
> > that when I need it.
> >
> > However I can't tell you how many times I've been bitten by this. Some
> > simple typo or other other parameter name error on keyword arguments
> > with untended and way-too-long-to-debug consequences.
> >
> > In my mind, on this subject, Common Lisp lambda lists got this right and
> > Clojure gets a poor grade.
> > Something about being doomed to repeat history.  In Common Lisp, if you
> > really wanted to allow other (arbitrary) keywords you'd
> > just use &allow-other-keys.
> >
> > Maybe clojure should only allow the above case to go un-complained-about
> if
> > :as was specified for the map.
> >
> > If there's some automatic enforcement I'm missing that comes with 'defn'
> > please let me know, I'm still learning the language.
> >
> > I've thought more that once about making a common lisp DEFUN statement
> that
> > maps to DEFN but implements
> > lambda list semantics (including 'supplied-p' parameters).  I've just
> been
> > too lazy to do it.
> >
> > It would also likely perform poorly after injecting the additional
> > checks/rearrangements into the function on top of what Clojure has
> already
> > done,
> > so I suppose it would have to be taken a step further so that it didn't
> > generate DEFN expressions at all but was implemented at DEFN's level as
> > a seperately named form.
> >
> > Tips welcome.  Just thinking aloud.
> >
> > - Dave
>
> --
> Sent with my mu4e
>
> --
> 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/3-CevvzQg1s/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: Rabid wild animals in my clojure argument lists, code gets infected.

[Dave Tenny]

Note Colin, if I had declared foo differenlty, e.g. (defn foo [a b {:keys
[c d]}), that would be slightly different since it requires a map as third
argument.  But that is not the case with
(defn foo [a b & {:keys [c d]}]).  It may be using maps under the hood, but
none of my formal parameters are necessarily intended to be bound to maps
in this case, and I'm looking for a very fixed set of keywords in the
function call.



On Sun, Aug 23, 2015 at 10:17 AM, Dave Tenny  wrote:

> The point of my colorful title and judgmental post is that in the example,
> passing :e for the declared parameters as declared is a pointless operation
> at best, and in most practical situations it is also an erroneous
> operation.
>
> The language designers have (arguably for the good) chosen to complain
> about various actual argument mismatches vs. formal parameters.
>
> If I tried to call foo with only one argument I'd get an error about
> missing arguments (or more generally, arity).
> Similarly, in this case, calling foo with :e should complain about
> superfluous arguments, all assuming that foo is declared as intended.
> Without an :as option on the destructuring, there is nothing that can be
> done to meaningfully process a keyword to the function named :e.
>
> I am proposing the language should do better in this case. If not now,
> perhaps 2.0.
>
>
> On Sat, Aug 22, 2015 at 9:06 PM, Colin Yates 
> wrote:
>
>> Hi Dave, it _isn't_ an Illegal argument though :-), your destructuring
>> is simply ignoring that parameter.
>>
>> However, I get the pain and solutions might be (in order of 'heavyness'):
>>  - http://blog.fogus.me/2009/12/21/clojures-pre-and-post/
>>  - https://github.com/Prismatic/schema
>>  - http://typedclojure.org/
>>
>> HTH
>>
>> Dave Tenny writes:
>>
>> > I sure wish Clojure would generate "IllegalArgumentException" in the
>> > following sample case:
>> >
>> > (defn foo [a b & {:keys [c d]}] 1)
>> > (foo 1 2 :e 5) ; blithely ignores :e 5
>> >
>> > I understand that Clojure's destructuring things are very nice, and more
>> > powerful than Common Lisp's, and I like
>> > that when I need it.
>> >
>> > However I can't tell you how many times I've been bitten by this. Some
>> > simple typo or other other parameter name error on keyword arguments
>> > with untended and way-too-long-to-debug consequences.
>> >
>> > In my mind, on this subject, Common Lisp lambda lists got this right and
>> > Clojure gets a poor grade.
>> > Something about being doomed to repeat history.  In Common Lisp, if you
>> > really wanted to allow other (arbitrary) keywords you'd
>> > just use &allow-other-keys.
>> >
>> > Maybe clojure should only allow the above case to go
>> un-complained-about if
>> > :as was specified for the map.
>> >
>> > If there's some automatic enforcement I'm missing that comes with 'defn'
>> > please let me know, I'm still learning the language.
>> >
>> > I've thought more that once about making a common lisp DEFUN statement
>> that
>> > maps to DEFN but implements
>> > lambda list semantics (including 'supplied-p' parameters).  I've just
>> been
>> > too lazy to do it.
>> >
>> > It would also likely perform poorly after injecting the additional
>> > checks/rearrangements into the function on top of what Clojure has
>> already
>> > done,
>> > so I suppose it would have to be taken a step further so that it didn't
>> > generate DEFN expressions at all but was implemented at DEFN's level as
>> > a seperately named form.
>> >
>> > Tips welcome.  Just thinking aloud.
>> >
>> > - Dave
>>
>> --
>> Sent with my mu4e
>>
>> --
>> 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/3-CevvzQg1s/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, se

Re: Rabid wild animals in my clojure argument lists, code gets infected.

[Dave Tenny]

Timothy, I think maps vs keywords is a matter of preference.  Certainly
there are cases where I use maps of options instead of keywords, but it
depends on what I'm doing.   Lisp and keywords go way back, and I like
keywords when I'm using lisp packages/namespaces as the equivalent of an
interactive query language.

Even for the case of pure options passed as a map, you'll still potentially
have cases where you might like to validate that only *expected* keywords
were used. Whether a map as argument or a :as option to destructuring. And
it's all well and good to let the user of those maps write code to enforce
that.

However in the traditional use of keywords naming formal parameters there's
a long Common Lisp (at least) history of validating these bindings,
and there's also compile time capabilities too, though perhaps less
effectively in Clojure than CL.  Clojure has provided these keyword
capabilities,
I just object to this one hole because it has zero up side that I can see,
and substantial downside to writing correct programs.

On Sun, Aug 23, 2015 at 10:12 AM, Timothy Baldridge 
wrote:

> It's generally considered better practice to pass maps to a function
> instead of keyword arguments. This also has the nice side-effect of making
> it easier to call programmatically  from other functions. For example:
>
> (my-func 1 2 (assoc default-opts :c 42)) is way cleaner than
>
> (apply my-func 1 2 (mapcat identity (assoc default-opts :c 42)))
>
> So don't do keyword argument, it rarely works out well. Instead accept a
> map of options and validate it with asserts, ignoring "extra" data. A map
> is a map, it shouldn't matter if it contains extra data.
>
> Timothy
>
> On Sat, Aug 22, 2015 at 7:21 PM, James Reeves 
> wrote:
>
>> https://github.com/roomkey/annotate is another possibility
>>
>> - James
>>
>> On 23 August 2015 at 02:06, Colin Yates  wrote:
>>
>>> Hi Dave, it _isn't_ an Illegal argument though :-), your destructuring
>>> is simply ignoring that parameter.
>>>
>>> However, I get the pain and solutions might be (in order of 'heavyness'):
>>>  - http://blog.fogus.me/2009/12/21/clojures-pre-and-post/
>>>  - https://github.com/Prismatic/schema
>>>  - http://typedclojure.org/
>>>
>>> HTH
>>>
>>> Dave Tenny writes:
>>>
>>> > I sure wish Clojure would generate "IllegalArgumentException" in the
>>> > following sample case:
>>> >
>>> > (defn foo [a b & {:keys [c d]}] 1)
>>> > (foo 1 2 :e 5) ; blithely ignores :e 5
>>> >
>>> > I understand that Clojure's destructuring things are very nice, and
>>> more
>>> > powerful than Common Lisp's, and I like
>>> > that when I need it.
>>> >
>>> > However I can't tell you how many times I've been bitten by this. Some
>>> > simple typo or other other parameter name error on keyword arguments
>>> > with untended and way-too-long-to-debug consequences.
>>> >
>>> > In my mind, on this subject, Common Lisp lambda lists got this right
>>> and
>>> > Clojure gets a poor grade.
>>> > Something about being doomed to repeat history.  In Common Lisp, if you
>>> > really wanted to allow other (arbitrary) keywords you'd
>>> > just use &allow-other-keys.
>>> >
>>> > Maybe clojure should only allow the above case to go
>>> un-complained-about if
>>> > :as was specified for the map.
>>> >
>>> > If there's some automatic enforcement I'm missing that comes with
>>> 'defn'
>>> > please let me know, I'm still learning the language.
>>> >
>>> > I've thought more that once about making a common lisp DEFUN statement
>>> that
>>> > maps to DEFN but implements
>>> > lambda list semantics (including 'supplied-p' parameters).  I've just
>>> been
>>> > too lazy to do it.
>>> >
>>> > It would also likely perform poorly after injecting the additional
>>> > checks/rearrangements into the function on top of what Clojure has
>>> already
>>> > done,
>>> > so I suppose it would have to be taken a step further so that it didn't
>>> > generate DEFN expressions at all but was implemented at DEFN's level as
>>> > a seperately named form.
>>> >
>>> > Tips welcome.  Just thinking aloud.
>>> >
>>> > - Dave
>>>
>>> --
>>> Sent with my mu4e
>>>
>>> --
>>> 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, s

Re: decoding clojure generated class names

[Dave Tenny]

Thanks Alex, clojure.lang.Compiler/demunge is just what I wanted.

On Sat, Aug 22, 2015 at 7:28 PM, Alex Miller  wrote:

> There is a demunge function in clojure.lang.Compiler. It's not foolproof
> as the munging is not unambiguously reversible.
>
> --
> 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/5-l7bxFSOxk/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: Rabid wild animals in my clojure argument lists, code gets infected.

[James Reeves]

On 23 August 2015 at 15:17, Dave Tenny  wrote:

> The point of my colorful title and judgmental post is that in the example,
> passing :e for the declared parameters as declared is a pointless operation
> at best, and in most practical situations it is also an erroneous
> operation.
>
> The language designers have (arguably for the good) chosen to complain
> about various actual argument mismatches vs. formal parameters.
>

Clojure uses destructuring to handle keyword arguments. If we want
destructuring keyword arguments to behave differently to destructuring a
map, then we make the language less consistent. Ideally there would be a
separate syntax for keyword arguments.

In general Clojure doesn't have great support for keyword arguments.
They're supported by destructuring, but they don't work with apply, and as
you've discovered, don't throw exceptions when you get the keys wrong.

- James

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

:arglists metadata on defmulti/defmethod forms

[Dave Tenny]

defmulti+detmethod doesn't seem to maintain any :arglists metadata with the 
Var filled by defmulti.  

How can I look up arglist information for multimethods like I can for 
regular function vars?


-- 
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: :arglists metadata on defmulti/defmethod forms

[James Reeves]

I tend to add the metadata in manually when I write multimethods.

(defmulti foo
  "Does some foo to x."
  {:arglists '([x])}
  :type)

- James

On 23 August 2015 at 16:51, Dave Tenny  wrote:

> defmulti+detmethod doesn't seem to maintain any :arglists metadata with
> the Var filled by defmulti.
>
> How can I look up arglist information for multimethods like I can for
> regular function vars?
>
>
> --
> 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.

Java constructor question

[Dave Tenny]

Is there a way to parameterize a bit of code that invokes a constructor 
without calling the java.lang.reflect.Constructor class?

e.g.

(defn make-it [class]
  (new class "abc")) ; won't work

(make-it IllegalArgumentException)  

I was trying to parameterize the class of exception thrown in a bit of code 
in my case,
but it appears the compiler wants a Class name and nothing else in java 
interop constructor positiosn.


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

Java constructor question

[Alex Miller]

Use a macro to produce the right code...

-- 
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: Java constructor question

[James Reeves]

You could use eval:

(defn make-it [class]
  (eval `(new ~class "abc")))

That's likely to be less performant than using
java.lang.reflect.Constructor though.

- James

On 23 August 2015 at 21:06, Dave Tenny  wrote:

> Is there a way to parameterize a bit of code that invokes a constructor
> without calling the java.lang.reflect.Constructor class?
>
> e.g.
>
> (defn make-it [class]
>   (new class "abc")) ; won't work
>
> (make-it IllegalArgumentException)
>
> I was trying to parameterize the class of exception thrown in a bit of
> code in my case,
> but it appears the compiler wants a Class name and nothing else in java
> interop constructor positiosn.
>
>
> --
> 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 can find something inside heavily nested data structure ?

[Brian Marick]

Andy- wrote:

I have yet to evaluate it myself but this might do help you:

https://github.com/nathanmarz/specter



Specter is great.

--
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: Java constructor question

[Reid McKenzie]

So after thinking about Alex and James' respective answers I think the
full answer to your question is that no you can't do that for reasons
pretty fundamental to the JVM unless you care to constrain the problem
domain or qualify your question some more.

Making a new class instance is a three step dance:
1. Get all the class initialization values on the stack
2. Use the new [1] instruction to create an instance
3. use invokeSpecial [2] to call the  constructor

The Clojure calling convention is logically Object* -> Object except
in the case of JVM primitives [3]. Without my strictly tagged Clojure
work, all Clojure locals are also Object typed at the byte code level
(again unless primitive) and checkCast instructions [4] are used to
dynamically check the tagged types. This means that in the general
case of a function as such:

```clojure
;; totally doesn't work
;; presuming that new was not special and could accept varargs
(defn make-it [class & args]
  (apply new class args))
```

the absolute best bytecode one could possibly emit for this expression
would be to 1, iterate over all the args (because it's a varargs seq
all we know is that they are Objects in a Seq) pushing them onto the
stack last to first. 2, get the class from the arguments, cast it to a
class (checkCast) and then use java.lang.Class.newInstance() [5] to
create an uninitialized instance. Now we have a problem. In order to
initialize and use the new instance, we _must_ invoke the appropriate
 method, which may not accept Object typed arguments. In your
own example you had an inline String. Somehow, for instance by using
java.lang.Class.getDeclaredConstructors [6] and looking for
constructors somehow matching the sequence of arguments (which are of
unknown types, all Object) so that we can then invoke it. All we have
on hand is an uninitialized (and probably useless) Object, and a heap
of argument Objects. We can do no better here at least statically than
to use reflection.

This gives the answer of "don't even bother trying to wrap new, just
use it" given by James and Alex. And frankly I agree. Inline new is
the way to preserve and use the most type information, and is
syntactically clear to other programmers.

If you _really really really_ want to do "better" than inline new and
I claim that you really don't, you could use the following code
modified from James' suggestion.

```clojure
;; MIT/X11 license disclaimed
;; - may not work, written late with alcohol
;; - no guarantee for any purpose

(def maybe-type?
  (some-fn nil?;; implicitly Object
   symbol? ;; primitive types
   class?  ;; a specific Class
   ))

(defn make-ctor-fn* [class & types]
  {:pre [;; class cannot be nil, we must make something
 (class? class)]}
  (let [args (mapv #(let [c (or % Object)]
  ;; args must have Types (could be prim) too
  (assert (maybe-type? c))
  ;; make a local sym with the tag
  (with-meta (gensym)
{:tag c}))
   types)]
`(fn ~(with-meta args {:tag class})
   (new ~class ~@args

(def make-ctor-fn
  (memoize
   (fn [& args]
 (eval (apply make-ctor-fn* args)
```

which will at least let you cache the dynamically generated
constructor fns and avoid repeatedly calling eval although I make no
claim of a meaningful performance difference.

Issues with this approach include the following:

You have to hit the memoize cache on every call (unless you safe your
constructor fns to a local since I'm assuming you're truly doing
something type dynamic here).

Clojure doesn't (and can't, see Object typed calling convention)
statically know the type of the result of your dynamic constructor fn
so you'll get back an Object. This means that in order to do any
method calls or field accesses you'll have to either use reflection or
do more crazy cached dynamic fn generation in order to work with the
resulting Class instance in a remotely performant fashion.

I claim that whatever you're working on probably isn't actually type
dynamic enough to require any of this weirdness if you stop and think
about it. But it may in which case cached eval of generated fns with
tags may be your best bet.



This was written with no effort made to profile anything just from my
knowledge of the JVM spec, Java standard library and Clojure. YYMV,
get a profiler and look at it for yourself.

Reid



Citations:

[1]
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.new
[2]
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.invokespecial
[3]
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java
[4]
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.checkcast
[5]
https://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#newInstance--
[6]
http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getDeclaredConstructors%28%29

Reviewers needed for new Clojure book!

[Akhil Wali]

If anyone is interested in being a reviewer for a new book "*Mastering 
Clojure*" by Packt Publishing, please let me know.
Reviewers will be entitled to a 6 montn subscription of PacktLib 
.

Here's the list of topics covered in this title.

   - 
   - Working with Sequences and Types
   - Orchestrating Concurrency and Parallelism
   - Parallelization using Reducers
   - Writing Macros
   - Composing Transducers
   - Using Functors and Monads
   - Programming with Logic
   - Asynchronous Programming
   - Reactive Programming
   - Working with Tests
   - Troubleshooting and Best Practices
   

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