Here's a new syntax that gets rid of everything except for :as and 
:except/:exclude:

(ns two.namespace
  [clojure [core :except (ancestors printf)]]
  [core [matrix math bs]] ; same as (:use (core matrix math bs))
  [[some-ns]] ; same as (:use some-ns)
  [ring.adapter.jetty (run-jetty :as jetty)]
  [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])


There are just four key rules to understand:

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 5, 2013, at 2:31 PM, Jonathan Fischer Friberg <odysso...@gmail.com> 
wrote:

> I forgot to add:
> 
> I think simplicity is really important, and I think one of clojure's strong 
> points are exactly that - simplicity. Simplifying something is not always the 
> right thing to do, but in this case I can't see why it wouldn't. After all, 
> the syntax is almost exactly the same.
> 
> To comment on the message Mark just sent, I don't agree. :)
> I think it's java that is at fault here. I think wildcards should never have 
> been part of java to begin with. The argument here is basically exactly the 
> same as why :use shouldn't be used, so I wont explain it further.
> 
> Jonathan
> 
> On Mon, Aug 5, 2013 at 8:25 PM, Jonathan Fischer Friberg 
> <odysso...@gmail.com> wrote:
> There is syntax to ns. It's not syntax in the traditional way, but it's 
> essentially the same thing. And Greg is right that it often causes confusion.
> 
> I +1 the second version. The first version's :as-class was too messy.
> 
> It could very easily be made backwards-compliant as well. All we have to do 
> is check if the first item in the list/vec is a keyword. If it is, then it's 
> the old-style ns. If not, it's the new.
> 
> Jonathan
> 
> 
> On Mon, Aug 5, 2013 at 8:14 PM, Timothy Baldridge <tbaldri...@gmail.com> 
> wrote:
> There's no syntax to ns, ns simply assumes that everything after the 
> symbol/doc is in the form (function-to-execute & args). The only special case 
> is gen-class, and even that is fixed up to look like everything else. Why 
> invent special syntax where none exists now? 
> 
> I think the issue is more around people not understanding the difference (and 
> problems behind) refer vs import instead of an actual problem with the 
> require macro. 
> 
> On that subject when last discussed, it was mentioned that Clojure doesn't 
> have a import * method because it's basically impossible to implement. 
> 
> 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. "
> 
> https://groups.google.com/forum/#!searchin/clojure/import$20wildcard/clojure/-gCg_0wmT5o/LnxDCU6W538J
> 
> Timothy
> 
> 
> On Mon, Aug 5, 2013 at 11:58 AM, Greg <g...@kinostudios.com> wrote:
>> I don't really understand why we would need to simplify something that is 
>> already so simple.
> 
> Because it's not simple to many people. It's one of the main things people 
> use as an example when discussing complexity in clojure.
> 
> There are many threads and blog posts where people explain why they consider 
> the "ns" declaration to be complicated.
> 
> 
>> That being said, if you really want your syntax above, nothing is stopping 
>> you from using your own import function
> 
> When I have time, I might do something like that, but not the way you 
> illustrated, because that's unnecessarily complicated in my view.
> 
> I might either add a hook to to 'ns', or if that's not possible, overwrite it 
> to support both syntaxes, or create a different name, like "include".
> 
> Then it would be this:
> 
> (include two.namespace
> 
>   [clojure :refer-all [core :except (ancestors printf)]]
>   [core :refer-all [matrix math bs]]
>   [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 :refer [reload middleware]]
> 
>   [net.cgrand :refer [enlive-html :as html]]
>   [org.apache.maven.artifact.resolver :refer ArtifactResolver] 
>   [java.io :refer File])
> 
> Instead of:
> 
> (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))))
> 
> - Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Aug 5, 2013, at 1:46 PM, Timothy Baldridge <tbaldri...@gmail.com> wrote:
> 
>> I don't really understand why we would need to simplify something that is 
>> already so simple. Teach people the following: 
>> 
>> (ns my-namespace
>>   ...calls to import fns...)
>> 
>> Where import functions can be either :require or :import:
>> 
>> (:import [clojure.lang Number AFn]) ;; use for Java imports
>> 
>> (:require [clojure.string :as string :refer [split]]) ;; use for clojure 
>> imports
>> 
>> :refer :all can be used to refer everything
>> 
>> Boom! everything you need to know to get started with Clojure's ns. What's 
>> the problem?
>> 
>> That being said, if you really want your syntax above, nothing is stopping 
>> you from using your own import function, they are pluggable after all:
>> 
>> (ns foo
>>   (:println "Hello World"))
>> 
>> Hello World
>> => nil
>> 
>> So you could easily write something like this:
>> 
>> (ns foo
>>   (:simple-ns/simple
>>     [clojure.core match logic async]))
>> 
>> Timothy Baldridge
>> 
>> 
>> 
>> 
>> On Mon, Aug 5, 2013 at 11:21 AM, Greg <g...@kinostudios.com> wrote:
>>> OK, that's enough from me on this for now, gotta run (lot of work to do!).
>> 
>> 
>> Sorry, after sending that, I couldn't resist simplifying 'ns' even further!
>> 
>> (ns two.namespace
>>   "optional doc string goes here"
>>   [core :refer-all [matrix math bs]]
>>   [clojure :refer-all [core :except (ancestors printf)]]
>>   [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 :refer reload]
>>   [one :refer middleware]
>>   [net.cgrand :refer [enlive-html :as html]]
>>   [org.apache.maven.artifact.resolver :refer ArtifactResolver] 
>>   [java.io :refer File])
>> 
>> Look at the beauty of that! :-D
>> 
>> Now not only have we gotten rid of :use, :require, :import, :refer-clojure, 
>> but we're starting to chip away at the mountain of keywords and we still 
>> have *all* of the power we had before! We got rid of :as-ns, :as-class and 
>> :all!
>> 
>> Keep simplifying till you can't simplify anymore! That's the Lisp way! :-)
>> 
>> - Greg
>> 
>> --
>> Please do not email me anything that you are not comfortable also sharing 
>> with the NSA.
>> 
>> On Aug 5, 2013, at 1:14 PM, Greg <g...@kinostudios.com> wrote:
>> 
>>>>> (ns one.fresh-server
>>>>>  [core :refer-all [matrix math bs]])
>>>> 
>>>> I like it.
>>> 
>>> Ideally, the whole thing would be well thought out enough to allow these 
>>> very basic principles to be combined in complicated ways (kinda like the 
>>> idea behind Lisp itself).
>>> 
>>> Getting rid of ambiguities might help make it more readable and 
>>> "generalizable". For example, it could be specified that vectors can 
>>> contain only namespaces and keywords, and lists can only contain functions.
>>> 
>>> If that rule is applied, the original example plus the :refer-all keyword 
>>> would look like this:
>>> 
>>> New School:
>>> 
>>> (ns two.namespace
>>>   "optional doc string goes here"
>>>   [core :refer-all [matrix math bs]]
>>>   [clojure :refer-all [core :except (ancestors printf)]]
>>>   [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])
>>> 
>>> Now the functions are emphasized as being functions (because only functions 
>>> are allowed in lists).
>>> 
>>> Notice that this:
>>> 
>>> [clojure.core :refer-except (ancestors printf)]
>>> 
>>> Has now changed to:
>>> 
>>> [clojure :refer-all [core :except (ancestors printf)]]
>>> 
>>> What if we want to :refer-all everything that's in the first level of the 
>>> namespace? I see no reason why we couldn't just do this then:
>>> 
>>> [:refer-all [core]]
>>> 
>>> Or optionally, in the case where there's just one namespace in the vector:
>>> 
>>> [:refer-all core]
>>> 
>>> OK, that's enough from me on this for now, gotta run (lot of work to do!).
>>> 
>>> - Greg
>>> 
>>> --
>>> Please do not email me anything that you are not comfortable also sharing 
>>> with the NSA.
>>> 
>>> On Aug 5, 2013, at 12:59 PM, Lee Spector <lspec...@hampshire.edu> wrote:
>>> 
>>>> 
>>>> On Aug 5, 2013, at 12:41 PM, Greg wrote:
>>>> 
>>>>>> Can you build in a way to get :require :refer :all to work on a bunch of 
>>>>>> sub-namespaces together on one line, as one currently can with :use, 
>>>>>> without listing each namespace completely on a separate line with a 
>>>>>> separate :refer :all?
>>>>> 
>>>>> Certainly. I'm not saying this is how the exact syntax would go, but the 
>>>>> general idea is to rely on the keywords to specify what (and how) you 
>>>>> want to import stuff:
>>>>> 
>>>>> Instead of:
>>>>> 
>>>>> (ns one.fresh-server
>>>>>  (:use (core matrix math bs))
>>>>> 
>>>>> You could do something like:
>>>>> 
>>>>> (ns one.fresh-server
>>>>>  [core :refer-all [matrix math bs]])
>>>> 
>>>> I like it.
>>>> 
>>>> I can't personally assess the costs and benefits of the overall proposal, 
>>>> but this would address my concern nicely.
>>>> 
>>>> -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.
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> “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.
>>  
>>  
> 
> 
> 
> 
> -- 
> “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.
>  
>  
> 
> 
> 
> -- 
> -- 
> 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.
>  
>  

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to