Re: matching, assigning and branching in one form
or even without let: (condp re-find msg #^:(.*?)!.*PRIVMSG (.*) :(.*) : (fn [[_ from to message]] (true-form ...)) (false-form...)) On Saturday, June 22, 2013 11:26:35 PM UTC+12, Vincent wrote: What about using condp? (condp re-find msg #^:(.*?)!.*PRIVMSG (.*) :(.*) : #(let [[_ from to message] %] (logic...))) Vincent On Friday, 21 June 2013 17:43:50 UTC+2, Steven Arnold wrote: Hi, I am writing a simple IRC bot, pretty much just for fun, starting with a simple implementation originally posted by Nurullah Akkaya on his blog. It already does what it's supposed to, which is message a fortune from mod-fortune (shelling out) when someone asks it to. However, there's a bit of code I don't like. It looks like this: (cond (re-find #^:(.*?)!.*PRIVMSG (.*) :(.*) msg) (let [[_ from to message] (re-find #^:(.*?)!.*PRIVMSG (.*) :(.*) msg)] [...logic omitted...] What's happening is we're looking for a PRIVMSG, and if we find one, we scan the message again and pull out the chunks we're interested in, and use them in the logic part below. The problem is I don't like maintaining two regular expressions. I wish I could use it only once, and therefore change it only once if it needs to be modified. I'd prefer to see an expression that looks like this (for example): (cond (if-matched #^:(.*?)!.*PRIVMSG (.*) :(.*) msg [from to message] (true form) (optional false form))) The if-matched acts as a let block while pulling out groups and assigning to local variables at the same time. Also, it ignores the first match of re-find, which is the entire expression -- not generally useful to me. Maybe if-matched-groups would ignore the overall expression, and if-matched would include it. I suppose a macro might be the way to go to accomplish this, but I wonder if there are any Clojure tricks that could accomplish this short of a macro. Also, do any fellow Clojurians think a macro like this is a bad idea in general? Would you suggest taking a different tack to solve this problem? Thanks in advance! steven -- -- 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/groups/opt_out.
Re: Data vs API
Great question and great answers, thank you. Regarding (3), what if want to process various customer order implementations (say, sort them) in a polymorphic way depending just on their total-price? Assuming I do not control the implementations.. Is it ok in this case to define *HasTotalPrice* protocol (or *total-price*multimethod) and code against that? Or is it better to accept a data structure * along with *total-price-fn* function as an additional parameter? * with :*total-price-fn* as a part of the data structure? * with *:total-price* value already computed? Thanks for any hints.. On Thursday, May 3, 2012 8:30:33 AM UTC+12, stuart@gmail.com wrote: I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? (1) You always have to choose a representation for your data. (2) Having chosen a data representation, if you make an accessor function API, you now have two representations. This is the very opposite of DRY. If you think that the representation implied by the accessor functions is better/more stable than the data representation, then choose a data representation like the one implied by your accessor functions. (3) If you have helper functions for dealing with a particular representation, those helpers can and should be separate from the representation itself. For example, a customer order is some combination of maps, vectors, etc. totalPrice is never a member function of some accessor-riddled Order object -- it is instead a plain function that knows how to navigate a data representation (or, via a la carte polymorphism, many different representations). Cheers, Stu Stuart Halloway Clojure/core http://clojure.com -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Multiple args: opts map vs inline arguments
According, to the library coding standards, the first is better:
(release-sharks 2 :laser-beams true); good
(release-sharks 2 {:laser-beams true}) ; bad
http://dev.clojure.org/display/design/Library+Coding+Standards
On Tuesday, June 18, 2013 5:26:15 PM UTC+12, Omer Iqbal wrote:
Hey folks,
What'c considered more idiomatic when having multiple, optional arguments?
(defn foo1 [a b args]
(let [opts (apply hash-map args]
...))
or
(defn foo2 [a b opts]
...)
Cheers,
Omer
--
--
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/groups/opt_out.
Re: In what OS do you code?
OS X on the working machine, Ubuntu on the servers. For my project it makes little difference, especially with *brew* on the mac. Currently moving from vi to emacs. On Saturday, June 15, 2013 1:46:37 AM UTC+12, Erlis Vidal wrote: Hi, I'm a bit curious to know in what OS do you code. Do you prefer iOS, Linux, Windows? Why is that? Because the tools? The environment? 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/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
(merge {:attr something} obj)
--
--
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/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
Sorry, that's just another suggestion for the first pattern.
For the second, I would use:
(cond- obj (some-test obj) some-transformation)
On Sunday, May 26, 2013 12:05:49 PM UTC+2, dmirylenka wrote:
(merge {:attr something} obj)
--
--
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/groups/opt_out.
Re: What's the point of - ?
For me - is a bread and butter of working with collections, like here: (- some-collection (concat other-collection) distinct (filter some-predicate) (sort-by some-sort-fn) (take 10)) On Monday, March 11, 2013 11:58:29 AM UTC+1, edw...@kenworthy.info wrote: So I understand that: (- foo bar wibble) is equivalent to (wibble (bar (foo))) With the advantage that the latter version is better, in the sense that it's clearer what the final result is (the result of the call to wobble). What I don't understand is the need for - the only thing it seems to do is make something Lispy appear to be imperative. Is that it? -- -- 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/groups/opt_out.
Re: Found bug in contains? used with vectors.
As for contains? behavior on lists, it is fixed (CLJ-932https://github.com/clojure/clojure/commit/3acb6ee7ec5c295ae14de861d03a5efd115a5968) in Clojure 1.5, some 17 days ago: = (contains? '(1 2 3) 2); IllegalArgumentException contains? not supported on type: clojure.lang.PersistentList ... I wonder if get is also going to be fixed? = (get [1 2 3] 2) 3 = (get '(1 2 3) 2) nil On Monday, September 3, 2012 1:03:07 PM UTC+2, Goldritter wrote: I use Clojure 1.4.0 and wanted to use 'contains?' on a vector and get following results: = (contains? [1 2 3] 3) false = (contains? [1 2 3] 2) true As it seems 'contains?' does not check for the last entry in the vector. And an other question. Why does contains? returns everytime 'false' when used on a list? = (contains? (list 1 2 3) 1) false = (contains? (list 1 2 3) 2) false = (contains? (list 1 2 3) 3) false -- 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: Found bug in contains? used with vectors.
Instead of
(let [predicate #(contains? (set unselect) %1)] ...)
I would write
(let [predicate (set unselect)] ...)
On Tuesday, September 4, 2012 11:10:04 AM UTC+2, Marcus Lindner wrote:
I wanted to use it to select a random element in a collection (set,
vector or list) where I can define elements which should not be selected.
The function I now use is:
(defn select-random [collection unselect]
(select-random collection unselect) selects a random element from
the specified 'collection'.
It will ignore any element which is specified in 'unselect'. If none
elements are specified in 'unselect',
then any element from the specified 'collection' may be chosen.
( let [predicate #(contains? (set unselect) %1)]
(rand-nth (remove predicate collection
Eventually this can be optimized for better reading and/or performance.
It might be also a good idea to add some preconditions to it like
{pre: [(coll? collection)] }.
Am 03.09.2012 13:29, schrieb Tassilo Horn:
Goldritter marcus.goldr...@googlemail.com javascript: writes:
Ah ok. So I need to transform a vector and/or a list into a set first.
No, not really. All clojure collections implement java.util.Collection,
so you can always use
(.contains your-coll something)
to check if your-coll contains something. However, keep in mind that
this does a linear search for lists, sequences or vectors. So if your
algorithm relies on containment checks, you might be better off using
sets directly.
Bye,
Tassilo
--
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: anonymous functions with names
Just 2 cents: A name you give to the anonymous function also appears in the stack traces instead of the things like fn_123_4532, which is very convenient for debugging. On Friday, August 31, 2012 5:52:55 PM UTC+2, Erlis Vidal wrote: Hi guys, I've been reading but I'm still confused about the difference between an anonymous function with name vs a defn function (fn my-func1[x] x) (defn my-func2[x] x) Thanks, Erlis -- 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: (merge) = nil
I sort of remember Rich Hickey say this, but I am not sure :).
I was a bit mistaken.
In this video (
http://blip.tv/clojure/clojure-data-structures-part-2-714064 ) , around
42nd minute, he says that assoc is the normal way and is more
convenient because you can assoc multiple keys and values without having
to create a map out of them:
(assoc m :a 1 :b 2) ; vs.
(conj m {:a 1 :b 2})
On Thursday, August 30, 2012 1:31:41 AM UTC+2, dmirylenka wrote:
I sort of remember Rich Hickey say this, but I am not sure :).
As far as I see it, it is generally better to use more specific functions,
as they make the assumptions about the types of the arguments more
explicit. Sometimes they are also more efficient (but probably not in this
case).
So, for working with maps assoc is more preferable, as it is specific to
maps (at least for non-integer keys).
Polymorphic functions are nice when the concrete argument type is not
important (e.g. list vs. vector).
But in practice very few code is not going care whether it's working with
map or a sequence - so conj is kind of overly polymorphic.
This extra polymorphism can be confusing, for instance, if one tries to
figure out the type of the following expression:
(conj something [1 2]).
contains? is maybe another example of generic function that has created
confusion.
That's my understanding ) .
On Thursday, August 30, 2012 12:05:48 AM UTC+2, Meikel Brandmeyer
(kotarak) wrote:
Hi,
Am 29.08.2012 um 23:38 schrieb dmirylenka:
Although, code working with maps shouldn't use conj anyway.
Why?
Kind regards
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: (merge) = nil
I would say, they treat nil as an empty sequence, which makes nil,
effectively, a unit:
(assoc nil :a :b) ; = {:a :b}
(merge nil {:a :b}) ; = {:a :b}
etc.
On Wednesday, August 29, 2012 7:36:26 PM UTC+2, Moritz Ulrich wrote:
This isn't true in Clojure: http://clojure.org/lisps
However, most functions treat an empty seq as nil because they call `seq'
on their arguments.
On Wed, Aug 29, 2012 at 6:41 PM, Joop Kiefte iko...@gmail.comjavascript:
wrote:
An empty sequence is equal to nil.
2012/8/29 Ambrose Bonnaire-Sergeant abonnair...@gmail.com javascript:
:
My guess is that `merge` has an invariant if all args are nil, return
nil,
making calls to `seq` contagious from args to return value.
= (merge (seq {}) (seq {}))
nil
Just a guess though.
Thanks,
Ambrose
On Thu, Aug 30, 2012 at 12:18 AM, Brian Marick
mar...@exampler.comjavascript:
wrote:
Why does `(merge)` return nil? I would have expected it to return the
unit
({}) by analogy with things like this:
(+) = 0
(*) = 1
-
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
Occasional consulting on Agile
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
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 clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your
first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
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 clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
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
another why: (flatten #{:a :b}) = () ???
Calling flatten on anything that is not 'sequential?' returns an empty
sequence:
(flatten 1); = ()
(flatten Hi); = ()
With sets if feels somewhat strange:
(flatten #{#{:a} #{:b :c}}); = ()
For some reason I expected #{#{:a} #{:b :c}} to equal #{:a :b :c}.
Ok, the docstring says: Takes any nested combination of sequential
things..., and sets are not sequential...
But then, why
(reduce + (flatten #{1 2})); = 0
(r/reduce + (r/flatten #{1 2})); = 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: (merge) = nil
Hm.. There seem to be cases when nil is not equivalent to {} when working
with maps:
(conj {} [:a :b]); = {:a :b}
(conj nil [:a :b]); = ([:a :b])
Although, code working with maps shouldn't use conj anyway.
Any other examples?
On Wednesday, August 29, 2012 9:08:07 PM UTC+2, dmirylenka wrote:
I would say, they treat nil as an empty sequence, which makes nil,
effectively, a unit:
(assoc nil :a :b) ; = {:a :b}
(merge nil {:a :b}) ; = {:a :b}
etc.
On Wednesday, August 29, 2012 7:36:26 PM UTC+2, Moritz Ulrich wrote:
This isn't true in Clojure: http://clojure.org/lisps
However, most functions treat an empty seq as nil because they call `seq'
on their arguments.
On Wed, Aug 29, 2012 at 6:41 PM, Joop Kiefte iko...@gmail.com wrote:
An empty sequence is equal to nil.
2012/8/29 Ambrose Bonnaire-Sergeant abonnair...@gmail.com:
My guess is that `merge` has an invariant if all args are nil, return
nil,
making calls to `seq` contagious from args to return value.
= (merge (seq {}) (seq {}))
nil
Just a guess though.
Thanks,
Ambrose
On Thu, Aug 30, 2012 at 12:18 AM, Brian Marick mar...@exampler.com
wrote:
Why does `(merge)` return nil? I would have expected it to return the
unit
({}) by analogy with things like this:
(+) = 0
(*) = 1
-
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
Occasional consulting on Agile
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@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+u...@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 clo...@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+u...@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 clo...@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+u...@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: another why: (flatten #{:a :b}) = () ???
Thanks for the elaborate answer!
It also clears some other doubts I had regarding the core functions.
On Wednesday, August 29, 2012 11:34:56 PM UTC+2, miner wrote:
flatten has been discussed before:
https://groups.google.com/forum/?fromgroups=#!topic/clojure/ye70iNJ73zc
See also CLJ-400, but it looks like no patch was submitted.
http://dev.clojure.org/jira/browse/CLJ-400
I think the general policy for Clojure is that the core functions of
course should work as documented, but they do not necessarily handle
undocumented edge cases. So if you use the wrong kinds of arguments, the
implementation does not have to detect your error -- it might throw or just
give you non-useful results. There's a trade-off among ease of
implementation, performance and programmer friendliness. If it's a common
mistake, maybe an assertion is warranted. If I remember correctly, Rich
Hickey suggested that someday there might be an option to run a stricter
version of Clojure (with lots of assertions) during development, and a
faster version with less checking in production.
Regarding flatten in particular, I would like it to be faster and to do a
bit more to help the careless programmer. I was all set to submit a patch
condemning the elegant but slow implementation when I noticed that the new
reducers version of flatten in 1.5 alphas is amazingly fast. So that
looks like the way to go.
On Aug 29, 2012, at 3:47 PM, dmirylenka daniilm...@gmail.comjavascript:
wrote:
Calling flatten on anything that is not 'sequential?' returns an empty
sequence:
(flatten 1); = ()
(flatten Hi); = ()
With sets if feels somewhat strange:
(flatten #{#{:a} #{:b :c}}); = ()
For some reason I expected #{#{:a} #{:b :c}} to equal #{:a :b :c}.
Ok, the docstring says: Takes any nested combination of sequential
things..., and sets are not sequential...
But then, why
(reduce + (flatten #{1 2})); = 0
(r/reduce + (r/flatten #{1 2})); = 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: (merge) = nil
I sort of remember Rich Hickey say this, but I am not sure :). As far as I see it, it is generally better to use more specific functions, as they make the assumptions about the types of the arguments more explicit. Sometimes they are also more efficient (but probably not in this case). So, for working with maps assoc is more preferable, as it is specific to maps (at least for non-integer keys). Polymorphic functions are nice when the concrete argument type is not important (e.g. list vs. vector). But in practice very few code is not going care whether it's working with map or a sequence - so conj is kind of overly polymorphic. This extra polymorphism can be confusing, for instance, if one tries to figure out the type of the following expression: (conj something [1 2]). contains? is maybe another example of generic function that has created confusion. That's my understanding ) . On Thursday, August 30, 2012 12:05:48 AM UTC+2, Meikel Brandmeyer (kotarak) wrote: Hi, Am 29.08.2012 um 23:38 schrieb dmirylenka: Although, code working with maps shouldn't use conj anyway. Why? Kind regards 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: (merge) = nil
It's not a unit if you're using `if-let` and expect nil to represent
failure and {} to represent a success that establishes no bindings.
You mean, something like this, right? :
(if-let [{:keys [a]} {}] Hi); = Hi
(if-let [{:keys [a]} nil] Hi); = nil
Interesting example!
In my own code, however, I wouldn't use a collection (in this case, a map)
as a test expression inside if (which happens here under the hood).
Exactly because in many cases empty sequence is equivalent to nil.
Instead, I would explicitly test for emptiness: (if (seq my-map) this that).
On Thursday, August 30, 2012 12:46:05 AM UTC+2, Brian Marick wrote:
On Aug 29, 2012, at 2:08 PM, dmirylenka wrote:
I would say, they treat nil as an empty sequence, which makes nil,
effectively, a unit:
(assoc nil :a :b) ; = {:a :b}
(merge nil {:a :b}) ; = {:a :b}
It's not a unit if you're using `if-let` and expect nil to represent
failure and {} to represent a success that establishes no bindings.
-
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
Occasional consulting on Agile
--
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 Sticker
I've got my stickers! So happy... On Friday, July 6, 2012 11:09:29 AM UTC+2, dmirylenka wrote: +1 On Sunday, June 10, 2012 3:03:46 AM UTC+2, aboy021 wrote: Is there anywhere that I can get a Clojure sticker? -- 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: Ideas for interactive tasks
, dmirylenka daniilm...@gmail.comwrote: Wow, too bad I already graduated :) ФПМИ? On Thursday, August 9, 2012 5:28:54 PM UTC+2, Nikita Beloglazov wrote: Thank you, Jim. This is Belarusian State University. On Thu, Aug 9, 2012 at 6:23 PM, Jim - FooBar(); jimpi...@gmail.comwrote: On 09/08/12 16:21, Nikita Beloglazov wrote: I'm going to organize little clojure course at my university this year. this is amazing! seriously, bravo! what university is this? Jim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@**googlegrou**ps.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://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 clo...@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+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://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 clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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: Ideas for interactive tasks
It's really great that you are going to teach Clojure at BSU. I have no clue about teaching, but my impression is that back in my days, we didn't learn much about how to write good code. Maybe things were different in 'informatics', but in 'applied mathematics', for instance, we only had exposure to imperative programming. If this is still the case, I think, your course could get students familiar with the concepts and benefits of FP (immutability, referential transparency, etc.). Then they could learn more specific things like persistent data structures, multimethods, macros, agents, etc.. I would probably try to emphasize the advantages of certain features of Clojure and FP in general, when it is appropriate to use them and how. As for the interactive tasks, I think, it's a good idea, as they are fun. My only note so far is that they seem to require quite some effort unrelated to learning Clojure, but it may be what you intended (would be nice seing your course program). For instance, in 'artillery' task, the time it took to code up the solution was infinitesimal, compared to the time I spent building the model and recalling how to solve trigonometric and quadratic equations :). But seing the plain fall was rewarding... One task I remember form my courses was to program a trolley that moves parts between the machines of a production line (Each machine has an input and output queue with limited capacities, and a distinct processing time). This can also be extended for concurrency task, if you introduce two trolleys, etc. Another thought about concurrency - let them program the 'dining philosophers'. In addition, the idea of writing game bots can be exploited further: e.g. what about a tetris bot? I'm very excited about your intent to teach Clojure at BSU. I would be glad to stay in touch for further discussions. Daniil On Monday, August 13, 2012 9:17:26 PM UTC+2, Nikita Beloglazov wrote: Daniil, yes it is Do you have some suggestions about tasks or teaching at the BSU in generally? :) Nikita On Mon, Aug 13, 2012 at 9:00 PM, dmirylenka daniilm...@gmail.comjavascript: wrote: Wow, too bad I already graduated :) ФПМИ? On Thursday, August 9, 2012 5:28:54 PM UTC+2, Nikita Beloglazov wrote: Thank you, Jim. This is Belarusian State University. On Thu, Aug 9, 2012 at 6:23 PM, Jim - FooBar(); jimpi...@gmail.comwrote: On 09/08/12 16:21, Nikita Beloglazov wrote: I'm going to organize little clojure course at my university this year. this is amazing! seriously, bravo! what university is this? Jim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@**googlegrou**ps.com For more options, visit this group at http://groups.google.com/**group**/clojure?hl=enhttp://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 clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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: Pattern of Succinctness
Should be (filter (comp not nil?) coll) On Sunday, August 12, 2012 9:44:11 PM UTC+2, Pierre-Henry Perret wrote: I prefer (filter (partial not nil?) coll) as a HOF Le dimanche 12 août 2012 20:46:59 UTC+2, rmarianski a écrit : On Sun, Aug 12, 2012 at 11:22:55AM -0700, Takahiro Hozumi wrote: (filter (partial not nil?) coll) You mean (filter (comp not nil?) coll). I'm not sure which is more readable, but thanks for Meikel and Alex, I now prefer (remove nil? coll). remove is better in this case, but for posterity (comp not nil?) can be spelled as (complement nil?) Robert -- 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: Pattern of Succinctness
Using threading operators + anonymous functions sometimes yields more
succinct code than using HOF,
especially because 'partial' and 'comp' are such long names:
(comp count (partial filter nil?) (partial map foo))
#(- % (map foo) (filter nil?) count)
On Sunday, August 12, 2012 7:35:16 PM UTC+2, Takahiro Hozumi wrote:
Hi,
I would like to know common technics that make code succinct.
For example:
(or (:b {:a 1}) 0)
(:b {:a 1} 0)
(if-not x 1 2)
(if x 2 1)
(filter #(not (nil? %)) coll)
(filter identity coll) ;; nearly equal
Please let me know any tips you found.
Cheers,
Takahiro.
--
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: Ideas for interactive tasks
Wow, too bad I already graduated :) ФПМИ? On Thursday, August 9, 2012 5:28:54 PM UTC+2, Nikita Beloglazov wrote: Thank you, Jim. This is Belarusian State University. On Thu, Aug 9, 2012 at 6:23 PM, Jim - FooBar(); jimpi...@gmail.comjavascript: wrote: On 09/08/12 16:21, Nikita Beloglazov wrote: I'm going to organize little clojure course at my university this year. this is amazing! seriously, bravo! what university is this? Jim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@**googlegroups.com javascript: For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://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: community interest in machine learning (?)
Not sure about the community, but I personally would be very interested in having a machine learning library or environment in Clojure. I'm playing with classification and clustering of academic papers, and use clojure for the whole research cycle - crawling and parsing the data from the web, text processing (through weka or mallet), classification (through svm-clj), and, of course, setting up the experiments, and doing input-output between other tools. I was also thinking it would be nice to have Incanter extended with machine learning algorithms. So far it looks like its focus has been statistics rather then machine learning. On Sunday, July 15, 2012 7:10:22 PM UTC+2, Joshua Bowles wrote: New to Clojure (but not Lisp). Does anyone have a good sense of the interest in machine learning in Clojure community? I've seen in the last few threads some interesting posts and libraries related to machine learning, and there is plenty of stuff one can get from Java (mahout, weka, clj-ml [ http://antoniogarrote.github.com/clj-ml/index.html]), but I'm curious to know if anyone here has a sense of the overall community interest. It's nice to see interesting libraries that support needed tasks for machine learning (I'm all for links to libraries), but what I'm really trying to get is* a sense of the overall interest the community has in machine learning*. For example, Python community overall has a lot of interest in scientific computing and machine learning. Compare this to Ruby... not that you couldn't provide good libraries in Ruby (for example the SciRuby project), but the Ruby community overall does not seem to have much interest in these kinds of academic pursuits. -- 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 Sticker
+1 On Sunday, June 10, 2012 3:03:46 AM UTC+2, aboy021 wrote: Is there anywhere that I can get a Clojure sticker? -- 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: IllegalStateException I/O in transaction in REPL
Thank you for the answers, and sorry for late reply. It seems I figured out what the problem was. My code was placed at the top level of a file sci-clustering/examples.clj, and I was loading the namespace from REPL like this:(use 'sci-clustering.examples :reload-all). So it looks like clojure.core/use loads the libraries / namespaces inside a transaction, which makes sense. Here is the code: http://pastie.org/4130967 , and here is the stack trace: http://pastie.org/4130930 . Best regards, Daniil. On Friday, June 15, 2012 1:20:01 AM UTC+2, Stephen Compall wrote: On Thu, 2012-06-14 at 13:33 -0700, dmirylenka wrote: Could you please explain a bit more? I don't have any dosync in my code. Look through your backtrace for a call to clojure.lang.LockingTransaction.runInTransaction. Its caller is using dosync. -- Stephen Compall ^aCollection allSatisfy: [:each|aCondition]: less is better -- 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: IllegalStateException I/O in transaction in REPL
Could you please explain a bit more? I don't have any dosync in my code. Daniil On Thursday, June 14, 2012 4:17:46 PM UTC+2, Meikel Brandmeyer (kotarak) wrote: Hi, the exception probably stems from the fact that you do the database interaction inside a dosync transaction. Kind regards 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
