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.
>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
