If there was one thing I would deprecate it's that the first element of
the vector is special.
I find the fact that these two:
(ns bob [:require [tawny owl reasoner]])
(ns john [:require [tawny.owl reasoner]])
are totally different, very confusing.
That feature is very important to me. It's super tedious in java to write
out the whole package for every class that you want to import.
The current version of the proposal is a bit too much I feel, it's
simplified to a point where it's actually more complicated to use. Mostly
because of the difference between ( and [.
(ns foo
[require [clojure.string :as c]])
Is anyone actually using that? I've never ever seen it used that way. It
wouldn't be terribly hard to support that anyway. Just check if: the first
element is a keyword, or, it's the symbol require or use etc. Of course it
wouldn't work if you have a namespace named require, but I don't think
that's a good idea anyway.
Jonathan
On Tue, Aug 6, 2013 at 6:41 PM, Greg <g...@kinostudios.com> wrote:
> > It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
>
> Wow that's confusing!
>
> I just view that as yet another reason to change the syntax.
>
> To answer your question though, I'd do both syntax's a favor and interpret
> "[require [clojure.string :as c]]" using the new syntax. It would save a
> lot of newbies many headaches. Think of the newbies.
>
> > Yeah, there's a bug in the code, but let me try to redefine the problem.
> Assume I have a namespace called foo that defines a protocol (and hence an
> interface) called bar. I then also have a namespace called foo.bar. How do
> I tell the new syntax to import each? If I simply say "go get foo.bar" what
> are you going to load, the .clj file, or the java interface?
>
> I think part of the problem here is that I'm not very well educated on
> this topic yet. Perhaps you can help:
>
> - If you defined a protocol Foo in user, is it referenced as user.Foo from
> another ns, or user/Foo ? Or both??
>
> - Can you have a function Foo at the same time as a protocol Foo in the
> same namespace?
>
> - What about records? Can you have a record Foo and a protocol Foo?
>
> - Can you have a class Foo and an protocol Foo?
>
> Clojure and I are already confused here:
>
> baz=> (defprotocol g (dostuff [this]))
> g
> baz=> g
> {:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists
> ([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff},
> :method-builders {#'baz/dostuff #<baz$eval300$fn__301
> baz$eval300$fn__301@7c2aa00c>}}
> baz=> (defn g [] "a")
> #'baz/g
> baz=> g
> #<baz$g baz$g@4bb2668f>
>
> And I'm not sure how to get the protocol back...
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 6, 2013, at 11:43 AM, Timothy Baldridge <tbaldri...@gmail.com>
> wrote:
>
> >> >> (ns foo
> >> >> [require [clojure.string :as c]])
> >
> > >> I've never seen that before. What does it do?
> >
> > It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
> >
> >
> > Yeah, there's a bug in the code, but let me try to redefine the problem.
> Assume I have a namespace called foo that defines a protocol (and hence an
> interface) called bar. I then also have a namespace called foo.bar. How do
> I tell the new syntax to import each? If I simply say "go get foo.bar" what
> are you going to load, the .clj file, or the java interface?
> >
> > Timothy
> >
> >
> > On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord <
> phillip.l...@newcastle.ac.uk> wrote:
> > Greg <g...@kinostudios.com> writes:
> >
> > >> I am dubious about distinguishing between lists and vectors.
> Currently,
> > >> as far as I can tell, the ns is agnostic, and only cares about them
> > >> being sequential. This is probably one of the sources of confusion for
> > >> beginners -- they see both and don't see why
> > >
> > > The reason for distinguishing between lists and vectors is as you say,
> it's
> > > confusing for beginnings. Also, it allows the syntax to have greater
> > > functionality/power.
> >
> > Really dubious about this. Having to keep in my head when I need to use
> > [] and when I need to use () is a significant problem when starting. It
> > was my realisation that for the ns declaration you don't that made
> > things easier.
> >
> > >> Also, I am confused as to how you distinguish between
> > >> [core [matrix math bs]] being equivalent to :use while
> > >> Is [one reload middleware] also :use? Or :require?
> > >
> > > Nested vectors = :use.
> > >
> > > Thus, as the comment says, [core [matrix math bs]] => (:use (core
> matrix math
> > > bs))
> > >
> > > It's a bit confusing in the current syntax (if I have it correct),
> because
> > > from it, it's not clear why "core" isn't "used".
> > >
> > > [one reload middleware]
> > >
> > > Is equivalent to:
> > >
> > > (:require [one.reload :as reload]
> > > [one.middleware :as middleware])
> >
> > Scares me to be honest. You now have an implicit alias ":as reload", and
> > are distinguishing between having an alias and having no qualification
> > by nesting or otherwise.
> >
> > I do like the idea of enforcing nesting though in
> >
> > [core [matrix math bs]]
> >
> > Phil
> >
> > --
> > --
> > 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.
