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

[Laurent PETIT]

Le mardi 6 août 2013, kovas boguta a écrit :

> 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-platform issues. (would also love to have rainbow parens :)
>
> The bulk of the work is done by Laurent's paredit.clj ; this just provides
> a thin swing UI wrapper so that one can actually interact with it.
>
> The bigger idea is that code editing should be available a la carte.
>

Nice ! I from the beginning had taken care of separating paredit.clj for
this exact reason, but never took the time to write the swing component.
Thanks Kovas!

I'm on holidays so won't be able to work on this during August, but of
course I'll be more than willing to help where I can when I'm back.
Probably trying to make the interface more explicit, learn & adapt from
your feedback, etc.


>
> Tying something as fundamental as code editing together with IDE concerns
> (file & project management, artifact generation, debugging, etc)  is a
> mistake with profound consequences.
>
>
>
>
> --
> --
> 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 '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  'clojure%2bunsubscr...@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  'clojure%2bunsubscr...@googlegroups.com');>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: the snake game with core.async and swing

[Andreas Liljeqvist]

+1 for Daniels suggestion.
Swing can be quite bothersome if you just want a canvas and key-events.

I would avoid multimethods:

(defn calc-new-pos [xy prev-pos dir]
  (condp = [xy dir]
[:x :right] (+ prev-pos step)
[:x :left]) (- prev-pos step)
[:y :down] (+ prev-pos step)
[:y :up] (- prev-pos step)
:default prev-pos)

But really I think you should see the current 'velocity' as 2d vector eg:
[x y] [step 0] [0 -step]
Both speed and direction integrated.
so:

(defn calc-new-pos [pos vel]
  (map + pos vel))

I would avoid multimethods:

(defn inside-window? [dir canvas [x y]]
  (condp = dir
:left (>= x (.getX canvas))
:right (<= x (+ (.getX canvas) (.getWidth canvas)))
:up (>= y (.getY canvas))
:down (<= y (+ (.getY canvas) (.getHeight canvas)

inside-window? depends on information from the actual window, I would
decouple the game-state from swing.
Remember: functional is good :)

alternative:
(defn inside-window? [[x y]]
  (and
   (< -1 x max-x)
   (< -1 y max-y)))

Also look up the 'doto' macro.

And I should go read up on what core.async does, I have ignored it for too
long.


On Sun, Aug 4, 2013 at 5:56 PM, Daniel  wrote:

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

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

Re: Can we please deprecate the :use directive ?

[Phillip Lord]

Struggling a bit. Moving the keywords to the end of the vector rather
than the beginning? This reduces complexity?

Phil


Greg  writes:

> 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.middleware.file-info :refer [wrap-file-info]]
>   [ring.middleware.stacktrace :refer [wrap-stacktrace]]
>   [ring.util.response :refer [file-response]]
>   [one.reload :as-ns]
>   [one.middleware :as-ns]
>   [net.cgrand.enlive-html :as html]
>   [org.apache.maven.artifact.resolver.ArtifactResolver :as-class] 
>   [java.io.File :as-class])
>
> - Greg

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

Re: [Proposal] Simplified 'ns' declaration

[Phillip Lord]

I've used Java since 1.0 days which is a depressing long time ago. In
that time, I've used and seen used * an awful lot. Of course, it's bad
(when 1.2 came out, we all had to fix our code because of the
java.awt/java.util List nameclash), but the alternative was a total pain
in the ass.

I stopped doing this around 2004, when Emacs started resolving the
imports for me. Currently, maintaining Java imports in Clojure feels
like it did with Java before 2004.

Stefan du Fresne  writes:

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

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

Re: [Proposal] Simplified 'ns' declaration

[Phillip Lord]

Mark Engelberg  writes:
> 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) do it.

Slamhound does it in clojure, so it's possible and has been done.


>> 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
>> namespace enumeration, e.g. ns-imports, that much less useful. "
>>
>
> Maybe it's not ideal if Clojure has to walk the classpath, but the
> alternative is that I have to manually walk the classpath and jars myself
> with no idea what I'm looking for.  Surely it's better for this to be
> handled through an automated process.

Yep. The only argument is whether it should be a language feature or an
IDE feature.

Phil

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

Re: [Proposal] Simplified 'ns' declaration

[Lee Spector]

On Aug 6, 2013, at 7:40 AM, Phillip Lord wrote:

>> Maybe it's not ideal if Clojure has to walk the classpath, but the
>> alternative is that I have to manually walk the classpath and jars myself
>> with no idea what I'm looking for.  Surely it's better for this to be
>> handled through an automated process.
> 
> Yep. The only argument is whether it should be a language feature or an
> IDE feature.


Language feature seems better to me, so that people can rely on it without 
being wedded to a particular IDE. Plus it can then be done once, correctly, and 
it'll be that much easier for people to write new IDEs.

 -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/groups/opt_out.

Ambiguous error message with lazy sequence.

[Qiu Xiafei]

I have a test.clj file like the following:

$ cat test.clj
(defn some-lazy-seq [n]
  (lazy-cat
 (concat n;; should be [n] here
 (some-lazy-seq (inc n)
(println (take 100 (some-lazy-seq 0)))

It's obviously wrong on line 3, the concat function shoud take a seq as
first argments.

But when i run this file, the error is reported on line 5, where the
function is invocated, but not on where it's ocurred. It's really hard to
locate the bug espacially in big project.

Any suggestions to avoid this kind of error message or better solutioins?

thanks!

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

Re: [ANN] Clotilde is Linda in Clojure.

[François DE SERRES]

Hi Lee,

translating some examples from C-Linda, I banged my head on an issue I need 
to fix first hand (see github). But they're definitely coming soon!

Thanks for your feedback, keep in touch ;o)
--
F.

Le mardi 6 août 2013 03:49:27 UTC+2, Lee a écrit :
>
>
> 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/wiki/Linda_(coordination_language) 
> > 
> > More on the topic: 
> http://www.sciencedirect.com/science/article/pii/S0890540199928237 
> > 
> > I'd be so happy to get feedback ;o) 
> > Also, I am now in search of a (possibly NP complex) short Linda program 
> to translate into Clotilde. 
> > Mucho thankies! 
>
> Thanks so much for this François -- I've always been intrigued with Linda 
> and I've played with the concepts a bit, and I'm happy to see this emerging 
> in Clojure. 
>
> Do you happen to have a simple example of a program that uses and 
> demonstrates the core features of the library? That would make it a lot 
> easier to see the system's potential and to start playing with it. I do see 
> the tests in clotilde.core-test but those seem to focus on testing 
> individual pieces, not showing what a simple program using the library 
> would look like. 
>
>  -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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Curtis Summers]

I agree that wildcards make it "easy" (in the nearness sense), but from a 
long-term maintainability standpoint, I'd prefer to have explicit imports 
as is.  When I'm reading your code a year from now and need to look-up the 
docs on a class, wildcards make me (and anyone else in the future) have to 
do that look-up every time.  It's almost the same argument as to why (:use) 
is a bad idea--you're dumping a bunch of symbols into your namespace.  So, 
you're trading some upfront ease for some long-term simplicity.

Yes, lots of Java tutorials are of no help in this endeavor :(  (Again, see 
the parallel in the Clojure world with so much "getting started/example" 
code showing :use instead of :require).

-Curtis


The argument for wildcards is very simple.  Go to just about any Java 
tutorial, for example:

>
> http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/2d/images/examples/LoadImageApp.java
>
> The sample code starts off with a dozen wildcard imports.  If I want to 
> try to use these techniques in Clojure, I have absolutely no idea which 
> specific classes to require.  This creates a tremendous obstacle to 
> consuming Java libraries.  This has affected me personally on several 
> occasions, preventing me from successfully figuring out how to use some 
> Java library from Clojure.
>
> Maybe it's not ideal if Clojure has to walk the classpath, but the 
> alternative is that I have to manually walk the classpath and jars myself 
> with no idea what I'm looking for.  Surely it's better for this to be 
> handled through an automated process.
>  

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

Re: [Proposal] Simplified 'ns' declaration

[Greg]

Folks, I feel this thread has gotten derailed by the discussion of implicit 
imports.

This thread is not about that. It's not about asterisks, or :use, it's about a 
simplified syntax for the 'ns' form.

PLEASE use the "Re: Can we please deprecate the :use directive ?" thread to 
discuss whether implicit imports are a good idea or not. All of comments here 
about implicitly interning symbols from a namespace are just as relevant to 
this proposed syntax as they are to the currently existing one.

Once again, the (latest version) of the syntax being proposed is:

Old School:

(ns one.fresh-server
  (:refer-clojure :exclude [ancestors printf])
  (:use core.matrix
[ring.adapter.jetty :only (run-jetty)]
[ring.middleware.file :only (wrap-file)]
[ring.middleware.file-info :only (wrap-file-info)]
[ring.middleware.stacktrace :only (wrap-stacktrace)]
[ring.util.response :only (file-response)])
  (:require [one.reload :as reload]
[one.middleware :as middleware]
[net.cgrand.enlive-html :as html])
  (:import (org.apache.maven.artifact.resolver ArtifactResolver)
   (java.io File

New School:

(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)]
  [ring.middleware.file ("warp-*")] ; refers all functions beginning with 
"wrap-"
; regex not supported because too confusing
  [ring.middleware.file-info (wrap-file-info)]
  [ring.middleware.stacktrace (wrap-stacktrace)]
  [ring.util.response (file-response)]
  [one reload middleware]
  [net.cgrand enlive-html :as html]
  [org.apache.maven.artifact.resolver ArtifactResolver] 
  [java.io File InputStream])

Four key rules to the new syntax:

1) vectors can only contain namespaces and the keywords :as and :except
2) vectors within vectors will refer everything in the the namespaces specified 
in them
3) lists can only contain functions and the keyword :as to rename functions.
4) namespaces are referred by placing a space after the namespace prefix

Also, an added feature/rule is that globbing-based strings can be used to save 
on typing (as shown in the example above).

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 6, 2013, at 7:55 AM, Curtis Summers  wrote:

> I agree that wildcards make it "easy" (in the nearness sense), but from a 
> long-term maintainability standpoint, I'd prefer to have explicit imports as 
> is.  When I'm reading your code a year from now and need to look-up the docs 
> on a class, wildcards make me (and anyone else in the future) have to do that 
> look-up every time.  It's almost the same argument as to why (:use) is a bad 
> idea--you're dumping a bunch of symbols into your namespace.  So, you're 
> trading some upfront ease for some long-term simplicity.
> 
> Yes, lots of Java tutorials are of no help in this endeavor :(  (Again, see 
> the parallel in the Clojure world with so much "getting started/example" code 
> showing :use instead of :require).
> 
> -Curtis
> 
> 
> The argument for wildcards is very simple.  Go to just about any Java 
> tutorial, for example:
> http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/2d/images/examples/LoadImageApp.java
> 
> The sample code starts off with a dozen wildcard imports.  If I want to try 
> to use these techniques in Clojure, I have absolutely no idea which specific 
> classes to require.  This creates a tremendous obstacle to consuming Java 
> libraries.  This has affected me personally on several occasions, preventing 
> me from successfully figuring out how to use some Java library from Clojure.
> 
> Maybe it's not ideal if Clojure has to walk the classpath, but the 
> alternative is that I have to manually walk the classpath and jars myself 
> with no idea what I'm looking for.  Surely it's better for this to be handled 
> through an automated process.
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Ambiguous error message with lazy sequence.

[jiujiu xiang]

在 2013年8月6日星期二UTC+8下午8时31分19秒，Qiu Xiafei写道：
>
> I have a test.clj file like the following:
>
> $ cat test.clj 
> (defn some-lazy-seq [n]
>   (lazy-cat
>  (concat n;; should be [n] here
>  (some-lazy-seq (inc n)
> (println (take 100 (some-lazy-seq 0)))
>
> It's obviously wrong on line 3, the concat function shoud take a seq as 
> first argments.
>
> But when i run this file, the error is reported on line 5, where the 
> function is invocated, but not on where it's ocurred. It's really hard to 
> locate the bug espacially in big project.
>
> Any suggestions to avoid this kind of error message or better solutioins?
>
> thanks!
>

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

Re: Can we please deprecate the :use directive ?

[Greg]

> Struggling a bit. Moving the keywords to the end of the vector rather
> than the beginning? This reduces complexity?

I changed the syntax a bit since posting that, please have a look at the 
"[Proposal] Simplified 'ns' declaration" thread.

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 6, 2013, at 7:22 AM, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:

> 
> 
> Struggling a bit. Moving the keywords to the end of the vector rather
> than the beginning? This reduces complexity?
> 
> Phil
> 
> 
> Greg  writes:
> 
>> 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.middleware.file-info :refer [wrap-file-info]]
>>  [ring.middleware.stacktrace :refer [wrap-stacktrace]]
>>  [ring.util.response :refer [file-response]]
>>  [one.reload :as-ns]
>>  [one.middleware :as-ns]
>>  [net.cgrand.enlive-html :as html]
>>  [org.apache.maven.artifact.resolver.ArtifactResolver :as-class] 
>>  [java.io.File :as-class])
>> 
>> - Greg
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Can we please deprecate the :use directive (was Re: [Proposal] Simplified 'ns' declaration)

[Lee Spector]

On Aug 6, 2013, at 7:55 AM, Curtis Summers wrote:

> I agree that wildcards make it "easy" (in the nearness sense), but from a 
> long-term maintainability standpoint, I'd prefer to have explicit imports as 
> is.  When I'm reading your code a year from now and need to look-up the docs 
> on a class, wildcards make me (and anyone else in the future) have to do that 
> look-up every time.  It's almost the same argument as to why (:use) is a bad 
> idea--you're dumping a bunch of symbols into your namespace.  So, you're 
> trading some upfront ease for some long-term simplicity.

This makes perfect sense if long-term maintainability is one of your higher 
priorities, which it certainly should be in many programming contexts. But not 
in many others. 

I do realize that many (most?) programmers spend lots (most?) of their time 
reading and maintaining code rather than writing original code. But not every 
programmer is "most" programmers :-). For me and I suspect many other 
researchers/teachers/students/artists/etc. upfront ease is really valuable and 
in fact crucial, and I can worry about long-term maintainability if/when that 
becomes a relevant concern. If I have an idea then I want to try it out ASAP by 
writing just the code I need to try it out, and it's a total drag when a 
language/environment makes me engage in a time-consuming and distracting 
bureaucratic process -- doing stuff that the system could really do for me -- 
on the way to expressing and trying my idea. If something works well, and I 
want to build on it and/or share it, then yes, I should re-engineer it for 
readability and maintainability. But that doesn't mean I want to -- or should 
have to -- jump through lots of hoops to play with ideas in the first place.

FWIW if you find my perspective here to be crazy I think that it's close in 
some ways to ideas that Paul Graham has expressed much better in some of his 
essays about Lisp, language design and programming methodology 
(http://www.paulgraham.com/articles.html --  mostly the ones near the bottom of 
the list).

In other words, "don't use wildcards" may be an excellent rule for programmers 
in many contexts, but that doesn't mean that it's a good idea for a language to 
impose it on everybody all of the time. And more generally, it's probably not a 
good idea to impose rules on all users of a language just because they're good 
rules for some/most programmers to follow some/most of the time.

 -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/groups/opt_out.

Re: [Proposal] Simplified 'ns' declaration

[Phillip Lord]

Greg  writes:
> New School:
>
> (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)]
>   [ring.middleware.file ("warp-*")] ; refers all functions beginning with 
> "wrap-"
> ; regex not supported because too 
> confusing
>   [ring.middleware.file-info (wrap-file-info)]
>   [ring.middleware.stacktrace (wrap-stacktrace)]
>   [ring.util.response (file-response)]
>   [one reload middleware]
>   [net.cgrand enlive-html :as html]
>   [org.apache.maven.artifact.resolver ArtifactResolver] 
>   [java.io File InputStream])
>
> Four key rules to the new syntax:
>
> 1) vectors can only contain namespaces and the keywords :as and :except
> 2) vectors within vectors will refer everything in the the namespaces 
> specified in them
> 3) lists can only contain functions and the keyword :as to rename functions.


I am dubious about distinguishing between lists and vectors. Currently,
as far as I can tell, the ns is agnostic, and only cares about them
being sequential. This is probably one of the sources of confusion for
beginners -- they see both and don't see why, when in fact on the outer
brackets are necessarily round. 

Also, I am confused as to how you distinguish between 

[core [matrix math bs]] being equivalent to :use while

Is [one reload middleware] also :use? Or :require?

If there was one thing I would deprecate it's that the first element of
the vector is special.

I find the fact that these two:

(ns bob [:require [tawny owl reasoner]])
(ns john [:require [tawny.owl reasoner]])

are totally different, very confusing. Throw in this

(ns john [:require [tawny.owl]])

In the first case "tawny.owl" is a prefix, and in the second it means
"require tawny.owl".

Phil





> 4) namespaces are referred by placing a space after the namespace prefix
>
> Also, an added feature/rule is that globbing-based strings can be used to 
> save on typing (as shown in the example above).
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
>
> On Aug 6, 2013, at 7:55 AM, Curtis Summers  wrote:
>
>> I agree that wildcards make it "easy" (in the nearness sense), but from a 
>> long-term maintainability standpoint, I'd prefer to have explicit imports as 
>> is.  When I'm reading your code a year from now and need to look-up the docs 
>> on a class, wildcards make me (and anyone else in the future) have to do 
>> that look-up every time.  It's almost the same argument as to why (:use) is 
>> a bad idea--you're dumping a bunch of symbols into your namespace.  So, 
>> you're trading some upfront ease for some long-term simplicity.
>> 
>> Yes, lots of Java tutorials are of no help in this endeavor :(  (Again, see 
>> the parallel in the Clojure world with so much "getting started/example" 
>> code showing :use instead of :require).
>> 
>> -Curtis
>> 
>> 
>> The argument for wildcards is very simple.  Go to just about any Java 
>> tutorial, for example:
>> http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/2d/images/examples/LoadImageApp.java
>> 
>> The sample code starts off with a dozen wildcard imports.  If I want to try 
>> to use these techniques in Clojure, I have absolutely no idea which specific 
>> classes to require.  This creates a tremendous obstacle to consuming Java 
>> libraries.  This has affected me personally on several occasions, preventing 
>> me from successfully figuring out how to use some Java library from Clojure.
>> 
>> Maybe it's not ideal if Clojure has to walk the classpath, but the 
>> alternative is that I have to manually walk the classpath and jars myself 
>> with no idea what I'm looking for.  Surely it's better for this to be 
>> handled through an automated process.
>> 
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russ

Re: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

For this to even have a chance at making it into Clojure you need to
consider all the edge cases. So I have two questions

a) How do you plan on having this backwards-compatible with existing code?
You will have to support both the old and new versions on the same Clojure
compiler. Notice that this is completely valid in the current compiler:

(ns foo
  [require [clojure.string :as c]])

b) You will also need a very concise, clear definition on why the new
approach is better. Once again, please notice that your "old school"
example could also have been written in a much more concise manner:

(ns one.fresh-server
  (:refer-clojure :exclude [ancestors printf])
  (:require [one.reload :as reload]
[one.middleware :as middleware]
[net.cgrand.enlive-html :as html]
[ring.adapter.jetty :refer (run-jetty)]
[ring.middleware.file :refer (wrap-file)]
[ring.middleware.file-info :refer (wrap-file-info)]
[ring.middleware.stacktrace :refer (wrap-stacktrace)]
[ring.util.response :refer (file-response)])
  (:import (org.apache.maven.artifact.resolver ArtifactResolver)
   (java.io File

As a support to the current method let me point out the following. We have
3 constructs in this case, each only does one thing:

a) refer-clojure - allows you to :exclude certain symbols from being
imported by default
b) require loads clojure namespaces
c) import loads Java classes

Your example also has the following problem:

bar=> (ns foo.bar)
nil
foo.bar=>

foo.bar=> (ns foo)
nil
foo=> (defprotocol bar (dostuff [this]))
bar
foo=> (ns user)
nil
user=> (ns user (:require [foo.bar]) (:import [foo.bar]))
nil
user=> bar
foo.bar
user=> (class bar)
java.lang.Class

With the current design we can clearly distinguish between loading a java
class, and loading a clojure namespace. In the example above, we need this
if we want to clearly load both the java interface foo.bar as well as the
clojure namespace foo.bar.

How would the new syntax express such a ns statement, and how would the
semantics be clearer in this approach?

Timothy Baldridge


On Tue, Aug 6, 2013 at 8:51 AM, Greg  wrote:

> Folks, I feel this thread has gotten derailed by the discussion of
> implicit imports.
>
> This thread is not about that. It's not about asterisks, or :use, it's
> about a simplified syntax for the 'ns' form.
>
> PLEASE use the "Re: Can we please deprecate the :use directive ?" thread
> to discuss whether implicit imports are a good idea or not. All of comments
> here about implicitly interning symbols from a namespace are just as
> relevant to this proposed syntax as they are to the currently existing one.
>
> Once again, the (latest version) of the syntax being proposed is:
>
> *Old School:*
>
> (ns one.fresh-server
>   (:refer-clojure :exclude [ancestors printf])
>   (:use core.matrix
> [ring.adapter.jetty :only (run-jetty)]
> [ring.middleware.file :only (wrap-file)]
> [ring.middleware.file-info :only (wrap-file-info)]
> [ring.middleware.stacktrace :only (wrap-stacktrace)]
> [ring.util.response :only (file-response)])
>   (:require [one.reload :as reload]
> [one.middleware :as middleware]
> [net.cgrand.enlive-html :as html])
>   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
>(java.io File
>
>
> *New School:*
>
> (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)]
>   [ring.middleware.file ("warp-*")] ; refers all functions beginning with
> "wrap-"
> ; regex not supported because too
> confusing
>   [ring.middleware.file-info (wrap-file-info)]
>   [ring.middleware.stacktrace (wrap-stacktrace)]
>   [ring.util.response (file-response)]
>   [one reload middleware]
>   [net.cgrand enlive-html :as html]
>   [org.apache.maven.artifact.resolver ArtifactResolver]
>   [java.io File InputStream])
>
>
> *Four key rules to the new syntax:*
>
> 1) vectors can only contain namespaces and the keywords :as and :except
> 2) vectors within vectors will refer everything in the the namespaces
> specified in them
> 3) lists can only contain functions and the keyword :as to rename
> functions.
> 4) namespaces are referred by placing a space after the namespace prefix
>
> Also, an added feature/rule is that globbing-based strings can be used to
> save on typing (as shown in the example above).
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 6, 2013, at 7:55 AM, Curtis Summers 
> wrote:
>
> I agree that wildcards make it "easy" (in the nearness sense), but from a
> long-term maintainability standpoint, I'd prefer to have explicit imports
> as is.  When I'm reading your code a year from now and need to look-up the
> docs o

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> I am dubious about distinguishing between lists and vectors. Currently,
> as far as I can tell, the ns is agnostic, and only cares about them
> being sequential. This is probably one of the sources of confusion for
> beginners -- they see both and don't see why

The reason for distinguishing between lists and vectors is as you say, it's 
confusing for beginnings. Also, it allows the syntax to have greater 
functionality/power.

> Also, I am confused as to how you distinguish between 
> [core [matrix math bs]] being equivalent to :use while
> Is [one reload middleware] also :use? Or :require?

Nested vectors = :use.

Thus, as the comment says, [core [matrix math bs]] => (:use (core matrix math 
bs))

It's a bit confusing in the current syntax (if I have it correct), because from 
it, it's not clear why "core" isn't "used".

[one reload middleware]

Is equivalent to:

(:require [one.reload :as reload]
  [one.middleware :as middleware])

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 6, 2013, at 11:07 AM, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:

> Greg  writes:
>> New School:
>> 
>> (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)]
>>  [ring.middleware.file ("warp-*")] ; refers all functions beginning with 
>> "wrap-"
>>; regex not supported because too 
>> confusing
>>  [ring.middleware.file-info (wrap-file-info)]
>>  [ring.middleware.stacktrace (wrap-stacktrace)]
>>  [ring.util.response (file-response)]
>>  [one reload middleware]
>>  [net.cgrand enlive-html :as html]
>>  [org.apache.maven.artifact.resolver ArtifactResolver] 
>>  [java.io File InputStream])
>> 
>> Four key rules to the new syntax:
>> 
>> 1) vectors can only contain namespaces and the keywords :as and :except
>> 2) vectors within vectors will refer everything in the the namespaces 
>> specified in them
>> 3) lists can only contain functions and the keyword :as to rename functions.
> 
> 
> I am dubious about distinguishing between lists and vectors. Currently,
> as far as I can tell, the ns is agnostic, and only cares about them
> being sequential. This is probably one of the sources of confusion for
> beginners -- they see both and don't see why, when in fact on the outer
> brackets are necessarily round. 
> 
> Also, I am confused as to how you distinguish between 
> 
> [core [matrix math bs]] being equivalent to :use while
> 
> Is [one reload middleware] also :use? Or :require?
> 
> If there was one thing I would deprecate it's that the first element of
> the vector is special.
> 
> I find the fact that these two:
> 
> (ns bob [:require [tawny owl reasoner]])
> (ns john [:require [tawny.owl reasoner]])
> 
> are totally different, very confusing. Throw in this
> 
> (ns john [:require [tawny.owl]])
> 
> In the first case "tawny.owl" is a prefix, and in the second it means
> "require tawny.owl".
> 
> Phil
> 
> 
> 
> 
> 
>> 4) namespaces are referred by placing a space after the namespace prefix
>> 
>> Also, an added feature/rule is that globbing-based strings can be used to 
>> save on typing (as shown in the example above).
>> 
>> - Greg
>> 
>> --
>> Please do not email me anything that you are not comfortable also sharing 
>> with the NSA.
>> 
>> On Aug 6, 2013, at 7:55 AM, Curtis Summers  wrote:
>> 
>>> I agree that wildcards make it "easy" (in the nearness sense), but from a 
>>> long-term maintainability standpoint, I'd prefer to have explicit imports 
>>> as is.  When I'm reading your code a year from now and need to look-up the 
>>> docs on a class, wildcards make me (and anyone else in the future) have to 
>>> do that look-up every time.  It's almost the same argument as to why (:use) 
>>> is a bad idea--you're dumping a bunch of symbols into your namespace.  So, 
>>> you're trading some upfront ease for some long-term simplicity.
>>> 
>>> Yes, lots of Java tutorials are of no help in this endeavor :(  (Again, see 
>>> the parallel in the Clojure world with so much "getting started/example" 
>>> code showing :use instead of :require).
>>> 
>>> -Curtis
>>> 
>>> 
>>> The argument for wildcards is very simple.  Go to just about any Java 
>>> tutorial, for example:
>>> http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/2d/images/examples/LoadImageApp.java
>>> 
>>> The sample code starts off with a dozen wildcard imports.  If I want to try 
>>> to use these techniques in Clojure, I have absolutely no idea which 
>>> specific classes to require.  This creates a tremendous obstacle to 
>>> consuming Java libraries.  This has affected me personally on several 
>>> occasions, preventing me from successfully figuring out how to use some 
>>> Java library from Clojure.
>>> 
>>> Maybe it's not ideal if Clojure has t

Re: [Proposal] Simplified 'ns' declaration

[Greg]

Thanks Timothy for your very thoughtful reply!

You bring up some very valid points.

> a) How do you plan on having this backwards-compatible with existing code? 
> You will have to support both the old and new versions on the same Clojure 
> compiler. Notice that this is completely valid in the current compiler:
> 
> (ns foo 
>   [require [clojure.string :as c]])

I've never seen that before. What does it do?

Someone else mentioned (I'm sorry, I don't remember who, or whether it was even 
in this thread), that you could simply distinguish between lists and vectors, 
and if that's not good enough, then distinguishing between lists/vectors that 
start with a keyword, and those that don't.

> Once again, please notice that your "old school" example could also have been 
> written in a much more concise manner: 


It could have, I agree, but its syntax doesn't force you to. This one does. 
It's always "concise", as you say.

The example you gave is also still too ambiguous for newcomers to understand, 
and contains a lot of unnecessary elements.

Ambiguity
It's not clear from your example why parenthesis are used sometimes and vectors 
are used in other cases.

Unnecessary elements

(:require [one.reload :as reload]
  [one.middleware :as middleware])

Versus:

[one reload middleware]

> With the current design we can clearly distinguish between loading a java 
> class, and loading a clojure namespace. 

I'm sorry, I tried running your example in a REPL and got:

CompilerException java.lang.RuntimeException: Unable to resolve symbol: bar in 
this context, compiling:(NO_SOURCE_PATH:0:0)

I also tried using definterface instead of defprotocol, but got the same error.

I assume there's some minor error in the example you gave, but let me try and 
and address your question anyway: you could either introduce a new keyword 
(like :as-class), or use :as to rename them to avoid conflicts. After all, it's 
already possible to have conflicts between just two namespaces if you try to 
alias them to the same symbol/var.

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 6, 2013, at 11:14 AM, Timothy Baldridge  wrote:

> For this to even have a chance at making it into Clojure you need to consider 
> all the edge cases. So I have two questions
> 
> a) How do you plan on having this backwards-compatible with existing code? 
> You will have to support both the old and new versions on the same Clojure 
> compiler. Notice that this is completely valid in the current compiler:
> 
> (ns foo 
>   [require [clojure.string :as c]])
> 
> b) You will also need a very concise, clear definition on why the new 
> approach is better. Once again, please notice that your "old school" example 
> could also have been written in a much more concise manner: 
> 
> (ns one.fresh-server
>   (:refer-clojure :exclude [ancestors printf])
>   (:require [one.reload :as reload]
> [one.middleware :as middleware]
> [net.cgrand.enlive-html :as html]
> [ring.adapter.jetty :refer (run-jetty)]
> [ring.middleware.file :refer (wrap-file)]
> [ring.middleware.file-info :refer (wrap-file-info)]
> [ring.middleware.stacktrace :refer (wrap-stacktrace)]
> [ring.util.response :refer (file-response)])
>   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
>(java.io File
> 
> As a support to the current method let me point out the following. We have 3 
> constructs in this case, each only does one thing:
> 
> a) refer-clojure - allows you to :exclude certain symbols from being imported 
> by default
> b) require loads clojure namespaces
> c) import loads Java classes
> 
> Your example also has the following problem:
> 
> bar=> (ns foo.bar)
> nil
> foo.bar=>
> 
> foo.bar=> (ns foo)
> nil
> foo=> (defprotocol bar (dostuff [this]))
> bar
> foo=> (ns user)
> nil
> user=> (ns user (:require [foo.bar]) (:import [foo.bar]))
> nil
> user=> bar
> foo.bar
> user=> (class bar)
> java.lang.Class
> 
> With the current design we can clearly distinguish between loading a java 
> class, and loading a clojure namespace. In the example above, we need this if 
> we want to clearly load both the java interface foo.bar as well as the 
> clojure namespace foo.bar.
> 
> How would the new syntax express such a ns statement, and how would the 
> semantics be clearer in this approach?
> 
> Timothy Baldridge
> 
> 
> On Tue, Aug 6, 2013 at 8:51 AM, Greg  wrote:
> Folks, I feel this thread has gotten derailed by the discussion of implicit 
> imports.
> 
> This thread is not about that. It's not about asterisks, or :use, it's about 
> a simplified syntax for the 'ns' form.
> 
> PLEASE use the "Re: Can we please deprecate the :use directive ?" thread to 
> discuss whether implicit imports are a good idea or not. All of comments here 
> about implicitly interning symbols from a namespace are just as relevant to 
> this propo

Re: [Proposal] Simplified 'ns' declaration

[Phillip Lord]

Greg  writes:

>> I am dubious about distinguishing between lists and vectors. Currently,
>> as far as I can tell, the ns is agnostic, and only cares about them
>> being sequential. This is probably one of the sources of confusion for
>> beginners -- they see both and don't see why
>
> The reason for distinguishing between lists and vectors is as you say, it's
> confusing for beginnings. Also, it allows the syntax to have greater
> functionality/power.

Really dubious about this. Having to keep in my head when I need to use
[] and when I need to use () is a significant problem when starting. It
was my realisation that for the ns declaration you don't that made
things easier.

>> Also, I am confused as to how you distinguish between 
>> [core [matrix math bs]] being equivalent to :use while
>> Is [one reload middleware] also :use? Or :require?
>
> Nested vectors = :use.
>
> Thus, as the comment says, [core [matrix math bs]] => (:use (core matrix math
> bs))
>
> It's a bit confusing in the current syntax (if I have it correct), because
> from it, it's not clear why "core" isn't "used".
>
> [one reload middleware]
>
> Is equivalent to:
>
> (:require [one.reload :as reload]
>   [one.middleware :as middleware])

Scares me to be honest. You now have an implicit alias ":as reload", and
are distinguishing between having an alias and having no qualification
by nesting or otherwise. 

I do like the idea of enforcing nesting though in 

[core [matrix math bs]]

Phil

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

Re: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

>> (ns foo
>>  [require [clojure.string :as c]])


>> I've never seen that before. What does it do?

It's exactly the same as a normal require. Ns allows vectors/seqs
symbols/keywords to be used interchangeably. Some people use (:require)
others use (require), ns just uses ns/namespace to get the data on the
first of each item after the symbol.


Yeah, there's a bug in the code, but let me try to redefine the problem.
Assume I have a namespace called foo that defines a protocol (and hence an
interface) called bar. I then also have a namespace called foo.bar. How do
I tell the new syntax to import each? If I simply say "go get foo.bar" what
are you going to load, the .clj file, or the java interface?

Timothy


On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord
wrote:

> Greg  writes:
>
> >> I am dubious about distinguishing between lists and vectors. Currently,
> >> as far as I can tell, the ns is agnostic, and only cares about them
> >> being sequential. This is probably one of the sources of confusion for
> >> beginners -- they see both and don't see why
> >
> > The reason for distinguishing between lists and vectors is as you say,
> it's
> > confusing for beginnings. Also, it allows the syntax to have greater
> > functionality/power.
>
> Really dubious about this. Having to keep in my head when I need to use
> [] and when I need to use () is a significant problem when starting. It
> was my realisation that for the ns declaration you don't that made
> things easier.
>
> >> Also, I am confused as to how you distinguish between
> >> [core [matrix math bs]] being equivalent to :use while
> >> Is [one reload middleware] also :use? Or :require?
> >
> > Nested vectors = :use.
> >
> > Thus, as the comment says, [core [matrix math bs]] => (:use (core matrix
> math
> > bs))
> >
> > It's a bit confusing in the current syntax (if I have it correct),
> because
> > from it, it's not clear why "core" isn't "used".
> >
> > [one reload middleware]
> >
> > Is equivalent to:
> >
> > (:require [one.reload :as reload]
> >   [one.middleware :as middleware])
>
> Scares me to be honest. You now have an implicit alias ":as reload", and
> are distinguishing between having an alias and having no qualification
> by nesting or otherwise.
>
> I do like the idea of enforcing nesting though in
>
> [core [matrix math bs]]
>
> Phil
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


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

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

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> Scares me to be honest. You now have an implicit alias ":as reload", and
> are distinguishing between having an alias and having no qualification
> by nesting or otherwise. 

Sorry, I'm not sure what you're saying at the end there.

If you want to rename a namespace you can do it explicitly with :as, like I 
gave in the example with "enlive-html":

[net.cgrand enlive-html :as html]

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 6, 2013, at 11:39 AM, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:

> Greg  writes:
> 
>>> I am dubious about distinguishing between lists and vectors. Currently,
>>> as far as I can tell, the ns is agnostic, and only cares about them
>>> being sequential. This is probably one of the sources of confusion for
>>> beginners -- they see both and don't see why
>> 
>> The reason for distinguishing between lists and vectors is as you say, it's
>> confusing for beginnings. Also, it allows the syntax to have greater
>> functionality/power.
> 
> Really dubious about this. Having to keep in my head when I need to use
> [] and when I need to use () is a significant problem when starting. It
> was my realisation that for the ns declaration you don't that made
> things easier.
> 
>>> Also, I am confused as to how you distinguish between 
>>> [core [matrix math bs]] being equivalent to :use while
>>> Is [one reload middleware] also :use? Or :require?
>> 
>> Nested vectors = :use.
>> 
>> Thus, as the comment says, [core [matrix math bs]] => (:use (core matrix math
>> bs))
>> 
>> It's a bit confusing in the current syntax (if I have it correct), because
>> from it, it's not clear why "core" isn't "used".
>> 
>> [one reload middleware]
>> 
>> Is equivalent to:
>> 
>> (:require [one.reload :as reload]
>>  [one.middleware :as middleware])
> 
> Scares me to be honest. You now have an implicit alias ":as reload", and
> are distinguishing between having an alias and having no qualification
> by nesting or otherwise. 
> 
> I do like the idea of enforcing nesting though in 
> 
> [core [matrix math bs]]
> 
> Phil
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Marcus Blankenship]

Hey Zach,

First, this is awesome.  Really.  Awesome.  ;-)

Second, you should put an email sign-up on this page, so folks can be notified 
when you update it, or when you have other cool things to say.  Anyone that 
builds this kind of product probably has other cool things to say, and I would 
want to hear them.  

Just my $0.02.
Marcus


On Aug 5, 2013, at 8:42 PM, Zach Oakes  wrote:

> 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 
> attempt to add Leiningen integration to Clooj, but eventually I decided to 
> start a new project from scratch. It is very alpha-quality, so please be 
> gentle:
> 
> http://nightcode.info/
> 
> Here’s what it has:
> 
> -Written in Clojure (the UI is written with seesaw)
> -Built-in copy of Leiningen to build Clojure and pure-Java projects
> -Built-in templates for several common types of Clojure and Java projects
> -Always-on REPL in the corner to try Clojure commands
> -Android integration (includes the lein-droid plugin, LogCat output, etc)
> -ClojureScript integration (includes the lein-cljsbuild plugin)
> -Cool looking dark theme, because that’s trendy these days
> 
> Here’s what it’s missing:
> 
> -Fast build times (it launches Leiningen in a separate process, which is 
> slw...I plan on fixing this and would love any help)
> -Important editing features (code completion, text replace, etc)
> -Quick switching between recent files
> -Jump to definition, built-in documentation
> -Integration between editor and REPL (eval form or entire file)
> -Integration with git
> -Many other things -- please give me your thoughts!
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

MARCUS BLANKENSHIP
\\\ Owner, Problem Solver, Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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

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

[Zach Oakes]

Thanks! It seems to work well so far in Nightcode. I noticed it pulled down 
a bunch of older versions of Clojure, but I'm guessing that's because 
you're using a SNAPSHOT version of seesaw in it? Also, I was wondering if 
the other library you use (org.kovas/paredit.clj) was available anywhere -- 
I couldn't find it on your Github.

On Monday, August 5, 2013 11:52:24 PM UTC-4, kovasb wrote:
>
> 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 text with every 
> paredit command execution. This might be an issue for big files, but is 
> fixable. 
>
>
> On Mon, Aug 5, 2013 at 7:51 PM, Zach Oakes > 
> wrote:
> >
> > 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 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/groups/opt_out.
> >
> >
>

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

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> It's exactly the same as a normal require. Ns allows vectors/seqs 
> symbols/keywords to be used interchangeably. Some people use (:require) 
> others use (require), ns just uses ns/namespace to get the data on the first 
> of each item after the symbol. 

Wow that's confusing!

I just view that as yet another reason to change the syntax.

To answer your question though, I'd do both syntax's a favor and interpret 
"[require [clojure.string :as c]]" using the new syntax. It would save a lot of 
newbies many headaches. Think of the newbies.

> Yeah, there's a bug in the code, but let me try to redefine the problem. 
> Assume I have a namespace called foo that defines a protocol (and hence an 
> interface) called bar. I then also have a namespace called foo.bar. How do I 
> tell the new syntax to import each? If I simply say "go get foo.bar" what are 
> you going to load, the .clj file, or the java interface?

I think part of the problem here is that I'm not very well educated on this 
topic yet. Perhaps you can help:

- If you defined a protocol Foo in user, is it referenced as user.Foo from 
another ns, or user/Foo ? Or both??

- Can you have a function Foo at the same time as a protocol Foo in the same 
namespace?

- What about records? Can you have a record Foo and a protocol Foo?

- Can you have a class Foo and an protocol Foo?

Clojure and I are already confused here:

baz=> (defprotocol g (dostuff [this]))
g
baz=> g
{:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists ([this]), 
:name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff}, 
:method-builders {#'baz/dostuff #}}
baz=> (defn g [] "a")
#'baz/g
baz=> g
#

And I'm not sure how to get the protocol back...

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 6, 2013, at 11:43 AM, Timothy Baldridge  wrote:

>> >> (ns foo 
>> >>  [require [clojure.string :as c]])
> 
> >> I've never seen that before. What does it do?
> 
> It's exactly the same as a normal require. Ns allows vectors/seqs 
> symbols/keywords to be used interchangeably. Some people use (:require) 
> others use (require), ns just uses ns/namespace to get the data on the first 
> of each item after the symbol. 
> 
> 
> Yeah, there's a bug in the code, but let me try to redefine the problem. 
> Assume I have a namespace called foo that defines a protocol (and hence an 
> interface) called bar. I then also have a namespace called foo.bar. How do I 
> tell the new syntax to import each? If I simply say "go get foo.bar" what are 
> you going to load, the .clj file, or the java interface?
> 
> Timothy
> 
> 
> On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord  
> wrote:
> Greg  writes:
> 
> >> I am dubious about distinguishing between lists and vectors. Currently,
> >> as far as I can tell, the ns is agnostic, and only cares about them
> >> being sequential. This is probably one of the sources of confusion for
> >> beginners -- they see both and don't see why
> >
> > The reason for distinguishing between lists and vectors is as you say, it's
> > confusing for beginnings. Also, it allows the syntax to have greater
> > functionality/power.
> 
> Really dubious about this. Having to keep in my head when I need to use
> [] and when I need to use () is a significant problem when starting. It
> was my realisation that for the ns declaration you don't that made
> things easier.
> 
> >> Also, I am confused as to how you distinguish between
> >> [core [matrix math bs]] being equivalent to :use while
> >> Is [one reload middleware] also :use? Or :require?
> >
> > Nested vectors = :use.
> >
> > Thus, as the comment says, [core [matrix math bs]] => (:use (core matrix 
> > math
> > bs))
> >
> > It's a bit confusing in the current syntax (if I have it correct), because
> > from it, it's not clear why "core" isn't "used".
> >
> > [one reload middleware]
> >
> > Is equivalent to:
> >
> > (:require [one.reload :as reload]
> >   [one.middleware :as middleware])
> 
> Scares me to be honest. You now have an implicit alias ":as reload", and
> are distinguishing between having an alias and having no qualification
> by nesting or otherwise.
> 
> I do like the idea of enforcing nesting though in
> 
> [core [matrix math bs]]
> 
> Phil
> 
> --
> --
> 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.c

Re: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

>> I just view that as yet another reason to change the syntax.

You're going to have to prove the new syntax better, because now you have
to justify it in the face of breaking existing code.


>>I think part of the problem here is that I'm not very well educated on
this topic yet. Perhaps you can help:

>> - If you defined a protocol Foo in user, is it referenced as user.Foo
from another ns, or user/Foo ? Or both??

user.Foo is the interface defined by the protocol, user/Foo is the protocol
information

>> - Can you have a function Foo at the same time as a protocol Foo in the
same namespace?

No.

>> - What about records? Can you have a record Foo and a protocol Foo?

No

>> - Can you have a class Foo and an protocol Foo?

Yes

Clojure and I are already confused here:

baz=> (defprotocol g (dostuff [this]))
g
baz=> g
{:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists
([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff},
:method-builders {#'baz/dostuff #}}
baz=> (defn g [] "a")
#'baz/g
baz=> g
#

You can't get the protocol back it's been redefined. However the interface
baz.g still exists.

The problem is that you are confusing Java classes with Clojure Namespaces.
Clojure defines namespaces where it keeps vars (see Namespace.java in the
clojure source). So creating a protocol in Clojure does two things. 1) it
creates a java interface with the name of the protocol. 2) it defines a
hashmap assigned to a var in a Clojure namespace that describes how to find
that interface.

This is why I go back to my original comments. You are taking two
completely different concepts (interacting with Java classes, and
interacting with Clojure namespaces) and smashing them together in an
arbitrary syntax. I would assert that this is a very bad idea.

Instead let's keep separate things separate. The fact that we have Java
classes and Clojure namespaces is a fact of life when programming Clojure.
We should be educating users about the differences instead of hiding it
behind custom syntax.

Timothy


On Tue, Aug 6, 2013 at 10:41 AM, Greg  wrote:

> > It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
>
> Wow that's confusing!
>
> I just view that as yet another reason to change the syntax.
>
> To answer your question though, I'd do both syntax's a favor and interpret
> "[require [clojure.string :as c]]" using the new syntax. It would save a
> lot of newbies many headaches. Think of the newbies.
>
> > Yeah, there's a bug in the code, but let me try to redefine the problem.
> Assume I have a namespace called foo that defines a protocol (and hence an
> interface) called bar. I then also have a namespace called foo.bar. How do
> I tell the new syntax to import each? If I simply say "go get foo.bar" what
> are you going to load, the .clj file, or the java interface?
>
> I think part of the problem here is that I'm not very well educated on
> this topic yet. Perhaps you can help:
>
> - If you defined a protocol Foo in user, is it referenced as user.Foo from
> another ns, or user/Foo ? Or both??
>
> - Can you have a function Foo at the same time as a protocol Foo in the
> same namespace?
>
> - What about records? Can you have a record Foo and a protocol Foo?
>
> - Can you have a class Foo and an protocol Foo?
>
> Clojure and I are already confused here:
>
> baz=> (defprotocol g (dostuff [this]))
> g
> baz=> g
> {:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists
> ([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff},
> :method-builders {#'baz/dostuff # baz$eval300$fn__301@7c2aa00c>}}
> baz=> (defn g [] "a")
> #'baz/g
> baz=> g
> #
>
> And I'm not sure how to get the protocol back...
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 6, 2013, at 11:43 AM, Timothy Baldridge 
> wrote:
>
> >> >> (ns foo
> >> >>  [require [clojure.string :as c]])
> >
> > >> I've never seen that before. What does it do?
> >
> > It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
> >
> >
> > Yeah, there's a bug in the code, but let me try to redefine the problem.
> Assume I have a namespace called foo that defines a protocol (and hence an
> interface) called bar. I then also have a namespace called foo.bar. How do
> I tell the new syntax to import each? If I simply say "go get foo.bar" what
> are you going to load, the .clj file, or the java interface?
> >
> > Timothy
> >
> >
> > On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord <
> phillip.l...@newcastle.ac.uk> wrote:
> > Greg  writes:
> >
> > >> I am dubious about disting

Re: [Proposal] Simplified 'ns' declaration

[Greg]

>> Yeah, there's a bug in the code, but let me try to redefine the problem. 
>> Assume I have a namespace called foo that defines a protocol (and hence an 
>> interface) called bar. I then also have a namespace called foo.bar. How do I 
>> tell the new syntax to import each? If I simply say "go get foo.bar" what 
>> are you going to load, the .clj file, or the java interface?

It would also help to have an example of how it's currently done.

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 6, 2013, at 12:41 PM, Greg  wrote:

>> It's exactly the same as a normal require. Ns allows vectors/seqs 
>> symbols/keywords to be used interchangeably. Some people use (:require) 
>> others use (require), ns just uses ns/namespace to get the data on the first 
>> of each item after the symbol. 
> 
> Wow that's confusing!
> 
> I just view that as yet another reason to change the syntax.
> 
> To answer your question though, I'd do both syntax's a favor and interpret 
> "[require [clojure.string :as c]]" using the new syntax. It would save a lot 
> of newbies many headaches. Think of the newbies.
> 
>> Yeah, there's a bug in the code, but let me try to redefine the problem. 
>> Assume I have a namespace called foo that defines a protocol (and hence an 
>> interface) called bar. I then also have a namespace called foo.bar. How do I 
>> tell the new syntax to import each? If I simply say "go get foo.bar" what 
>> are you going to load, the .clj file, or the java interface?
> 
> I think part of the problem here is that I'm not very well educated on this 
> topic yet. Perhaps you can help:
> 
> - If you defined a protocol Foo in user, is it referenced as user.Foo from 
> another ns, or user/Foo ? Or both??
> 
> - Can you have a function Foo at the same time as a protocol Foo in the same 
> namespace?
> 
> - What about records? Can you have a record Foo and a protocol Foo?
> 
> - Can you have a class Foo and an protocol Foo?
> 
> Clojure and I are already confused here:
> 
> baz=> (defprotocol g (dostuff [this]))
> g
> baz=> g
> {:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists 
> ([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff}, 
> :method-builders {#'baz/dostuff # baz$eval300$fn__301@7c2aa00c>}}
> baz=> (defn g [] "a")
> #'baz/g
> baz=> g
> #
> 
> And I'm not sure how to get the protocol back...
> 
> - Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Aug 6, 2013, at 11:43 AM, Timothy Baldridge  wrote:
> 
> (ns foo 
> [require [clojure.string :as c]])
>> 
 I've never seen that before. What does it do?
>> 
>> It's exactly the same as a normal require. Ns allows vectors/seqs 
>> symbols/keywords to be used interchangeably. Some people use (:require) 
>> others use (require), ns just uses ns/namespace to get the data on the first 
>> of each item after the symbol. 
>> 
>> 
>> Yeah, there's a bug in the code, but let me try to redefine the problem. 
>> Assume I have a namespace called foo that defines a protocol (and hence an 
>> interface) called bar. I then also have a namespace called foo.bar. How do I 
>> tell the new syntax to import each? If I simply say "go get foo.bar" what 
>> are you going to load, the .clj file, or the java interface?
>> 
>> Timothy
>> 
>> 
>> On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord  
>> wrote:
>> Greg  writes:
>> 
 I am dubious about distinguishing between lists and vectors. Currently,
 as far as I can tell, the ns is agnostic, and only cares about them
 being sequential. This is probably one of the sources of confusion for
 beginners -- they see both and don't see why
>>> 
>>> The reason for distinguishing between lists and vectors is as you say, it's
>>> confusing for beginnings. Also, it allows the syntax to have greater
>>> functionality/power.
>> 
>> Really dubious about this. Having to keep in my head when I need to use
>> [] and when I need to use () is a significant problem when starting. It
>> was my realisation that for the ns declaration you don't that made
>> things easier.
>> 
 Also, I am confused as to how you distinguish between
 [core [matrix math bs]] being equivalent to :use while
 Is [one reload middleware] also :use? Or :require?
>>> 
>>> Nested vectors = :use.
>>> 
>>> Thus, as the comment says, [core [matrix math bs]] => (:use (core matrix 
>>> math
>>> bs))
>>> 
>>> It's a bit confusing in the current syntax (if I have it correct), because
>>> from it, it's not clear why "core" isn't "used".
>>> 
>>> [one reload middleware]
>>> 
>>> Is equivalent to:
>>> 
>>> (:require [one.reload :as reload]
>>>  [one.middleware :as middleware])
>> 
>> Scares me to be honest. You now have an implicit alias ":as reload", and
>> are distinguishing between having an alias and having no qualification
>> by nesting or otherwise.
>> 
>> I do like the idea of enforcing nesting though

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

[Nelson Morris]

It might be a version range somewhere.  `lein deps :tree` in lein 2.2.0
should show the path to it.  If it doesn't please let me know


On Tue, Aug 6, 2013 at 11:32 AM, Zach Oakes  wrote:

> Thanks! It seems to work well so far in Nightcode. I noticed it pulled
> down a bunch of older versions of Clojure, but I'm guessing that's because
> you're using a SNAPSHOT version of seesaw in it? Also, I was wondering if
> the other library you use (org.kovas/paredit.clj) was available anywhere --
> I couldn't find it on your Github.
>
>
> On Monday, August 5, 2013 11:52:24 PM UTC-4, kovasb wrote:
>
>> 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 text with every
>> paredit command execution. This might be an issue for big files, but is
>> fixable.
>>
>>
>> On Mon, Aug 5, 2013 at 7:51 PM, Zach Oakes  wrote:
>> >
>> > 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 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/**groups/opt_out
>> .
>> >
>> >
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Interest in a commercial IDE for Clojure?

[ngieschen]

I would absolutely pay for something like this.

On Sunday, July 28, 2013 8:34:19 PM UTC-7, Colin Fleming wrote:
>
> Thanks for the thoughts, Matt - I agree it's a tough market for all the 
> reasons you describe. It's unfortunate that companies that pay for an 
> Ultimate license would have to pay again for this when the 
> JetBrains-developed extra languages (Python, Ruby) come for free. There's 
> not much to be done unfortunately except just be better than everyone else 
> :-)
>
>
> On 29 July 2013 09:07, Matt Hoffman >wrote:
>
>> I've been watching your fork on Github for a while -- I've been excited 
>> to see that someone is actively working on La Clojure. I would pay for an 
>> IntelliJ plugin that was significantly better than La Clojure, but I'm also 
>> aware that I'd be paying just for my preference of IntelliJ over Eclipse 
>> for mixed Java/Clojure development. For pure Clojure development, Emacs 
>> would also be a contender. So that would be a really tough market. 
>> It would be a tough sell for my company, as well. They pay for IntelliJ 
>> Ultimate licenses, and if we told them we wanted to add in $200 more for a 
>> Clojure plugin, I'd have to be prepared to re-open the "just use Eclipse" 
>> argument. 
>>
>> I'd also contribute to a Kickstarter, if you decided to go that route. I 
>> don't imagine you could make a living off of it that way, but you might be 
>> able to recoup some of your time.  A couple of developers in my company 
>> have talked about funding a bounty for nrepl integration alone. 
>>
>>
>>
>> On Sat, Jul 27, 2013 at 3:20 PM, kovas boguta 
>> 
>> > wrote:
>>
>>> My suggestion: release as open source, and then try a kickstarter to see 
>>> if there is interest in extending/continuing the project.
>>>
>>> IDE is a tough business. It has broken many. After all there is a reason 
>>> intellij open-sourced the core in the first place.
>>>
>>> Frankly I think there is a bigger market in using clojure to develop 
>>> better tools for other languages. If you have a nice intellij wrapper, then 
>>> you have a huge advantage in developing tooling in general. 
>>>
>>> On a side note, I would love to see intellij's widget library broken out 
>>> in a more stand-alone way, so we can develop sexy clojure apps with pure 
>>> jvm technology. Any thoughts on if that is technically doable?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Jul 27, 2013 at 4:54 AM, Colin Fleming 
>>> 
>>> > wrote:
>>>
 Hi all,

 I was planning to wait a little longer before going public, but since 
 it's pretty relevant to the other IntelliJ thread going on at the moment I 
 thought I'd jump in. For the last couple of months of happy unemployment 
 I've been working on a fork of La Clojure which is now about 70% migrated 
 to Clojure and significantly improved. It's a lot of work to develop a 
 tool 
 like this, and one of the options I'm considering is starting a company to 
 develop it as a commercial product - JetBrains have never maintained 
 development of La Clojure very actively. I've been doing a little market 
 research but there's really not much data around about whether there are 
 enough people working with Clojure to sustain a product like that, and 
 also 
 the community is currently very focused on open source.

 One problem is that the IDE space is already fairly fractured - there's 
 Emacs and CCW, Clooj, Sublime Text and the promise of Light Table at some 
 point, and of course the current public version of La Clojure. But there's 
 still not a great option for something that's powerful but easy to use - 
 CCW is probably the closest thing to this right now. However I think it's 
 telling that a large fraction of people in the State of Clojure 2012 
 survey 
 still identified development tools as a major pain point.

 I think that the IntelliJ platform is a fantastic base to build 
 something like this on. Clojure as a language makes it pretty challenging 
 to develop a lot of the great functionality that JetBrains are famous for, 
 but I think there's scope to do a lot of great things. Certainly for mixed 
 Clojure/Java projects it would be difficult to beat, but even for Clojure 
 only projects I can imagine a lot of fantastic functionality built on 
 their 
 infrastructure. My plan would be to release a standalone IDE and a plugin 
 for people using IntelliJ Ultimate for web dev, Ruby/Python or whatever. 
 Since it's mostly Clojure now (and I'm migrating what's left as I get to 
 it) there's a real possibility of a Clojure plugin/extension API. I 
 envision charging PyCharm/RubyMine type prices, say $200 for company 
 licenses or $100 for individual developers.

 So, I'd love to hear what people think. I'd appreciate it if we could 
 stay away from the politics of open source vs proprietary - several people 
 have told me priva

Re: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

Sure, put this into a repl:

(ns foo)

(defprotocol IBar
  (do-stuff [this]))

(ns user
  (require [foo])
  (import [foo IBar]))

(class foo/IBar)
(class foo.IBar)


If this syntax were unified into something like you suggest we have a
problem:

(ns user
  [foo IBar]) ;; What is IBar, a class or a var?

Timothy


On Tue, Aug 6, 2013 at 10:56 AM, Greg  wrote:

> >> Yeah, there's a bug in the code, but let me try to redefine the
> problem. Assume I have a namespace called foo that defines a protocol (and
> hence an interface) called bar. I then also have a namespace called
> foo.bar. How do I tell the new syntax to import each? If I simply say "go
> get foo.bar" what are you going to load, the .clj file, or the java
> interface?
>
> It would also help to have an example of how it's currently done.
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 6, 2013, at 12:41 PM, Greg  wrote:
>
> >> It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
> >
> > Wow that's confusing!
> >
> > I just view that as yet another reason to change the syntax.
> >
> > To answer your question though, I'd do both syntax's a favor and
> interpret "[require [clojure.string :as c]]" using the new syntax. It would
> save a lot of newbies many headaches. Think of the newbies.
> >
> >> Yeah, there's a bug in the code, but let me try to redefine the
> problem. Assume I have a namespace called foo that defines a protocol (and
> hence an interface) called bar. I then also have a namespace called
> foo.bar. How do I tell the new syntax to import each? If I simply say "go
> get foo.bar" what are you going to load, the .clj file, or the java
> interface?
> >
> > I think part of the problem here is that I'm not very well educated on
> this topic yet. Perhaps you can help:
> >
> > - If you defined a protocol Foo in user, is it referenced as user.Foo
> from another ns, or user/Foo ? Or both??
> >
> > - Can you have a function Foo at the same time as a protocol Foo in the
> same namespace?
> >
> > - What about records? Can you have a record Foo and a protocol Foo?
> >
> > - Can you have a class Foo and an protocol Foo?
> >
> > Clojure and I are already confused here:
> >
> > baz=> (defprotocol g (dostuff [this]))
> > g
> > baz=> g
> > {:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists
> ([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff},
> :method-builders {#'baz/dostuff # baz$eval300$fn__301@7c2aa00c>}}
> > baz=> (defn g [] "a")
> > #'baz/g
> > baz=> g
> > #
> >
> > And I'm not sure how to get the protocol back...
> >
> > - Greg
> >
> > --
> > Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >
> > On Aug 6, 2013, at 11:43 AM, Timothy Baldridge 
> wrote:
> >
> > (ns foo
> > [require [clojure.string :as c]])
> >>
>  I've never seen that before. What does it do?
> >>
> >> It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
> >>
> >>
> >> Yeah, there's a bug in the code, but let me try to redefine the
> problem. Assume I have a namespace called foo that defines a protocol (and
> hence an interface) called bar. I then also have a namespace called
> foo.bar. How do I tell the new syntax to import each? If I simply say "go
> get foo.bar" what are you going to load, the .clj file, or the java
> interface?
> >>
> >> Timothy
> >>
> >>
> >> On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord <
> phillip.l...@newcastle.ac.uk> wrote:
> >> Greg  writes:
> >>
>  I am dubious about distinguishing between lists and vectors.
> Currently,
>  as far as I can tell, the ns is agnostic, and only cares about them
>  being sequential. This is probably one of the sources of confusion for
>  beginners -- they see both and don't see why
> >>>
> >>> The reason for distinguishing between lists and vectors is as you say,
> it's
> >>> confusing for beginnings. Also, it allows the syntax to have greater
> >>> functionality/power.
> >>
> >> Really dubious about this. Having to keep in my head when I need to use
> >> [] and when I need to use () is a significant problem when starting. It
> >> was my realisation that for the ns declaration you don't that made
> >> things easier.
> >>
>  Also, I am confused as to how you distinguish between
>  [core [matrix math bs]] being equivalent to :use while
>  Is [one reload middleware] also :use? Or :require?
> >>>
> >>> Nested vectors = :use.
> >>>
> >>> Thus, as the comment says, [core [matrix math bs]] => (:use (core
> matrix math
> >>> bs))
> >>>
> >>> It's a bit 

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

[Zach Oakes]

Yeah that's what it is:

WARNING!!! version ranges found for:
[org.kovas/paredit-widget "0.1.1-SNAPSHOT"] -> [org.kovas/paredit.clj 
"0.20.1-SNAPSHOT"] -> [net.cgrand/parsley "0.9.2"] -> [net.cgrand/regex 
"1.1.0"] -> [org.clojure/clojure "[1.2.0,)"]

I guess my only remaining question is whether the paredit.clj library is 
available somewhere, so I can take a quick look.

On Tuesday, August 6, 2013 1:01:43 PM UTC-4, Nelson Morris wrote:
>
> It might be a version range somewhere.  `lein deps :tree` in lein 2.2.0 
> should show the path to it.  If it doesn't please let me know
>
>
> On Tue, Aug 6, 2013 at 11:32 AM, Zach Oakes 
> > wrote:
>
>> Thanks! It seems to work well so far in Nightcode. I noticed it pulled 
>> down a bunch of older versions of Clojure, but I'm guessing that's because 
>> you're using a SNAPSHOT version of seesaw in it? Also, I was wondering if 
>> the other library you use (org.kovas/paredit.clj) was available anywhere -- 
>> I couldn't find it on your Github.
>>
>>
>> On Monday, August 5, 2013 11:52:24 PM UTC-4, kovasb wrote:
>>
>>> 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 text with every 
>>> paredit command execution. This might be an issue for big files, but is 
>>> fixable. 
>>>
>>>
>>> On Mon, Aug 5, 2013 at 7:51 PM, Zach Oakes  wrote:
>>> >
>>> > 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 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/**groups/opt_out
>>> .
>>> >
>>> >
>>>
>>  -- 
>> -- 
>> 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/groups/opt_out.
>>  
>>  
>>
>
>

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

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

[Arie van Wingerden]

Zach,
sorry for my late reply.
It seems that 0.0.4 indeed solves the problem with "run repl"!
Thx very much,
   Arie


2013/8/6 Marcus Blankenship 

> Hey Zach,
>
> First, this is awesome.  Really.  Awesome.  ;-)
>
> Second, you should put an email sign-up on this page, so folks can be
> notified when you update it, or when you have other cool things to say.
>  Anyone that builds this kind of product probably has other cool things to
> say, and I would want to hear them.
>
> Just my $0.02.
> Marcus
>
>
> On Aug 5, 2013, at 8:42 PM, Zach Oakes  wrote:
>
> 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 attempt to add Leiningen integration to Clooj, but eventually I decided
>> to start a new project from scratch. It is very alpha-quality, so please be
>> gentle:
>>
>> http://nightcode.info/
>>
>> Here’s what it has:
>>
>> -Written in Clojure (the UI is written with seesaw)
>> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>> -Built-in templates for several common types of Clojure and Java projects
>> -Always-on REPL in the corner to try Clojure commands
>> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>> -ClojureScript integration (includes the lein-cljsbuild plugin)
>> -Cool looking dark theme, because that’s trendy these days
>>
>> Here’s what it’s missing:
>>
>> -Fast build times (it launches Leiningen in a separate process, which is
>> slw...I plan on fixing this and would love any help)
>> -Important editing features (code completion, text replace, etc)
>> -Quick switching between recent files
>> -Jump to definition, built-in documentation
>> -Integration between editor and REPL (eval form or entire file)
>> -Integration with git
>> -Many other things -- please give me your thoughts!
>>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> MARCUS BLANKENSHIP
> \\\ Owner, Problem Solver, Thinker
> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: [Proposal] Simplified 'ns' declaration

[Greg]

> If this syntax were unified into something like you suggest we have a problem:
> 
> (ns user
>   [foo IBar]) ;; What is IBar, a class or a var?

Look what happens after we also do this:

foo=> (defn IBar [] "a")
#'foo/IBar
foo=> (ns user)
nil
user=> (class foo.IBar)
java.lang.Class
user=> (class foo/IBar)
foo$IBar

Now foo/IBar refers to the function, so my understanding is that interfaces are 
bound to vars just like functions.

So, to answer your question:

> (ns user
>   [foo IBar]) ;; What is IBar, a class or a var?


IBar is a class, it's the same as an import statement.

If you want the var, do either:

(ns user [foo])
foo/IBar

Or, if you want to refer the protocol so that you don't have to qualify it as 
above, simply do this:

(ns user [foo (IBar)])

It's the same thing as writing this at a REPL:

(require '[foo :refer (IBar)])

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Aug 6, 2013, at 1:09 PM, Timothy Baldridge  wrote:

> Sure, put this into a repl:
> 
> (ns foo)
> 
> (defprotocol IBar
>   (do-stuff [this]))
> 
> (ns user
>   (require [foo])
>   (import [foo IBar]))
> 
> (class foo/IBar)
> (class foo.IBar)
> 
> 
> If this syntax were unified into something like you suggest we have a problem:
> 
> (ns user
>   [foo IBar]) ;; What is IBar, a class or a var?
> 
> Timothy
> 
> 
> On Tue, Aug 6, 2013 at 10:56 AM, Greg  wrote:
> >> Yeah, there's a bug in the code, but let me try to redefine the problem. 
> >> Assume I have a namespace called foo that defines a protocol (and hence an 
> >> interface) called bar. I then also have a namespace called foo.bar. How do 
> >> I tell the new syntax to import each? If I simply say "go get foo.bar" 
> >> what are you going to load, the .clj file, or the java interface?
> 
> It would also help to have an example of how it's currently done.
> 
> - Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Aug 6, 2013, at 12:41 PM, Greg  wrote:
> 
> >> It's exactly the same as a normal require. Ns allows vectors/seqs 
> >> symbols/keywords to be used interchangeably. Some people use (:require) 
> >> others use (require), ns just uses ns/namespace to get the data on the 
> >> first of each item after the symbol.
> >
> > Wow that's confusing!
> >
> > I just view that as yet another reason to change the syntax.
> >
> > To answer your question though, I'd do both syntax's a favor and interpret 
> > "[require [clojure.string :as c]]" using the new syntax. It would save a 
> > lot of newbies many headaches. Think of the newbies.
> >
> >> Yeah, there's a bug in the code, but let me try to redefine the problem. 
> >> Assume I have a namespace called foo that defines a protocol (and hence an 
> >> interface) called bar. I then also have a namespace called foo.bar. How do 
> >> I tell the new syntax to import each? If I simply say "go get foo.bar" 
> >> what are you going to load, the .clj file, or the java interface?
> >
> > I think part of the problem here is that I'm not very well educated on this 
> > topic yet. Perhaps you can help:
> >
> > - If you defined a protocol Foo in user, is it referenced as user.Foo from 
> > another ns, or user/Foo ? Or both??
> >
> > - Can you have a function Foo at the same time as a protocol Foo in the 
> > same namespace?
> >
> > - What about records? Can you have a record Foo and a protocol Foo?
> >
> > - Can you have a class Foo and an protocol Foo?
> >
> > Clojure and I are already confused here:
> >
> > baz=> (defprotocol g (dostuff [this]))
> > g
> > baz=> g
> > {:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists 
> > ([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff}, 
> > :method-builders {#'baz/dostuff # > baz$eval300$fn__301@7c2aa00c>}}
> > baz=> (defn g [] "a")
> > #'baz/g
> > baz=> g
> > #
> >
> > And I'm not sure how to get the protocol back...
> >
> > - Greg
> >
> > --
> > Please do not email me anything that you are not comfortable also sharing 
> > with the NSA.
> >
> > On Aug 6, 2013, at 11:43 AM, Timothy Baldridge  wrote:
> >
> > (ns foo
> > [require [clojure.string :as c]])
> >>
>  I've never seen that before. What does it do?
> >>
> >> It's exactly the same as a normal require. Ns allows vectors/seqs 
> >> symbols/keywords to be used interchangeably. Some people use (:require) 
> >> others use (require), ns just uses ns/namespace to get the data on the 
> >> first of each item after the symbol.
> >>
> >>
> >> Yeah, there's a bug in the code, but let me try to redefine the problem. 
> >> Assume I have a namespace called foo that defines a protocol (and hence an 
> >> interface) called bar. I then also have a namespace called foo.bar. How do 
> >> I tell the new syntax to import each? If I simply say "go get foo.bar" 
> >> what are you going to load, the .clj file, or the java interface?
> >>
> >> Timothy
> >>
> >>
> >> On Tue, Aug 6, 2013 at 9:39 AM, Phi

Re: [Proposal] Simplified 'ns' declaration

[Jonathan Fischer Friberg]

If there was one thing I would deprecate it's that the first element of
the vector is special.
I find the fact that these two:
(ns bob [:require [tawny owl reasoner]])
(ns john [:require [tawny.owl reasoner]])
are totally different, very confusing.


That feature is very important to me. It's super tedious in java to write
out the whole package for every class that you want to import.

The current version of the proposal is a bit too much I feel, it's
simplified to a point where it's actually more complicated to use. Mostly
because of the difference between ( and [.

(ns foo
  [require [clojure.string :as c]])


Is anyone actually using that? I've never ever seen it used that way. It
wouldn't be terribly hard to support that anyway. Just check if: the first
element is a keyword, or, it's the symbol require or use etc. Of course it
wouldn't work if you have a namespace named require, but I don't think
that's a good idea anyway.

Jonathan

On Tue, Aug 6, 2013 at 6:41 PM, Greg  wrote:

> > It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
>
> Wow that's confusing!
>
> I just view that as yet another reason to change the syntax.
>
> To answer your question though, I'd do both syntax's a favor and interpret
> "[require [clojure.string :as c]]" using the new syntax. It would save a
> lot of newbies many headaches. Think of the newbies.
>
> > Yeah, there's a bug in the code, but let me try to redefine the problem.
> Assume I have a namespace called foo that defines a protocol (and hence an
> interface) called bar. I then also have a namespace called foo.bar. How do
> I tell the new syntax to import each? If I simply say "go get foo.bar" what
> are you going to load, the .clj file, or the java interface?
>
> I think part of the problem here is that I'm not very well educated on
> this topic yet. Perhaps you can help:
>
> - If you defined a protocol Foo in user, is it referenced as user.Foo from
> another ns, or user/Foo ? Or both??
>
> - Can you have a function Foo at the same time as a protocol Foo in the
> same namespace?
>
> - What about records? Can you have a record Foo and a protocol Foo?
>
> - Can you have a class Foo and an protocol Foo?
>
> Clojure and I are already confused here:
>
> baz=> (defprotocol g (dostuff [this]))
> g
> baz=> g
> {:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists
> ([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff},
> :method-builders {#'baz/dostuff # baz$eval300$fn__301@7c2aa00c>}}
> baz=> (defn g [] "a")
> #'baz/g
> baz=> g
> #
>
> And I'm not sure how to get the protocol back...
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 6, 2013, at 11:43 AM, Timothy Baldridge 
> wrote:
>
> >> >> (ns foo
> >> >>  [require [clojure.string :as c]])
> >
> > >> I've never seen that before. What does it do?
> >
> > It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
> >
> >
> > Yeah, there's a bug in the code, but let me try to redefine the problem.
> Assume I have a namespace called foo that defines a protocol (and hence an
> interface) called bar. I then also have a namespace called foo.bar. How do
> I tell the new syntax to import each? If I simply say "go get foo.bar" what
> are you going to load, the .clj file, or the java interface?
> >
> > Timothy
> >
> >
> > On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord <
> phillip.l...@newcastle.ac.uk> wrote:
> > Greg  writes:
> >
> > >> I am dubious about distinguishing between lists and vectors.
> Currently,
> > >> as far as I can tell, the ns is agnostic, and only cares about them
> > >> being sequential. This is probably one of the sources of confusion for
> > >> beginners -- they see both and don't see why
> > >
> > > The reason for distinguishing between lists and vectors is as you say,
> it's
> > > confusing for beginnings. Also, it allows the syntax to have greater
> > > functionality/power.
> >
> > Really dubious about this. Having to keep in my head when I need to use
> > [] and when I need to use () is a significant problem when starting. It
> > was my realisation that for the ns declaration you don't that made
> > things easier.
> >
> > >> Also, I am confused as to how you distinguish between
> > >> [core [matrix math bs]] being equivalent to :use while
> > >> Is [one reload middleware] also :use? Or :require?
> > >
> > > Nested vectors = :use.
> > >
> > > Thus, as the comment says, [core [matrix math bs]] => (:use (core
> matrix math
> > > bs))
> > >
> > > It's a bit confusing in the current syntax (if I have it correct),
> because
>

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

[kovas boguta]

I got it from

https://github.com/laurentpetit/ccw/tree/master/paredit.clj

I had to make a change to bump the parsley version




On Tue, Aug 6, 2013 at 10:14 AM, Zach Oakes  wrote:

> Yeah that's what it is:
>
> WARNING!!! version ranges found for:
> [org.kovas/paredit-widget "0.1.1-SNAPSHOT"] -> [org.kovas/paredit.clj
> "0.20.1-SNAPSHOT"] -> [net.cgrand/parsley "0.9.2"] -> [net.cgrand/regex
> "1.1.0"] -> [org.clojure/clojure "[1.2.0,)"]
>
> I guess my only remaining question is whether the paredit.clj library is
> available somewhere, so I can take a quick look.
>
> On Tuesday, August 6, 2013 1:01:43 PM UTC-4, Nelson Morris wrote:
>
>> It might be a version range somewhere.  `lein deps :tree` in lein 2.2.0
>> should show the path to it.  If it doesn't please let me know
>>
>>
>> On Tue, Aug 6, 2013 at 11:32 AM, Zach Oakes  wrote:
>>
>>> Thanks! It seems to work well so far in Nightcode. I noticed it pulled
>>> down a bunch of older versions of Clojure, but I'm guessing that's because
>>> you're using a SNAPSHOT version of seesaw in it? Also, I was wondering if
>>> the other library you use (org.kovas/paredit.clj) was available anywhere --
>>> I couldn't find it on your Github.
>>>
>>>
>>> On Monday, August 5, 2013 11:52:24 PM UTC-4, kovasb wrote:
>>>
 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 text with every
 paredit command execution. This might be an issue for big files, but is
 fixable.


 On Mon, Aug 5, 2013 at 7:51 PM, Zach Oakes  wrote:
 >
 > 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 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/**grou**ps/opt_out
 .
 >
 >

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

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

Re: [Proposal] Simplified 'ns' declaration

[Sean Corfield]

On Tue, Aug 6, 2013 at 7:51 AM, Greg  wrote:
> (ns one.fresh-server
>   (:refer-clojure :exclude [ancestors printf])
>   (:use core.matrix
> [ring.adapter.jetty :only (run-jetty)]

Except most code I've seen uses (nested) vectors not lists.

> [ring.middleware.file :only (wrap-file)]
> [ring.middleware.file-info :only (wrap-file-info)]
> [ring.middleware.stacktrace :only (wrap-stacktrace)]
> [ring.util.response :only (file-response)])
>   (:require [one.reload :as reload]
> [one.middleware :as middleware]
> [net.cgrand.enlive-html :as html])
>   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
>(java.io File
>
>
> New School:
>
> (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)]
>   [ring.middleware.file ("warp-*")] ; refers all functions beginning with
> "wrap-"
> ; regex not supported because too
> confusing
>   [ring.middleware.file-info (wrap-file-info)]
>   [ring.middleware.stacktrace (wrap-stacktrace)]
>   [ring.util.response (file-response)]
>   [one reload middleware]
>   [net.cgrand enlive-html :as html]
>   [org.apache.maven.artifact.resolver ArtifactResolver]
>   [java.io File InputStream])

Why the arbitrary change from commonly used nested vectors to nested lists?

Given Timothy's protocol example, do you agree that Clojure
namespaces/vars and Java packages/classes need to be treated
differently?

Personally I think your syntax is far more cryptic than the status quo.

In my production code base (~14kloc + 4kloc for tests), we have just
one instance of :refer-clojure so I'd consider that to be a special
edge case that should _not_ be merged into another syntax. We have
four :use's at the moment, all in legacy test code. Everything else is
either :require or :import (and we only have a dozen of those). We use
(:require [... [...]]) and (:import (...)) consistently. It's clear
and easy to understand.

Deprecating (not removing) :use from ns seems reasonable but I really
don't see any value in a new unified syntax - esp. since it would have
to support the legacy syntax for several releases alongside (and then
you'd have to consider whether mixed syntax should be supported -
ugh!).
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

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

[kovas boguta]

On Tue, Aug 6, 2013 at 12:46 AM, Laurent PETIT wrote:

>
>
> Le mardi 6 août 2013, kovas boguta a écrit :
>
> 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-platform issues. (would also love to have rainbow parens :)
>>
>> The bulk of the work is done by Laurent's paredit.clj ; this just
>> provides a thin swing UI wrapper so that one can actually interact with it.
>>
>> The bigger idea is that code editing should be available a la carte.
>>
>
> Nice ! I from the beginning had taken care of separating paredit.clj for
> this exact reason, but never took the time to write the swing component.
> Thanks Kovas!
>
> I'm on holidays so won't be able to work on this during August, but of
> course I'll be more than willing to help where I can when I'm back.
> Probably trying to make the interface more explicit, learn & adapt from
> your feedback, etc.
>

Thanks Laurent! Wouldn't have been possible without your paredit.clj. So
far I've found it very nice to work with.

I'm sure I'll come up with some better suggestions later, but an immediate
issue is that it would be nice to have updated paredit.clj artifacts on
clojars (those artifacts are dated, and right now it seems there are 2
separate repositories for paredit.clj, and they don't work out of the box
due to an easily solved parsley issue)

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

Re: [Proposal] Simplified 'ns' declaration

[Softaddicts]

Enforcing good use through syntax is a bad thing.
"Good use" is a matter of taste. I suspect that your tastes and mines are not in
agreement so please let me express mines as I wish.

I am not against some of the changes you propose but if your goal is to have 
everyone use ns "correctly" according to your understanding and ban anything 
else,
then I stand against your entire proposal.

Clojure proposes various recipes to achieve similar goals. Your spirit seems to
be the opposite.

Since this discussion started there has been confusion between better syntax
versus restricting behaviors. While syntax improvements might be
welcomed, removing features based on things like 'this should never be done
hence allowed' is counter productive and based on a narrow vision.

Someone somewhere is using the features you would ban and find it
useful. Rigidity pair very well with death. Keep this in mind.

Luc P.

> Thanks Timothy for your very thoughtful reply!
> > You bring up some very valid points.
> > > a) How do you plan on having this backwards-compatible with existing 
> > > code? You will have to support both the old and new versions on the same 
> > > Clojure compiler. Notice that this is completely valid in the current 
> > > compiler:
> > > > (ns foo > >   [require [clojure.string :as c]])
> > I've never seen that before. What does it do?
> > Someone else mentioned (I'm sorry, I don't remember who, or whether it was 
> > even in this thread), that you could simply distinguish between lists and 
> > vectors, and if that's not good enough, then distinguishing between 
> > lists/vectors that start with a keyword, and those that don't.
> > > Once again, please notice that your "old school" example could also have 
> > > been written in a much more concise manner: > > > It could have, I agree, 
> > > but its syntax doesn't force you to. This one does. It's always 
> > > "concise", as you say.
> > The example you gave is also still too ambiguous for newcomers to 
> > understand, and contains a lot of unnecessary elements.
> > Ambiguity
> It's not clear from your example why parenthesis are used sometimes and 
> vectors are used in other cases.
> > Unnecessary elements
> > (:require [one.reload :as reload]
>   [one.middleware :as middleware])
> > Versus:
> > [one reload middleware]
> > > With the current design we can clearly distinguish between loading a java 
> > > class, and loading a clojure namespace. > > I'm sorry, I tried running 
> > > your example in a REPL and got:
> > CompilerException java.lang.RuntimeException: Unable to resolve symbol: bar 
> > in this context, compiling:(NO_SOURCE_PATH:0:0)
> > I also tried using definterface instead of defprotocol, but got the same 
> > error.
> > I assume there's some minor error in the example you gave, but let me try 
> > and and address your question anyway: you could either introduce a new 
> > keyword (like :as-class), or use :as to rename them to avoid conflicts. 
> > After all, it's already possible to have conflicts between just two 
> > namespaces if you try to alias them to the same symbol/var.
> > - Greg
> > --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> > On Aug 6, 2013, at 11:14 AM, Timothy Baldridge  wrote:
> > > For this to even have a chance at making it into Clojure you need to 
> > > consider all the edge cases. So I have two questions
> > > > a) How do you plan on having this backwards-compatible with existing 
> > > > code? You will have to support both the old and new versions on the 
> > > > same Clojure compiler. Notice that this is completely valid in the 
> > > > current compiler:
> > > > (ns foo > >   [require [clojure.string :as c]])
> > > > b) You will also need a very concise, clear definition on why the new 
> > > > approach is better. Once again, please notice that your "old school" 
> > > > example could also have been written in a much more concise manner: > > 
> > > > > > (ns one.fresh-server
> >   (:refer-clojure :exclude [ancestors printf])
> >   (:require [one.reload :as reload]
> > [one.middleware :as middleware]
> > [net.cgrand.enlive-html :as html]
> > [ring.adapter.jetty :refer (run-jetty)]
> > [ring.middleware.file :refer (wrap-file)]
> > [ring.middleware.file-info :refer (wrap-file-info)]
> > [ring.middleware.stacktrace :refer (wrap-stacktrace)]
> > [ring.util.response :refer (file-response)])
> >   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
> >(java.io File
> > > > As a support to the current method let me point out the following. We 
> > > > have 3 constructs in this case, each only does one thing:
> > > > a) refer-clojure - allows you to :exclude certain symbols from being 
> > > > imported by default
> > b) require loads clojure namespaces
> > c) import loads Java classes
> > > > Your example also has the following problem:
> > > > bar=> (ns foo

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

[Zach Oakes]

OK thanks, that makes sense. I just pushed the commit that adds it to 
Nightcode so hopefully I'll get some feedback on it for the next release. 
Thanks again.

On Tuesday, August 6, 2013 1:43:57 PM UTC-4, kovasb wrote:
>
> I got it from 
>
> https://github.com/laurentpetit/ccw/tree/master/paredit.clj
>
> I had to make a change to bump the parsley version
>
>
>
>
> On Tue, Aug 6, 2013 at 10:14 AM, Zach Oakes 
> > wrote:
>
>> Yeah that's what it is:
>>
>> WARNING!!! version ranges found for:
>> [org.kovas/paredit-widget "0.1.1-SNAPSHOT"] -> [org.kovas/paredit.clj 
>> "0.20.1-SNAPSHOT"] -> [net.cgrand/parsley "0.9.2"] -> [net.cgrand/regex 
>> "1.1.0"] -> [org.clojure/clojure "[1.2.0,)"]
>>
>> I guess my only remaining question is whether the paredit.clj library is 
>> available somewhere, so I can take a quick look.
>>
>> On Tuesday, August 6, 2013 1:01:43 PM UTC-4, Nelson Morris wrote:
>>
>>> It might be a version range somewhere.  `lein deps :tree` in lein 2.2.0 
>>> should show the path to it.  If it doesn't please let me know
>>>
>>>
>>> On Tue, Aug 6, 2013 at 11:32 AM, Zach Oakes  wrote:
>>>
 Thanks! It seems to work well so far in Nightcode. I noticed it pulled 
 down a bunch of older versions of Clojure, but I'm guessing that's because 
 you're using a SNAPSHOT version of seesaw in it? Also, I was wondering if 
 the other library you use (org.kovas/paredit.clj) was available anywhere 
 -- 
 I couldn't find it on your Github.


 On Monday, August 5, 2013 11:52:24 PM UTC-4, kovasb wrote:

> 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 text with every 
> paredit command execution. This might be an issue for big files, but is 
> fixable. 
>
>
> On Mon, Aug 5, 2013 at 7:51 PM, Zach Oakes  wrote:
> >
> > 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 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/**grou**ps/opt_out
> .
> >
> >
>
  -- 
 -- 
 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/**groups/opt_out
 .
  
  

>>>
>>>  -- 
>> -- 
>> 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/groups/opt_out.
>>  
>>  
>>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Gr

Re: [Proposal] Simplified 'ns' declaration

[Tassilo Horn]

Sean Corfield  writes:

> Deprecating (not removing) :use from ns seems reasonable but I really
> don't see any value in a new unified syntax - esp. since it would have
> to support the legacy syntax for several releases alongside (and then
> you'd have to consider whether mixed syntax should be supported -
> ugh!).

I totally agree with Sean.  Maybe deprecate :use, and keep the rest as
it is.  The current syntax is really not hard, and it's very good that
the keywords map 1-to-1 to the functions of the same name.  Check the
docs for `require`, then you know what `(:require ...)` does.  The same
goes for `use` and `import`.

You don't have that match with the new proposed syntax where you have to
ask yourself "is a vector with nested vector the syntax for `require` or
`import` or whatnot?".  And the only benefit seems to be that it's a bit
more concise in some cases.  I don't care if my ns declaration is 20 or
only 12 lines long.  It should be clear, and that's what the current
syntax achieves.

Bye,
Tassilo

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

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

[kovas boguta]

Cool! I just cloned the repo and tried it out. Seems to work pretty well.



On Tue, Aug 6, 2013 at 11:05 AM, Zach Oakes  wrote:

> OK thanks, that makes sense. I just pushed the commit that adds it to
> Nightcode so hopefully I'll get some feedback on it for the next release.
> Thanks again.
>
>
> On Tuesday, August 6, 2013 1:43:57 PM UTC-4, kovasb wrote:
>
>> I got it from
>>
>> https://github.com/**laurentpetit/ccw/tree/master/**paredit.clj
>>
>> I had to make a change to bump the parsley version
>>
>>
>>
>>
>> On Tue, Aug 6, 2013 at 10:14 AM, Zach Oakes  wrote:
>>
>>> Yeah that's what it is:
>>>
>>> WARNING!!! version ranges found for:
>>> [org.kovas/paredit-widget "0.1.1-SNAPSHOT"] -> [org.kovas/paredit.clj
>>> "0.20.1-SNAPSHOT"] -> [net.cgrand/parsley "0.9.2"] -> [net.cgrand/regex
>>> "1.1.0"] -> [org.clojure/clojure "[1.2.0,)"]
>>>
>>> I guess my only remaining question is whether the paredit.clj library is
>>> available somewhere, so I can take a quick look.
>>>
>>> On Tuesday, August 6, 2013 1:01:43 PM UTC-4, Nelson Morris wrote:
>>>
 It might be a version range somewhere.  `lein deps :tree` in lein 2.2.0
 should show the path to it.  If it doesn't please let me know


 On Tue, Aug 6, 2013 at 11:32 AM, Zach Oakes  wrote:

> Thanks! It seems to work well so far in Nightcode. I noticed it pulled
> down a bunch of older versions of Clojure, but I'm guessing that's because
> you're using a SNAPSHOT version of seesaw in it? Also, I was wondering if
> the other library you use (org.kovas/paredit.clj) was available anywhere 
> --
> I couldn't find it on your Github.
>
>
> On Monday, August 5, 2013 11:52:24 PM UTC-4, kovasb wrote:
>
>> 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 text with every
>> paredit command execution. This might be an issue for big files, but is
>> fixable.
>>
>>
>> On Mon, Aug 5, 2013 at 7:51 PM, Zach Oakes  wrote:
>> >
>> > 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 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/**grou
>> ps/opt_out .
>> >
>> >
>>
>  --
> --
> 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/**grou**ps/opt_out
> .
>
>
>

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

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

[Lee Spector]

On Aug 6, 2013, at 2:15 PM, kovas boguta wrote:

> Cool! I just cloned the repo and tried it out. Seems to work pretty well. 
> 

I just tried it too, mainly to see if there was a way to turn paredit off... 
and I don't see one. Is there one? I really dislike paredit.

Also, is there not a way to evaluate a selected expression in the edit window, 
or am I just missing it? I do think that's an important core feature of Clooj 
and of most Clojure/Lisp IDEs.

 -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/groups/opt_out.

REPL sessions crash Windows

[Steve J]

I am new to Clojure programming and have been running REPL sessions from 
the Command Prompt. At some unpredictable time, either during the session 
or after it is ended, Windows will crash (the computer not responding and 
with a frozen pattern on the screen).  I have tried several things, such as 
turning off the anti-virus, disconnecting from the internet, installing 
earlier versions of Clojure,  downloading without a firewall, and running 
the "slim" jar file.  Is there anything else I might try?  I have a 2 GB, 
32-bit Windows Vista computer, JRE 1.7.0.

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

Re: Interest in a commercial IDE for Clojure?

[ngieschen]

Oh and I'd love to contribute to this too. I didn't see the fork on github. 
If you're open to contribution let me know since I'd love something better 
than la clojure. (I wouldn't care if it ended up commercial.) I'm also 
considering creating some better clojure tools for Intellij, but would 
prefer not to duplicate efforts. 

On Tuesday, August 6, 2013 10:04:27 AM UTC-7, ngieschen wrote:
>
> I would absolutely pay for something like this.
>
> On Sunday, July 28, 2013 8:34:19 PM UTC-7, Colin Fleming wrote:
>>
>> Thanks for the thoughts, Matt - I agree it's a tough market for all the 
>> reasons you describe. It's unfortunate that companies that pay for an 
>> Ultimate license would have to pay again for this when the 
>> JetBrains-developed extra languages (Python, Ruby) come for free. There's 
>> not much to be done unfortunately except just be better than everyone else 
>> :-)
>>
>>
>> On 29 July 2013 09:07, Matt Hoffman  wrote:
>>
>>> I've been watching your fork on Github for a while -- I've been excited 
>>> to see that someone is actively working on La Clojure. I would pay for an 
>>> IntelliJ plugin that was significantly better than La Clojure, but I'm also 
>>> aware that I'd be paying just for my preference of IntelliJ over Eclipse 
>>> for mixed Java/Clojure development. For pure Clojure development, Emacs 
>>> would also be a contender. So that would be a really tough market. 
>>> It would be a tough sell for my company, as well. They pay for IntelliJ 
>>> Ultimate licenses, and if we told them we wanted to add in $200 more for a 
>>> Clojure plugin, I'd have to be prepared to re-open the "just use Eclipse" 
>>> argument. 
>>>
>>> I'd also contribute to a Kickstarter, if you decided to go that route. I 
>>> don't imagine you could make a living off of it that way, but you might be 
>>> able to recoup some of your time.  A couple of developers in my company 
>>> have talked about funding a bounty for nrepl integration alone. 
>>>
>>>
>>>
>>> On Sat, Jul 27, 2013 at 3:20 PM, kovas boguta wrote:
>>>
 My suggestion: release as open source, and then try a kickstarter to 
 see if there is interest in extending/continuing the project.

 IDE is a tough business. It has broken many. After all there is a 
 reason intellij open-sourced the core in the first place.

 Frankly I think there is a bigger market in using clojure to develop 
 better tools for other languages. If you have a nice intellij wrapper, 
 then 
 you have a huge advantage in developing tooling in general. 

 On a side note, I would love to see intellij's widget library broken 
 out in a more stand-alone way, so we can develop sexy clojure apps with 
 pure jvm technology. Any thoughts on if that is technically doable?







 On Sat, Jul 27, 2013 at 4:54 AM, Colin Fleming 
 wrote:

> Hi all,
>
> I was planning to wait a little longer before going public, but since 
> it's pretty relevant to the other IntelliJ thread going on at the moment 
> I 
> thought I'd jump in. For the last couple of months of happy unemployment 
> I've been working on a fork of La Clojure which is now about 70% migrated 
> to Clojure and significantly improved. It's a lot of work to develop a 
> tool 
> like this, and one of the options I'm considering is starting a company 
> to 
> develop it as a commercial product - JetBrains have never maintained 
> development of La Clojure very actively. I've been doing a little market 
> research but there's really not much data around about whether there are 
> enough people working with Clojure to sustain a product like that, and 
> also 
> the community is currently very focused on open source.
>
> One problem is that the IDE space is already fairly fractured - 
> there's Emacs and CCW, Clooj, Sublime Text and the promise of Light Table 
> at some point, and of course the current public version of La Clojure. 
> But 
> there's still not a great option for something that's powerful but easy 
> to 
> use - CCW is probably the closest thing to this right now. However I 
> think 
> it's telling that a large fraction of people in the State of Clojure 2012 
> survey still identified development tools as a major pain point.
>
> I think that the IntelliJ platform is a fantastic base to build 
> something like this on. Clojure as a language makes it pretty challenging 
> to develop a lot of the great functionality that JetBrains are famous 
> for, 
> but I think there's scope to do a lot of great things. Certainly for 
> mixed 
> Clojure/Java projects it would be difficult to beat, but even for Clojure 
> only projects I can imagine a lot of fantastic functionality built on 
> their 
> infrastructure. My plan would be to release a standalone IDE and a plugin 
> for people usin

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

[Zach Oakes]

I'll try adding a way to toggle paredit, but it'll be complicated since I 
will probably have to re-create and re-load all open files, unless 
paredit-widget provides a way to disable paredit from a JTextArea that 
previously had it added. As for evaluating selected expressions, I 
definitely intend on adding that soon.

On Tuesday, August 6, 2013 2:44:51 PM UTC-4, Lee wrote:
>
> On Aug 6, 2013, at 2:15 PM, kovas boguta wrote: 
>
> > Cool! I just cloned the repo and tried it out. Seems to work pretty 
> well. 
> > 
>
> I just tried it too, mainly to see if there was a way to turn paredit 
> off... and I don't see one. Is there one? I really dislike paredit. 
>
> Also, is there not a way to evaluate a selected expression in the edit 
> window, or am I just missing it? I do think that's an important core 
> feature of Clooj and of most Clojure/Lisp IDEs. 
>
>  -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/groups/opt_out.

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

[Jörg Winter]

Hey Zach, great initiative! Keep it going.. much needed toole there!

Just wanted to say that for indenting/reformatting clojure-code, it is 
indeed possible to
use clojure's own "pprint" function.

Unfortunately the official java API.invoke() is only available in clojure 
1.6
But I have used this successfully already, so maybe this can help you 
somewhere.

Best,
Joerg

Am Dienstag, 6. August 2013 05:42:40 UTC+2 schrieb Zach Oakes:
>
> 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 attempt to add Leiningen integration to Clooj, but eventually I decided 
>> to start a new project from scratch. It is very alpha-quality, so please be 
>> gentle:
>>
>> http://nightcode.info/
>>
>> Here’s what it has:
>>
>> -Written in Clojure (the UI is written with seesaw)
>>
>> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>>
>> -Built-in templates for several common types of Clojure and Java projects
>>
>> -Always-on REPL in the corner to try Clojure commands
>>
>> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>>
>> -ClojureScript integration (includes the lein-cljsbuild plugin)
>>
>> -Cool looking dark theme, because that’s trendy these days
>>
>> Here’s what it’s missing:
>>
>> -Fast build times (it launches Leiningen in a separate process, which is 
>> slw...I plan on fixing this and would love any help)
>>
>> -Important editing features (code completion, text replace, etc)
>>
>> -Quick switching between recent files
>>
>> -Jump to definition, built-in documentation
>>
>> -Integration between editor and REPL (eval form or entire file)
>>
>> -Integration with git
>> -Many other things -- please give me your thoughts!
>>
>

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

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

[Lee Spector]

On Aug 6, 2013, at 3:51 PM, Zach Oakes wrote:

> I'll try adding a way to toggle paredit, but it'll be complicated since I 
> will probably have to re-create and re-load all open files, unless 
> paredit-widget provides a way to disable paredit from a JTextArea that 
> previously had it added.

Thanks. FWIW, although I understand the idea and appeal of paredit, and I've 
tried to give a chance many times over many years, it still drives me 
completely nuts. I don't want to go into the pro/con arguments but (again: just 
FWIW as one data point) I wouldn't personally spend any serious amount of time 
in an IDE with mandatory paredit. 

> As for evaluating selected expressions, I definitely intend on adding that 
> soon.

Fabulous.

Thanks so much for working on this!

 -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/groups/opt_out.

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

[kovas boguta]

Its just a matter of removing the event handlers that got added in the
first place.

I'll think about what the best way of exposing those via the api is.

In the meantime feel free to look at the source, its not very complicated
when it gets down to the paredit-widget function.




On Tue, Aug 6, 2013 at 12:51 PM, Zach Oakes  wrote:

> I'll try adding a way to toggle paredit, but it'll be complicated since I
> will probably have to re-create and re-load all open files, unless
> paredit-widget provides a way to disable paredit from a JTextArea that
> previously had it added. As for evaluating selected expressions, I
> definitely intend on adding that soon.
>
>
> On Tuesday, August 6, 2013 2:44:51 PM UTC-4, Lee wrote:
>>
>> On Aug 6, 2013, at 2:15 PM, kovas boguta wrote:
>>
>> > Cool! I just cloned the repo and tried it out. Seems to work pretty
>> well.
>> >
>>
>> I just tried it too, mainly to see if there was a way to turn paredit
>> off... and I don't see one. Is there one? I really dislike paredit.
>>
>> Also, is there not a way to evaluate a selected expression in the edit
>> window, or am I just missing it? I do think that's an important core
>> feature of Clooj and of most Clojure/Lisp IDEs.
>>
>>  -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/groups/opt_out.
>
>
>

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

What are the phases of the Clojure compiler?

[gixxi]

Hi there,

I wanne dive a bit more deep into the clojure compiler and I wonder whether 
it follows the std procedure for compiled languages

Character Stream -> Scanner (lexical analysis) -> Token Stream
Token Stream -> Parser (syntax analysis) -> Parse Tree
Parse Tree -> Semantic Analysis -> Abstract Syntax Tree (AST)
(Optional) AST -> Machine Independent code improvement) -> Modified AST
Modified AST -> Target Code Generation -> Target Language (here Java Byte 
Code)

Thanks for hints and references regarding this topic. Literature on this 
topic (e.g.  O'Reilly Clojure Programming by Emerick, Carper et Grand) 
states that clojure programs are written using clojure datastructures and 
directly represent an AST. But a task of semantic analysis is to check 
whether a statement given in the programming language is valid in terms of 
the programming language semantics. So some component has to check whether 
the symbol foo in the list (foo "baz") denotes either a static function 
applicable to a string literal or a instance function of the string literal 
itself. Which component serves this job?

thanks & cheers

christian

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

Re: What are the phases of the Clojure compiler?

[Kevin Downey]

On 8/6/13 2:23 PM, gixxi wrote:
> Hi there,
> 
> I wanne dive a bit more deep into the clojure compiler and I wonder whether 
> it follows the std procedure for compiled languages
> 
> Character Stream -> Scanner (lexical analysis) -> Token Stream
> Token Stream -> Parser (syntax analysis) -> Parse Tree
> Parse Tree -> Semantic Analysis -> Abstract Syntax Tree (AST)
> (Optional) AST -> Machine Independent code improvement) -> Modified AST
> Modified AST -> Target Code Generation -> Target Language (here Java Byte 
> Code)
> 
> Thanks for hints and references regarding this topic. Literature on this 
> topic (e.g.  O'Reilly Clojure Programming by Emerick, Carper et Grand) 
> states that clojure programs are written using clojure datastructures and 
> directly represent an AST. But a task of semantic analysis is to check 
> whether a statement given in the programming language is valid in terms of 
> the programming language semantics. So some component has to check whether 
> the symbol foo in the list (foo "baz") denotes either a static function 
> applicable to a string literal or a instance function of the string literal 
> itself. Which component serves this job?
> 
> thanks & cheers
> 
> christian
> 

being a lisp with a reader the converting of the character stream to
data structures doesn't happen in the compiler, the compiler's input is
a data structure produced by the reader.

the compiler does:

1. macro expansion
2. analysis
3. code generation

you could argue that macro expansion is just part of analysis (analysis
code calls macroexpand) but I think it is more useful mentally to keep
it as a distinct phase just before analysis.

the clojure compiler is not very complicated and does a pretty straight
forward mapping of clojure expressions to jvm byte code, depending on
the jvm's jit for optimizations.

the compilation unit in clojure is a single top level expression,
however there are some special purpose hooks in the compiler for
compiling a whole source file at a time. those hooks don't really change
anything about the generated code; they change the context the generated
code is emitted in to. the target being jvm byte code you can't just
emit instructions, the instructions have to belong to a method, and the
method has to belong to a class.

there is a meme going around that lisp is its own ast, but if you'd
worked on a compiler and are familiar with the richness of a real ast,
that tends to just seem silly. the clojure compiler does an analysis of
the clojure datastructures and emits a tree of richer expression objects
which is the ast, which the code generator uses to generate bytecode.
the ast objects have methos like emit(...) which is how the code
generation is actually done.

all this being said I don't think anyone is a huge fan of the current
compiler, but it has three huge advantage over alternatives:

1. it works (this might be debatable)
2. it has been in use for many years now
3. and alternative would involve making lots of effort to ultimately get
back to where we are

which is(my opinion) why it still persists.

the clojurescript compiler (which shares no code with the clojure
compiler) could be considered a more modern approach to clojure
complication, but there are important parts of the clojure environment
(vars mainly) that are missing from the clojurescript environment. the
clojurescript compiler has a very rich intermediate representation using
maps. in my opinion the intermediate representation is so rich it is
actually kind of hard to work with.


-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?



signature.asc
Description: OpenPGP digital signature

Is it possible to increase the canvas size of an Incanter chart?

[Tim Visher]

`(view … :width … :height …)` isn't what I want as that doesn't seem
to intrinsically increase the size that incanter thinks it can use to
draw. It more seems to have the effect that scaling the resulting
window has, which is not desirable.

I'm putting a bunch of box and whisker data on a single chart so I'd
like to give it more breathing room.

Thanks in advance!

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

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

Re: Is it possible to increase the canvas size of an Incanter chart?

[Alex Ott]

Hi

basically, if I remember correctly, it should be configured via setPadding
method of JFreeChart class (
http://www.jfree.org/jfreechart/api/javadoc/org/jfree/chart/JFreeChart.html#setPadding%28org.jfree.ui.RectangleInsets%29),
but I haven't checked it.

P.S. for incanter questions it's better to ask in its list - there are more
people there who are working with it more often :-)



On Wed, Aug 7, 2013 at 4:10 AM, Tim Visher  wrote:

> `(view … :width … :height …)` isn't what I want as that doesn't seem
> to intrinsically increase the size that incanter thinks it can use to
> draw. It more seems to have the effect that scaling the resulting
> window has, which is not desirable.
>
> I'm putting a bunch of box and whisker data on a single chart so I'd
> like to give it more breathing room.
>
> Thanks in advance!
>
> --
>
> In Christ,
>
> Timmy V.
>
> http://blog.twonegatives.com/
> http://five.sentenc.es/ -- Spend less time on mail
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
With best wishes,Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott

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