Global namespace (was Re: python libs v lisp coolness?

[Ingvar Mattsson]

Ville Vainio <ville.spammehardvainio at spamtut.fi> writes:

> Paolo Amoroso <amoroso at mclink.it> writes:
> 
> > The lack of Lisp libraries is being addressed.
> 
> Are they also going to address the lack of modules? The way I've seen
> Lisp used, everything is dumped into a global namespace (even
> "methods" in CLOS). I shudder at the thought of using Python where all
> the names from various modules would be in the global namespace.

There's packages. They're not *quite* the same thing, I hear, but for
this discussion, we can assume they are. One of the reasons most
examples just dump stuff in the global namespace is because (to some
degree) it's simpler.

>From a piece of code I'm doodling on in my copious free time:
(defpackage "ELISP"
  (:shadow "=" "DEFUN" "LET" "IF" "SETQ" "ASSOC" "COMMANDP" "AREF")
  (:use "COMMON-LISP" "HEMLOCK-INTERNALS")
  (:export
; Lots of symbols not listed
    ))
(defpackage "ELISP-INTERNALS"
  (:shadow "READ-STRING")
  (:use "COMMON-LISP")
  (:export
   "FIND-LAMBDA-LIST-VARIABLES"
   "GENERATE-CL-PACKAGE"
   "REQUIRE-LOAD"
   "GET-USER-HOMEDIR"
   "INTERACTIVE-GLUE"
   "*ELISP-READTABLE*"
   )
  )
(defpackage "ELISP-USER"
  (:use "ELISP" "ELISP-INTERNALS")
  )

After this has been done (and the relevant code loaded), there is a
package called ELISP-USER, where all action happens. It sees
symbols from ELISP and ELISP-INTERNALS as "local" and instead of using
<module>.<name>, one uses <package>:<name> to signify a thing from a
package one isn't using or isn't the local package.

//Ingvar
-- 
When C++ is your hammer, everything looks like a thumb
	Latest seen from Steven M. Haflich, in c.l.l