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 <tbaldri...@gmail.com> 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 <g...@kinostudios.com> 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 <curtis.summ...@gmail.com>
> > > > 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.
> >> > >> > > > > > > > > > > -- > > “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.
> > > > > > --
Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad!
--
--
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.
