deep thinking

[Tim Daly]

I read Simon Parent's thesis, "How Programmers Comment When They Think
Nobody's Watching". Simon is analyzing comments in source files.

Simon quotes two other sources about comments to try to find a
classification scheme. I've quoted the summaries Simon quoted from the
sources [1] and [2]. I've included a summary of Simon's criteria [3]
as well as the "extreme" criteria I outline in a previous post
[4]. I've included Val's original post [0] which laid out the
original criteria.

Perhaps these can be taken as starting points of rational dialog.

Val[0]

 I've been thinking for a while that the Clojure community could
 benefit a lot from a more sophisticated and ergonomic documentation
 system.

 I have seen some existing plugins like lein-sphinx, but I think it
 would be really good to have documentation that would be written in
 Clojure, for the following reasons :

we're all very fond of Clojure data structures and their
syntax. (I don't know about you, but I find that even HTML looks
better in Clojure than in HTML). Plus, Clojure programmers already
know how to edit them.

(better reason) The facts that Vars are first-class citizens and
that symbols can be referred explicitly with hardly any ceremony
(macros) are a exceptional opportunity to make smart and
highly-structured documentation very easily.

if it's in Clojure, Clojure programmers can seamlessly build ad
hoc documentation functionality on top of it to suit their own
particular needs.

 I haven't found anything of the like yet, and if it exists, I would be
 grateful if someone would redirect me to it.

 Here are my thoughts on this :

Clojure doc-strings, although they are quite handy as reminders
and for doc-indexation, are too raw a content. Even when they are
done right, they tend to be cumbersome, and it's too bad to have
such concise code drown in the middle of so much
documentation. What's more, I believe that when programmers
program a function (or anything), they tend to think more about
the implementation than the (uninformed) usage, so they have
little incentive to make it right.

Building on 1. having a system where documentation and programs
live in separate files, in the same way as tests, would enforce a
healthy separation of concerns. Importantly, it would make life
much easier on the Version Control perspective.

Documentation should probably be made differently than what people
have got accustomed to by classical languages. Because you seldom
find types, and because IMHO Clojure programs are formed more by
factoring out recurring mechanisms in code than from implementing
intellectual abstractions, the relevant concepts tend not to be
obvious in the code. Since in Clojure we program with verbs, not
nouns, I think documentation is best made by example.

Documentation of a Var should not be a formal description of what
it is and what it does with some cryptically-named
variables. Every bit of documentation should be a
micro-tutorial. Emphasis should be put on usage, examples, tips,
pitfalls, howtos.

 There should be structure in the documentation, and it shouldn't
 be just :see-also links - there should be semantics in it.  For
 example, some functions/macros are really meant to be nothing but
 shorthands for calling other functions : that kind of relationship
 should be explicitly documented.

Documentation should not be just information about each separate
Var in a namespace. There should be a hierarchy to make the most
useful elements of an API more obvious. Also, adding cross-vars
documentation elements such as tags and topics could make it
easier to navigate and understand.

Documentation in the REPL is great, it was one of the very good
surprises when I started learning Clojure. However, a rich and
good-looking presentation like in Javadocs would be welcome too.

 Of course, all of the above are just vague principles. Here is some
 functionality I suggest for a start :

Documentation content elements could be written in a Clojure DSL
emulating some kind of docbook-like markup language.

On the user side, the documentation would be accessible through a
generated web interface, a REPL interface, and maybe other formats
like Wiki.

Documentation could be programmed anywhere in a project by simply
referring to the relevant Vars and calling the documentation
API. Ideally, there would be a dedicated folder for documentation
files, and a Leiningen plugin to compile them and generate the
HTML from them.

I often find myself lost because I have no idea what shape some
arguments to a function should have, such as config maps and maps
representing application-specific models. To adress this, I
propose to explicitly declare and describe "stereotypes" in the
documentation. Such stereotypes could be, for insta

Achieving structural sharing when composing data

[Mike Fikes]

Are there common techniques or idioms for achieving structural sharing when 
composing data where equivalences exist?

(My motivation is to reduce heap usage for a particular problem I'm working 
on that involves a lot of repeated data.)

As a specific example, consider sharing equivalent map values:

(def m1 {:a [1 2]})

(def m2 (assoc m1 :b [1 2]))


(identical? (m2 :a) (m2 :b))

;; => false


For this simple example, I can force sharing by introducing a variant of 
assoc which looks at existing values:


(defn assoc-id [map key val] (assoc map key (get (apply hash-set (vals 
map)) val val)))


And using it results in a map with two identical values:


(def m3 (assoc-id m1 :b [1 2]))


(identical? (m3 :a) (m3 :b))

;; => true


But, of course, this approach could get to be expensive and/or unwieldy if 
not done carefully.


So, I was wondering if there are general techniques in this area. I'm sure 
I'm not the first to come across it. We already get this automatically for 
boxing of small integers:


(identical? 5 5)

;; => true


(identical? 500 500)

;; => false


So I suppose I'm essentially looking for the same idea but for larger 
non-primitive "values".


-- 
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: Basic question: metadata reader

[Angel Java Lopez]

Ah!

Thanks to all.

Yes, I was a bit confused, thinking ^ expands as ' (quote), to use
(with-meta..). But there is not expansion. It really applies the map to the
next read form, expecting the read form implements IObj:

public interface IObj extends IMeta {

public IObj withMeta(IPersistentMap meta);

}

So. ^{  } applied to a symbol, returns a new symbol. From Symbol.java:


public IObj withMeta(IPersistentMap meta){
return new Symbol(meta, ns, name);
}

I have seen the light! ;-)

Time to refactor my code, TDD will save my day

Angel "Java" Lopez
@ajlopez






On Sat, May 3, 2014 at 6:51 PM, Stephen Gilardi  wrote:

> I just read:
>
>
> http://clojure.org/reader
>
>
>- Metadata (^)
>Metadata is a map associated with some kinds of objects: Symbols,
>Lists, Vector, Sets, Maps, tagged literals returning an IMeta, and record,
>type, and constructor calls. The metadata reader macro first reads the
>metadata and attaches it to the next form read (see 
> with-meta
>  to
>attach meta to an object):
>^{:a 1 :b 2} [1 2 3] yields the vector [1 2 3] with a metadata map of
>{:a 1 :b 2}.
>
>
> Ok, but how the reader works?
>
>
> The description above is literally how it works: "The metadata reader
> macro first reads the metadata and attaches it to the next form read”.
>
> Reader macros are implemented within the reader. They are distinct from
> defmacro macros.
>
> The implementation is here:
>
> https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/LispReader.java#L706
>
> The reader reads from an input stream; it:
>
>   - reads the metadata object, meta [L716]
>   - reads the object that follows it, o [L724]
>   - figures out how to apply meta to o based on the interface(s) o
> implements [L725.L731]
>   - applies meta to o [L733,L741]
>
> —Steve
>
>  --
> 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: Basic question: metadata reader

[Stephen Gilardi]

> I just read:
> 
> http://clojure.org/reader
> 
> Metadata (^)
> Metadata is a map associated with some kinds of objects: Symbols, Lists, 
> Vector, Sets, Maps, tagged literals returning an IMeta, and record, type, and 
> constructor calls. The metadata reader macro first reads the metadata and 
> attaches it to the next form read (see with-meta to attach meta to an object):
> ^{:a 1 :b 2} [1 2 3] yields the vector [1 2 3] with a metadata map of {:a 1 
> :b 2}.
> 
> Ok, but how the reader works?


The description above is literally how it works: "The metadata reader macro 
first reads the metadata and attaches it to the next form read".

Reader macros are implemented within the reader. They are distinct from 
defmacro macros.

The implementation is here:
https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/LispReader.java#L706

The reader reads from an input stream; it:

  - reads the metadata object, meta [L716]
  - reads the object that follows it, o [L724]
  - figures out how to apply meta to o based on the interface(s) o implements 
[L725.L731]
  - applies meta to o [L733,L741]

--Steve

-- 
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: Basic question: metadata reader

[Andy Fingerhut]

Note that if you try the same sequence you gave in your examples *without*
metadata, you would get very similar results:

(def one 1)
one
;; evaluates to 1
bar
;; exception with message "Unable to resolve symbol: bar"

The exception is because bar has not been def'd before.

Andy

-- 
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: Basic question: metadata reader

[James Reeves]

The metadata is attached to the symbol, before the form is evaluated. You
can see this with a macro:

  (defmacro foo [x] (meta x))

  (foo ^:bar baz)  ;=> {:bar true}

The with-meta function attaches metadata to the value the symbol evaluates
to.

- James


On 3 May 2014 22:10, Angel Java Lopez  wrote:

> I'm trying to implement in my clojure interpreter (in c#) the metadata
> reader. I read in core.clj something like
>
> (ns ^{:doc "The core Clojure language."
>:author "Rich Hickey"}
>   clojure.core)
>
> I just read:
>
> http://clojure.org/reader
>
>
>- Metadata (^)
>Metadata is a map associated with some kinds of objects: Symbols,
>Lists, Vector, Sets, Maps, tagged literals returning an IMeta, and record,
>type, and constructor calls. The metadata reader macro first reads the
>metadata and attaches it to the next form read (see 
> with-meta
>  to
>attach meta to an object):
>^{:a 1 :b 2} [1 2 3] yields the vector [1 2 3] with a metadata map of
>{:a 1 :b 2}.
>
>
> Ok, but how the reader works?
>
> I tried
>
> (def one 1)
>
> ^:foo one
>
> and it works
>
> But i tried
>
> ^:foo bar
>
> and it yields an error (Unable to resolve the symbol bar...)
>
> But then
>
> (ns ^:foo bar)
>
> IT WORKS!
>
> Where the attached form to metadata is evaluated?
>
> I thought that
>
> ^:foo bar
>
> was expanded as
>
> (with-meta bar {:foo true})
>
> in the same way like
>
> 'a
>
> is expanded to
>
> (quote a)
>
> and then (with-meta bar {:foo true}) is passed to ns.
>
> I know that ns is a macro. So the attachment of the metadata is not yet
> evaluated. But when it is evaluated? Is it true that ns receives
> (with-meta bar {:foo true})? Or in which way the ^ reader works?
>
> I checked ns source
> https://github.com/clojure/clojure/blob/028af0e0b271aa558ea44780e5d951f4932c7842/src/clj/clojure/core.clj#L5304but
>  apparently it is some magic detecting the metadata
>
> Any clue?
>
> Angel "Java" Lopez
> @ajlopez
>
>
>  --
> 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.

Basic question: metadata reader

[Angel Java Lopez]

I'm trying to implement in my clojure interpreter (in c#) the metadata
reader. I read in core.clj something like

(ns ^{:doc "The core Clojure language."
   :author "Rich Hickey"}
  clojure.core)

I just read:

http://clojure.org/reader


   - Metadata (^)
   Metadata is a map associated with some kinds of objects: Symbols, Lists,
   Vector, Sets, Maps, tagged literals returning an IMeta, and record, type,
   and constructor calls. The metadata reader macro first reads the metadata
   and attaches it to the next form read (see
with-meta
to
   attach meta to an object):
   ^{:a 1 :b 2} [1 2 3] yields the vector [1 2 3] with a metadata map of
   {:a 1 :b 2}.


Ok, but how the reader works?

I tried

(def one 1)

^:foo one

and it works

But i tried

^:foo bar

and it yields an error (Unable to resolve the symbol bar...)

But then

(ns ^:foo bar)

IT WORKS!

Where the attached form to metadata is evaluated?

I thought that

^:foo bar

was expanded as

(with-meta bar {:foo true})

in the same way like

'a

is expanded to

(quote a)

and then (with-meta bar {:foo true}) is passed to ns.

I know that ns is a macro. So the attachment of the metadata is not yet
evaluated. But when it is evaluated? Is it true that ns receives (with-meta
bar {:foo true})? Or in which way the ^ reader works?

I checked ns source
https://github.com/clojure/clojure/blob/028af0e0b271aa558ea44780e5d951f4932c7842/src/clj/clojure/core.clj#L5304but
apparently it is some magic detecting the metadata

Any clue?

Angel "Java" Lopez
@ajlopez

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Val Waeselynck]

All right, I'll give it a try, here are some thoughts :

I think it's too hard make precise requirements for advanced features in 
advance; I'd rather find a way to let usage drive us in the right 
direction. However, there are a few principles that we know will be wise to 
follow :

   - encouraging separation of concerns
   - avoiding duplication of logic

And indeed as a programming language, Clojure follow these very well in 
many respects. 

  Applying these to the topic of documentation, I think it's a good idea to 
make the documentation system/process separate the concerns of writing 
quality code and making understandable. That seems to make a case towards 
documenting with tests/examples/schemas and against literate programming 
(was that your point, Gregg?) - and maybe also against using types for 
documenting, but that's really my own personal feeling and I don't have any 
evidence for it.

  Avoiding duplication of logic seems to encourage the overlapping of tests 
and documentation examples in code, so something close to what 
lein-midje-doc currently offers.

  Is that OK for everyone?
Le vendredi 2 mai 2014 16:16:24 UTC+2, Gregg Reynolds a écrit :
>
> On Fri, May 2, 2014 at 4:00 AM, Val Waeselynck 
> 
> > wrote:
>
>>
>> That is NOT what I said. Please go back and read my response more 
>>> carefully. 
>>>
>>
>> Apologies, guess I disagree only with Gregg on that point then.
>>
>
> I guess this illustrates a point that is usually overlooked: no matter how 
> good your documentation is, somebody will always misread it.  Which gets 
> back to the point I was trying to make: the ultimate source of 
> authoritative information about what the code does is the code itself.  It 
> does not follow that the names used in the code are reliable guides to what 
> the code means.  Consider the following (mangled from 
> http://en.wikibooks.org/wiki/Clojure_Programming/Examples/Lazy_Fibonacci):
>
> (def factorial 
>   ((fn rfact [a b] 
>  (lazy-seq (cons a (rfact b (+ a b)
>0 1))
>
>
> Obviously not a factorial function; to know what it is, you have to read 
> the code, which expresses an algorithm (in this case fibonacci).  Something 
> this extreme probably doesn't happen very often, but something very like it 
> happens all the time.  Yesterday I was working through some Java code 
> called "fooReader".  The docstring said it inherited from XMLReader.  It 
> did not, rather it inherited from XMLFilter.  Which in turn inherits from 
> AbstractWriter.  So what is it, a Reader, Filter, or Writer?  The only way 
> to find out is to read the code - that is, the algorithm, not just the 
> names.   (This code was documented, by the way.)  In my experience clashes 
> between the natural language semantics of function and var names on the one 
> had, and the jobs they actually do on the other, is pervasive, and I see 
> little chance that this will ever change.  Not because programmers are dumb 
> but because coming up with expressive and accurate names is hard and time 
> consuming.
>
> Which leads to a larger point: a genuine improvement in the Clojure 
> documentation situation requires (IMHO) some Deep Thinking about the nature 
> of code, the relation between code (text) and algorithm, natural language 
> text, expressivity, programmer practices, etc.  In other words, we should 
> follow Rich Hickey's example - I take it that Clojure itself emerged from 
> some Deep Thinking about the nature of computation, programming language 
> design, etc.
>
> -Gregg
>
>
>
>

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

Code Genres

[Gregg Reynolds]

The recent threads on documentation lit a small fire under my butt so I
started a Code Genres  repo.  For
the moment it is there mainly for the wiki, which I offer as a place for
any interested parties to contribute ideas, requirements, etc.  I've posted
a little bit of stuff there to get started, really more suggestions rather
than fully worked out ideas, but they are (so I imagine) mildly
innovative.  One is that we should think of both code and documentation in
terms of literary genres (the inspiration comes from Bakhtin on speech
genres), and the other is that we should treat unit tests as documentation
(in the sense that they record a trace of actual code behavior).  I've got
more stuff, but I don't know when I'll find time to write it up.  In the
meantime if you have ideas you want to record in a stable and relatively
visible place (rather than buried in a mailing list) the wiki is open for
business.

The main motivation (I think) is that by engaging in fundamentally
rethinking code and documentation we may come up with new and better ways
of attacking "the documentation problem".

-Gregg

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

How aliased "require" is different?

[Petr]

Hello.

I experienced non obvious behavior of "require namespace as alias" when 
using clojure.tools.namespace.repl/refresh.
If I use aliased namespace then after changing source files and call to 
refresh I seem to have old values in that alias. If I use plain require all 
seem to work as expected, new definitions take effect after reload.

For example, in first case:
(ns a (require [b :as b-alias]))
(println b-alias/x) ; original value
; change sources of b or it's dependencies
(clojure.tools.namespace.repl/refresh)
(println b-alias/x) ; original value
; and also
(println b/x) ; new value

In second case:
(ns a (require [b]))
(println b/x) ; original value
; change sources of b or it's dependencies
(clojure.tools.namespace.repl/refresh)
(println b/x) ; new value

Can anyone explain why require acts like this? Does it mean that alias is 
not just naming change but some data structure in memory?

-- 
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: Clojure equivalent of special common lisp vars: still looking for that zen place...

[Dave Tenny]

re: binding behavior, I've only been using clojure since 1.5.1, but in my
travels I get the impression that the binding form didn't always enforce
the variable to be declared dynamic, and so maybe didn't behave the way
you'd expect if the ^:dynamic was missing from the target of the binding
form.  Just guessing.


On Sat, May 3, 2014 at 11:08 AM, Lee Spector  wrote:

>
> On May 3, 2014, at 9:45 AM, Dave Tenny  wrote:
> >
> > The way I'm tempted to do this in clojure is
> >
> > (def ^{:dynamic true} *x* (atom 1))
> > ... do stuff with @*x* ...
> > (reset! *x* 2)
> > ... do stuff with @*x* ...
> > (binding [*x* (atom 3)] (do stuff with @*x*))
>
>
> Having also come from Common Lisp and having once done things similar to
> your suggestion in Clojure, I got burned by the fact (I *think* it was a
> fact) that "binding" created thread-local bindings that reverted to global
> bindings inside of code executed in another thread, e.g. in a pmap buried
> somewhere within the code executed within the binding form. I found this to
> be unexpected and problematic.
>
> Trying some simple examples with your outline, however, I don't see this
> happening. And I wonder if it's because of changes in more recent versions
> of Clojure related to ^{:dynamic true}.
>
> Does anyone know if the reversion of "binding"-bound vars to global
> bindings when crossing thread boundaries has really been eliminated? Or am
> I just not seeing it because my examples have been too simple?
>
>   -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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/Wh1M345Y5u4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Clojure equivalent of special common lisp vars: still looking for that zen place...

[Dave Tenny]

On Sat, May 3, 2014 at 10:53 AM, Bob Hutchison wrote:

> You can also just use ‘def’ to redefine the global binding.



Thanks, though in this case it's a mixed use.  In some cases I want to
change the root of the global binding, in others I want to rebind to a new
value in some context without changing the value seen in other contexts.

-- 
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: Clojure equivalent of special common lisp vars: still looking for that zen place...

[Lee Spector]

On May 3, 2014, at 9:45 AM, Dave Tenny  wrote:
> 
> The way I'm tempted to do this in clojure is
> 
> (def ^{:dynamic true} *x* (atom 1))
> ... do stuff with @*x* ...
> (reset! *x* 2)
> ... do stuff with @*x* ...
> (binding [*x* (atom 3)] (do stuff with @*x*))


Having also come from Common Lisp and having once done things similar to your 
suggestion in Clojure, I got burned by the fact (I *think* it was a fact) that 
"binding" created thread-local bindings that reverted to global bindings inside 
of code executed in another thread, e.g. in a pmap buried somewhere within the 
code executed within the binding form. I found this to be unexpected and 
problematic.

Trying some simple examples with your outline, however, I don't see this 
happening. And I wonder if it's because of changes in more recent versions of 
Clojure related to ^{:dynamic true}.

Does anyone know if the reversion of "binding"-bound vars to global bindings 
when crossing thread boundaries has really been eliminated? Or am I just not 
seeing it because my examples have been too simple?

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

Re: Clojure equivalent of special common lisp vars: still looking for that zen place...

[Bob Hutchison]

On May 3, 2014, at 9:45 AM, Dave Tenny  wrote:

> I'm still struggling with how to write the most readable, simple clojure code
> to deal with dynamically bindings.
> 
> What is the graceful clojure equivalent of common lisp special variables for 
> the following scenario.
> 
> If I were writing common lisp I'd just do something like (pardon if my lisp 
> is rusty here):
> 
> (defvar *x* 1)
> ... do stuff with *x* ...
> (setq *x* 2)
> ... do stuff with *x* ...
> (let ((*x* 3))  (do stuff with *x*...)
> ;; do stuff with *x* that's currently at 2
> 
> 
> The way I'm tempted to do this in clojure is
> 
> (def ^{:dynamic true} *x* (atom 1))
> ... do stuff with @*x* ...
> (reset! *x* 2)
> ... do stuff with @*x* ...
> (binding [*x* (atom 3)] (do stuff with @*x*))

Inside the binding you can call set! if you must.

You can also just use 'def' to redefine the global binding. It says this:

"Using def to modify the root value of a var at other than the top level is 
usually an indication that you are using the var as a mutable global, and is 
considered bad style. Consider either using binding to provide a thread-local 
value for the var, or putting a ref or agent in the var and using transactions 
or actions for mutation." in the docs at http://clojure.org/special_forms#def 
which is roughly what you did with the atom. But it'll work.

You can also just write it:

(def ^:dynamic *x* (atom 1))

which is a little less verbose.

Cheers,
Bob

> 
> 
> Is that the simplest way to map between the two language scenarios?
> Or is there something simpler, perhaps using some var-* apis or what have you?
> 
> 
> 
> -- 
> 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: [ANN] packthread 0.1.0

[Jozef Wagner]

Thanks for releasing this library. How does it compare to the synthread 
library [1] [2] ? Seems like both libraries have the same goal.

Jozef

[1] https://github.com/LonoCloud/synthread
[2] http://www.infoq.com/presentations/Macros-Monads

-- 
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: [ANN] packthread 0.1.0

[James Reeves]

Some software companies, particularly larger ones, are careful about the
licenses of software they use in their products. With a standard open
source license it's often easy to get approval, because licenses like MIT
are very common.

Software with a custom license is trickier, because it's not a case of
rubber-stamping a license known to be safe. Someone with legal training
would have to look over the license and certify it as being safe to use.

This also applies to dependencies. If a library happens to use packthread,
then suddenly that library becomes legally suspect as well. Is MIT
compatible with your license? Is EPL?

The benefit to using an existing open source license is that their legal
position is clear. Even though your license is simple, IANAL, so I wouldn't
be able to say for sure there's no hidden subtlety there that might impact
my project if I use it. It may be that there will never be an issue, but
why should I risk it?

- James


On 3 May 2014 13:46, Jason Felice  wrote:

> Hi!
>
> I'm pretty familiar with legal license stuff (though IANAL).  I wouldn't
> mind considering changing it at the point where someone wants to use it but
> can't - because that would carry with it a specific reason we can think
> about.
>
> -Jason
>
>
> On Fri, May 2, 2014 at 3:03 PM, James Reeves wrote:
>
>> The non-standard license might make using this library difficult to use
>> for some companies. You may want to consider using an existing open source
>> license that's broadly similar, such as MIT.
>>
>> - James
>>
>>
>> On 2 May 2014 09:00, Fabien Todescato  wrote:
>>
>>> Thanks for that great work ! Reminds me of similar techniques in the
>>> context of logic programming : http://www.info.ucl.ac.be/~pvr/edcg.html:)

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

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

Clojure equivalent of special common lisp vars: still looking for that zen place...

[Dave Tenny]

I'm still struggling with how to write the most readable, simple clojure 
code
to deal with dynamically bindings.

What is the graceful clojure equivalent of common lisp special variables 
for the following scenario.

If I were writing common lisp I'd just do something like (pardon if my lisp 
is rusty here):

(defvar *x* 1)
... do stuff with *x* ...
(setq *x* 2)
... do stuff with *x* ...
(let ((*x* 3))  (do stuff with *x*...)
;; do stuff with *x* that's currently at 2


The way I'm tempted to do this in clojure is

(def ^{:dynamic true} *x* (atom 1))
... do stuff with @*x* ...
(reset! *x* 2)
... do stuff with @*x* ...
(binding [*x* (atom 3)] (do stuff with @*x*))


Is that the simplest way to map between the two language scenarios?
Or is there something simpler, perhaps using some var-* apis or what have 
you?


-- 
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: difference in behavior for :let modifiers in "for" vs. "doseq"

[Xfeep Zhang]

user> (for [ b '(1 2 3) :let [a 1] ] (println a b))

is OK.

On Thursday, May 1, 2014 12:39:22 PM UTC+8, Yuri Niyazov wrote:
>
> Hello everyone, 
>
>   In Clojure 1.6:
>
> user> (doseq [:let [a 1] b '(1 2 3)] (println a b))
> 1 1
> 1 2
> 1 3
> nil
> user> (for [:let [a 1] b '(1 2 3)] (println a b))
> IllegalStateException Can't pop empty vector 
>  clojure.lang.PersistentVector.pop (PersistentVector.java:381)
> user> 
>
> Is this expected behavior? a bug? Something I missed in the documentation?
>

-- 
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: Converting sequence from sort into a list

[Dave Tenny]

After nosing around all I've come up with via clojure mechanisms is to use
(apply list (sort ...)).
It seems to work well enough for lists of arbitrary size (subject to usual
memory/size limitations of large lists).

I also considered some native java abuse such as
java.util.Arrays.asList(Enumeration),
though I didn't quickly find a way to convert the clojure.lang.ArraySeq
from my sort() in testing to an Enumeration.

Guess I'm set for now, I was just hoping to avoid consing a new list on my
sort result in order to get a specific collection type.


On Fri, May 2, 2014 at 10:53 AM, Dave Tenny  wrote:

> I have a sequence from a call to 'sort'.
> I want a list.
>
> What is the best way to do this?
>
> (apply list (sort ...))?
>
> Will it have problems on large sequence inputs?
>
>
> I can't use (into () (sort ...))
> since that conjoins and ruins the sort order.
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/sN37zftHSQ4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Managing State Changes, using Component

[Timothy Washington]

Hey, thanks for responding. My responses are inlined.


On Thu, May 1, 2014 at 1:34 AM, Atamert Ölçgen  wrote:

> I am not an expert on Component. But AFAIK it is not for managing mutable
> state but for assembling and configuring components, that might or might
> not be mutable themselves, in an immutable fashion.
>

Agreed, this is what I've found. Component isn't for the use case of state
changes between components.

I'm actually looking at Datascript
as a way of managing internal,
runtime, changing RIA state.



> However from what I can understand, your component-a has an atom, like:
>
>  (->component-a (atom something))
>
> Which should be OK. I mean it shouldn't matter from which path you are
> accessing this atom.
>
> Can you share the constructor/definition of the components?
>

I can't really share actual client code. But the system definition in
fig.1. pretty much describes how the real components are stitched together.


Also, have you tried confirming that only one :a is instantiated?
>

That one *:a* is not the same instance throughout all the dependant
components. Seems that it's the [*:core :a*] bit that's passed to all the
components in the *'start* *'stop* functions. I say this, because when one
of my dependant components updated an atom in it's own [*:local :a*], it
was [*:core :a*] that reflected that change.


On Wed, Apr 30, 2014 at 9:13 PM, Timothy Washington wrote:
>
>> Hi all,
>>
>> I'm having a weird state problem with 
>> Component.
>> Let's say I have a system component, like in fig.1. Starting / stopping and
>> loading state is fine.
>> However, let's say I have 2 other components (:updater , :reader) that
>> use component :a. This is the problem that occurs.
>>
>>1. When *:updater*, modifies an atom in *:a*, that change appears in
>>path [*:core :a*], not path [*:updater :a*] or [*:a*].
>>2. Because of the abouve, when *:reader* goes to it's local path [
>>*:reader :a*] to read that change, it doesn't see those
>>modifications.
>>3. Using this scheme, *:a* is duplicated 4 times, in the system map.
>>However, the modifications only appear in path [*:core :a*]. Thus
>>:reader is unable to access it (it's local [*:a*] is unchanged).
>>
>>
>> (def system-components [:a :updater :reader])
>>
>> (defrecord Core [env] component/Lifecycle
>>   (start [this] ...)
>>   (stop [this] ...))
>>
>> (defn component-core [env]
>>
>>   (component/system-map
>>:a (component/using
>>   (ca/component-a env)
>>   {})
>>:updater (component/using
>>  (cs/component-updater env)
>>  {:a :a})
>>:reader(component/using
>>  (cs/component-reader env)
>>  {:a :a})
>>:core (component/using
>> (map->Foobar {:env env})
>> {:a :a
>>
>>   :updater :updater
>>
>>  :reader :reader })))
>>
>> *fig.1 *
>>
>>
>> I was hoping to use Component to manage all internal application state.
>> But maybe it's not designed for this use case (state changes between
>> components). I imagine that immutability is preventing all those duplicates
>> from seeing the modifications. However, in this case I do need an update to
>> :a in one component, to be accessed by another component.
>>
>> Any suggestions on patterns here? I'm also looking at
>> component/update-system.
>> But again, I don't have access to the core *system* var, from within my
>> components.
>>
>>
>> Any insights appreciated
>>
>> Tim Washington
>> Interruptsoftware.com 
>>
>>
> --
> Kind Regards,
> Atamert Ölçgen
>
>
> www.muhuk.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/d/optout.

Re: [ANN] packthread 0.1.0

[Jason Felice]

Hi!

I'm pretty familiar with legal license stuff (though IANAL).  I wouldn't
mind considering changing it at the point where someone wants to use it but
can't - because that would carry with it a specific reason we can think
about.

-Jason


On Fri, May 2, 2014 at 3:03 PM, James Reeves  wrote:

> The non-standard license might make using this library difficult to use
> for some companies. You may want to consider using an existing open source
> license that's broadly similar, such as MIT.
>
> - James
>
>
> On 2 May 2014 09:00, Fabien Todescato  wrote:
>
>> Thanks for that great work ! Reminds me of similar techniques in the
>> context of logic programming : http://www.info.ucl.ac.be/~pvr/edcg.html:)
>>>
>>>  --
>> 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: Do not understand why loop takes 3 arguments who are all the same

[Bob Hutchison]

On May 3, 2014, at 6:42 AM, Roelof Wobben  wrote:

> 
> (fn [default initial-keys]
>   (loop [remaining-keys initial-keys
>  result-map {}]
>  (if (empty? remaining-keys)
>result-map
>(let [key (first remaining-keys)
>  remaining-keys' (rest remaining-keys)
>  result-map' (assoc result-map key default)]
>  (recur remaining-keys' result-map')
> 
> This also passes the unit tests.
> 
> Maybe that's a bit clearer as to what's going on. Maybe the new names help a 
> bit. Notice the ticks on some of the names (the ' characters). This is just a 
> convention some programmers use. The ticks are part of the name, nothing 
> magic, and are used to indicate that the value of the name is derived from 
> the value of the name with one less tick. Some programmers use numbers 
> instead. Other programmers don't care and just use the same name.
> 
> When you've understood the solution you've come up with, you might want to 
> try using reduce to do this. It'll be both shorter and much easier to 
> understand. If you look carefully at your code the only part that isn't 
> boiler-plate is the (assoc result-map key default) -- the boiler-plate 
> corresponds closely to what reduce does.
> 
> 
> Thanks,
> 
> Now It more clearer what loop does.
> I can look at a reduce solution but then I have to look which reduce I have 
> to use.
> I know  reduce + and reduce - which does calculations on the collection.

This reduce: http://clojuredocs.org/clojure_core/clojure.core/reduce is what 
you need.

Cheers,
Bob

> 
> Roelof
>  
> 
> -- 
> 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: Do not understand why loop takes 3 arguments who are all the same

[Roelof Wobben]

>
>
> (fn [default initial-keys]
>   (loop [remaining-keys initial-keys
>  result-map {}]
>  (if (empty? remaining-keys)
>result-map
>(let [key (first remaining-keys)
>  remaining-keys' (rest remaining-keys)
>  result-map' (assoc result-map key default)]
>  (recur remaining-keys' result-map')
>
> This also passes the unit tests.
>
> Maybe that’s a bit clearer as to what’s going on. Maybe the new names help 
> a bit. Notice the ticks on some of the names (the ‘ characters). This is 
> just a convention some programmers use. The ticks are part of the name, 
> nothing magic, and are used to indicate that the value of the name is 
> derived from the value of the name with one less tick. Some programmers use 
> numbers instead. Other programmers don’t care and just use the same name.
>
> When you’ve understood the solution you’ve come up with, you might want to 
> try using reduce to do this. It’ll be both shorter and much easier to 
> understand. If you look carefully at your code the only part that isn’t 
> boiler-plate is the (assoc result-map key default) — the boiler-plate 
> corresponds closely to what reduce does.
>
>
Thanks, 

Now It more clearer what loop does.
I can look at a reduce solution but then I have to look which reduce I have 
to use.
I know  reduce + and reduce - which does calculations on the collection.

Roelof
 

-- 
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: Do not understand the -> macro here

[Michael Wood]

That whole form is not something you would be likely to write. I think the
exercise is just trying to demonstrate that the version with the -> is
equivalent to the version without the arrow and perhaps also that (= a b c)
can be used instead of (and (= a b) (= b c)).

-- 
Michael Wood
On 01 May 2014 5:02 PM, "Roelof Wobben"  wrote:

> oke,
>
> I misunderstood everyone.
> The right answer is last.
>
> (def A (__ (sort (rest (reverse [2 5 4 1 3 6])
> which would be :
>
> (def A (last (sort (rest (reverse [2 5 4 1 3 6])
> which resolves to 5
>
> (def B (-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__)))
> Which would be :
>
> (def B (-> [2 5 4 1 3 6] (reverse) (rest) (sort) (last)))
>
> which resolves also to 5
>
> so the last part :
>
> ( = a b 5) is also true ( = 5 5 5)
>
> Still I find it wierd to make such sort of form.
>
> Roelof
>
>
> Op donderdag 1 mei 2014 16:35:59 UTC+2 schreef Erlis Vidal:
>
>> Look that (def A ...) won't compile as given, so you cannot say A is [1 2
>> 3 4 5], A is something else once you make it compile filling the blank
>> space with the missing function.
>>
>>
>> On Thu, May 1, 2014 at 10:24 AM, Maik Schünemann wrote:
>>
>>> The task is to replace __ with the function that makes this true in this
>>> case makes [1 2 3 4 5] to 5
>>>
>>>
>>> On Thu, May 1, 2014 at 4:23 PM, Maik Schünemann wrote:
>>>



 On Thu, May 1, 2014 at 3:51 PM, Roelof Wobben wrote:

>
>
> Op donderdag 1 mei 2014 15:20:38 UTC+2 schreef Erlis Vidal:
>
>> I think the confusion is because they used multiple values when
>> comparing the equality
>>
>> (= (__ (sort (rest (reverse [2 5 4 1 3 6]
>>(-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))
>>5)
>>
>> This can be seen as :
>> (def A (__ (sort (rest (reverse [2 5 4 1 3 6])
>> (def B (-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__)))
>>
>> Then the 4Clojure exercise can be written as:
>>
>> (= A B 5)
>>
>> Do not feel bad, this took me some time to realize 5 was not part of
>> B.
>>
>
> No problem. But still it does not make any sense.
>
> If I do it right. this schould be the output of the functions
>
> A [ 1 2 3 4 5]
> B [ 1 2 3 4 5]
> (= A B 5) --> [1,2,3,4,5] = [1,2,3,4,5] = 5 and this is not true.
>
This is the output when you don't write the function to replace __.


>
>
>
>>
>>
>>
>> On Thu, May 1, 2014 at 7:52 AM, Roelof Wobben wrote:
>>
>>> Is this a nice explanation about macros :
>>> http://bryangilbert.com/code/2013/07/30/anatomy-of-a-clojure-macro/
>>>
>>> or is there a better one for a beginner.
>>>
>>> Roelof
>>>
>>>
>>> --
>>> 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 unsubscribe from this group and stop receiving emails from it,
>>> send an email to clojure+u...@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 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 unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@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 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 unsubscribe from this group and stop receiving emails

NoClassDefFoundError when AOT compiling namespace using protocol

[Colin Fleming]

Hi all,

I'm having a strange problem when AOT compiling some code I just added. I
have a namespace that, amongst other things, returns qualified names of
things:

(ns plugin.names
  ...)

(defprotocol QualifiedNamed
  (qualified-name ^String [this]))

(extend-protocol QualifiedNamed
  nil
  (qualified-name [this] nil)
  PsiClass
  (qualified-name [this] (.getQualifiedName this))
  ... etc etc ...
  Object
  (qualified-name [this] nil))

Now, when I require this namespace and try to use it, I get a failure
during AOT compilation via Ant of the using namespace:

java.lang.NoClassDefFoundError: plugin/names/QualifiedNamed
at plugin.lookup__init.load(Unknown Source)
at plugin.lookup__init.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
Caused by: java.lang.ClassNotFoundException: plugin.names.QualifiedNamed
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)

However when I compile this same code within Cursive, it works, even from a
clean build. I assumed this was some kind of ordering issue of the compiled
namespaces, but shouldn't transitive compilation take care of that?

Cheers,
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: Do not understand why loop takes 3 arguments who are all the same

[Bob Hutchison]

Hi Roelof,

On May 3, 2014, at 3:09 AM, Roelof Wobben  wrote:

> Hello, 
> 
> Im now at the last exercise of the beginners exercise of 4clojure.

nice!

> 
> I figured out that this solution works.
> 
> (fn [default lijst1]
>   (loop [lijst lijst1 d {}]
>  (if (empty? lijst)
>d
>(recur (rest lijst) (assoc d (first lijst) default)

Yes, it passes the unit tests.

> 
> But as I see it lijst lijst 1 and d are all the same. They all contains the 
> collection which has to fill in the end collection.
> As a example I mean  default = 0 lijst 1 [:a :b: :c] 
> then lijst1 and d also contains [:a :b:c]  so what is then the point of using 
> 3 arguments.

There's only two arguments (to the loop and to the function). I re-wrote your 
code changing the names of variables and adding a few line breaks as:

(fn [default initial-keys]
  (loop [remaining-keys initial-keys
 result-map {}]
 (if (empty? remaining-keys)
   result-map
   (let [key (first remaining-keys)
 remaining-keys' (rest remaining-keys)
 result-map' (assoc result-map key default)]
 (recur remaining-keys' result-map')

This also passes the unit tests.

Maybe that's a bit clearer as to what's going on. Maybe the new names help a 
bit. Notice the ticks on some of the names (the ' characters). This is just a 
convention some programmers use. The ticks are part of the name, nothing magic, 
and are used to indicate that the value of the name is derived from the value 
of the name with one less tick. Some programmers use numbers instead. Other 
programmers don't care and just use the same name.

When you've understood the solution you've come up with, you might want to try 
using reduce to do this. It'll be both shorter and much easier to understand. 
If you look carefully at your code the only part that isn't boiler-plate is the 
(assoc result-map key default) -- the boiler-plate corresponds closely to what 
reduce does.

I hope this doesn't confuse you even more.

Cheers,
Bob
 
> 
> Roelof
> 
> 
> -- 
> 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.

Do not understand why loop takes 3 arguments who are all the same

[Roelof Wobben]

Hello, 

Im now at the last exercise of the beginners exercise of 4clojure.

I figured out that this solution works.

(fn [default lijst1]
  (loop [lijst lijst1 d {}]
 (if (empty? lijst)
   d
   (recur (rest lijst) (assoc d (first lijst) default)

But as I see it lijst lijst 1 and d are all the same. They all contains the 
collection which has to fill in the end collection.
As a example I mean  default = 0 lijst 1 [:a :b: :c] 
then lijst1 and d also contains [:a :b:c]  so what is then the point of 
using 3 arguments.

Roelof

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