Re: ANN: paredit-widget, simple swing-based clojure paredit widget

Thanks for the feedback. I just extended the paredit-widget function to be able to consume pre-existing widgets: (p/paredit-widget (javax.swing.JTextArea. "(foo bar)")) fyi right now the implementation isn't taking advantage of parsley's incremental parsing support, and instead is reparsing the t

Re: [ANN] Nightcode, an IDE for Clojure and Java

I just pushed 0.0.4 to the website. I received reports that it fixes the nightcode.lein error, but please let me know if anyone experiences otherwise. On Friday, August 2, 2013 9:03:03 AM UTC-4, Zach Oakes wrote: > > I’ve been working on a simple IDE for the past few months. It started as > an

At Long Last Hoare

The "Misc" section, containing the Sieve of Eratosthenes and a highly concurrent (and interesting) matrix multiplier, completes my Clojure core.async port of the examples from Hoare's 1978 Communicating Sequential Pr

ANN: paredit-widget, simple swing-based clojure paredit widget

Hi kovasb, I mentioned this in the other thread but it's best to ask here: Can you provide a way to pass an existing JTextArea to it, rather than instantiating your own? -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send

Re: ANN: paredit-widget, simple swing-based clojure paredit widget

On Mon, Aug 5, 2013 at 6:55 PM, John D. Hume wrote: > On Mon, Aug 5, 2013 at 8:37 PM, kovas boguta wrote: > >> https://github.com/kovasb/paredit-widget >> > > >> The bigger idea is that code editing should be available a la carte. >> >> Tying something as fundamental as code editing together with

Re: [ANN] Nightcode, an IDE for Clojure and Java

kovasb, that looks really great. Could you modify it to allow passing in an existing JTextArea? Right now it appears to be instantiating its own, whereas I am using TextEditorPane, which inherits JText

Re: ANN: paredit-widget, simple swing-based clojure paredit widget

On Mon, Aug 5, 2013 at 8:55 PM, John D. Hume wrote: > ICE concerns? > IDE concerns. -- -- 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 - ple

Re: ANN: paredit-widget, simple swing-based clojure paredit widget

On Mon, Aug 5, 2013 at 8:37 PM, kovas boguta wrote: > https://github.com/kovasb/paredit-widget > > The bigger idea is that code editing should be available a la carte. > > Tying something as fundamental as code editing together with IDE concerns > (file & project management, artifact generation

Re: [ANN] Nightcode, an IDE for Clojure and Java

I've just released paredit-widget, https://github.com/kovasb/paredit-widget with the intention of creating a drop-in paredit solution for projects like nightcode. Its still pretty experimental but might be an interesting test case to try to integrate. On Sun, Aug 4, 2013 at 8:19 PM, Matthew C

Re: [ANN] Clotilde is Linda in Clojure.

On Aug 5, 2013, at 10:37 AM, François DE SERRES wrote: > 9 months and half a dozen books later, here's my first (hopefully) useful > Clojure program: https://github.com/justiniac/clotilde > > Clotilde implements the basic ops of the Linda process coordination language: > http://en.wikipedia.org

ANN: paredit-widget, simple swing-based clojure paredit widget

https://github.com/kovasb/paredit-widget This is a simple project that does the obvious: provide a simple widget that implements paredit. It is intended to be embedded as part of other applications, and thus is minimal. This is a rough cut and contributions welcome, particularly for cross-platfor

Re: [ANN] Clotilde is Linda in Clojure.

Quoted patterns need to be handled correctly by clotilde.innards/-match-fn. Tried to make it a macro and to unquote pattern, but clojure.core.match/match complains. See test-match-fn. Gah! Le lundi 5 août 2013 16:37:16 UTC+2, François DE SERRES a écrit : > > Hi, > > 9 months and half a dozen boo

Re: [ANN] Nightcode, an IDE for Clojure and Java

> As for my choice of public domain, I always do that for my > projects. I realize that I am going against the grain, but it's a > principled issue for me. I wrote about it on my blog, but if you'd > like to discuss it further we should do it elsewhere because it can > easily derail the thread. Oo

Re: [ANN] Nightcode, an IDE for Clojure and Java

On Friday, August 2, 2013 8:49:06 AM UTC-7, Zach Oakes wrote: > As for my choice of public domain, I always do that for my projects. Of course it's your choice, but are you aware there are jurisdictions in which users cannot legally make copies of code released in the public domain? -Phil [1]

Re: Two Dimensional Associative Map

On 8/2/13 8:08 PM, JvJ wrote: > Actually, what I'm looking for is a way to use arbitrary types of keys > rather than integers. > > I have this so far: > > Table data structure. > For now, the table data structure is a map of maps. > > (defn row > "Get a row of the table. > If only

Re: [ANN] Nightcode, an IDE for Clojure and Java

Arie, it looks like this is occurring for a lot of people. In lein.clj, I'm using two different methods to launch a process, a "fast" method that leverages Leiningen's trampoline feature, and a "slow" method that runs nightcode.lein which in turn runs Leiningen commands (i.e. it adds a level of

Re: [Proposal] Simplified 'ns' declaration

Just a note: my understanding was that even in Java-land using import * is not recommended. I've done professional Java development since 2006 and in that time I don't think I've ever used import *. I've certainly seen it *in *production code, but I've never felt the need to use it myself. On T

[ANN] Call for papers: Dutch Clojure Day

Hi all, After four successful years of the October Amsterdam Clojure event, the two biggest Clojure communities in the Netherlands, AmsClj and EHRD.clj , joined forces to put together the greatest free event in

Re: Clojars "Could not transfer artifact... ReasonPhrase: Forbidden"

Ok, got this sorted out. Thanks to xeqi @ #leiningen @ irc.freenode.org. Tim Washington Interruptsoftware.ca / Bkeeping.com On Mon, Aug 5, 2013 at 11:24 AM, Timothy Washington wrote: > Hi all, > > I'm having problems deploying a project to Clojars. I've just reset my > Clojars i) password and

Re: [ClojureScript] [ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

Can you all guys please stop starting sooo many interesting topics while I'm on holidays ? ;-) Le lundi 5 août 2013, Chas Emerick a écrit : > On Aug 5, 2013, at 9:21 AM, Chas Emerick wrote: > > > As you might know, I've been tinkering with an easier-to-use variant of > ClojureScript's browser-REP

Re: [Proposal] Simplified 'ns' declaration

Wildcards for java imports will probably never be resolvable when the ns is called. By that I mean that java class loaders are not enumerable, so you cannot get this to work generally. This is a technical detail which objectively prevents the possibility to import "massively" class symbols into a n

Re: [Proposal] Simplified 'ns' declaration

I guess you're right. There should be a way to import many java classes just as importing an entire clojure namespace. We could also have exactly the same syntax for clojure namespaces as java classes. So instead of [org.apache.maven.artifact.resolver ArtifactResolver] we would have [org.apache

Re: [Proposal] Simplified 'ns' declaration

Mark Engelberg writes: >> I think it's java that is at fault here. I think wildcards should >> never have been part of java to begin with. The argument here is >> basically exactly the same as why :use shouldn't be used, so I wont >> explain it further. > > Well, Clojure is hosted on Java and cle

Re: Can we please deprecate the :use directive ?

I agree on this, just started to replace some :use by refer all and I have to maintain the convention to place these at the end of the :require list otherwise they get obfuscated if they end up in the middle. There are only one or two per name space and we can have six to a dozen required name spac

Re: [Proposal] Simplified 'ns' declaration

On Mon, Aug 5, 2013 at 11:31 AM, Jonathan Fischer Friberg < odysso...@gmail.com> wrote: I think it's java that is at fault here. I think wildcards should never > have been part of java to begin with. The argument here is basically > exactly the same as why :use shouldn't be used, so I wont explain

Re: [Proposal] Simplified 'ns' declaration

Here's a new syntax that gets rid of everything except for :as and :except/:exclude: (ns two.namespace [clojure [core :except (ancestors printf)]] [core [matrix math bs]] ; same as (:use (core matrix math bs)) [[some-ns]] ; same as (:use some-ns) [ring.adapter.jetty (run-jetty :as jetty)]

Re: Can we please deprecate the :use directive ?

I find that having both `:use` and `:require` in my `ns` declarations can, with a little judicious formatting, communicate something about which packages are core and which are peripheral. Having to obfuscate that distinction with a `:refer :all` tacked - in a visually obscure way - onto `:requi

Re: [Proposal] Simplified 'ns' declaration

I forgot to add: I think simplicity is really important, and I think one of clojure's strong points are exactly that - simplicity. Simplifying something is not always the right thing to do, but in this case I can't see why it wouldn't. After all, the syntax is almost exactly the same. To comment

Re: [Proposal] Simplified 'ns' declaration

On Aug 5, 2013, at 2:14 PM, Timothy Baldridge wrote: > > To quote Rich: "Java packages are not enumerable. The only way to do so is to > walk the classpath/jars etc. I don't think import * is a good idea, as it > brings more into a namespace than you are going to use, making Clojure's > namesp

Re: [Proposal] Simplified 'ns' declaration

On Mon, Aug 5, 2013 at 11:14 AM, Timothy Baldridge wrote: > On that subject when last discussed, it was mentioned that Clojure doesn't > have a import * method because it's basically impossible to implement. > Well, surely the word "impossible" is inaccurate, since other languages (e.g., Scala) d

Re: [Proposal] Simplified 'ns' declaration

There is syntax to ns. It's not syntax in the traditional way, but it's essentially the same thing. And Greg is right that it often causes confusion. I +1 the second version. The first version's :as-class was too messy. It could very easily be made backwards-compliant as well. All we have to do i

Re: [Proposal] Simplified 'ns' declaration

There's no syntax to ns, ns simply assumes that everything after the symbol/doc is in the form (function-to-execute & args). The only special case is gen-class, and even that is fixed up to look like everything else. Why invent special syntax where none exists now? I think the issue is more around

Re: [Proposal] Simplified 'ns' declaration

> I don't really understand why we would need to simplify something that is > already so simple. Because it's not simple to many people. It's one of the main things people use as an example when discussing complexity in clojure. There are many threads and blog posts where people explain why the

Re: [Proposal] Simplified 'ns' declaration

I don't really understand why we would need to simplify something that is already so simple. Teach people the following: (ns my-namespace ...calls to import fns...) Where import functions can be either :require or :import: (:import [clojure.lang Number AFn]) ;; use for Java imports (:require

Re: [ClojureScript] [ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

This looks awesome. I can't wait to dig into it. On Mon, Aug 5, 2013 at 9:21 AM, Chas Emerick wrote: > As you might know, I've been tinkering with an easier-to-use variant of > ClojureScript's browser-REPL for some time. I've finally wrapped that up > into its own project, Austin: > >

Re: [Proposal] Simplified 'ns' declaration

> OK, that's enough from me on this for now, gotta run (lot of work to do!). Sorry, after sending that, I couldn't resist simplifying 'ns' even further! (ns two.namespace "optional doc string goes here" [core :refer-all [matrix math bs]] [clojure :refer-all [core :except (ancestors printf)

Re: [Proposal] Simplified 'ns' declaration

>> (ns one.fresh-server >> [core :refer-all [matrix math bs]]) > > I like it. Ideally, the whole thing would be well thought out enough to allow these very basic principles to be combined in complicated ways (kinda like the idea behind Lisp itself). Getting rid of ambiguities might help make

Re: PoC: Combining Wikidata and Clojure logic programming

This looks a re-implementation of many of the goals of Datomic. Perhaps you can use Datomic as a datastore, and then use Datomic's datalog, or a custom query engine (such as core.logic https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic/datomic.clj) to do your quer

Re: [Proposal] Simplified 'ns' declaration

On Aug 5, 2013, at 12:41 PM, Greg wrote: >> Can you build in a way to get :require :refer :all to work on a bunch of >> sub-namespaces together on one line, as one currently can with :use, without >> listing each namespace completely on a separate line with a separate :refer >> :all? > > Cert

Re: [Proposal] Simplified 'ns' declaration

On Aug 5, 2013, at 12:39 PM, Mark Engelberg wrote: > > I agree that subnamespaces are important. Relatedly, I frequently struggle > with the fact that Clojure's import doesn't support wildcards. When using > Java libraries, very frequently the Java tutorials or library documentation > use w

Re: PoC: Combining Wikidata and Clojure logic programming

Very interesting. The rel feature is really still a bit of an experimental thing and we'd like to replace it eventually with something less problematic like pldb http://github.com/threatgrid/pldb. Still, core.logic isn't really a database and your needs may be better served by something with diffe

Re: Can we please deprecate the :use directive ?

On Aug 5, 2013, at 8:15 AM, Mikera wrote: > On Monday, 5 August 2013 11:35:22 UTC+1, Phillip Lord wrote: > Anthony Grimes writes: > > I can't think of a single good reason to not deprecate :use. :require can > > do everything :use could do now. > > Wait for it, wait for it > > > This i

Re: [Proposal] Simplified 'ns' declaration

> Can you build in a way to get :require :refer :all to work on a bunch of > sub-namespaces together on one line, as one currently can with :use, without > listing each namespace completely on a separate line with a separate :refer > :all? Certainly. I'm not saying this is how the exact syntax

PoC: Combining Wikidata and Clojure logic programming

Hi, folks, After one night quick work, I had gave a proof-of-concept to demonstrate the feasibility that we can combine Wikidata and Clojure logic programming together. The source code is at here: https://github.com/mountain/knowledge An example of an entity: https://github.com/mountain/knowledg

Re: [Proposal] Simplified 'ns' declaration

On Mon, Aug 5, 2013 at 9:32 AM, Lee Spector wrote: > Can you build in a way to get :require :refer :all to work on a bunch of > sub-namespaces together on one line, as one currently can with :use, > without listing each namespace completely on a separate line with a > separate :refer :all? > I

Re: [Proposal] Simplified 'ns' declaration

On Aug 5, 2013, at 12:28 PM, Greg wrote: > Branching off of the "Can we please deprecate the :use directive ?" thread, I > was wondering what the Clojure community thinks of radically simplifying the > "ns" declaration while keeping all of its power. Can you build in a way to get :require :ref

[Proposal] Simplified 'ns' declaration

Branching off of the "Can we please deprecate the :use directive ?" thread, I was wondering what the Clojure community thinks of radically simplifying the "ns" declaration while keeping all of its power. Old School: (ns one.fresh-server (:refer-clojure :exclude [ancestors printf]) (:use cor

Re: Can we please deprecate the :use directive ?

On Aug 5, 2013, at 4:40 AM, Korny Sietsma wrote: > > 3. Use ":refer :all". It's perfectly fine, IMHO, when used responsibly. I agree in principle, but as I mentioned earlier in a related thread, when I actually tried to convert my :use instances to :require :refer :all I learned (I think!) tha

Re: Can we please deprecate the :use directive ?

Looking at it again, we don't even need an explicit :require anymore: (ns one.fresh-server "optional doc string goes here" [clojure.core :refer-except [ancestors printf]] [core.matrix :refer :all] [ring.adapter.jetty :refer [run-jetty]] [ring.middleware.file :refer [wrap-file]] [ring.m

Re: Incanter 1.5.2 has been released

The documentation is, in general, updated automatically when there is a github checkin that causes a change to the docs. However, github doesn't seem to trigger a webhook call when a tag is added, so autodoc didn't get called. I just ran it manually and we're now happily in 1.5.2-land. Tom On

Re: Can we please deprecate the :use directive ?

* That email was just an idea to explore, not perfection. Also, this is a mistake: (:require [clojure.core :refer [ancestors printf]] Should read something like: (:require [clojure.core :refer-except [ancestors printf]] - Greg -- Please do not email me anything that you are not comfortable

[ANN] Clotilde is Linda in Clojure.

Hi, 9 months and half a dozen books later, here's my first (hopefully) useful Clojure program: https://github.com/justiniac/clotilde Clotilde implements the basic ops of the Linda process coordination language: http://en.wikipedia.org/wiki/Linda_(coordination_language) More on the topic:

Re: [ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

On Aug 5, 2013, at 9:21 AM, Chas Emerick wrote: > As you might know, I've been tinkering with an easier-to-use variant of > ClojureScript's browser-REPL for some time. I've finally wrapped that up > into its own project, Austin: > > https://github.com/cemerick/austin > > Everything you

Re: Can we please deprecate the :use directive ?

This email contains a proposal for a way to get rid of at-least the following forms from the (ns) declaration: - :refer-clojure - :use - :import See below... > The namespace declaration is too complex. The existence of ":use" is not > what causes this. I agree that it is not the *sole* cause,

Clojars "Could not transfer artifact... ReasonPhrase: Forbidden"

Hi all, I'm having problems deploying a project to Clojars. I've just reset my Clojars i) password and ii) SSH public key. And now, from my development system, I want to push my project. Yet I get the below error: "*Could not transfer artifact... ReasonPhrase: Forbidden*". I'm very sure that the p

Re: [ANN] core.typed 0.1.19 - core.async support

0.1.20 is cut, the examples should work. [org.clojure/core.typed "0.1.20"] Also, you probably need to have (clojure.core.typed/typed-deps clojure.core.typed.async) just below your ns form. core.typed doesn't seem to infer the companion namespace sometimes. Thanks, Ambrose On Mon, Aug 5, 2013 at

Re: Can we please deprecate the :use directive ?

Greg writes: >> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, >> e.g. > > Agreed. It's nice that :require :refer :all is available for such instances, > isn't it? Which leads to the crux of the question. Given that the functionality is there, and that you agree tha

Re: Incanter 1.5.2 has been released

I don't know, how often the documentation is regenerated - I think, that Tom can clarify this... On Mon, Aug 5, 2013 at 3:19 PM, Jakub Holy wrote: > I can see that http://liebke.github.io/incanter/core-api.html still reads > "Incanter 1.5.1" so either it hasn't been long enough since you tagged

Re: core.async: macro and visibilities of async operations

Alice writes: > I've used those as a debugging tool, and never thought about using it > inside a macro. For almost all macros you'll probably ever define, you don't need to drive macro expansion yourself. You need it only if you have to transform code that might be anywhere inside the macro's a

Re: core.async: macro and visibilities of async operations

This works fine on my box: foo=> (ns foo (require [clojure.core.async :refer [go !!]])) nil foo=> (defmacro foo #_=> [c] #_=> `( foo=> (let [c (chan)] #_=> (go (prn (foo c))) #_=> (>!! c :hi)) :hi nil foo=> Timothy Baldridge On Mon, Aug 5, 2013 at 7:59 AM, Alice wrote: > I didn't

Re: Incanter 1.5.2 has been released

I can see that http://liebke.github.io/incanter/core-api.html still reads "Incanter 1.5.1" so either it hasn't been long enough since you tagged it or something else must be done to update the docs. Thank you! On Monday, August 5, 2013 8:10:38 AM UTC+2, Alex Ott wrote: > > Ooops, completely for

Re: Can we please deprecate the :use directive ?

>> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, >> e.g. > > Agreed. It's nice that :require :refer :all is available for such instances, > isn't it? * Or for the more gentlemanly and considerate among us, just (:require ... :refer [+ - / *]). -Greg -- Please do

Re: Can we please deprecate the :use directive ?

> It's pretty ugly to use aliases for numerical code, e.g. with core.matrix, > e.g. Agreed. It's nice that :require :refer :all is available for such instances, isn't it? -Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Aug 5, 2013, at 8:22

Re: core.async: macro and visibilities of async operations

I didn't have to fully qualify >! because I referred it using :refer. I'm Sorry if that was not clear. On Monday, August 5, 2013 10:45:16 PM UTC+9, tbc++ wrote: > > Right, so if syntax quote fully qualifies unqualified symbols with the > current namespace, what good is user/>! to core.async? It

Re: core.async: macro and visibilities of async operations

Right, so if syntax quote fully qualifies unqualified symbols with the current namespace, what good is user/>! to core.async? It has no clue that you want that to be a put and not something else. So yes, either async/>! or a fully qualified symbol is what you want here. Timothy Baldridge On Mon,

Re: core.async: macro and visibilities of async operations

I'm not sure I understand your point. Syntax-quote fully qualifies unqualified symbols with the current namespace, so it shouldn't be a problem as long as I don't redefine the >! in the file that defines the macro. On the other hand, ~'>! would be dangerous because you don't know what it will b

Re: [ANN] core.typed 0.1.19 - core.async support

This release didn't quite go as planned. While trying release core.typed without a core.async dependency I managed to break support for core.async. Fix coming. Thanks, Ambrose On Sun, Aug 4, 2013 at 12:52 PM, Ambrose Bonnaire-Sergeant < abonnaireserge...@gmail.com> wrote: > Hi, > > This should

[ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

As you might know, I've been tinkering with an easier-to-use variant of ClojureScript's browser-REPL for some time. I've finally wrapped that up into its own project, Austin: https://github.com/cemerick/austin Everything you need to know is there. The tl;dr is: 1. You can have a Cloj

Re: core.async: macro and visibilities of async operations

I've used those as a debugging tool, and never thought about using it inside a macro. On Monday, August 5, 2013 8:52:56 PM UTC+9, Tassilo Horn wrote: > > Alice > writes: > > > I didn't know that macros can do that! > > Then you might want to have a look at `macroexpand-1` and `macroexpand` > f

Re: core.async: macro and visibilities of async operations

Your macro is incorrect. Notice what happens to un-namespaced symbols inside a syntax quote: (ns 'user) (macroexpand `(foo)) =>(user/foo) So your use of >! is getting translated into mynamespace/>!. Core.async sees your macro and expands it, it just doesn't condsider mynamespace/>! to be a put!

Re: Can we please deprecate the :use directive ?

On Monday, August 5, 2013 2:13:02 PM UTC+2, Mikera wrote: > > > To me the things that make Clojure namespace handling a nightmare for > beginners are: > - Bad error messages (no.1 problem!) > - Confusion with keywords vs. symbols (why ":use" in ns declarations vs > "use" at the repl?) > - Confu

Re: Can we please deprecate the :use directive ?

On Monday, 5 August 2013 09:50:34 UTC+1, Steven Degutis wrote: > The only time I've seen :as lead to ugly code was when it was in a DSL > that would probably have been nicer to use if it was a data-based DSL like > Hiccup rather than code-based. > It's pretty ugly to use aliases for numerical c

Re: Can we please deprecate the :use directive ?

On Monday, 5 August 2013 11:35:22 UTC+1, Phillip Lord wrote: > Anthony Grimes > writes: > > I can't think of a single good reason to not deprecate :use. :require > can > > do everything :use could do now. > > Wait for it, wait for it > > > This isn't about whether or not (:use ..) without

Re: Can we please deprecate the :use directive ?

On Monday, 5 August 2013 09:40:04 UTC+1, Korny wrote: > Agree that :use should be deprecated, mostly as it's quite a barrier to > folks new to the language that you need to know 3 different parts of the ns > macro before you start. > I really don't think :use was ever a significant problem for n

Re: core.async: macro and visibilities of async operations

Alice writes: > I didn't know that macros can do that! Then you might want to have a look at `macroexpand-1` and `macroexpand` from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from clojure.tools.macro. Bye, Tassilo -- -- You received this message because you are subscribed to

Re: core.async: macro and visibilities of async operations

I didn't know that macros can do that! Thanks for the detailed answer. On Monday, August 5, 2013 8:00:16 PM UTC+9, Tassilo Horn wrote: > > Alice > writes: > > > (defmacro foo > > [c] > > `( > > > (let [c (chan)] > > (go (prn (foo c))) > > (>!! c :hi)) > > > > I thought this would n

Re: core.async: macro and visibilities of async operations

Hi, Am Montag, 5. August 2013 12:17:53 UTC+2 schrieb Alice: > > (defmacro foo > [c] > `( > (let [c (chan)] > (go (prn (foo c))) > (>!! c :hi)) > > I thought this would not work because foo is expanded after go is > expanded, so What am I missing? > > I'm not sure what your expectations a

Re: core.async: macro and visibilities of async operations

Alice writes: > (defmacro foo > [c] > `( > (let [c (chan)] > (go (prn (foo c))) > (>!! c :hi)) > > I thought this would not work because foo is expanded after go is expanded, > so What am I missing? `go` explicitly macroexpands the form given to it rather than relying on the standard o

Re: Can we please deprecate the :use directive ?

Anthony Grimes writes: > I can't think of a single good reason to not deprecate :use. :require can > do everything :use could do now. Wait for it, wait for it > This isn't about whether or not (:use ..) without :only is bad. I'd go as > far as to say that outside of test files (and sometim

core.async: macro and visibilities of async operations

(defmacro foo [c] `(!! c :hi)) I thought this would not work because foo is expanded after go is expanded, so 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 r

Re: Can we please deprecate the :use directive ?

The only time I've seen :as lead to ugly code was when it was in a DSL that would probably have been nicer to use if it was a data-based DSL like Hiccup rather than code-based. On Mon, Aug 5, 2013 at 3:40 AM, Korny Sietsma wrote: > Agree that :use should be deprecated, mostly as it's quite a ba

Re: Can we please deprecate the :use directive ?

Agree that :use should be deprecated, mostly as it's quite a barrier to folks new to the language that you need to know 3 different parts of the ns macro before you start. However "objectively bad" is strong language indeed. ":refer :all" is vital anywhere you want a DSL - if using something like