I'll also note that it's missing some features, and is a bit broken in some ways, but I have a plan to fix that. I also noticed that it seems to be a bit slower (than using load), but that could be because I'm using a hash table rather than a Racket namespace. I'll switch over to Racket namespaces later and see if it helps any.

However, for basic stuff, it works. As an example, let's suppose you wanted to load up "arc3.1/pprint.arc", which creates a bunch of functions, like ppr. But now let's also suppose that some of those functions clash with other functions in your namespace... if you just use `load`, you'll get a namespace collision and stuff will break. Import to the rescue!

  >>> ppr
  error: reference to undefined identifier: ppr

  >>> (import pprint "arc3.1/pprint.arc")
  nil

  >>> pprint!ppr
  #<procedure>

  >>> (pprint!ppr "foobar")
  "foobar"nil

  >>> ppr
  error: reference to undefined identifier: ppr

But you can still call functions in the pprint namespace by using table notation. There are some neat things you can do with this. Aside from the obvious one of loading libraries into separate namespaces so they don't collide, you could load the same library twice, or you could load multiple libraries into the same namespace, while still keeping it separate from your namespace:

  (= foo (new-namespace))

  (w/namespace foo
    (load "lib/bar.arc")
    (load "lib/qux.arc"))

By the way, in addition to namespaces, it actually supports anything with type 'table, so the following works:

  >>> (w/namespace (table)
        (eval '(+ 10 5)))
  undefined variable: +

  >>> (w/namespace (obj + +)
        (eval '(+ 10 5)))
  15

  >>> (eval '(+ 10 5) (obj + +))
  15

  (= foo (new-namespace (table)))

---

I'd also like to note something here. Because you can create custom namespaces, there is the theoretical ability to create a "safe namespace" that would not be able to access things like "system" or similar destructive things.

Then, if you ever wanted to load up a library, rather than inspecting it to make sure it doesn't do anything bad, you could just load it into the safe namespace. This won't protect against things like infinite loops, or programs designed to consume a lot of CPU/RAM, but it will protect against the obvious stuff like (system "rm -rf /") and such.

I haven't added in support for that just yet, but it is planned.

---

When I have more than one value that I'm working with at a time, then I find implicit variables often become awkward, and I'd prefer to just specify the value explicitly.

It seems like namespaces may fall into this latter category, since I'll be working with my namespace and the other namespace, and perhaps more than one other namespace.

I could be wrong of course, and there's a good example of when passing the namespace implicitly is simpler than the alternative.

Anyway, how about this for "multiple layers of function calls": If you call 'load, that calls 'eval. Two whole layers! ^_^

---

"I think "namespace" may be too narrow a description since a runtime may have other configuration settings (such as how it handles optimizations) besides just which global variables it has."

Yeah, I have nothing against making macros or functions that handle namespaces in other ways, but I'd rather have a simple and concise low-level way too.

---

"I agree. I think "runtime" is a pretty good name for what you're headed for. :)"

Yeah, but I think the word "namespace" makes perfect sense for my library, especially considering that a namespace is a simple mapping between names and values. You can even pass in tables, so I think "namespace" is just fine.

I'm finding a lot of uses for implicit variables. I've come to like them a lot. :P I'll note that there can only be one namespace active per executing code, so it made a lot of sense for me to use implicit variables.

---

"When I have more than one value that I'm working with at a time, then I find implicit variables often become awkward, and I'd prefer to just specify the value explicitly."

You mean like this?

  (w/namespace foo ... do stuff ...)

Well, it's pretty simple[1], really. I used git fetch upstream to grab all the changes from ar. Then I used git reset --hard to reset my master branch to ar's branch, completely destroying everything on my branch, including commits.

Then I used git push -f to force my changes onto GitHub. Voila, now my fork is in the exact same state as ar. Of course, before I did all that, I created the old branch, so I wouldn't lose my work. Here's roughly what I did:

  git branch old
  git push origin old
  ... do stuff ...
  git fetch upstream
  git reset --hard 2be9ac75f67edfe9b3c43a9515dd78acebba6f1c
  git push -f origin

By the way, while I was trying to do that, I found this: http://stackoverflow.com/questions/772846/create-git-branch-...

But their directions are somewhat different from mine. I don't think I needed git pull for instance, and git push origin :master didn't work for me. So I had to use -f to force the push, since git was kindly telling me that it might destroy my commits (which I wanted to do).

---

After using git for a while, I gotta say, I like it a lot more than Mercurial. git gives you the power to do stuff, whereas Mercurial seems to hold your hand a lot more, and say, "no I can't let you do that, Dave"

Now, I'm not saying Mercurial is bad, just that I like the raw power of git, in the same way that I like the raw power of Arc. So for me personally, git seems to be the winner.

---