SearchYC.com

  A foreing function interface

"The kind of modularity provided by packages is actually a bit odd. We have modules not of objects, but of names. Every package that uses 'common-lisp' has access to the name 'cons', because 'common-lisp' includes a function with that name. But in consequence a variable called 'cons' would also be visible in every package that used 'common-lisp'. If packages are confusing, this is the main reason why; they're not based on objects, but on their names".

So what you say is to simplify it to a function 'use' that creates a table of symbols? How do you solve the references within modules? I don't see that, but otherwise it's very good. I would even remove the 'as', and make it a simple optional parameter:

  (use 'foo 'f)
  (f!bar 1 2 3)

  (set f (use "foo"))
  (f!bar 1 2 3)

I also wanted to mention a fourth benefit that I think modules can offer, which is:

4. They allow some form of management of dependencies between pieces of code.

  > (define nil '())
  > (eqv? '() 'nil)
  #f

In my case, I kind of think about it as "typographical" reasons. For instance, all manuals of typography tell you that it's uncomfortable to read very long lines of text if they are too close (in fact, this forum is above the limit, whereas PGs essays, if you remember, are almost perfect). The reason is that when you try to find the exact line that is the continuation of the one you are on, you have to search. Best measures for this have been tabulated by the professionals, of course. And, you know, lately I've discovered myself trying all the time to make programs not surpass the 65th column, and using the "wc -L" command all the time, so that programs occupy mostly your field of vision without moving your eyes... Stupid maybe? Perfectionism? Yes, I know. But I think this goes in the lines of your comment, since documentation breaks this 'unity' of code, I don't like it in the middle.

And the one thing that has attracted me towards Arc is, as a matter of fact, "the PG style", this minimalist, amazing (for my taste) coding style that I saw in "On Lisp" and "ANSI Common Lisp". It feels right to me, and you feel that code becomes a 'definition', so I now think I should be trained enough to read "arc.arc" _without_ documentation, as if I was reading math or something. And since Arc seemed like a language built with those principles, the addition of documentation, while certainly useful, didn't feel right to me.