Re: let vs. let*
Hi, I fear that I have to excuse me for triggering a debate about principles of behavior patterns on this list. Of course, I tried to answer my question myself using Google. Perhaps I made a mistake on the selection of the right search pattern so I didn't find satisfactory results. The lmgtfy link posted by raould was helpful. Johannes On Thursday, June 25, 2015 at 3:22:02 PM UTC+2, Alex Miller wrote: raould, I find lmgtfy links to be a condescending way to answer a question and I would prefer that we not use them on this list. If you have an answer or a link to one, then respond with this, otherwise I do not see a reason to post this. Thanks, Alex On Thursday, June 18, 2015 at 3:35:53 PM UTC-5, raould wrote: http://lmgtfy.com/?q=clojure+%22let+vs.+let*%22 -- 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: let vs. let*
My apologies (sincerely). Won't use that again. -- 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: remote - DSL for clj-http/cljs-http
Are you tired of writing the same clj-http/cljs-https boilerplate? Looking for an easy way to express an endpoint or a service API? Then remote is the library for you! Github: https://github.com/outpace/remote Leiningen: [com.outpace/remote 0.3.1] This library has been closed source up until now and by popular demand has been made available to the public. On behalf of the Outpace staff and myself we hope you or your team find this library useful. Thanks! -- 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: Looking for library to annotate structures with grammar descriptions
I took a swing at this using prismatic schema: (ns schema-test.core (:require [schema.core :as s] [schema.utils :as utils] [schema.coerce :as coerce]) (:import schema.core.NamedSchema)) (def Alternate (s/named [s/Keyword] alternate)) (def Path (s/named [(s/either s/Keyword Alternate)] path)) (def T [(s/either s/Keyword Path)]) (def example [ :a [:a :b :c][:a [:b1 :b2] :c ] ] ) (defn annotater [schema] (s/start-walker (fn [s] (let [walk (s/walker s)] (fn [x] (if (and (instance? clojure.lang.IObj x) (instance? schema.core.NamedSchema s)) (with-meta (walk x) {:schema (.name s)}) (walk x) schema)) (defn annotate [schema data] ((annotater schema) data)) (def r (annotate T example)) (map meta r) ; = (nil {:schema path} {:schema path}) (meta (nth (nth r 2) 1)) ; = {:schema alternate} On Thu, Jun 25, 2015 at 12:35 PM, Brian Marick mar...@exampler.com wrote: Suppose we have a structure like this: [ :a [:a :b :c][:a [:b1 :b2] :c ] ] That is a *required* list. It consists of keywords and *paths* (nested vector like [:a :b :c] above). A path consists of keywords and *alternates* (a twice-nested vector like [:b1 :b2]) above. It's easy to descend this by hand and keep track of which type of vector you're dealing with. However, this sort of thing comes up enough that it would be convenient if there were a function that takes a grammar and a structure and returns that structure annotated (metadata?) with type information. Coupled with Specter https://github.com/nathanmarz/specter, that would make a good number of data transformations easy-peasy. Is there such a library? Or a library I can build on? A quick scan shows a lot of parsers for dealing with strings, but we've already got one of those: it's called `read`. @marick -- 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: Calling an overloaded Scala function
Sorry about the double threads - I messed up and thought the original post didn't go through. Looking further into this it seems in Java generics are largely a compile time thing. The generic type information is wiped out from the type on compile. So how does Java know which overload to call when the only difference in the generic type of the parameter? The answer is - it doesn't. I whipped up a quick bit of Java to test this : public static String Onk(ArrayListString str) { System.out.println(string); return ; } public static int Onk(ArrayListInteger it) { System.out.println(int); return 0; } This fails to compile : Error:(11, 24) java: name clash: Onk(java.util.ArrayListjava.lang.Integer) and Onk(java.util.ArrayListjava.lang.String) have the same erasure This sort of thing doesn't seem to be a problem for Scala, so it must be doing something funky under the hood to resolve these methods. Now, I can get the generic information about these methods using reflection : (- Dist$/MODULE$ type .getMethods vec (map #(.getGenericParameterTypes %)) pprint) gives me : ([#ParameterizedTypeImpl scala.collection.Seqscala.Tuple2java.lang.Object, com.cra.figaro.language.ElementT, #ParameterizedTypeImpl com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection] [#ParameterizedTypeImpl scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object, com.cra.figaro.language.ElementT, #ParameterizedTypeImpl com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection] So in theory I think I should be able to hack something together to resolve to the correct method. It won't be fast - or elegant, but hopefully it can work. Thanks On Fri, Jun 26, 2015 at 3:38 AM Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: That was meant as a response to the other thread. On Fri, Jun 26, 2015 at 10:35 AM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: They apparently differ in the return type. I don't think clojure.lang.Reflector considers the return type hint when resolving methods. Thanks, Ambrose On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely fungus.humun...@gmail.com wrote: javap gives : public T com.cra.figaro.language.AtomicDistT apply(scala.collection.Seqscala.Tuple2java.lang.Object, com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection); public T com.cra.figaro.language.CompoundDistT apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object, com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection); Bit of an eyesore, but the two methods only differ in the generic types.. On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely fungus.humun...@gmail.com wrote: So using reflection on the objects gives the following signatures - they have identical signatures : {:name apply, :return-type com.cra.figaro.language.CompoundDist, :declaring-class com.cra.figaro.language.Dist$, :parameter-types [scala.collection.Seq com.cra.figaro.language.Name com.cra.figaro.language.ElementCollection], :exception-types [], :flags #{:public}} {:name apply, :return-type com.cra.figaro.language.AtomicDist, :declaring-class com.cra.figaro.language.Dist$, :parameter-types [scala.collection.Seq com.cra.figaro.language.Name com.cra.figaro.language.ElementCollection], :exception-types [], :flags #{:public}} On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra the.stuart.sie...@gmail.com wrote: Scala has to compile down to JVM bytecode just like Clojure, but it may change method signatures along the way. You could try running `javap` to disassemble the compiled Scala bytecode and figure out what the method signatures actually are. Or use Java reflection to examine the objects you have and see what methods they declare. –S On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote: I am trying to call into some Scala that has the following overloaded methods : def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T], collection: ElementCollection) = new AtomicDist(name, clauses.toList, collection) def apply[T](clauses: (Element[Double], Element[T])*)(implicit name: Name[T], collection: ElementCollection) = new CompoundDist(name, clauses.toList, collection) So one method takes a list of tuples of Double to Element and the other method takes a list of tuples of Element to Element. I am using t6.from-scala (https://github.com/t6/from-scala) to build up my list of Tuples. But when building these up there is no way to specify explicit type information about the collections. Consequently when calling this apply method Clojure will always choose to call the first method - even when my list is a collection of Element to Element
Re: Calling an overloaded Scala function
I want to fully understand what is going on before doing anything. Interestingly if I convert the Java code below to Scala it fails to compile with the same error : def Onk(str: util.ArrayList[String]): String = { println(String) erk } def Onk(it: util.ArrayList[Integer]): Integer = { println(Int) 0 } But changing it to using (I think) more idiomatic Scala compiles and runs fine. def Onk(str: (String)*): String = { println(String) erk } def Onk(it: (Integer)*): Integer = { println(Int) 0 } On Fri, Jun 26, 2015 at 12:27 PM Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: Have you considered writing a wrapper method in Scala and calling that? Thanks, Ambrose On Fri, Jun 26, 2015 at 7:24 PM, Stephen Wakely fungus.humun...@gmail.com wrote: Sorry about the double threads - I messed up and thought the original post didn't go through. Looking further into this it seems in Java generics are largely a compile time thing. The generic type information is wiped out from the type on compile. So how does Java know which overload to call when the only difference in the generic type of the parameter? The answer is - it doesn't. I whipped up a quick bit of Java to test this : public static String Onk(ArrayListString str) { System.out.println(string); return ; } public static int Onk(ArrayListInteger it) { System.out.println(int); return 0; } This fails to compile : Error:(11, 24) java: name clash: Onk(java.util.ArrayListjava.lang.Integer) and Onk(java.util.ArrayListjava.lang.String) have the same erasure This sort of thing doesn't seem to be a problem for Scala, so it must be doing something funky under the hood to resolve these methods. Now, I can get the generic information about these methods using reflection : (- Dist$/MODULE$ type .getMethods vec (map #(.getGenericParameterTypes %)) pprint) gives me : ([#ParameterizedTypeImpl scala.collection.Seqscala.Tuple2java.lang.Object, com.cra.figaro.language.ElementT, #ParameterizedTypeImpl com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection] [#ParameterizedTypeImpl scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object, com.cra.figaro.language.ElementT, #ParameterizedTypeImpl com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection] So in theory I think I should be able to hack something together to resolve to the correct method. It won't be fast - or elegant, but hopefully it can work. Thanks On Fri, Jun 26, 2015 at 3:38 AM Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: That was meant as a response to the other thread. On Fri, Jun 26, 2015 at 10:35 AM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: They apparently differ in the return type. I don't think clojure.lang.Reflector considers the return type hint when resolving methods. Thanks, Ambrose On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely fungus.humun...@gmail.com wrote: javap gives : public T com.cra.figaro.language.AtomicDistT apply(scala.collection.Seqscala.Tuple2java.lang.Object, com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection); public T com.cra.figaro.language.CompoundDistT apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object, com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection); Bit of an eyesore, but the two methods only differ in the generic types.. On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely fungus.humun...@gmail.com wrote: So using reflection on the objects gives the following signatures - they have identical signatures : {:name apply, :return-type com.cra.figaro.language.CompoundDist, :declaring-class com.cra.figaro.language.Dist$, :parameter-types [scala.collection.Seq com.cra.figaro.language.Name com.cra.figaro.language.ElementCollection], :exception-types [], :flags #{:public}} {:name apply, :return-type com.cra.figaro.language.AtomicDist, :declaring-class com.cra.figaro.language.Dist$, :parameter-types [scala.collection.Seq com.cra.figaro.language.Name com.cra.figaro.language.ElementCollection], :exception-types [], :flags #{:public}} On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra the.stuart.sie...@gmail.com wrote: Scala has to compile down to JVM bytecode just like Clojure, but it may change method signatures along the way. You could try running `javap` to disassemble the compiled Scala bytecode and figure out what the method signatures actually are. Or use Java reflection to examine the objects you have and see what methods they declare. –S On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote: I am trying to call into some Scala that has the
Re: Calling an overloaded Scala function
Have you considered writing a wrapper method in Scala and calling that? Thanks, Ambrose On Fri, Jun 26, 2015 at 7:24 PM, Stephen Wakely fungus.humun...@gmail.com wrote: Sorry about the double threads - I messed up and thought the original post didn't go through. Looking further into this it seems in Java generics are largely a compile time thing. The generic type information is wiped out from the type on compile. So how does Java know which overload to call when the only difference in the generic type of the parameter? The answer is - it doesn't. I whipped up a quick bit of Java to test this : public static String Onk(ArrayListString str) { System.out.println(string); return ; } public static int Onk(ArrayListInteger it) { System.out.println(int); return 0; } This fails to compile : Error:(11, 24) java: name clash: Onk(java.util.ArrayListjava.lang.Integer) and Onk(java.util.ArrayListjava.lang.String) have the same erasure This sort of thing doesn't seem to be a problem for Scala, so it must be doing something funky under the hood to resolve these methods. Now, I can get the generic information about these methods using reflection : (- Dist$/MODULE$ type .getMethods vec (map #(.getGenericParameterTypes %)) pprint) gives me : ([#ParameterizedTypeImpl scala.collection.Seqscala.Tuple2java.lang.Object, com.cra.figaro.language.ElementT, #ParameterizedTypeImpl com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection] [#ParameterizedTypeImpl scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object, com.cra.figaro.language.ElementT, #ParameterizedTypeImpl com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection] So in theory I think I should be able to hack something together to resolve to the correct method. It won't be fast - or elegant, but hopefully it can work. Thanks On Fri, Jun 26, 2015 at 3:38 AM Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: That was meant as a response to the other thread. On Fri, Jun 26, 2015 at 10:35 AM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: They apparently differ in the return type. I don't think clojure.lang.Reflector considers the return type hint when resolving methods. Thanks, Ambrose On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely fungus.humun...@gmail.com wrote: javap gives : public T com.cra.figaro.language.AtomicDistT apply(scala.collection.Seqscala.Tuple2java.lang.Object, com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection); public T com.cra.figaro.language.CompoundDistT apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object, com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT, com.cra.figaro.language.ElementCollection); Bit of an eyesore, but the two methods only differ in the generic types.. On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely fungus.humun...@gmail.com wrote: So using reflection on the objects gives the following signatures - they have identical signatures : {:name apply, :return-type com.cra.figaro.language.CompoundDist, :declaring-class com.cra.figaro.language.Dist$, :parameter-types [scala.collection.Seq com.cra.figaro.language.Name com.cra.figaro.language.ElementCollection], :exception-types [], :flags #{:public}} {:name apply, :return-type com.cra.figaro.language.AtomicDist, :declaring-class com.cra.figaro.language.Dist$, :parameter-types [scala.collection.Seq com.cra.figaro.language.Name com.cra.figaro.language.ElementCollection], :exception-types [], :flags #{:public}} On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra the.stuart.sie...@gmail.com wrote: Scala has to compile down to JVM bytecode just like Clojure, but it may change method signatures along the way. You could try running `javap` to disassemble the compiled Scala bytecode and figure out what the method signatures actually are. Or use Java reflection to examine the objects you have and see what methods they declare. –S On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote: I am trying to call into some Scala that has the following overloaded methods : def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T], collection: ElementCollection) = new AtomicDist(name, clauses.toList, collection) def apply[T](clauses: (Element[Double], Element[T])*)(implicit name: Name[T], collection: ElementCollection) = new CompoundDist(name, clauses.toList, collection) So one method takes a list of tuples of Double to Element and the other method takes a list of tuples of Element to Element. I am using t6.from-scala (https://github.com/t6/from-scala) to build up my list of Tuples. But when building these up there is no way to