Small Problem: Which Strings Differ at One Location
Let's say that I have a set of strings, each three English letters long. How can I determine which strings differ only at one location (e.g. xxe and xbe)? Right now, I'm writing a loop that sequentially compares every string to every other string. I think that there's a better way, but I don't know where to start. -- 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
Re: Small Problem: Which Strings Differ at One Location
Thanks for the reply. Levenshtein distance would be especially useful for when I need to compare general strings, with a general amount of edits between them. Unfortunately, the problem isn't so much determining whether any two strings are one edit apart: that can be done just by checking if the first two, first and third, or last two characters of one string equals those of the other. The problem is which strings you compare with to determine which ones are one edit apart. Right now, I have to compare every string with every other string, but it seems really wasteful, seemingly being in O(n^2) time. I just can't figure out how to make it more efficient, though. I'm hoping that this a common problem with a common solution, like using some data structure I haven't thought of. On May 30, 1:01 pm, Laurent PETIT laurent.pe...@gmail.com wrote: Hi, there's the levenshtein distance algorithm which will help you determine which string is one edit close to another (since all your strings are of length 3, then the distance will inevitably be a single replacement if of size one). Don't know if that helps, anyway here's a compact functional implementation:https://gist.github.com/828413 2011/5/30 joshua-choi rbysam...@gmail.com: Let's say that I have a set of strings, each three English letters long. How can I determine which strings differ only at one location (e.g. xxe and xbe)? Right now, I'm writing a loop that sequentially compares every string to every other string. I think that there's a better way, but I don't know where to start. -- 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 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
JavaFX alternative languages talk at JavaOne
I have no idea how many of you both care at all about JavaFX and are planning to go to the JavaOne conference tomorrow Monday in San Francisco, but there's apparently going to be a talk about using the JavaFX platform from alternative languages, particularly Clojure, at 4 PM. I myself can't go, but I am interested in JavaFX, so it'd be great if someone goes and reports on it. http://steveonjava.com/javafx-your-way-building-javafx-applications-with-alternative-languages/ -- 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
Re: Macro problems with delay
That ought to be correct, but I can't reconcile that with the error message. Doesn't the Can't embed object in code, maybe print-dup not defined error only appear in macros, when some object being spliced into a macro's expansion is not a basic Clojure form? Yet, you are correct, commenting out that function call in the macro does prevent the error. I don't understand it. Konrad Hinsen wrote: On 10 Sep 2010, at 03:11, joshua-choi wrote: And here is a full macro-expansion of the call at which the error happens: http://gist.github.com/572879 If I understand the comment (the following form is the culprit...) correctly, it's not the macroexpansion that fails, but the evaluation of the resulting expression. Is that correct? In that case, it's not really a macro problem, but a problem with a complex use case of alter- var-root. Konrad. -- 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
Re: Macro problems with delay
You're right about the namespace-qualification: I accidentally macroexpanded with syntax-quote rather than quote. My mistake; the actual expansion is the same, but without namespace-qualification. Using (var ~fn-name) results in the same error, unfortunately. I think now the attempted embedding of a delay into macro code is somewhere else, but I don't know. Meikel Brandmeyer wrote: Hi, On 10 Sep., 03:11, joshua-choi rbysam...@gmail.com wrote: I am running into a problem sometimes when I call a certain macro I defined. This problem macro (and an associated problem function) is: http://gist.github.com/572875 I run into this error (which is at a call to the macro, but *not* at the *first* time it's called for some reason!): http://gist.github.com/572824 And here is a full macro-expansion of the call at which the error happens: http://gist.github.com/572879 I *cannot* figure this out. The error seems to be that there's a delay directly being embedded in some macro's form, but the delay call in the function that's causing the problem…is in a function! How can the delay show up at hound.clj's compile time? I must confess, I'm not sure, what's going on. However the expansion looks suspicious. Everything is namespace qualified. One thing core does differently to your approach is using the var special form. You might try: (defmacro general-defmaker [def-form description rule-type-kw fn-name forms] `(do (~def-form ~fn-name ~...@forms) (alter-var-root (var ~fn-name) named-rule-maker ~rule-type-kw) (var ~fn-name))) But this is just guessing. As I said above: everything is qualified. So maybe the problem is at some surrounding macro or so. Sincerely Meikel -- 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
Re: Macro problems with delay
I've solved the problem. I found that it only occurred when general- defmaker was called with its forms argument containing another general- defmaker call with def-form being defmacro. Thus, in the inner general- defmaker call, the *result* of (NamedRule. (delay …)) was embedded into a defmacro call, resulting in the error. The solution was to change (alter-var-root maker-var# named-rule-maker ~rule-type-kw) to (when (= '~def-form `defmacro) (alter-var-root maker-var# named-rule-maker ~rule-type-kw)) Thanks, everyone for your help. joshua-choi wrote: That ought to be correct, but I can't reconcile that with the error message. Doesn't the Can't embed object in code, maybe print-dup not defined error only appear in macros, when some object being spliced into a macro's expansion is not a basic Clojure form? Yet, you are correct, commenting out that function call in the macro does prevent the error. I don't understand it. Konrad Hinsen wrote: On 10 Sep 2010, at 03:11, joshua-choi wrote: And here is a full macro-expansion of the call at which the error happens: http://gist.github.com/572879 If I understand the comment (the following form is the culprit...) correctly, it's not the macroexpansion that fails, but the evaluation of the resulting expression. Is that correct? In that case, it's not really a macro problem, but a problem with a complex use case of alter- var-root. Konrad. -- 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
Macro problems with delay
I am running into a problem sometimes when I call a certain macro I defined. This problem macro (and an associated problem function) is: http://gist.github.com/572875 I run into this error (which is at a call to the macro, but *not* at the *first* time it's called for some reason!): http://gist.github.com/572824 And here is a full macro-expansion of the call at which the error happens: http://gist.github.com/572879 I *cannot* figure this out. The error seems to be that there's a delay directly being embedded in some macro's form, but the delay call in the function that's causing the problem…is in a function! How can the delay show up at hound.clj's compile time? -- 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
Re: Another JavaFX and Clojure Demo
This is fascinating—I too am interested in Clojure-JavaFX interaction. Thanks a lot for putting this up! On Aug 21, 8:43 pm, Sam Griffith stayp...@mac.com wrote: Hello group, I'd replied a long time ago to one of the posts about JavaFX and Clojure working together... I've now finally gotten back to putting it up on Github. It is very rough and ugly code, but it does show one way to get Clojure working with JavaFX. The simplest way I could imagine at the time (June 2009). It has a JavaFX UI talking to a Java facade class which loads and exposes a Clojure script. Be sure and read the README. It has a little more details. Here is the Github link: http://github.com/staypufd/JavaFXClojure Hope it helps someone or at least gets more balls rolling on linking up JavaFX and Clojure Sam Griffith Jr -- 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
Re: DSL with a grammar
Consider using FnParse (http://github.com/joshua-choi/fnparse/tree/ develop). It's a pure Clojure parser combiner that is flexible in what tokens it accepts. You can use it to parse the symbol/list/etc. structures given to your macros into other forms. FnParse 3, the latest version, is currently a little unstable and poorly documented. But it makes very good error messages, and I'm willing to personally help you if you run into any problems if you contact me via GitHub or whatever. FnParse 3 is in the develop I suggest looking at http://github.com/joshua-choi/fnparse/blob/develop/src/edu/arizona/fnparse/json.clj for a good example. On Jul 8, 11:52 am, Nicolas Oury nicolas.o...@gmail.com wrote: Dear all, I am trying to write a small Domain Specific Language using macro, and I want the syntax of the args of the macro to be somehow parsed and transformed. So, I have two questions: - Does anybody else does that? (except the infix calculus) Is there a generic method for doing it? Or even better a library? - I want to report syntax error from my macro expansion. Is there a way to get the line (or even better the line/file and character) of the usage of a macro being expanded? That way I could have helpful error message Best regards, Nicolas. -- 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
Language request: Passing metadata to a fn from its name (in a fn form)
I have a language request for the fn special form.
Functions can now have metadata. This is great, and very useful for
me.
I'd like to request that now the (fn name …) form pass on any metadata
on the name symbol to the function itself:
user= (meta (fn ^{:a 3} name …))
{:a 3}
This would ideally come especially in handy in letfn:
user= (letfn [(^{:a 3} some-fn …)] (meta some-fn))
{:a 3}
The above is currently impossible at all; def must be used instead.
The proposal above would make it possible, and it would be a logical
extension of enabling metadata on functions.
This matters especially for me, because I use function metadata in my
parser library's rules to validate rules, store rule labels, and other
things. I would love for this to happen, and I'd like to know the
prospects of this feature being implemented for Clojure 1.3.
--
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
Re: Language request: Passing metadata to a fn from its name (in a fn form)
I suppose I could, but that would make some things such as using letfn
for my rules impossible when the rules are mutually recursive.
In any case, it doesn't change the fact that, though functions now
have metadata, there is no way to give functions defined letfn that
metadata. This would be useful in any other case involving function
metadata, such as in logging, or tracking callings. So far, I cannot
think of any good reason to reject this proposal.
On May 24, 12:36 pm, Sean Devlin francoisdev...@gmail.com wrote:
It doesn't sound like your metadata is metadata any more.
Should you be proxying AFn instead?
On May 24, 3:24 pm, joshua-choi rbysam...@gmail.com wrote:
I have a language request for the fn special form.
Functions can now have metadata. This is great, and very useful for
me.
I'd like to request that now the (fn name …) form pass on any metadata
on the name symbol to the function itself:
user= (meta (fn ^{:a 3} name …))
{:a 3}
This would ideally come especially in handy in letfn:
user= (letfn [(^{:a 3} some-fn …)] (meta some-fn))
{:a 3}
The above is currently impossible at all; def must be used instead.
The proposal above would make it possible, and it would be a logical
extension of enabling metadata on functions.
This matters especially for me, because I use function metadata in my
parser library's rules to validate rules, store rule labels, and other
things. I would love for this to happen, and I'd like to know the
prospects of this feature being implemented for Clojure 1.3.
--
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
athttp://groups.google.com/group/clojure?hl=en
--
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
athttp://groups.google.com/group/clojure?hl=en
--
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
Re: Splitting a string with the characters between each split?
Excellent! This is exactly what I'm looking for; thanks everyone for their help. On May 13, 10:13 pm, Justin Kramer jkkra...@gmail.com wrote: clojure.contrib.string/partition does exactly what you're looking for. (require 'clojure.contrib.string) (clojure.contrib.string/partition #\s+ ab c de) ;; (ab c de) Justin On May 13, 12:24 pm, joshua-choi rbysam...@gmail.com wrote: I'd like to know if there's a standard function similar to clojure.contrib.string/split that includes the characters between the spitted string, or if there isn't one, how I might write one. In other words, I'd like a function split* such that (split* #\s+ ab c de) returns (ab c de). -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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
Splitting a string with the characters between each split?
I'd like to know if there's a standard function similar to clojure.contrib.string/split that includes the characters between the spitted string, or if there isn't one, how I might write one. In other words, I'd like a function split* such that (split* #\s+ ab c de) returns (ab cde). -- 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
Re: Splitting a string with the characters between each split?
Ah, thanks, I forgot about the word-boundary regex, but unfortunately, the regex I want to split on is more complicated than #\s+—I just used #\s+ as an example, and I don't think #\b will work in this case. On May 13, 1:26 pm, Drew Raines aarai...@gmail.com wrote: You could do it by using the word boundary regexp operator. (ns foo.bar (:use [clojure.contrib.string :only [split]])) (defn split* [s] (drop 1 (split #\b s))) (split* ab c de) ;; (ab c de) -Drew On Thu, May 13, 2010 at 11:24, joshua-choi rbysam...@gmail.com wrote: I'd like to know if there's a standard function similar to clojure.contrib.string/split that includes the characters between the spitted string, or if there isn't one, how I might write one. In other words, I'd like a function split* such that (split* #\s+ ab c de) returns (ab c de). -- 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 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 athttp://groups.google.com/group/clojure?hl=en -- 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
Re: removing the need for refer-clojure ?
I would love if this happened; it could probably be implemented in a backwardly compatible way, since you're currently not supposed to use or require clojure.core anyway, as far as I know. On May 5, 8:36 am, Laurent PETIT laurent.pe...@gmail.com wrote: Hello, After thinking twice about it, ns does 2 special things for clojure.core today: 1. if no mention of clojure.core (indirectly via refer-clojure), consider that clojure.core must entirely be 'use d in the namespace 2. if refer-clojure is used, bypass 1. and do whatever is in refer-clojure what about getting rid of refer-clojure in 'ns (or probably deprecating it). 1. if no mention of clojure.core (via require or use), consider that clojure.core must entirely be 'use d in the namespace 2. if clojure.core is 'use d or 'refer ed, bypass 1. Bonus for the user: * one less special case to handle (no need to remember refer-clojure) * same suppleness as with refer-clojure, with the extra-bonus of being able to requiring clojure.core (think of namespaces dedicated to dsls where you will want to provide only certain clojure.core vars to dsl users, and/or make it clear that the user is not using dsl primitives but clojure primitives by requiring clojure.core :as core etc.) What do you think about 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 athttp://groups.google.com/group/clojure?hl=en -- 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
Re: Trouble with Leiningen and Autodoc
Yes, http://github.com/joshua-choi/fnparse/tree/develop. You must use the latest tree in the develop branch (which is at the time of this writing commit baf3b39f51fdd3893471f52d330336b5a794fa6d). Thanks for the help, and I look forward to what you figure out. On May 3, 12:12 pm, Tom Faulhaber tomfaulha...@gmail.com wrote: Hi Joshua, Autodoc depends on clojure 1.1, which Phil has suggested might be a problem (he told me not to depend on a clojure version at all). Let me pull that dependency and see if that fixes the problem. Is this in your repo on github? Tom On May 1, 7:17 pm, joshua-choi rbysam...@gmail.com wrote: This is my project.clj: (defproject fnparse 3.á.3 :description A library for creating functional parsers in Clojure. :dependencies [[org.clojure/clojure 1.2.0-master-SNAPSHOT] [org.clojure/clojure-contrib 1.2.0-master- SNAPSHOT]] :dev-dependencies [[autodoc 0.7.0]]) I run lein deps, and it works. But then I run lein autodoc, and I get the following: [null] #CompilerException java.lang.ExceptionInInitializerError (autodoc.clj:1) [null] Make sure autodoc is added as a dev-dependency in your project.clj. Do I need to do something else? -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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
Re: Trouble with Leiningen and Autodoc
Actually, disregard the message above! You don't want the latest tree on the develop branch; it currently throws errors because defalias doesn't work with macros anymore. You want to use the tree at the tag 3.α.3! My apologies. On May 3, 5:15 pm, joshua-choi rbysam...@gmail.com wrote: Yes,http://github.com/joshua-choi/fnparse/tree/develop. You must use the latest tree in the develop branch (which is at the time of this writing commit baf3b39f51fdd3893471f52d330336b5a794fa6d). Thanks for the help, and I look forward to what you figure out. On May 3, 12:12 pm, Tom Faulhaber tomfaulha...@gmail.com wrote: Hi Joshua, Autodoc depends on clojure 1.1, which Phil has suggested might be a problem (he told me not to depend on a clojure version at all). Let me pull that dependency and see if that fixes the problem. Is this in your repo on github? Tom On May 1, 7:17 pm, joshua-choi rbysam...@gmail.com wrote: This is my project.clj: (defproject fnparse 3.á.3 :description A library for creating functional parsers in Clojure. :dependencies [[org.clojure/clojure 1.2.0-master-SNAPSHOT] [org.clojure/clojure-contrib 1.2.0-master- SNAPSHOT]] :dev-dependencies [[autodoc 0.7.0]]) I run lein deps, and it works. But then I run lein autodoc, and I get the following: [null] #CompilerException java.lang.ExceptionInInitializerError (autodoc.clj:1) [null] Make sure autodoc is added as a dev-dependency in your project.clj. Do I need to do something else? -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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
Calling for advice on a parser's location data
I'm making a parsing library that can keep track of its location in a
stream of tokens, and the tokens can be of any type—character, map,
and so forth. I need advice on this question:
Can you think of an instance where the location would not be a line
number and column number, such as {:line 3, :column 25}?
I'm deciding if I should bother with the trouble of making the
location data structure independent and pluggable with my parser, or
if I should make it always a line-column pair, which would make the
API much simpler.
--
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
Trouble with Leiningen and Autodoc
This is my project.clj: (defproject fnparse 3.α.3 :description A library for creating functional parsers in Clojure. :dependencies [[org.clojure/clojure 1.2.0-master-SNAPSHOT] [org.clojure/clojure-contrib 1.2.0-master- SNAPSHOT]] :dev-dependencies [[autodoc 0.7.0]]) I run lein deps, and it works. But then I run lein autodoc, and I get the following: [null] #CompilerException java.lang.ExceptionInInitializerError (autodoc.clj:1) [null] Make sure autodoc is added as a dev-dependency in your project.clj. Do I need to do something else? -- 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
Naming factory functions
When it comes to naming factory functions—functions that create things— clojure.core gives four precedents: 1. Name it exactly what the new object is called. vector, hash-map, set. 2. Name it a shortened version of #1. vec. 3. Prefix #1 with make-. make-hierarchy, make-array. 4. Prefix #1 with create-. create-ns, create-struct. Are there any guidelines for naming a library's own factory functions? (I find #1 and #2 pretty annoying, since they interfere with my binding of symbols in let forms, but between #3 and #4 I'm not sure.) -- 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
Are there any plans for more allowed symbol characters?
According to http://clojure.org/reader, “Symbols begin with a non- numeric character and can contain alphanumeric characters and *, +, !, -, _, and ? (other characters will be allowed eventually, but not all macro characters have been determined).” Are there any plans of allowing any more symbol characters? Also, another related question: What alphanumeric characters are allowed? US-ASCII only? -- 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
Re: bug: clojure.contrib.json should not default to use keywords.
As a small note, according to http://clojure.org/reader, Clojure
keywords and symbols are allowed to contain only alphanumeric
characters, *, +, !, -, _, and ?. Spaces aren’t allowed, but the
keyword function allows them anyway because it doesn’t do any checking
for validity for performance. I’m told that it’s up to the programmer
to make sure that only valid keywords are created.
I agree that clojure.contrib.json should default to string keys,
because keywords are so limited. The thing is, when
clojure.contrib.json *does* convert JSON keys into Clojure keywords,
should it check for validity and fail when it cannot create a valid
keyword?
On Feb 27, 3:24 pm, MarkSwanson mark.swanson...@gmail.com wrote:
Actually, I shouldn't have worded this as a json issue. It's really a
core problem that keywords with spaces can't be serialized/
deserialized.
A keyword is basically a String, and the language definition does not
preclude keywords from having spaces.
(keyword a b c) works, and so does (get m (keyword a b c)) - on an
appropriately created map
Cheers.
On Feb 27, 3:55 pm, MarkSwanson mark.swanson...@gmail.com wrote:
Hello,
Consider the following valid JSON:
Clojure= (def mq {\Question one\:\test\})
#'user/mq
Clojure= (read-json mq)
{:Question one test}
So the default behaviour fails to work correctly for a common case.
The Clojure failure is not exactly obvious either:
(read-string (str mq))
request failed java.lang.RuntimeException:
java.lang.ArrayIndexOutOfBoundsException: 19
at clojure.lang.RT.readString(RT.java:1220)
at clojure.core$read_string__4163.invoke(core.clj:2517)
I also tried with print-dup and it fails the same way:
=(def ms (new StringWriter))
=(print-dup mq ms)
=(. ms toString)
#=(clojure.lang.PersistentArrayMap/create {:Question one \test\})
=(read-string (. ms toString))
#CompilerException java.lang.RuntimeException:
java.lang.ArrayIndexOutOfBoundsException: 3 (REPL:65)
--
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
Re: Prefixed or suffixed symbols?
Yeah, I don’t really like the underscores either. But I have to work with the set of currently allowed non-alphanumeric symbol characters (*, +, !, -, _, and ?, according to clojure.org/reader). There’s actually two different questions here—I’d love for other people to bring in their input. I need to set apart “rules”, a certain type of object, from other kinds of Clojure objects. (Why do you even need to do this? people ask. Because I really want to graphically set them apart in the programmers mind. And also, rules often shared names with objects that they were representing: it was difficult to remember string-char-r vs. string-char in functions, for instance. It was always a big pain. I think it will be worth it.) Question 1: Of the allowed characters, which would be best to distinguish rule symbols from other symbols? * can be confused with the REPL vars (*1, *e, etc.) and re-bindable vars. + may be a better choice, though in the other Lisps it already indicates constants. I don’t think ! and ? are good at all, because they really stand out to me to mean destruction and querying respectively. - is apparently used only once in the standard libraries: in defn-. Maybe it would be a good choice. _ is ugly, but it’s not used at all, so that’s good. Well, except when used on its own: “_”, for useless bindings. I’m leaning toward +, -, or _. Question 2: Prefix, suffix, or circumfix? +vector, vector+, or +vector+? -vector, vector-, -vector-? Or whatever. Don’t forget, I’m deciding this for my parser rules library. “vector” means a rule that can parse strings representing vectors. Could everyone give me their opinion? Which annoys your taste the least? I still have time to change the style in my library, and I’d like to hear from as many people as possible. On Feb 25, 3:16 pm, Jarkko Oranen chous...@gmail.com wrote: On Feb 25, 12:17 am, joshua-choi rbysam...@gmail.com wrote: When it comes to distinguishing certain types of symbols from other things, should one use prefixes or suffixes? Whichever makes more sense, of course. :) Example: naming tests with clojure.test/deftest. If you distinguish your tests’ symbols at all, do you do “t-addition” or “addition-t”? Name tests descriptively. Putting them in their own namespace helps too. If there's absolutely a need to distinguish them from non-tests, I would prefer '-test'. Abbreviating it just makes it noisy. (I need to know what the standard is, if there is any, because I need a way to distinguish a certain type of symbol—those that represent “rules”— in my libraries. I’m using an underscore suffix right now, like “vector_”, which means “vector-rule” But “_rule” might be better, or even “_rule_”, though the last one might be overkill. In the past, I’ve used “vector-r, but I don’t like that now.) I personally find underscores offensive, but... Some logic DSLs use ? foo for variables, maybe you could have something similar for you rules. Or you could name them using angled brackets (eg. vector). When it comes to naming, you just need to be consistent. And avoid underscores, please :P -- 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
Re: Prefixed or suffixed symbols?
Could you explain more what you mean? For instance, how are macros related to these questions? This just has to do with informal naming conventions, in the same matter as *e or *print-dup*. Are you talking about that it’s possible for naming conventions to interfere with macros that interpret symbols abnormally if they’re named a certain way? Now, I’ve considered just not using any characters to set apart rules completely, but that’ll bring me back to my original problems. The only disadvantage I can think of to using a convention is that it might make code that use rules more noisy...but I think that’s preferable to having to recall what a rule is called if it conflicts with another symbol—which is really common with my rules. What notation do you all think is the least ugly? On Feb 25, 7:32 pm, Sean Devlin francoisdev...@gmail.com wrote: I think using a naming convention isn't a good idea, especially when you have a rich macro system like Clojure. I'm actually going to be talking about using a reference to handle things like this in my next episode. For now, you can take a look at my definference macro here: http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/master/s... Hope this helps, Sean On Feb 25, 8:59 pm, joshua-choi rbysam...@gmail.com wrote: Yeah, I don’t really like the underscores either. But I have to work with the set of currently allowed non-alphanumeric symbol characters (*, +, !, -, _, and ?, according to clojure.org/reader). There’s actually two different questions here—I’d love for other people to bring in their input. I need to set apart “rules”, a certain type of object, from other kinds of Clojure objects. (Why do you even need to do this? people ask. Because I really want to graphically set them apart in the programmers mind. And also, rules often shared names with objects that they were representing: it was difficult to remember string-char-r vs. string-char in functions, for instance. It was always a big pain. I think it will be worth it.) Question 1: Of the allowed characters, which would be best to distinguish rule symbols from other symbols? * can be confused with the REPL vars (*1, *e, etc.) and re-bindable vars. + may be a better choice, though in the other Lisps it already indicates constants. I don’t think ! and ? are good at all, because they really stand out to me to mean destruction and querying respectively. - is apparently used only once in the standard libraries: in defn-. Maybe it would be a good choice. _ is ugly, but it’s not used at all, so that’s good. Well, except when used on its own: “_”, for useless bindings. I’m leaning toward +, -, or _. Question 2: Prefix, suffix, or circumfix? +vector, vector+, or +vector+? -vector, vector-, -vector-? Or whatever. Don’t forget, I’m deciding this for my parser rules library. “vector” means a rule that can parse strings representing vectors. Could everyone give me their opinion? Which annoys your taste the least? I still have time to change the style in my library, and I’d like to hear from as many people as possible. On Feb 25, 3:16 pm, Jarkko Oranen chous...@gmail.com wrote: On Feb 25, 12:17 am, joshua-choi rbysam...@gmail.com wrote: When it comes to distinguishing certain types of symbols from other things, should one use prefixes or suffixes? Whichever makes more sense, of course. :) Example: naming tests with clojure.test/deftest. If you distinguish your tests’ symbols at all, do you do “t-addition” or “addition-t”? Name tests descriptively. Putting them in their own namespace helps too. If there's absolutely a need to distinguish them from non-tests, I would prefer '-test'. Abbreviating it just makes it noisy. (I need to know what the standard is, if there is any, because I need a way to distinguish a certain type of symbol—those that represent “rules”— in my libraries. I’m using an underscore suffix right now, like “vector_”, which means “vector-rule” But “_rule” might be better, or even “_rule_”, though the last one might be overkill. In the past, I’ve used “vector-r, but I don’t like that now.) I personally find underscores offensive, but... Some logic DSLs use ? foo for variables, maybe you could have something similar for you rules. Or you could name them using angled brackets (eg. vector). When it comes to naming, you just need to be consistent. And avoid underscores, please :P -- 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
Re: Prefixed or suffixed symbols?
Ah, yes, it is a. (The only thing that I anticipate a computer would use this for is different syntax highlighting. Actually, can any Clojure editors change symbols’ colors based on if they match a pattern like *a*?) Because Daniel Warner and Jarkko Oranen both said they think underscores are undesirable, I suspect that a lot of other Clojure users feel the same too. Right now, I’m thus leaning toward using - vector-. I’ve just tried replacing all rule symbols in one of my files with -blah-, and it actually looks a little pretty. If I don’t hear any other good suggestions, I think I’ll use circumfix hyphens, then. On Feb 25, 8:31 pm, Sean Devlin francoisdev...@gmail.com wrote: Hmmm... maybe I misunderstood your point. Is the intent of your naming conventions: a. Something that is human readable but does not affect the execution of code? Examples include placing I in front of interface names, and A in front of abstract class names. b. Something that other code will use to infer behavior? Examples of this include JUnit 3.8 the get/set Java Bean convention. If it's a, I made a mistake my comments don't apply (as a matter of taste I like suffixes). If it's the behavior version, I think that a special macro is in order (e.g. deftest) Sean On Feb 25, 10:22 pm, joshua-choi rbysam...@gmail.com wrote: Could you explain more what you mean? For instance, how are macros related to these questions? This just has to do with informal naming conventions, in the same matter as *e or *print-dup*. Are you talking about that it’s possible for naming conventions to interfere with macros that interpret symbols abnormally if they’re named a certain way? Now, I’ve considered just not using any characters to set apart rules completely, but that’ll bring me back to my original problems. The only disadvantage I can think of to using a convention is that it might make code that use rules more noisy...but I think that’s preferable to having to recall what a rule is called if it conflicts with another symbol—which is really common with my rules. What notation do you all think is the least ugly? On Feb 25, 7:32 pm, Sean Devlin francoisdev...@gmail.com wrote: I think using a naming convention isn't a good idea, especially when you have a rich macro system like Clojure. I'm actually going to be talking about using a reference to handle things like this in my next episode. For now, you can take a look at my definference macro here: http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/master/s... Hope this helps, Sean On Feb 25, 8:59 pm, joshua-choi rbysam...@gmail.com wrote: Yeah, I don’t really like the underscores either. But I have to work with the set of currently allowed non-alphanumeric symbol characters (*, +, !, -, _, and ?, according to clojure.org/reader). There’s actually two different questions here—I’d love for other people to bring in their input. I need to set apart “rules”, a certain type of object, from other kinds of Clojure objects. (Why do you even need to do this? people ask. Because I really want to graphically set them apart in the programmers mind. And also, rules often shared names with objects that they were representing: it was difficult to remember string-char-r vs. string-char in functions, for instance. It was always a big pain. I think it will be worth it.) Question 1: Of the allowed characters, which would be best to distinguish rule symbols from other symbols? * can be confused with the REPL vars (*1, *e, etc.) and re-bindable vars. + may be a better choice, though in the other Lisps it already indicates constants. I don’t think ! and ? are good at all, because they really stand out to me to mean destruction and querying respectively. - is apparently used only once in the standard libraries: in defn-. Maybe it would be a good choice. _ is ugly, but it’s not used at all, so that’s good. Well, except when used on its own: “_”, for useless bindings. I’m leaning toward +, -, or _. Question 2: Prefix, suffix, or circumfix? +vector, vector+, or +vector+? -vector, vector-, -vector-? Or whatever. Don’t forget, I’m deciding this for my parser rules library. “vector” means a rule that can parse strings representing vectors. Could everyone give me their opinion? Which annoys your taste the least? I still have time to change the style in my library, and I’d like to hear from as many people as possible. On Feb 25, 3:16 pm, Jarkko Oranen chous...@gmail.com wrote: On Feb 25, 12:17 am, joshua-choi rbysam...@gmail.com wrote: When it comes to distinguishing certain types of symbols from other things, should one use prefixes or suffixes? Whichever makes more sense, of course. :) Example: naming tests with clojure.test/deftest. If you distinguish your
Prefixed or suffixed symbols?
When it comes to distinguishing certain types of symbols from other things, should one use prefixes or suffixes? Example: naming tests with clojure.test/deftest. If you distinguish your tests’ symbols at all, do you do “t-addition” or “addition-t”? (I need to know what the standard is, if there is any, because I need a way to distinguish a certain type of symbol—those that represent “rules”— in my libraries. I’m using an underscore suffix right now, like “vector_”, which means “vector-rule” But “_rule” might be better, or even “_rule_”, though the last one might be overkill. In the past, I’ve used “vector-r, but I don’t like that now.) -- 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
Re: idiomatic question about reader macro
I see why you want to create your own reader macros—you want to set apart certain code visually. But ataggart has a good point when he keeps asking you for specific examples of your code. Do you want to use reader macros to change something like this: (make-data red blue green) into something like this? #$red blue green Even if you keep explaining the general reason why you want macros, it's very hard to determine if your code would really benefit from reader macros. Just give a more specific example of the code you want to change; if it's private, just change the names and words. The reader macro above is more concise, yes, but it's also harder to read and find documentation for anyone else who's reading your code, because it obeys nonstandard language rules. And that's assuming that reader macros are even limited to your namespaces rather than globally— if they happen to be implemented globally, you have conflicts to worry about. And one more thing: you may have to parse the following _characters_ yourself, which is much harder than being able to manipulate actual data structures as you can in regular macros. In my opinion, I believe the language's core should stay as simple as possible. Regular macros can do everything that reader macros can do, but in a more homoiconic and generally easier way. Each reader macro, even the _standard,_ built-in ones, adds a burden on the programmer to remember yet another syntax. I don't think conciseness and visual separation are compelling enough to sacrifice consistency. Don't forget, it's important that other people be able to read and understand your code easily too. On Feb 3, 7:48 am, A.Rost aravanc...@gmail.com wrote: Also I can try to implement them by myself. I have some ideas how to do this. -- 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
Clojure IRC help
Sorry for asking this here, but it's about the Clojure IRC room, which is kind of related to Clojure, being this group's sister help resource. I know nothing about IRC, but I've been using the Colloquy application for Mac OS X to connect to the Clojure IRC room on irc.freenode.net. It was working fine for a month, until recently—every time I try to send a message to the room, I get the following error: Can't send to room #clojure on irc.freenode.net. Server Details: Please register with services and use the IDENTIFY command (/msg nickserv help) to speak in this channel I don't know if a setting in my client or in the server changed, but does anyone have any idea how I might get around this? I haven't found any help on Google, and the room is so convenient for small Clojure questions. -- 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
Re: Clojure IRC help
Thanks for the link; it's helpful. I've registered with Freenode as joshua-choi with a password and nickname, and my IRC client informs me when I reconnect that the server has identified me as joshua-choi. However, when I try to send a message, I still get the same error. Could anything else be a problem too? On Jan 24, 11:34 am, David Nolen dnolen.li...@gmail.com wrote: Perhaps this might help:http://freenode.net/faq.shtml#userregistration On Sun, Jan 24, 2010 at 1:30 PM, joshua-choi rbysam...@gmail.com wrote: Sorry for asking this here, but it's about the Clojure IRC room, which is kind of related to Clojure, being this group's sister help resource. I know nothing about IRC, but I've been using the Colloquy application for Mac OS X to connect to the Clojure IRC room on irc.freenode.net. It was working fine for a month, until recently—every time I try to send a message to the room, I get the following error: Can't send to room #clojure on irc.freenode.net. Server Details: Please register with services and use the IDENTIFY command (/msg nickserv help) to speak in this channel I don't know if a setting in my client or in the server changed, but does anyone have any idea how I might get around this? I haven't found any help on Google, and the room is so convenient for small Clojure questions. -- 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.comclojure%2bunsubscr...@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 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
Re: Clojure IRC help
Ah! Never mind! I just got an email telling me that I had to verify the account! I did that, and I can now send messages to the room (I think). Thanks a lot! On Jan 24, 12:00 pm, joshua-choi rbysam...@gmail.com wrote: Thanks for the link; it's helpful. I've registered with Freenode as joshua-choi with a password and nickname, and my IRC client informs me when I reconnect that the server has identified me as joshua-choi. However, when I try to send a message, I still get the same error. Could anything else be a problem too? On Jan 24, 11:34 am, David Nolen dnolen.li...@gmail.com wrote: Perhaps this might help:http://freenode.net/faq.shtml#userregistration On Sun, Jan 24, 2010 at 1:30 PM, joshua-choi rbysam...@gmail.com wrote: Sorry for asking this here, but it's about the Clojure IRC room, which is kind of related to Clojure, being this group's sister help resource. I know nothing about IRC, but I've been using the Colloquy application for Mac OS X to connect to the Clojure IRC room on irc.freenode.net. It was working fine for a month, until recently—every time I try to send a message to the room, I get the following error: Can't send to room #clojure on irc.freenode.net. Server Details: Please register with services and use the IDENTIFY command (/msg nickserv help) to speak in this channel I don't know if a setting in my client or in the server changed, but does anyone have any idea how I might get around this? I haven't found any help on Google, and the room is so convenient for small Clojure questions. -- 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.comclojure%2bunsubscr...@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 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
Re: Was it decided to add these functions to core?
On creating an infinite range, I think it'd be wonderful if Double/ POSITIVE_INFINITY or something like it would be bound to a core symbol, such as infinity or something. That'd way, one would be able to do things like (range 3 infinity) or ( infinity 5). CuppoJava, how long ago did those discussions that you're talking about occur? On Jun 23, 2:15 pm, Stephen C. Gilardi squee...@mac.com wrote: On Jun 23, 2009, at 2:07 PM, Chouser wrote: On Tue, Jun 23, 2009 at 1:09 PM, CuppoJavapatrickli_2...@hotmail.com wrote: (iterate inc 0) Just riffing here, but what if range took some kind of sentinel to indicate an infinite range? So instead of (iterate inc 0), you could say (range 0 :forever). Then that would also allow: (range 0 :forever 2) ; even numbers (range 1 :forever 2) ; odd numbers Along these lines, please see also: http://groups.google.com/group/clojure/browse_frm/thread/5e665ce7a318... --Steve smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Small question: Best way to create a map with vector vals
Come to think of it, this would also work for me: keeping the vector
of pairs, and instead using filter to get the values of a key:
(defn get-from-pairs [pairs key-to-fetch]
(map #(get % 1) (filter #(= key-to-fetch (get % 0)) pairs)))
(I wish the key and val functions were defined on vectors too. :( )
Is there still a better Clojure way?
On Jun 23, 3:09 pm, samppi rbysam...@gmail.com wrote:
The idiom (into {} coll-of-entries) is often used to create a map from
a collection of entries or two-sized vectors. But what if I want to do
something like this:
(mystery-fn [[:a 1] [:b 3] [:b 5] [:c 1]]) ; returns {:a [1], :b [3
5], :c [1]})
The only way I can think of doing this is with a complex loop
construction. But can mystery-fn be built without resorting to that?
What would be the best way?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: breaking early from a tight loop
Is the function of the filter identity call to make (map isInteresting pixels) a lazy sequence? I thought that the sequences map returned were already lazy, but I could be mistaken. On Jun 12, 8:56 am, CuppoJava patrickli_2...@hotmail.com wrote: Hi Vlad, I would approach it like this, and make full use of Clojure's lazy sequences: (count (take-while belowCount (filter identity (map isInteresting pixels -Patrick --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: breaking early from a tight loop
Oh! I see. Thanks for the explanation. On Jun 12, 9:56 am, J. McConnell jdo...@gmail.com wrote: On Fri, Jun 12, 2009 at 12:35 PM, joshua-choi rbysam...@gmail.com wrote: Is the function of the filter identity call to make (map isInteresting pixels) a lazy sequence? I thought that the sequences map returned were already lazy, but I could be mistaken. I believe the idea is that mapping isInteresting over pixels will produce a lazy sequence of true/false values, eg. (true true false ...) or, if it returns a measure of the interestingness of a pixel, (0.75 0.32 nil ...). Then, the filter on identity will strip out any* false/nil values, leaving only the interesting pixels to count. HTH, - J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: In let: unpacking maps with accessors too
Oh, I didn't know that. It makes me wonder, then, why integers were
not implemented as functions of sequential collections: (3
[:a :b :c]).
Ah, well. I guess since let can't be changed, it's then a choice
between using accessors or being more elegant. Thanks for the reply.
On Jun 8, 9:25 am, Konrad Hinsen konrad.hin...@laposte.net wrote:
On Jun 8, 2009, at 17:46, samppi wrote:
...I'd love it if the values of symbol keys could be any symbol, not
just keywords, so that the key symbol is bound to (val-symbol
the-map):
(let [{name this-is-a-symbol} person-1] ...) ; name is bound to
(this-is-a-symbol person-1)
It's backwards-compatible. But is this possible? Practical?
I don't think it could made to be backwards-compatible. The
documentation states:
Map binding-forms allow you to bind names to parts of associative
things (not just maps), like maps, vectors, string and arrays (the
latter three have integer keys).
The current implementation of destructuring map binding forms uses get:
(destructure '[{name :name} person-1])
- [map__268 person-1 name (clojure.core/get map__268 :name)]
This works as advertised with maps, vectors, strings, etc. Your
proposal would change the expansion to
- [map__268 person-1 name (:name map__268)]
That works fine if person-1 is a map, but destructuring a vector with
a map binding form is no longer possible.
Nothing stops you from defining your own let-like macro with your own
destructuring rules, of course!
Konrad.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: error-kit + test-is
I'd love for that to happen—either error-kit support in test-is or
test-is support in error-kit. clojure.contrib libraries should be able
to use each other with no worries, since they'll be installed together
just about always.
On May 17, 12:52 am, Dan Larkin d...@danlarkin.org wrote:
Sorry for the necro, but I just started using error-kit and read this
thread for the first time today.
Both error-kit (errors no longer inherit from *error* AFAICT) and test-
is (the report function syntax) have changed since David last posted a
working function, so I've updated it work with the latest revision of
contrib. Would it make sense for this to be included in
error_kit.clj? That way raised? would automatically work when testing
any error-kit'ed code.
Attached is a patch for adding raised? to error-kit.
error_kit_test_is.patch
1KViewDownload
On Feb 16, 2009, at 12:13 PM, David Nolen wrote:
(defmethod assert-expr 'raised? [msg [_ error-type body :as form]]
(let [error-name (qualify-sym error-type)]
`(with-handler
(do
~...@body
(report :fail ~msg '~form ~(str error-name not raised.)))
(handle ~error-type {:as err#}
(report :pass ~msg '~form nil))
(handle *error* {:as err#}
(report :fail ~msg '~form (:tag err#))
You're right I think the entire first handle statement was wrong. I
believe handle does the isa? check on the error type, correct? If so
then this will allow inherited error types to pass the test.
Many, many thanks for the feedback.
test-is + error-kit is a great combo.
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---
