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.
