101 on simple and flexible graph query/update?

[Bertrand Dechoux]

Hi,

I have various general questions about how one can perform simple and 
flexible graph query/update.

If we start by a structure being nested maps then I know about 
get-in/update-in/assoc-in. The common point about these functions is that 
they all take a path to where the data is in the superstructure and that 
this path is only a sequence of keys, which may or not be symbols.

1) What happens when one layer of this superstructure is not a map but a 
sequence? For the sake of the argument, we can keep the discussion simple 
by only arguing about the vector case.

Typically instead of
{ :key1 { :key2 val }}

we now have
{ :key1 [{ :key2 val }]}

Of course, one can perform get/update/assoc using map/reduce. However, it 
means that the code using this superstructure is taking a hit on 
complexity/maintenance each time a non-map layer must be crossed. Of 
course, the simplicity/beauty of the current implementation is that a path 
can point to at most one target substructure/value. Is there a way to do 
something similar with a more general definition of a path? One would 
assume that it is something that might be handled by xml/html modification 
libraries (think xpath or css selector) but this problem is more general 
and not domain specific. Is there a clean library that handle that case 
without being tied to html/xml?

2) How to deal with more general superstructure like a graph?

One could build an immutable graph but I don't believe it is something that 
can be done by nesting immutable maps and vectors. One solution to deal 
with 'entity'--'entity' relationships is for one of the member to own only 
an identifier to get the other member from another reference structure.

(from the basic OM tutorial:)

{:people
 [{:type :student :first "Ben" :last "Bitdiddle"}
  {:type :professor :first "Gerald" :last "Sussman" :classes [:6001 :6946]}]
 :classes
 {:6001 "The Structure and Interpretation of Computer Programs"
  :6946 "The Structure and Interpretation of Classical Mechanics"
  :1806 "Linear Algebra"}}


It is, of course, again, manually possible to get/update/assoc using 
map/reduce.  But then, again, this is the same problematic as with the 
first question : each time a relation needs to be crossed, the code using 
this superstructure is taking a hit on complexity/maintenance. How do you 
usually deal with this problematic?

For both question 1) and 2), a more appropriate data structure might be the 
answer like a graph/semantic-like store (Datomic or something else). The 
questions are about intermediary solutions which would be less heavier.

3) How does Demeter lives with graph traversal?

This law is often heard in the OOP world but it is a bit more general than 
that. When a long path on a superstructure is specified then if one 
intermediary layer is introduced later, all hardcoded paths will be broken 
ie in multiple locations in the code base. One would like to store local 
structure knowledge in a single place. How do you usually deal with this 
problematic?

I have yet to take a serious look at lenses and their composition, they are 
probably an element of answer, but they are more often seen in more 
statically typed langage.

Thanks for any feedback.

Bertrand

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An Averaging function

[Stephen Feyrer]

Hi Sam, Lee.

Thank you both.

It would appear that I am faced with the old adage, "A little knowledge is
a dangerous thing".

Again thank you, you ' ve been a great help.  If I may impose upon you a
little further?  Would either of you be able to recommend an introductory
book either for Clojure or FP that might fit well with Clojure, for the
mildly bewildered?  I have a book Programming Clojure but it is written
with an assumption of prior knowledge/experience which I don't have.  By
the way, Programming Clojure is a good book, I just don't think I fit
within the target audience.


On 10 July 2014 02:41, Lee Spector  wrote:

>
> On Jul 9, 2014, at 9:31 PM, Lee Spector  wrote:
> > You could patch (not recommended!) this by adding "do" to the beginning
> of that list:
>
> Or -- I now see, instead of adding the "do" you could just remove the
> outermost parentheses after the parameter list. But as Sam and I said this
> is a bad way to go anyway -- you want to avoid the nested defs.
>
>  -Lee
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 101 on simple and flexible graph query/update?

[Thomas Heller]

I usually just give every ENTITY in my system a primary id and structure 
everything in a nested map.

{:people {1 {:id 1 :type :student :name "Ben" :taking-classes #{1 2}}
  2 ...}
 :classes {1 {:id 1 :name "Clojure 101"}
   2 ...}}

This basically looks like a database table. You can also go with something 
a little more flat.

{1 {:type :student, :name "Ben" :taking-classes #{3}}
 3 {:type :class, :name "Clojure 101"}}

Usually needs some form of indexing otherwise you are taking some 
performance hits if you have alot of entities in your system. You dont want 
to (->> (vals @data) (filter #(= :class (:type %))) every time you want to 
list all :classes.

Nothing fancy but it is simple. 


On Thursday, July 10, 2014 10:26:33 AM UTC+2, Bertrand Dechoux wrote:
>
> Hi,
>
> I have various general questions about how one can perform simple and 
> flexible graph query/update.
>
> If we start by a structure being nested maps then I know about 
> get-in/update-in/assoc-in. The common point about these functions is that 
> they all take a path to where the data is in the superstructure and that 
> this path is only a sequence of keys, which may or not be symbols.
>
> 1) What happens when one layer of this superstructure is not a map but a 
> sequence? For the sake of the argument, we can keep the discussion simple 
> by only arguing about the vector case.
>
> Typically instead of
> { :key1 { :key2 val }}
>
> we now have
> { :key1 [{ :key2 val }]}
>
> Of course, one can perform get/update/assoc using map/reduce. However, it 
> means that the code using this superstructure is taking a hit on 
> complexity/maintenance each time a non-map layer must be crossed. Of 
> course, the simplicity/beauty of the current implementation is that a path 
> can point to at most one target substructure/value. Is there a way to do 
> something similar with a more general definition of a path? One would 
> assume that it is something that might be handled by xml/html modification 
> libraries (think xpath or css selector) but this problem is more general 
> and not domain specific. Is there a clean library that handle that case 
> without being tied to html/xml?
>
> 2) How to deal with more general superstructure like a graph?
>
> One could build an immutable graph but I don't believe it is something 
> that can be done by nesting immutable maps and vectors. One solution to 
> deal with 'entity'--'entity' relationships is for one of the member to own 
> only an identifier to get the other member from another reference structure.
>
> (from the basic OM tutorial:)
>
> {:people
>  [{:type :student :first "Ben" :last "Bitdiddle"}
>   {:type :professor :first "Gerald" :last "Sussman" :classes [:6001 
> :6946]}]
>  :classes
>  {:6001 "The Structure and Interpretation of Computer Programs"
>   :6946 "The Structure and Interpretation of Classical Mechanics"
>   :1806 "Linear Algebra"}}
>
>
> It is, of course, again, manually possible to get/update/assoc using 
> map/reduce.  But then, again, this is the same problematic as with the 
> first question : each time a relation needs to be crossed, the code using 
> this superstructure is taking a hit on complexity/maintenance. How do you 
> usually deal with this problematic?
>
> For both question 1) and 2), a more appropriate data structure might be 
> the answer like a graph/semantic-like store (Datomic or something else). 
> The questions are about intermediary solutions which would be less heavier.
>
> 3) How does Demeter lives with graph traversal?
>
> This law is often heard in the OOP world but it is a bit more general than 
> that. When a long path on a superstructure is specified then if one 
> intermediary layer is introduced later, all hardcoded paths will be broken 
> ie in multiple locations in the code base. One would like to store local 
> structure knowledge in a single place. How do you usually deal with this 
> problematic?
>
> I have yet to take a serious look at lenses and their composition, they 
> are probably an element of answer, but they are more often seen in more 
> statically typed langage.
>
> Thanks for any feedback.
>
> Bertrand
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 101 on simple and flexible graph query/update?

[François Rey]

On 10/07/14 10:26, Bertrand Dechoux wrote:
For both question 1) and 2), a more appropriate data structure might 
be the answer like a graph/semantic-like store (Datomic or something 
else). The questions are about intermediary solutions which would be 
less heavier.


I would suggest you look into the walk 
/prewalk 
/postwalk 
 functions. 
These are able to traverse arbitrary nested data structures while 
building a different or modified data structure.



3) How does Demeter lives with graph traversal?

This law is often heard in the OOP world but it is a bit more general 
than that. When a long path on a superstructure is specified then if 
one intermediary layer is introduced later, all hardcoded paths will 
be broken ie in multiple locations in the code base. One would like to 
store local structure knowledge in a single place. How do you usually 
deal with this problematic?


I have yet to take a serious look at lenses and their composition, 
they are probably an element of answer, but they are more often seen 
in more statically typed langage.


The walk /prewalk 
/postwalk 
 can support 
some resilience with respects to structural changes if one can recognize 
what any data structure represents at any level based on its content 
(e.g. a :type key).


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 101 on simple and flexible graph query/update?

[Daniel Neal]

> Is there a way to do something similar with a more general definition of 
a path? 

The lens library Fresnel (https://github.com/ckirkendall/fresnel) might be 
worth a look - it abstracts
get-in/assoc-in into lenses which can store/retrieve state from complex 
structures (and can be composed). 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An Averaging function

[Linus Ericsson]

You should try Clojure Programming (Halloway, Bedra). I felt enlightened
after reading the first edition, the second edition is also very good!

http://pragprog.com/book/shcloj2/programming-clojure

/Linus

On Thursday, July 10, 2014, Stephen Feyrer  wrote:

> Hi Sam, Lee.
>
> Thank you both.
>
> It would appear that I am faced with the old adage, "A little knowledge is
> a dangerous thing".
>
> Again thank you, you ' ve been a great help.  If I may impose upon you a
> little further?  Would either of you be able to recommend an introductory
> book either for Clojure or FP that might fit well with Clojure, for the
> mildly bewildered?  I have a book Programming Clojure but it is written
> with an assumption of prior knowledge/experience which I don't have.  By
> the way, Programming Clojure is a good book, I just don't think I fit
> within the target audience.
>
>
> On 10 July 2014 02:41, Lee Spector  > wrote:
>
>>
>> On Jul 9, 2014, at 9:31 PM, Lee Spector > > wrote:
>> > You could patch (not recommended!) this by adding "do" to the beginning
>> of that list:
>>
>> Or -- I now see, instead of adding the "do" you could just remove the
>> outermost parentheses after the parameter list. But as Sam and I said this
>> is a bad way to go anyway -- you want to avoid the nested defs.
>>
>>  -Lee
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> 
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An Averaging function

[Sam Ritchie]

Good luck with the learning, by the way! I found that the language had a 
definite "click" after a few weeks, and then I was in for good. Because 
the syntax is simple, many of the examples you'll see as you work 
through the book have a similar shape to them; I think this makes it 
easier to start absorbing patterns in Clojure. Have fun :)



Linus Ericsson 
July 10, 2014 at 6:52 AM
You should try Clojure Programming (Halloway, Bedra). I felt 
enlightened after reading the first edition, the second edition is 
also very good!


http://pragprog.com/book/shcloj2/programming-clojure

/Linus

On Thursday, July 10, 2014, Stephen Feyrer > wrote:

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.
Stephen Feyrer 
July 10, 2014 at 2:37 AM
Hi Sam, Lee.

Thank you both.

It would appear that I am faced with the old adage, "A little 
knowledge is a dangerous thing".


Again thank you, you ' ve been a great help.  If I may impose upon you 
a little further?  Would either of you be able to recommend an 
introductory book either for Clojure or FP that might fit well with 
Clojure, for the mildly bewildered?  I have a book Programming Clojure 
but it is written with an assumption of prior knowledge/experience 
which I don't have.  By the way, Programming Clojure is a good book, I 
just don't think I fit within the target audience.




--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.
Lee Spector 
July 9, 2014 at 7:41 PM

Or -- I now see, instead of adding the "do" you could just remove the 
outermost parentheses after the parameter list. But as Sam and I said 
this is a bad way to go anyway -- you want to avoid the nested defs.


-Lee

Lee Spector 
July 9, 2014 at 7:31 PM
On Jul 9, 2014, at 8:48 PM, Stephen Feyrer  wrote:


Hi,

I tried to create the function below in a Lighttable instarepl.  In lieu of any 
better idea for formatting, the<   >  statements below indicate instarepl 
output.

(defn avged ([x]
((def sumed (reduce + x))<  10>
(def counted (count x))<  4>
(def result (/ sumed counted))<  5/2>
result
)))

(avged [1 2 3 4])<  java.lang.ClassCastException: java.lang.Long cannot be cast 
to clojure.lang.IFn
Var.java:392 clojure.lang.Var.fn
Var.java:423 clojure.lang.Var.invoke
(Unknown Source) user/avged>

The objective of this function is just a learning exercise.

I have three questions:

1. Why doesn't it work, return a value?


Hi Stephen,

The main reason it doesn't work is that the expression after the parameter list [x] is a 
list and will be interpreted as a function call, with the function being whatever is 
returned from the first thing in the list -- which in this case is the "def 
sumed" definition, which returns the defined var.

You could patch (not recommended!) this by adding "do" to the beginning of that 
list:

(defn avged
   ([x]
 (do
   (def sumed (reduce + x))
   (def counted (count x))
   (def result (/ sumed counted))
   result)))

That will work, but it's not idiomatic clojure -- it is almost never idiomatic 
clojure to have a def or defn within another defn. Also, you've used the syntax 
that allows for multiple arglist/body pairs, although you only need one so the 
extra layer of parentheses isn't necessary.

Here's how I might write it somewhat more idiomatically:

(defn avged
  [x]
  (let [sumed (reduce + x)
counted (count x)
result (/ sumed counted)]
result))

=>  (avged [1 2 3 4])
5/2
=>  (float (avged [1 2 3 4]))
2.5



2. What doe

Re: auto-reloading tests with diffs

[Conrad]

Thanks, that's exactly what I was looking for!

On Thursday, July 3, 2014 8:41:07 AM UTC-5, Jake McCrary wrote:
>
> Hi Conrad,
>
> Not sure if this will meet your needs but I just tried using 
> humane-test-output with lein-test-refresh and had auto-running of tests 
> with a nice diff output. If humane-test-output gives you the output you are 
> looking for I'd imagine it works with prism as well.
>
> humane-test-output: https://github.com/pjstadig/humane-test-output
> lein-test-refresh: https://github.com/jakemcc/lein-test-refresh
>
> Jake
>
> On Wednesday, July 2, 2014 1:25:59 PM UTC-5, Conrad wrote:
>>
>> FYI, I installed difftest via a plugin entry in my ~/.lein/profiles.clj. 
>> This requires me to call "lein difftest", since "lein test" still shows the 
>> un-diffed test results. I suspect there's some extra step I need to take to 
>> hook difftest into the default error reporting to make it work with "lein 
>> prism" but I can't find any documentation for that... any pointers are 
>> welcome!
>>
>> On Wednesday, July 2, 2014 1:16:47 PM UTC-5, Conrad wrote:
>>>
>>> Hi, I'm doing some tests that require diff reporting (ala "lein 
>>> difftest") but want them to autoreload (ala "lein prism").
>>>
>>> Does anyone know if there's a way to make these libraries function 
>>> together? Is there some other approach/library I should be using to get 
>>> both diff reporting and autoreloading at once?
>>>
>>> Thanks for any pointers!
>>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 101 on simple and flexible graph query/update?

[Bertrand Dechoux]

*@*Thomas Heller: It's a bit cleaner indeed. That way, a 'join-like' 
operation does not need to know about the structure. But the three 
problematics from my post are still unsolved.

*@Francois Rey:* I believe walk/prewalk/postwalk (and zipper?) might be the 
building blocks for implementing query/update based on a more flexible path 
definition. But by themselves, they are a bit low level. They indeed are 
beautiful and useful abstractions but I think another abstraction, even 
higher, could be built.

*@Daniel Neal:* I will look into it. I am new to lenses as I said. I don't 
know if a lens can target multiple structures at once (first question).

(def s { :key1 [{ :key2 { :key3 val } }]})
(update-in s [:key1 :all :key2 :key3] inc)

The principle might work with a custom lens but I guess it is likely the 
implementation for the traversal must be changed in order to handle a 
sequence at each step. But at least I have a place where I can start from.

Bertrand


Le jeudi 10 juillet 2014 13:26:57 UTC+2, Daniel Neal a écrit :
>
> > Is there a way to do something similar with a more general definition of 
> a path? 
>
> The lens library Fresnel (https://github.com/ckirkendall/fresnel) might 
> be worth a look - it abstracts
> get-in/assoc-in into lenses which can store/retrieve state from complex 
> structures (and can be composed). 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

When to use ! in function name

[Cecil Westerhof]

When a function returns a true/false value you should end it with a '?'.

Clojure Programming says that with side effects you should end the function
name with a '!'.

I have functions reset-game! and walk!. But what about a function like
look? It does not change state, but it displays where you are. So it has a
side effect. But most of my functions have this. So, should I append them
all with a '!'?

-- 
Cecil Westerhof

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: When to use ! in function name

[Plínio Balduino]

IMO, ! is used when change any global state. A side effect like print on
screen is not enough to cause a ! in the name. I think that's why the
functions print/println don't have ! =)

Plínio


On Thu, Jul 10, 2014 at 12:28 PM, Cecil Westerhof 
wrote:

> When a function returns a true/false value you should end it with a '?'.
>
> Clojure Programming says that with side effects you should end the
> function name with a '!'.
>
> I have functions reset-game! and walk!. But what about a function like
> look? It does not change state, but it displays where you are. So it has a
> side effect. But most of my functions have this. So, should I append them
> all with a '!'?
>
> --
> Cecil Westerhof
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: When to use ! in function name

[Stefan Kamphausen]

On Thursday, July 10, 2014 5:28:26 PM UTC+2, Cecil Westerhof wrote:
>
> When a function returns a true/false value you should end it with a '?'.
>
> Clojure Programming says that with side effects you should end the 
> function name with a '!'.
>

"Use the bang! only for things not safe in an STM transaction."
-- http://dev.clojure.org/display/community/Library+Coding+Standards

Side-effects are usually a good candidate for this, but not necessarily so.

Best,
stefan

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: When to use ! in function name

[James Reeves]

In clojure.core, an ending "!" indicates a function that is unsafe for STM,
rather than one with side effects. For instance, alter and send are
functions with side effects, but have no ending "!" because they're safe to
use in a dosync block.

In other words, an ending "!" indicates a function has side effects that
are not idempotent.

- James


On 10 July 2014 16:28, Cecil Westerhof  wrote:

> When a function returns a true/false value you should end it with a '?'.
>
> Clojure Programming says that with side effects you should end the
> function name with a '!'.
>
> I have functions reset-game! and walk!. But what about a function like
> look? It does not change state, but it displays where you are. So it has a
> side effect. But most of my functions have this. So, should I append them
> all with a '!'?
>
> --
> Cecil Westerhof
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: When to use ! in function name

[Softaddicts]

The fn that does the display is the one having side effects.
Now if your look fn creates the side effect, it should reflect that in its name.

But... I wonder why it does so. Looking at something does not change state.
You may be better splitting the side effect away from it or change the name.

Looks (no pun intended) odd from a naming perspective but w/o looking at your 
code base it's hard to telll.  It may made sense in your context.

If look is a predicate, the name might not be appropriate.
number? is clearly a predicate. "look" does "look" as a true/false property
to me. visible? or hidden? look to me as a predicates.

But again it may make sense in your context.

If your fn does too many things, you may want to split it.

Luc P.

> When a function returns a true/false value you should end it with a '?'.
> 
> Clojure Programming says that with side effects you should end the function
> name with a '!'.
> 
> I have functions reset-game! and walk!. But what about a function like
> look? It does not change state, but it displays where you are. So it has a
> side effect. But most of my functions have this. So, should I append them
> all with a '!'?
> 
> -- 
> Cecil Westerhof
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 101 on simple and flexible graph query/update?

[François Rey]

Also of interest is datomic datalog on regular clojure data structures 
and records:

https://gist.github.com/stuarthalloway/2645453
https://gist.github.com/stuarthalloway/3068749

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [question] Multimethods vs case

[Elric Erkose]

This sounds interesting. I tried to define a multimethod in one file and a 
method in another file. I had no success.

>  

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An Averaging function

[blake]

I have yet to find a Clojure book I consider suitable for a novice to FP
programming. The problem (it seems to me) is that the people who can write
books on Clojure have long ago made the paradigm shift, and don't
necessarily recall how that shift happened. This is similar to what I've
found in Smalltalk (And the similarities between Smalltalk and Lisp are
almost as profound as their differences.)

The books tend to be as dense as Clojure code itself. Which means, though,
that you can get a lot out of them the more grounding in actual code you
have. Like, I've gotten a lot out of Clojure Programming, but reading it
cover-to-cover (as I originally tried) is not the way to learn the
language.

The I Love Ponies workshop, while incomplete, is an excellent mix of theory
and practice. http://iloveponies.github.io/

What has worked for me is to try to write some code, succeed or not, dig
into some text for a while, go back to writing code, ask things on
#clojure, peek at the Clojure source (though better than that is to find
"naive" examples of how things are done in Clojure, since the reality is a
lot uglier), do some exercises on 4clojure, go back to writing code, bug
#clojure more, try to get further in some of the texts (or try to find
clarifications of things in the texts), go back to write some code, etc.

"Write some code" = I wouldn't worry much about screen I/O for starters,
just print to the REPL. Try to do code of increasing difficulty but to do
it as pure as possible. E.g., stay away from "def", except for defining
functions. Ultimately, ugly real world stuff is ugly and real, and isn't
necessarily helpful starting out.

Like, for myself, I wrote a program to solve "Mastermind" puzzles, create
and solve a maze, and stuff like that at first. This stuff is great because
it can all be done pure. Then I moved into rewriting some production Ruby
code, and noting where I had (lazily) used state, and what I got out of
taking it out when I rewrote in Clojure. I've inherited a big (10K-20K
line) Clojure project that I've been studying and trying to extend without
making a mess out of it, so there's a real-world goal for motivation.

Humility is good: Experienced Clojurers will be able to rewrite your 20
lines of ugly code into 3 lines of elegance that you probably won't even
understand at first.

Tackle it in pieces, just like you would a software project: Get the
functional part down, then branch out into things like macros, async, etc.
Don't try to take it all on at once.

My 2 cents in month 5 of my journey.




On Thu, Jul 10, 2014 at 1:37 AM, Stephen Feyrer 
wrote:

> Hi Sam, Lee.
>
> Thank you both.
>
> It would appear that I am faced with the old adage, "A little knowledge is
> a dangerous thing".
>
> Again thank you, you ' ve been a great help.  If I may impose upon you a
> little further?  Would either of you be able to recommend an introductory
> book either for Clojure or FP that might fit well with Clojure, for the
> mildly bewildered?  I have a book Programming Clojure but it is written
> with an assumption of prior knowledge/experience which I don't have.  By
> the way, Programming Clojure is a good book, I just don't think I fit
> within the target audience.
>
>
> On 10 July 2014 02:41, Lee Spector  wrote:
>
>>
>> On Jul 9, 2014, at 9:31 PM, Lee Spector  wrote:
>> > You could patch (not recommended!) this by adding "do" to the beginning
>> of that list:
>>
>> Or -- I now see, instead of adding the "do" you could just remove the
>> outermost parentheses after the parameter list. But as Sam and I said this
>> is a bad way to go anyway -- you want to avoid the nested defs.
>>
>>  -Lee
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails fro

Re: An Averaging function

[Raoul Duke]

here are some related resources (books, videos). imbibe all of these
and it might help.
http://realmofracket.com/
http://landoflisp.com/
https://news.ycombinator.com/item?id=1023970

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [question] Multimethods vs case

[Daniel Kersten]

It does work.

As far as I can tell, the namespace with defmethod must require the
namespace with defmulti and also the namespace with defmethod must be
required from some other namespace that is being executed.

Eg:

*foo.clj:*
(ns foo)
(defmulti mmtest identity)
(defmethod mmtest :default [_] (println "default"))

*bar.clj:*
(ns bar
  (:require [foo]))
(defmethod mmtest :bar [_] (println "in bar"))

*core.clj:*
(ns core
  (:require [foo :refer [mmtest]] ; The mm we want to call
   [bar])) ; include the :bar impl

(println "Testing")
(mmtest :bar) ; Prints "in bar"


If you don't require bar from core, it will print default instead.

Note, in this example I require foo and bar from core and use mmtest in
core too - you don't need to require bar from the same namespace that you
use in from like I did here. You just need to make sure that the (defmethod
...) call gets executed before you call mmtest.



On 10 July 2014 19:09, Elric Erkose  wrote:

> This sounds interesting. I tried to define a multimethod in one file and a
> method in another file. I had no success.
>
>>   --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [question] Multimethods vs case

[Elric Erkose]

This cleared it up, thanks.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [question] Multimethods vs case

[Timothy Baldridge]

Case only works with ints keywords and some other literals (including
lists, but don't do that, since it doesn't do what you think it does).
While multi-methods work on pretty much anything:

(defmulti first-of-both (fn [a b]
 [(first a) (first b)]))

(defmethod first-of-both [1 1]
   [a b]
   (println "one"))

(defmethod first-of-both [1 2]
   [a b]
   (println "two"))

(first-of-both [1] [2]) => "two"
(first-of-both [1] [1]) => "one"

Timothy


On Thu, Jul 10, 2014 at 12:44 PM, Daniel Kersten  wrote:

> It does work.
>
> As far as I can tell, the namespace with defmethod must require the
> namespace with defmulti and also the namespace with defmethod must be
> required from some other namespace that is being executed.
>
> Eg:
>
> *foo.clj:*
> (ns foo)
> (defmulti mmtest identity)
> (defmethod mmtest :default [_] (println "default"))
>
> *bar.clj:*
> (ns bar
>   (:require [foo]))
> (defmethod mmtest :bar [_] (println "in bar"))
>
> *core.clj:*
> (ns core
>   (:require [foo :refer [mmtest]] ; The mm we want to call
>[bar])) ; include the :bar impl
>
> (println "Testing")
> (mmtest :bar) ; Prints "in bar"
>
>
> If you don't require bar from core, it will print default instead.
>
> Note, in this example I require foo and bar from core and use mmtest in
> core too - you don't need to require bar from the same namespace that you
> use in from like I did here. You just need to make sure that the (defmethod
> ...) call gets executed before you call mmtest.
>
>
>
> On 10 July 2014 19:09, Elric Erkose  wrote:
>
>> This sounds interesting. I tried to define a multimethod in one file and
>> a method in another file. I had no success.
>>
>>>   --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Counterclockwise 0.26.0

[Laurent PETIT]

Hello,

Counterclockwise 0.26.0 has just been released.

This version fixes lots of longstanding, unnerving usability issues.

Please see the Changelog for detailed explanations:

Release Note
===

http://doc.ccw-ide.org/ChangeLog.html#_changes_between_counterclockwise_0_25_2_and_0_26_0

Install
===

Installation instructions:

http://doc.ccw-ide.org/documentation.html#_install_counterclockwise

Cheers,

-- 
Laurent Petit

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Determine file of auxiliary test method with clojure.test?

[Colin Fleming]

Hi all,

Cursive provides test functionality that paints pass/fail markers in the
editors when tests are running. This all works great, except when someone
defines a test that calls a function containing is forms in another
namespace. An example:

(ns foo.core-test
  (:require [clojure.test :refer :all]
[foo.test-helper :as helper]))
(deftest a-test
  (helper/test-something))

and

(ns foo.test-helper
  (:require [clojure.test :refer [is]]))
(defn test-something []
  (is (= 42 42)))

I'm overriding clojure.test/report, but I can't see any way to determine
when I receive the :pass message that the test is actually in another file.
The :begin-test-var event contains the a-test var, but that's in the wrong
file. The :pass event contains the :expected form, but the meta for that
only contains :line and :column, not :file.

Am I missing something obvious?

Thanks,
Colin

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An Averaging function

[Marcus Blankenship]

Ok, I'm sure this is heresy, but I'm getting a great deal from Paul Graham's 
"On Lisp", even though the examples are in Common Lisp. Really amazing stuff!!!

Sent from my iPhone

> On Jul 10, 2014, at 11:26 AM, Raoul Duke  wrote:
> 
> here are some related resources (books, videos). imbibe all of these
> and it might help.
> http://realmofracket.com/
> http://landoflisp.com/
> https://news.ycombinator.com/item?id=1023970
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Determine file of auxiliary test method with clojure.test?

[Jeff Valk]

You could override the clojure.test/do-report implementation and use the 
same stack frame trick that the default :fail case uses. Then from there, 
either use the file name from the StackTraceElement, or demunge the method 
name to get the var. I wouldn't really call that "obvious", though. :-)

Cheers,
Jeff

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 101 on simple and flexible graph query/update?

[Frank Castellucci]

Bertrand

I've been doing a lot of Ontology (OWL) with directed graphs (with cycles) 
and DAGS. One application we went with the nested map structure however now 
that I've been working on a normalized BPMN/XPDL utility 
( https://github.com/FrankC01/tributary ) I'm becoming enamored with the in 
XML format produced by xml-parse and then zipping it up. Coupled with 
clojures 'functional' nature, zippers become your friend really quickly and 
provide a most generic way of dealing with any graph with any number of 
layers.

The next step will be a normalized DSL on top of the zippers and using 
things like hickory-parse/data.zip selector concepts.

For the Ontology work we use datomic as the persist mechanism.



On Thursday, July 10, 2014 4:26:33 AM UTC-4, Bertrand Dechoux wrote:
>
> Hi,
>
> I have various general questions about how one can perform simple and 
> flexible graph query/update.
>
> If we start by a structure being nested maps then I know about 
> get-in/update-in/assoc-in. The common point about these functions is that 
> they all take a path to where the data is in the superstructure and that 
> this path is only a sequence of keys, which may or not be symbols.
>
> 1) What happens when one layer of this superstructure is not a map but a 
> sequence? For the sake of the argument, we can keep the discussion simple 
> by only arguing about the vector case.
>
> Typically instead of
> { :key1 { :key2 val }}
>
> we now have
> { :key1 [{ :key2 val }]}
>
> Of course, one can perform get/update/assoc using map/reduce. However, it 
> means that the code using this superstructure is taking a hit on 
> complexity/maintenance each time a non-map layer must be crossed. Of 
> course, the simplicity/beauty of the current implementation is that a path 
> can point to at most one target substructure/value. Is there a way to do 
> something similar with a more general definition of a path? One would 
> assume that it is something that might be handled by xml/html modification 
> libraries (think xpath or css selector) but this problem is more general 
> and not domain specific. Is there a clean library that handle that case 
> without being tied to html/xml?
>
> 2) How to deal with more general superstructure like a graph?
>
> One could build an immutable graph but I don't believe it is something 
> that can be done by nesting immutable maps and vectors. One solution to 
> deal with 'entity'--'entity' relationships is for one of the member to own 
> only an identifier to get the other member from another reference structure.
>
> (from the basic OM tutorial:)
>
> {:people
>  [{:type :student :first "Ben" :last "Bitdiddle"}
>   {:type :professor :first "Gerald" :last "Sussman" :classes [:6001 
> :6946]}]
>  :classes
>  {:6001 "The Structure and Interpretation of Computer Programs"
>   :6946 "The Structure and Interpretation of Classical Mechanics"
>   :1806 "Linear Algebra"}}
>
>
> It is, of course, again, manually possible to get/update/assoc using 
> map/reduce.  But then, again, this is the same problematic as with the 
> first question : each time a relation needs to be crossed, the code using 
> this superstructure is taking a hit on complexity/maintenance. How do you 
> usually deal with this problematic?
>
> For both question 1) and 2), a more appropriate data structure might be 
> the answer like a graph/semantic-like store (Datomic or something else). 
> The questions are about intermediary solutions which would be less heavier.
>
> 3) How does Demeter lives with graph traversal?
>
> This law is often heard in the OOP world but it is a bit more general than 
> that. When a long path on a superstructure is specified then if one 
> intermediary layer is introduced later, all hardcoded paths will be broken 
> ie in multiple locations in the code base. One would like to store local 
> structure knowledge in a single place. How do you usually deal with this 
> problematic?
>
> I have yet to take a serious look at lenses and their composition, they 
> are probably an element of answer, but they are more often seen in more 
> statically typed langage.
>
> Thanks for any feedback.
>
> Bertrand
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: practice for learning clojure

[Gregg Williams]

A web search turned up the following:

http://stackoverflow.com/questions/3628958/good-clojure-code-examples

https://groups.google.com/forum/#!topic/clojure/U6fLpc_NO98

I have heard from more than one source that the clojure.core source code is 
good to read. Maybe I'll get around to it myself someday. Good luck, and 
keep at it!

--Gregg

On Tuesday, May 27, 2014 6:54:02 PM UTC-7, Randy Chiu wrote:
>
> Hi Gregg,
> Your suggestion is very good and explicit,thanks for your response.
> I'd like to ask you another question since you mentioned :
> >>> spend *a lot* of time studying other people's solutions, looking at 
> both the factors of elegance and readability in solutions. 
> do you have any good projects/solutions recommended?
>
> 在 2014年5月28日星期三UTC+8上午3时15分37秒，Gregg Williams写道：
>>
>> Hi, Randy,
>>
>> I'm several years into learning Clojure. Here's what has worked for me:
>>
>> * Use either Light Table or (if you're determined) Emacs as your IDE.
>> * I learned a lot from taking this free online course: 
>> http://iloveponies.github.io/120-hour-epic-sax-marathon/index.html
>> * I have *all* the published Clojure books. To start, I recommend 
>> Programming Clojure, 2nd Ed. (Halloway), or Clojure Programming (Emerick 
>> et. al.).
>> * Start on the exercises at 4clojure.com (sorted from easiest to 
>> hardest) ***AND*** (this is where you will learn the most) once you've 
>> completed an exercise, spend *a lot* of time studying other people's 
>> solutions, looking at both the factors of elegance and readability in 
>> solutions. If you can't figure one out, keep at it until you do.
>> * Ask for help on stackoverflow.com. You get better results there 
>> because people have an incentive to write clearly.
>> * In your own code, prefer readability over brevity (this bucks the 
>> common wisdom of the community). Use multiline functions that show 
>> structure through (auto)indentation. Symbol names are tricky--too short and 
>> they're cryptic, too long and they hide the code; find what works for you.
>> * Watch videos from the various Clojure conferences and groups, 
>> especially those from Rich Hickey and the most visible contributors of the 
>> Clojure community. Their talks have given me a lot more about the 
>> philosophy of Clojure and how to think about coding in Clojure than most of 
>> the printed books.
>> * Finally, here are my Clojure bookmarks, which go back almost five years 
>> https://www.pinboard.in/search/u:GreggInCA?query=clojure. Older links 
>> are, in some cases, outdated. Use your best judgement.
>> * Persevere. Clojure is not an easy language/environment, but it is 
>> uniquely oriented to future hardware and it is very powerful.
>>
>>
>>
>> On Tuesday, May 27, 2014 4:58:44 AM UTC-7, Randy Chiu wrote:
>>>
>>> Hi all,
>>> I'm new to clojure and want to find some suggestion for learning 
>>> clojure. I googled some project about "how to learn clojure" but without 
>>> any perfect answers until now.
>>> I worked on linux kernel in last several years mainly with C, and I'm 
>>> recently interested in lisp. I try to read some books about common lisp and 
>>> scheme  and even clojure, so I think I know a little about lisp but lacking 
>>> for practice. 
>>> So, I'd like to know any project I could read(or even try to join in), 
>>> or any other suggestion for learning this new lisp dialect please let me 
>>> know.
>>> Thanks for your advance.
>>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An Averaging function

[Joseph Smith]

When you're done with "On Lisp" check out "Let Over Lambda". :)

---
@solussd


> On Jul 10, 2014, at 5:38 PM, Marcus Blankenship  wrote:
> 
> Ok, I'm sure this is heresy, but I'm getting a great deal from Paul Graham's 
> "On Lisp", even though the examples are in Common Lisp. Really amazing 
> stuff!!!
> 
> Sent from my iPhone
> 
>> On Jul 10, 2014, at 11:26 AM, Raoul Duke  wrote:
>> 
>> here are some related resources (books, videos). imbibe all of these
>> and it might help.
>> http://realmofracket.com/
>> http://landoflisp.com/
>> https://news.ycombinator.com/item?id=1023970
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An Averaging function

[Marcus Blankenship]

Have it, and it's next on my list. ;-)  Thanks!

On Jul 10, 2014, at 9:33 PM, Joseph Smith  wrote:

> When you're done with "On Lisp" check out "Let Over Lambda". :)
> 
> ---
> @solussd
> 
> 
>> On Jul 10, 2014, at 5:38 PM, Marcus Blankenship  
>> wrote:
>> 
>> Ok, I'm sure this is heresy, but I'm getting a great deal from Paul Graham's 
>> "On Lisp", even though the examples are in Common Lisp. Really amazing 
>> stuff!!!
>> 
>> Sent from my iPhone
>> 
>>> On Jul 10, 2014, at 11:26 AM, Raoul Duke  wrote:
>>> 
>>> here are some related resources (books, videos). imbibe all of these
>>> and it might help.
>>> http://realmofracket.com/
>>> http://landoflisp.com/
>>> https://news.ycombinator.com/item?id=1023970
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Best,
Marcus

Marcus Blankenship
\\\ Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Developer with clojure wanted in Auckland.

[Indiana Logan]

Hi all .. I hope it is OK to post in here. I am looking for a number of 
Java developers with clojure experience for an exciting start up in 
Auckland. If you are interested to hear more then please email or call me - 
cheers, Indiana 
ilo...@globalattract.co.nz
09 903 0865

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.