clojure/ns and gen-and-save-class

[Stuart Sierra]

I think there's a problem with the new clojure/ns and gen-and-save-
class.

Suppose you define:
(clojure/ns com.example
(:use clojure.contrib.pred))
(defn MyClass-close [this]
(println "Hello, World!"))

And you generate a .class file with:
(gen-and-save-class
*classes-dir*
"com.example.MyClass"
:implements [java.io.Closeable])

Then, at runtime, when com/example/MyClass.clj gets loaded, clojure/ns
does not (refer 'clojure) because the namespace already exists. So
you get:

Exception in thread "main" java.lang.ExceptionInInitializerError
at com.example.Main.main(Main.java:5)
Caused by: clojure.lang.Compiler$CompilerException: MyClass.clj:8:
Unable to resolve symbol: defn in this context

If you replace (clojure/ns...) with:
(clojure/in-ns 'com.example)
(clojure/refer 'clojure)
(use 'clojure.contrib.pred)
then it works fine.

-Stuart

[Stephen C. Gilardi]

I saw some discussion of how to fix this on the IRC log but I can't get on at the moment.

It looks like the current plan is to change "ns" to remove the sensitivity to "the namespace is already defined" and add "(:refer-clojure ...)" to the list of supported reference arguments. The new ":refer-clojure" would have arguments like those of  clojure/refer and apply them to the clojure namespace.  If an "ns" call contains no "(:refer-clojure ...)" reference argument , that "ns" call refers to all of Clojure.

I have been thinking recently that "(:refer ...)" would make a good supported reference argument. Instead of "(:refer-clojure ...)", I suggest "(:refer ...)" which acts like any other call to refer but doesn't require its arguments to be quoted. "ns" would still refer to all of clojure if there is no explicit "(:refer clojure ...)" argument present.

The reference arguments would then play these roles:

:require (when you need to be sure a lib is loaded from classpath resource(s))

:use (ditto, but also refers to the namespace with filters)

:load-resources (when you're just loading resources from classpath, as in a lib implementation)

:refer (when you know another namespace is already present and you want to bring some or all of it into this namespace with filters)

One important case of knowing the namespace is already present is the clojure namespace, but there could be others in a particular deployment of Clojure or given a particular policy for a program about how it loads itself. I like ":refer" over ":refer-clojure" because it's more general and shorter.

On the subject of shorter, the name "clojure/load" is already in use, but would be a better name for "load-resources" than "load-resources". I think we should consider changing the name of the former to something else like "load-reader" and using "load" for what is now load-resources (and :load for what is now :load-resources).

--Steve

[Chouser]

On Wed, Sep 3, 2008 at 4:36 PM, Stephen C. Gilardi <sque...@mac.com> wrote:
> I have been thinking recently that "(:refer ...)" would make a good
> supported reference argument. Instead of "(:refer-clojure ...)", I suggest
> "(:refer ...)" which acts like any other call to refer but doesn't require
> its arguments to be quoted. "ns" would still refer to all of clojure if
> there is no explicit "(:refer clojure ...)" argument present.

Personally, I'd rather nobody use refer for anything except the
'clojure namespace itself. This would also be an argument against
:use. But my opinion seems to be in the minority, so I'll once again
drop it until I can find a new excuse for bringing it up again. :-)

> :refer (when you know another namespace is already present and you want to
> bring some or all of it into this namespace with filters)

Is there any reason not to use :use in this case? :use is more
robust, as it doesn't rely on your assumption that the namespace is
indeed already present. The only namespace I'm aware of that doesn't
behave properly with :use is 'clojure, since it's loaded from
clojure/boot.clj instead of clojure/clojure.clj.

> I like ":refer" over ":refer-clojure" because it's more general and
> shorter.

Well, it's not really shorter since you'd have to say ":refer clojure"
instead of ":refer-clojure". But it is more general, and therefore
requires less code to support more cases. If it's useful, I'm fine
with it.

The only other point I'll bring up is that it may be slightly less
surprising for a missing :refer-clojure to automatically refer
'clojure than it would be for the more general :refer to have a
special case for the refering of 'clojure if it's not mentioned.

> On the subject of shorter, the name "clojure/load" is already in use, but
> would be a better name for "load-resources" than "load-resources". I think
> we should consider changing the name of the former to something else like
> "load-reader" and using "load" for what is now load-resources (and :load for
> what is now :load-resources).

I have no objection to this.

--Chouser

[Chouser]

On Wed, Sep 3, 2008 at 4:36 PM, Stephen C. Gilardi <sque...@mac.com> wrote:

> I saw some discussion of how to fix this on the IRC log but I can't get on
> at the moment.
> It looks like the current plan is to change "ns" to remove the sensitivity
> to "the namespace is already defined" and add "(:refer-clojure ...)" to the
> list of supported reference arguments.

Well, here's a patch for the behavior discussed on IRC. I'm posting
it only because it's complete and working, not in any attempt to
stifle further discussion. If we settle on any alternate solution,
this patch can just be ignored.

--Chouser

[Stephen C. Gilardi]

On Sep 3, 2008, at 4:59 PM, Chouser wrote:

On Wed, Sep 3, 2008 at 4:36 PM, Stephen C. Gilardi <sque...@mac.com> wrote:

:refer (when you know another namespace is already present and you want to

bring some or all of it into this namespace with filters)

Is there any reason not to use :use in this case?  :use is more
robust, as it doesn't rely on your assumption that the namespace is
indeed already present.  The only namespace I'm aware of that doesn't
behave properly with :use is 'clojure, since it's loaded from
clojure/boot.clj instead of clojure/clojure.clj.

Good point. It seems that :use would suffice except if both of the following are true for a particular namespace:

- it's defined outside of a lib,

- it's reasonable to want to refer to it.

I'm not aware of any uses of namespaces that meet both of those criteria. Does anyone else know of any?

I like ":refer" over ":refer-clojure" because it's more general and shorter.

Well, it's not really shorter since you'd have to say ":refer clojure" instead of ":refer-clojure".

Right, it's not shorter in the call. It's only shorter in docs and when we talk about it.

But it is more general, and therefore requires less code to support more cases.  If it's useful, I'm fine with it.

Some of my suggestions may be over-general when I don't have enough experience or knowledge to see why a something very general is unnecessary. I'd appreciate hearing more opinions on :refer vs. :refer-clojure.

The only other point I'll bring up is that it may be slightly less
surprising for a missing :refer-clojure to automatically refer
'clojure than it would be for the more general :refer to have a
special case for the refering of 'clojure if it's not mentioned.

That's a very good point in favor of :refer-clojure.

Thanks for the discussion.

--Steve

[Michael Reid]

Hi,

> Good point. It seems that :use would suffice except if both of the following
> are true for a particular namespace:
> - it's defined outside of a lib,
> - it's reasonable to want to refer to it.
>
> I'm not aware of any uses of namespaces that meet both of those criteria.
> Does anyone else know of any?
>

One thing I encountered with the new (ns) is when some Java code that
operates with Clojure creates a Namespace before the corresponding
.clj file is loaded. With the current behaviour, when the .clj loads
and calls (ns com.my-ns) it does not automatically refer 'clojure
since the namespace was already created by the Java code.

In this case a call to (clojure/refer 'clojure) was necessary.

Again we're talking about 'clojure, but its not inconceivable to me
that a similar situation could arise with a different namespace. A
manual call to clojure/refer is not a big deal to me, but being able
to contain this in a :refer clause in the call to (ns) would feel a
little cleaner.

Use of the general :refer clause would likely be low, but I don't see
any reason to limit flexibility for when its needed. I wouldn't expect
there be too much confusion between when to use :use and when to use
:refer--use :use if you want to load the lib if necessary and refer it
into the current namespace, and use :refer if you are sure that the
namespace is already loaded.

Rich might have something else to say about it though :).

/mike.

[Rich Hickey]

On Sep 3, 4:59 pm, Chouser <chou...@gmail.com> wrote:

> On Wed, Sep 3, 2008 at 4:36 PM, Stephen C. Gilardi <squee...@mac.com> wrote:
>
> > I have been thinking recently that "(:refer ...)" would make a good
> > supported reference argument. Instead of "(:refer-clojure ...)", I suggest
> > "(:refer ...)" which acts like any other call to refer but doesn't require
> > its arguments to be quoted. "ns" would still refer to all of clojure if
> > there is no explicit "(:refer clojure ...)" argument present.
>
> Personally, I'd rather nobody use refer for anything except the
> 'clojure namespace itself.

I agree.

> This would also be an argument against
> :use.

Did you mean to say :refer? :use seems necessary to hide refer, and
there are certainly cases where you want to load and not refer (i.e.
require).

> But my opinion seems to be in the minority, so I'll once again
> drop it until I can find a new excuse for bringing it up again. :-)
>
> > :refer (when you know another namespace is already present and you want to
> > bring some or all of it into this namespace with filters)
>
> Is there any reason not to use :use in this case? :use is more
> robust, as it doesn't rely on your assumption that the namespace is
> indeed already present. The only namespace I'm aware of that doesn't
> behave properly with :use is 'clojure, since it's loaded from
> clojure/boot.clj instead of clojure/clojure.clj.
>

Right, and automatically loaded so the load semantics of requier and
use don't apply.

> > I like ":refer" over ":refer-clojure" because it's more general and
> > shorter.
>
> Well, it's not really shorter since you'd have to say ":refer clojure"
> instead of ":refer-clojure". But it is more general, and therefore
> requires less code to support more cases. If it's useful, I'm fine
> with it.
>

I'm not - simpler is better.

> The only other point I'll bring up is that it may be slightly less
> surprising for a missing :refer-clojure to automatically refer
> 'clojure than it would be for the more general :refer to have a
> special case for the refering of 'clojure if it's not mentioned.
>

Right.

> > On the subject of shorter, the name "clojure/load" is already in use, but
> > would be a better name for "load-resources" than "load-resources". I think
> > we should consider changing the name of the former to something else like
> > "load-reader" and using "load" for what is now load-resources (and :load for
> > what is now :load-resources).
>
> I have no objection to this.
>

Me neither, other than the breakage for people using load, most of
whom I presume are loading from strings to do evals, and may be
placated with a load-string.

Rich

[Rich Hickey]

Given :refer-clojure, I'd hope there are no other scenarios not
covered by use/require.

Rich

[Matt Revelle]

On Sep 3, 2008, at 4:59 PM, Chouser wrote:

>
> On Wed, Sep 3, 2008 at 4:36 PM, Stephen C. Gilardi
> <sque...@mac.com> wrote:
>> I have been thinking recently that "(:refer ...)" would make a good
>> supported reference argument. Instead of "(:refer-clojure ...)", I
>> suggest
>> "(:refer ...)" which acts like any other call to refer but doesn't
>> require
>> its arguments to be quoted. "ns" would still refer to all of
>> clojure if
>> there is no explicit "(:refer clojure ...)" argument present.
>
> Personally, I'd rather nobody use refer for anything except the
> 'clojure namespace itself. This would also be an argument against
> :use. But my opinion seems to be in the minority, so I'll once again
> drop it until I can find a new excuse for bringing it up again. :-)

Was that conversation on the list? Just curious...

>
>> :refer (when you know another namespace is already present and you
>> want to
>> bring some or all of it into this namespace with filters)
>
> Is there any reason not to use :use in this case? :use is more
> robust, as it doesn't rely on your assumption that the namespace is
> indeed already present. The only namespace I'm aware of that doesn't
> behave properly with :use is 'clojure, since it's loaded from
> clojure/boot.clj instead of clojure/clojure.clj.
>
>> I like ":refer" over ":refer-clojure" because it's more general and
>> shorter.
>
> Well, it's not really shorter since you'd have to say ":refer clojure"
> instead of ":refer-clojure". But it is more general, and therefore
> requires less code to support more cases. If it's useful, I'm fine
> with it.
>
> The only other point I'll bring up is that it may be slightly less
> surprising for a missing :refer-clojure to automatically refer
> 'clojure than it would be for the more general :refer to have a
> special case for the refering of 'clojure if it's not mentioned.

Having both :use and :refer is unnecessary and will confuse newcomers
and there's no obvious benefit.

I'm in the :refer-clojure camp, with its absence bringing in all
symbols from clojure but with a simple way to turn it off. Perhaps
(:refer-clojure false) or using a special argument, such as :all, with
the :exclude filter.

>
>
>> On the subject of shorter, the name "clojure/load" is already in
>> use, but
>> would be a better name for "load-resources" than "load-resources".
>> I think
>> we should consider changing the name of the former to something
>> else like
>> "load-reader" and using "load" for what is now load-resources
>> (and :load for
>> what is now :load-resources).
>
> I have no objection to this.

Sounds good.

>
>
> --Chouser
>
> >

[Rich Hickey]

On Sep 3, 5:14 pm, Chouser <chou...@gmail.com> wrote:

> On Wed, Sep 3, 2008 at 4:36 PM, Stephen C. Gilardi <squee...@mac.com> wrote:
>
> > I saw some discussion of how to fix this on the IRC log but I can't get on
> > at the moment.
> > It looks like the current plan is to change "ns" to remove the sensitivity
> > to "the namespace is already defined" and add "(:refer-clojure ...)" to the
> > list of supported reference arguments.
>
> Well, here's a patch for the behavior discussed on IRC. I'm posting
> it only because it's complete and working, not in any attempt to
> stifle further discussion. If we settle on any alternate solution,
> this patch can just be ignored.
>

I think the only problem is in the case of subsequent use of ns. I
originally envisioned the 'main' .clj file doing an involved ns and
subsequent files just doing (ns foo), as well as the use of ns at the
repl to change namespaces. Now, if you did

(ns foo (:refer-clojure ...) ...)

any later (ns foo) is going to bring in all of clojure. I'd prefer it
did nothing but change *ns*.

Rich

[Rich Hickey]

After sleeping on it, I think what we have been calling ns should be
called defns instead, and ns should just set *ns*. Thus there should
be only one defns for any particular namespace, and (ns foo) can be
used to set the namespace for a file and/or change the namespace at
the repl.

Thoughts?

Rich

[Chouser]

On Thu, Sep 4, 2008 at 9:28 AM, Rich Hickey <richh...@gmail.com> wrote:
>
> After sleeping on it, I think what we have been calling ns should be
> called defns instead, and ns should just set *ns*. Thus there should
> be only one defns for any particular namespace, and (ns foo) can be
> used to set the namespace for a file and/or change the namespace at
> the repl.
>
> Thoughts?

The other def's have no impact on the state except for the name
they're defining -- will defns also change *ns*? At the very least it
may cause other namespaces to be created (via :require for example).
The other def's, if repeated, fully replace the old definition with
the new one -- will defns do that, or will it just add any new
namespaces and aliases to any that already exist?

Maybe those are comments about the name more than the functionality.

Is there really any harm in re-refering 'clojure if ns (or defns) is
run a second time on the same namespace?

--Chouser

[Rich Hickey]

On Sep 4, 9:46 am, Chouser <chou...@gmail.com> wrote:

> On Thu, Sep 4, 2008 at 9:28 AM, Rich Hickey <richhic...@gmail.com> wrote:
>
> > After sleeping on it, I think what we have been calling ns should be
> > called defns instead, and ns should just set *ns*. Thus there should
> > be only one defns for any particular namespace, and (ns foo) can be
> > used to set the namespace for a file and/or change the namespace at
> > the repl.
>
> > Thoughts?
>
> The other def's have no impact on the state except for the name
> they're defining -- will defns also change *ns*?

Yes. But when used declaratively in a file that is loaded, there is no
lingering change of the state of *ns*, as a new binding for *ns* is
pushed/popped around the load.

> At the very least it
> may cause other namespaces to be created (via :require for example).
> The other def's, if repeated, fully replace the old definition with
> the new one -- will defns do that, or will it just add any new
> namespaces and aliases to any that already exist?

The latter.

>
> Maybe those are comments about the name more than the functionality.
>

Point taken. But there is no way to 'replace' a namespace, given
compiled-in bindings to vars. re-defing is inherently an interactive
development thing. And other re-defs do not completely replace the old
definition - the var object is the same. In that way, defns would be
similar, just applied to a set of vars/mappings.

> Is there really any harm in re-refering 'clojure if ns (or defns) is
> run a second time on the same namespace?
>

Not at all. The example I gave, where one ns call pulled in only some
of clojure and the other defaulted to all of it, is the problem, and
it arises from using ns for two different purposes.

Rich

[Stephen C. Gilardi]

On Sep 4, 2008, at 9:28 AM, Rich Hickey wrote:

After sleeping on it, I think what we have been calling ns should be
called defns instead, and ns should just set *ns*. Thus there should
be only one defns for any particular namespace, and (ns foo) can be
used to set the namespace for a file and/or change the namespace at
the repl.

Thoughts?

I like it.

--Steve

[Christopher Taylor]

Hi,

this is my first post to the list (though I've been lurking for a
while) and I'm not yet actively working with Clojure, so take what I
say here with a grain of salt :).

So, if I understand this correctly, you'd have a file myns/myns.clj
containing (defns myns) along with :require and/or :use clauses for
the dependencies of the whole ns. Other files under myns/ would
contain just the statement (ns myns).

Personally, from a separations-of-concerns standpoint, I'd prefer if
every file were responsible for getting access to all the libs it needs.

Oh, one (tiny) niggle wrt the name "defns": it looks a bit like the
plural form of "defn", so it might be confused with defmulti or
something that defines a bunch of functions at once.

just my 2¢,
--Chris

[Rich Hickey]

Right.

> Personally, from a separations-of-concerns standpoint, I'd prefer if
> every file were responsible for getting access to all the libs it needs.
>

Being an interactive language, hanging such dependencies on files
doesn't really work, since bits and pieces of things originally
defined in files might be fixed/redefined in the repl etc. So the unit
of reference is the namespace, and all code in the same namespace
shares the same references and name resolution. This aids
introspection as well.

> Oh, one (tiny) niggle wrt the name "defns": it looks a bit like the
> plural form of "defn", so it might be confused with defmulti or
> something that defines a bunch of functions at once.
>

I didn't think about the plural angle - anyone else bothered by that?
The alternative is defnamespace.

Rich

[Stephen C. Gilardi]

On Sep 5, 2008, at 3:23 PM, Rich Hickey wrote:

I didn't think about the plural angle - anyone else bothered by that?
The alternative is defnamespace.

I like the clarity of defnamespace over defns. The only knock I see against defnamespace is its length (in characters). I think that length is justified by the fact that its arguments will nearly always be much longer and that it will only be used once per namespace.

This is how it appears in an actual call:

(clojure/defnamespace clojure.contrib.sql

 (:import

  (java.sql DriverManager Connection PreparedStatement ResultSet)))

The "clojure/" qualifier is necessary in case the namespace doing the loading doesn't have clojure referenced. Rich do you see any merit in treating "defnamespace" (or "defns") specially so that it's effectively referenced by every namespace. This would allow us to remove the clojure/ and still allow every lib to load reliably regardless of the current namespace. That would allow the above call to be:

(defnamespace clojure.contrib.sql

 (:import

  (java.sql DriverManager Connection PreparedStatement ResultSet)))

I like both ways, but I thought I'd mention the possibility of shortening it.

--Steve

[Stuart Sierra]

On Sep 5, 2008, at 3:23 PM, Rich Hickey wrote:
> I didn't think about the plural angle - anyone else bothered by that?
> The alternative is defnamespace.

Erg. Here, I think shorter is better. Maybe it's only once per file,
but you still have to type it every time you start a new file. If
people don't like the similarity to defn, then maybe just call it
"namespace". But every other namespace-related function uses "ns."

By the way, what happened to "in-ns"? Couldn't that be the form used
for switching to a namespace that already exists?
-Stuart

[Stephen C. Gilardi]

On Sep 5, 2008, at 10:08 PM, Stuart Sierra wrote:

On Sep 5, 2008, at 3:23 PM, Rich Hickey wrote:

I didn't think about the plural angle - anyone else bothered by that?

The alternative is defnamespace.

Erg.  Here, I think shorter is better.  Maybe it's only once per file,
but you still have to type it every time you start a new file.  If
people don't like the similarity to defn, then maybe just call it
"namespace".  But every other namespace-related function uses "ns."

clojure/namespace already exists: returns the namespace string of a symbol or keyword. If it were available I think it would be a good alternative for clojure/defns.

By the way, what happened to "in-ns"?  Couldn't that be the form used
for switching to a namespace that already exists?

clojure/in-ns takes a symbol argument which must be quoted. clojure/ns doesn't require its argument to be quoted--it's part of the "easier to type" group of namespace-related functions.

I see from the doc that clojure/in-ns creates the namespace if it doesn't exist. Is the intent for clojure/ns to be simply a wrapper for in-ns or should it give an error if the namespace doesn't already exist?

--Steve

[Parth Malwankar]

I like the idea of having a defxxx to define a name space as its
consistent with the rest of the API. Thanks Rich.

Regarding the name, actually, I didn't realize plural angle till
it was pointed out. However, I feel defns is a good enough name
as there isn't a 's' being used for plural by any of the other defs to
my knowledge.

If a need arises to use s for plurals in some future def it may
become confusing.

defnamespace will make be inconsistent with 'ns', 'in-ns' etc.
Putting a - as 'def-ns' will also make it somewhat different from
the other defs IMHO.

Parth



> Rich

[Rich Hickey]

On Sep 3, 5:14 pm, Chouser <chou...@gmail.com> wrote:

> On Wed, Sep 3, 2008 at 4:36 PM, Stephen C. Gilardi <squee...@mac.com> wrote:
>
> > I saw some discussion of how to fix this on the IRC log but I can't get on
> > at the moment.
> > It looks like the current plan is to change "ns" to remove the sensitivity
> > to "the namespace is already defined" and add "(:refer-clojure ...)" to the
> > list of supported reference arguments.
>
> Well, here's a patch for the behavior discussed on IRC. I'm posting
> it only because it's complete and working, not in any attempt to
> stifle further discussion. If we settle on any alternate solution,
> this patch can just be ignored.
>

I've applied this patch (SVN rev 1017).

ns should be used in only one file. in-ns should still be used in
subsidiary files and to change *ns* at the repl.

Rich

[Stephen C. Gilardi]

On Sep 6, 2008, at 6:48 PM, Rich Hickey wrote:

On Sep 3, 5:14 pm, Chouser <chou...@gmail.com> wrote:

On Wed, Sep 3, 2008 at 4:36 PM, Stephen C. Gilardi <squee...@mac.com> wrote:

I saw some discussion of how to fix this on the IRC log but I can't get on

at the moment.

It looks like the current plan is to change "ns" to remove the sensitivity

to "the namespace is already defined" and add "(:refer-clojure ...)" to the

list of supported reference arguments.

Well, here's a patch for the behavior discussed on IRC.  I'm posting

it only because it's complete and working, not in any attempt to

stifle further discussion.  If we settle on any alternate solution,

this patch can just be ignored.

I've applied this patch (SVN rev 1017).

It looks good.

I'm getting a null pointer exception for (doc ns) and (doc in-ns).

--Steve

[Rich Hickey]

Fixed - thanks for the report.

Rich

[Chouser]

On Sat, Sep 6, 2008 at 6:48 PM, Rich Hickey <richh...@gmail.com> wrote:
>
> I've applied this patch (SVN rev 1017).
>
> ns should be used in only one file. in-ns should still be used in
> subsidiary files and to change *ns* at the repl.

Also you mentioned in IRC (but not here I think) that ns and in-ns
have special resolution rules, so that you never have to say
clojure/ns or clojure/in-ns:

user=> (in-ns 'foo)
#<Namespace: foo>
foo=> (prn "hi")
java.lang.Exception: Unable to resolve symbol: prn in this context
foo=> (in-ns 'user) ; <-- but this works fine
#<Namespace: user>
user=>

I've updated zip-filter and mmap in clojure.contrib to use the new
format. I like it. It's such a relief to be able to rely on the
availability of lib.clj goodness, and the ns macro is a very pleasant
way to use it.

--Chouser

[Stephen C. Gilardi]

On Sep 3, 2008, at 7:11 PM, Rich Hickey wrote:

>>> On the subject of shorter, the name "clojure/load" is already in
>>> use, but
>>> would be a better name for "load-resources" than "load-resources".
>>> I think
>>> we should consider changing the name of the former to something
>>> else like
>>> "load-reader" and using "load" for what is now load-resources
>>> (and :load for
>>> what is now :load-resources).
>>
>> I have no objection to this.
>>
>
> Me neither, other than the breakage for people using load, most of
> whom I presume are loading from strings to do evals, and may be
> placated with a load-string.

I've enclosed a patch to implement this.

Changes:

renamed clojure/load to clojure/load-reader
added clojure/load-string
renamed clojure/load-resources to clojure/load
fixed up doc strings accordingly

These changes are all at the Clojure level--the load method of
Compiler is not changed.

$ cd <clojure-root-dir>
$ patch -p0 < load-reader.patch
patching file src/clj/clojure/boot.clj
$

--Steve

[Rich Hickey]

On Sep 7, 10:23 am, "Stephen C. Gilardi" <squee...@mac.com> wrote:
> On Sep 3, 2008, at 7:11 PM, Rich Hickey wrote:
>
>
>
> >>> On the subject of shorter, the name "clojure/load" is already in
> >>> use, but
> >>> would be a better name for "load-resources" than "load-resources".
> >>> I think
> >>> we should consider changing the name of the former to something
> >>> else like
> >>> "load-reader" and using "load" for what is now load-resources
> >>> (and :load for
> >>> what is now :load-resources).
>
> >> I have no objection to this.
>
> > Me neither, other than the breakage for people using load, most of
> > whom I presume are loading from strings to do evals, and may be
> > placated with a load-string.
>
> I've enclosed a patch to implement this.
>
> Changes:
>
> renamed clojure/load to clojure/load-reader
> added clojure/load-string
> renamed clojure/load-resources to clojure/load
> fixed up doc strings accordingly
>
> These changes are all at the Clojure level--the load method of
> Compiler is not changed.
>

Patch applied (rev 1019) - thanks!

Rich