Re: Splitting Read into 2 steps?

[Colin Fleming]

Hi Terje,

This is how the parsing works in Cursive. I have a classical lexer/parser
split because IntelliJ forces me to do that. That said, I like it that way,
and I believe it makes things more flexible. I've been able to make a
couple of special-case parsers easily on top of the lexer - I'm about to
start work on another one for Parinfer support.

I can't speak to why the Clojure reader works the way it does, but what you
suggest is definitely possible and works well.

Cheers,
Colin

On 8 February 2016 at 20:12, Terje Dahl  wrote:

>
>
> I have been studying and and implementing my own version of LispReader /
> tool.reader - for the purpose of syntax highlighting and visual token
> manipulation.
> My question is this:
> Why not split this into 2 steps?
>
>1. Reads the input (from PushbackReader et al) and emits a stream of
>tokens, preserving information about location in source, and applying
>typing to tokens, if possible.
>2. Consumes the stream from step one, descending recursively, applying
>reader-macros, resolving symbols in name-spaces, etc.
>
> This would allow for easier configuration of each step, such as:
>
>- turning exceptions on/off (useful for syntax highlighting)
>- custom reader-macros and custom classes of reader-macros
>- static analysis of code by controlling the namespacing/context
>
> Is there any reason not to do this?
> (Other than: This is the way it has always been done. This is the way
> lisp-readers are aways implemented.)
>
> Perhaps such a development is already underway?
>
> Finally, if I wanted to implement such a solution, would it be to do it in
> Java or Clojure?  Why?
>
> --
> 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: defrecord == premature optimization?

[Terje Dahl]

To comment my own question some years and a bit of experience later:
I would say that, just like with type-hinting: hold of as long as possible.
Only when you find yourself adding to a map something like: {:type Person} 
is it time to consider using a Record in stead. And of course also if you 
would like to dispatch on type (defprotocol / defmethod).



On Monday, September 5, 2011 at 3:46:37 PM UTC+2, Terje Dahl wrote:
>
> Ref:  Stuart Halloway's talk: "Simplicity": 
>
> http://blip.tv/clojure/stuart-halloway-simplicity-ain-t-easy-4842694 
>
> Found via reading list: http://clojure.com/reading.html ) 
>
> At one point in his talk he states that defrecord is in fact basically 
> "documented, named [typed] structure". 
> (as opposed to a standard map). 
> This I thought was quite genius. 
>
> But on further reflection I wonder if: 
>
> A: Doesn't this contradict another Clojure rationale: 
> "It is better to have 100 functions operate on one data structure than 
> to have 10 functions operate on 10 data structures." - Alan J. 
> Perlis   http://clojure.org/rationale 
>
> B: Is this not a form of optimization - (which may be premature)? 
>
> C: Is it best to use records only within an aplication, but to export 
> to generic maps when "serializing" data to a string og stream for 
> communication or storage ... 
> Is this the best way to "serialize" a record?: 
>(into {} intance-of-my-record) 
> Would you "desiralize" it with a custom function like this? 
>   (fn [{key1 :key1, key2 :key2}] (MyRecord. key1 key2))  (calling it 
> like this: (my-fn map-to-be-destructure-and-recordfied) 
>
>
>
>

-- 
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: Clojars Christmas outage - One month on

[Laurens Van Houtven]

Happy to help, and thank you for your continued hard work :)

lvh

-- 
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] Leiningen 2.6.0

[Jean Niklas L'orange]

Hi all,

Instead of creating a new thread for the 2.6.1 release of Leiningen,
I'll just piggyback on this one.

Leiningen 2.6.1 is a small release to fix an issue with 2.6.0. Some
popular plugins (`lein midje`, `lein ring` to mention a few) broke
because of a change in eval-in-project. This has now been fixed.

Sorry for any inconvenience caused.

-- Jean Niklas

On Friday, February 5, 2016 at 2:27:37 AM UTC+1, Jean Niklas L'orange wrote:
>
> Greetings!
>
> I am happy to announce Leiningen 2.6.0! This release contains mostly
> usability improvements, along with some bugfixes. 
>
> The biggest notable change will likely be for Homebrew users. When the
> Homebrew formula is updated to 2.6.0, you will likely experience startup
> time improvements.
>
> In addition, `lein release` now supports '-SNAPSHOT' on qualifiers (alpha,
> beta, RC), and signing GPG artifacts from the terminal will give you
> feedback on whether you managed to type in your passphrase correctly or
> not.
>
> Due to syntax changes from Clojure 1.1.0 to 1.2.0, we had to drop
> support for Clojure 1.1.0 and older.
>
> The full list of significant changes:
>
> * The templates, repl and Leiningen itself now use Clojure 1.8.
> * Support for Clojure 1.1.0 and older is now dropped.
> * Warn if possibly stale native dependencies end up in `:native-path`.
>   (Jean Niklas L'orange)
> * Speed up restarts after `:dependency` changes. (Jean Niklas L'orange)
> * `lein release` now supports SNAPSHOT on qualifiers. (Chris Price)
> * Synchronise `lein-pkg` and `lein` scripts. (Thu Trang Pham)
> * Decrease timeout for the Clojure compiler agent thread pool. (Ryan
>   Fowler)
> * Fix a bug where implicit resource directories were created by default.
>   (Jean Niklas L'orange)
> * Avoid optimizing away stack traces by default. (solicode)
> * Fix a bug where duplicate profiles were merged when profile merging.
>   (Jean Niklas L'orange)
> * Improved GPG artifact signing feedback. (Jean Niklas L'orange, Andrea
>   Richiardi)
> * Add function to support binary files with `lein-new`. (Sergiy Bondaryev)
> * Show better error message when java is not found on the path. (Pavel
>   Prokopenko, Jürgen Hötzel)
> * Fix a bug with non-GitHub SCM urls in pom files. (Ralf Schmitt)
> * Don't send aot warning if `:aot` contains regex matching the main
>   namespace. (Emlyn Corrin)
>
> As usual, for those who manually installed, `lein upgrade` will pull in
> the latest. `lein downgrade 2.5.3` will back it down to the previous
> version if you run into any issues.
>
> Thanks to all the contributors who made this happen!
>
> -- Jean Niklas
>
>

-- 
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] clj-refactor.el and refactor-nrepl 2.0.0 is released

[James Elliott]

Thank you all! I have been watching progress on the Gitter chat and am very 
excited to be able to use all the great new features in this amazing 
package. The fact that I am now warned when the project needs to be 
re-evaluated, and that I can recover from issues with my protocols being 
redefined when I go ahead and allow that to happen by calling 
cider-refresh, means I can now learn and apply these tools without fear.

On Saturday, February 6, 2016 at 5:30:39 PM UTC-6, benedek fazekas wrote:
>
> The stable release for clj-refactor.el is out together with its nrepl 
> middleware backend refactor-nrepl.
>
> clj-refactor.el is an Emacs package for clojure and clojure script 
> refactorings while refactor-nrepl is an editor agnostic nrepl middleware 
> backend supporting refactoring features in your editor of choice. For a 
> state of art demo what you can achieve with clj-refactor and Emacs see 
> Magnar's  parens of the dead 
>  series.
>
> The main areas of improvement for this release are
>
>- supporting refactorings for *cljc and clojurescript* files
>- *boot* support
>- *find usages* (and related features) supporting *macros*.
>- *improve discoverability* of features via hydra menus 
> and the 
>project wiki .
>
> Apart from these there are a huge number of changes, improvements and 
> bugfixes, see full changelog for clj-refactor 
> 
>  and refactor-nrepl 
> 
> .
>
> This release is also compatible with the latest cider stable release. 
> Unfortunately tho we had to drop support for clojure 1.6 and older.
>
> As for almost all releases Lars Andersen  invested 
> a lot of time and energy in commits and also in support, also the original 
> creator of clj-refactor Magnar Sveen  helped 
> *create 
> function from example* to grow brains for this release. Thanks for both 
> of them and all the contributors 
> ! 
> Also thanks for the maintainers and contributors of the packages we build 
> on, like cider, tools.nrepl, tools.analyzer, tools.namespace and others!
>
> As always any contribution and/or feedback is welcome. We are available on 
> gitter  and usually hang 
> out on clojurian slack #cider channel too.
>
> Enjoy!
>
> --
> Benedek Fazekas
>

-- 
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] Leiningen 2.6.0

[James Elliott]

Thanks, I’ve created a PR to update the version in homebrew (this time I 
checked to make sure nobody else had already done so first... *blush*)

  -James

On Monday, February 8, 2016 at 12:06:32 PM UTC-6, Jean Niklas L'orange 
wrote:
>
> Hi all,
>
> Instead of creating a new thread for the 2.6.1 release of Leiningen,
> I'll just piggyback on this one.
>
> Leiningen 2.6.1 is a small release to fix an issue with 2.6.0. Some
> popular plugins (`lein midje`, `lein ring` to mention a few) broke
> because of a change in eval-in-project. This has now been fixed.
>
> Sorry for any inconvenience caused.
>
> -- Jean Niklas
>
> On Friday, February 5, 2016 at 2:27:37 AM UTC+1, Jean Niklas L'orange 
> wrote:
>>
>> Greetings!
>>
>> I am happy to announce Leiningen 2.6.0! This release contains mostly
>> usability improvements, along with some bugfixes. 
>>
>> The biggest notable change will likely be for Homebrew users. When the
>> Homebrew formula is updated to 2.6.0, you will likely experience startup
>> time improvements.
>>
>> In addition, `lein release` now supports '-SNAPSHOT' on qualifiers (alpha,
>> beta, RC), and signing GPG artifacts from the terminal will give you
>> feedback on whether you managed to type in your passphrase correctly or
>> not.
>>
>> Due to syntax changes from Clojure 1.1.0 to 1.2.0, we had to drop
>> support for Clojure 1.1.0 and older.
>>
>> The full list of significant changes:
>>
>> * The templates, repl and Leiningen itself now use Clojure 1.8.
>> * Support for Clojure 1.1.0 and older is now dropped.
>> * Warn if possibly stale native dependencies end up in `:native-path`.
>>   (Jean Niklas L'orange)
>> * Speed up restarts after `:dependency` changes. (Jean Niklas L'orange)
>> * `lein release` now supports SNAPSHOT on qualifiers. (Chris Price)
>> * Synchronise `lein-pkg` and `lein` scripts. (Thu Trang Pham)
>> * Decrease timeout for the Clojure compiler agent thread pool. (Ryan
>>   Fowler)
>> * Fix a bug where implicit resource directories were created by default.
>>   (Jean Niklas L'orange)
>> * Avoid optimizing away stack traces by default. (solicode)
>> * Fix a bug where duplicate profiles were merged when profile merging.
>>   (Jean Niklas L'orange)
>> * Improved GPG artifact signing feedback. (Jean Niklas L'orange, Andrea
>>   Richiardi)
>> * Add function to support binary files with `lein-new`. (Sergiy Bondaryev)
>> * Show better error message when java is not found on the path. (Pavel
>>   Prokopenko, Jürgen Hötzel)
>> * Fix a bug with non-GitHub SCM urls in pom files. (Ralf Schmitt)
>> * Don't send aot warning if `:aot` contains regex matching the main
>>   namespace. (Emlyn Corrin)
>>
>> As usual, for those who manually installed, `lein upgrade` will pull in
>> the latest. `lein downgrade 2.5.3` will back it down to the previous
>> version if you run into any issues.
>>
>> Thanks to all the contributors who made this happen!
>>
>> -- Jean Niklas
>>
>>

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

Undocumented reader macros?

[James Elliott]

I learned recently  that you 
can tell the reader to evaluate a function at read time, if you want some 
potentially costly operation that you know will result in a constant value 
to be done just once, rather than every time the surrounding form is 
evaluated, by prefixing it with the reader macro #= and I found this 
surprising. Shouldn’t this be documented in the Reader reference 
?

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

conditional logic implemented as pattern-matching and restructuring in the signature of the function

[Laws]

Sean Johnson has a great video about pattern matching, where he suggests 
that any function that starts with a conditional should have the 
conditional removed and the conditional logic implemented as 
pattern-matching and restructuring in the signature of the function. But 
after some experimentation, I have failed to figure out a way to do this 
here: 

(defn add-parties-to-customer-queue [parties]
  (if (seq parties)
(swap! customer-queue
   (fn [previous-customer-queue]
 (apply conj previous-customer-queue parties)

"parties" sometimes has a vector of vectors, but sometimes it is simply: ()

Is there any way I can match against that pattern in the function 
signature? 





-- 
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: Announcing KR v1.4.2 :: RDF and SPARQL support using clojure data / interfaces

[Fred Eisele]

Are you still working with this?
I have used your package to build an in-memory store.
How to dump an in-memory jena knowledge base?
Thanks

On Thursday, June 14, 2012 at 10:20:03 PM UTC-5, K Livingston wrote:
>
> Hello everyone, I just wanted to announce the open-sourcing of a RDF and 
> SPARQL (and more) library that has been under development and use for quite 
> a while in our lab.  It supports the use of clojure symbols and lists as 
> rdf resources and triples, and it can form triple patterns into sparql 
> queries.  It extends and normalizes the two common Java APIs for 
> RDF/SPARQL: Jena and Sesame, providing a consistent view and easier to 
> write queries through the use of triple-patterns (symbols and sequences) 
> instead of messy string munging.
>
> There are release jars on clojars.org, and all the code is here:
>
> https://github.com/drlivingston/kr
>
> There are two examples in the kr-examples directory showing an in-memory 
> triple store and a remote store.  There is a lot more that can be document 
> and examples written.  A great source of examples exists in 
> kr-core/src/test...  I'll try to keep documenting more and more...
>
> It still has some wrinkles to be sure, but it's a highly functional and 
> useful library.  I welcome feedback, and help improving it.
>
> I hope you find it useful,
> thanks,
> Kevin
>

-- 
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: conditional logic implemented as pattern-matching and restructuring in the signature of the function

[Stuart Sierra]

Clojure's destructuring is not the same thing as the "pattern matching" 
found in some other functional languages. Pattern matching can do various 
conditional checks, destructuring cannot. Clojure's "defn" supports 
destructuring in the argument list.

Full pattern matching is available in Clojure via libraries such as 
core.match:
https://github.com/clojure/core.match

–S



On Monday, February 8, 2016 at 2:41:44 PM UTC-5, Laws wrote:
>
> Sean Johnson has a great video about pattern matching, where he suggests 
> that any function that starts with a conditional should have the 
> conditional removed and the conditional logic implemented as 
> pattern-matching and restructuring in the signature of the function. But 
> after some experimentation, I have failed to figure out a way to do this 
> here: 
>
> (defn add-parties-to-customer-queue [parties]
>   (if (seq parties)
> (swap! customer-queue
>(fn [previous-customer-queue]
>  (apply conj previous-customer-queue parties)
>
> "parties" sometimes has a vector of vectors, but sometimes it is simply: ()
>
> Is there any way I can match against that pattern in the function 
> signature? 
>
>
>
>
>
>

-- 
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: Undocumented reader macros?

[Alex Miller]

Rich has never committed to officially making this part of Clojure so it 
has been left as an undocumented feature.

On Monday, February 8, 2016 at 12:33:44 PM UTC-6, James Elliott wrote:
>
> I learned recently  that you 
> can tell the reader to evaluate a function at read time, if you want some 
> potentially costly operation that you know will result in a constant value 
> to be done just once, rather than every time the surrounding form is 
> evaluated, by prefixing it with the reader macro #= and I found this 
> surprising. Shouldn’t this be documented in the Reader reference 
> ?
>

-- 
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: Undocumented reader macros?

[James Elliott]

Oh, I see… interesting. What would it take to achieve commitment? :) I 
humbly submit that it feels qiote dissonant to stumble across something 
like this in a language that is attaining such wide adoption as Clojure is 
now.

On Monday, February 8, 2016 at 8:53:45 PM UTC-6, Alex Miller wrote:
>
> Rich has never committed to officially making this part of Clojure so it 
> has been left as an undocumented feature.
>
> On Monday, February 8, 2016 at 12:33:44 PM UTC-6, James Elliott wrote:
>>
>> I learned recently  that you 
>> can tell the reader to evaluate a function at read time, if you want some 
>> potentially costly operation that you know will result in a constant value 
>> to be done just once, rather than every time the surrounding form is 
>> evaluated, by prefixing it with the reader macro #= and I found this 
>> surprising. Shouldn’t this be documented in the Reader reference 
>> ?
>>
>

-- 
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: Undocumented reader macros?

[James Elliott]

Quite dissonant, I mean, derp.

On Monday, February 8, 2016 at 9:49:28 PM UTC-6, James Elliott wrote:
>
> Oh, I see… interesting. What would it take to achieve commitment? :) I 
> humbly submit that it feels qiote dissonant to stumble across something 
> like this in a language that is attaining such wide adoption as Clojure is 
> now.
>
> On Monday, February 8, 2016 at 8:53:45 PM UTC-6, Alex Miller wrote:
>>
>> Rich has never committed to officially making this part of Clojure so it 
>> has been left as an undocumented feature.
>>
>> On Monday, February 8, 2016 at 12:33:44 PM UTC-6, James Elliott wrote:
>>>
>>> I learned recently  that 
>>> you can tell the reader to evaluate a function at read time, if you want 
>>> some potentially costly operation that you know will result in a constant 
>>> value to be done just once, rather than every time the surrounding form is 
>>> evaluated, by prefixing it with the reader macro #= and I found this 
>>> surprising. Shouldn’t this be documented in the Reader reference 
>>> ?
>>>
>>

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