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.
