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

[Ville Vainio]

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.

in Python you can do:

import os

files = os.listdir("/root")

 

[Christophe Rhodes]

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.

in Python you can do:

import os

files = os.listdir("/root")

Knowing no python, I believe the Common Lisp equivalent of this is
(cl:defpackage "MY-APP" use "CL"))
(cl:in-package "MY-APP")

(os:listdir "/root")

Optionally, if one wishes to import an interface wholesale and use it
without qualification, one may USE-PACKAGE a package, for example:
(cl:defpackage ("MY-OTHER-APP") use "CL" "OS"))
(cl:in-package "MY-OTHER-APP")

(listdir "/root")

[ this is written for maximum paranoia; usually you wouldn't see the
cl: prefixes on defpackage and in-package. ]

Ancient code is typically less careful about stomping over the global
namespace; if you see (in-package "CL-USER") anywhere, reeducate the
maintainer of the code

Christophe

 

[Ingvar Mattsson]

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

 

[Kenny Tilton]

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.

in Python you can do:

import os

files = os.listdir("/root")

Python and Lisp, separated at birth?

(require 'os)
(defparameter *files* (os::listdir "/root"))

kenny

--
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL Highlight Film

Your Project Here! http://alu.cliki.net/Industry Application

 

[Bruce Stephens]

Paolo Amoroso <[email protected]> writes:

[...]

in Python you can do:
import os
files = os.listdir("/root")

Python and Lisp, separated at birth?

(require 'os)
(defparameter *files* (os::listdir "/root"))

That should be

(defparameter *files* (os:listdir "/root"))

shouldn't it?

(Single colons let you at exported symbols; double colons let you
access even unexported symbols. If I understand things correctly,
anyway.)

 

[Kenny Tilton]

Paolo Amoroso <[email protected]> writes:

[...]

in Python you can do:
import os
files = os.listdir("/root")

Python and Lisp, separated at birth?

(require 'os)
(defparameter *files* (os::listdir "/root"))

That should be

(defparameter *files* (os:listdir "/root"))

shouldn't it?

(Single colons let you at exported symbols; double colons let you
access even unexported symbols. If I understand things correctly,
anyway.)

Right, thx. I actually always "use" a package and started my response
that way, then realized a closer parallel would be just to load the code
and use a package qualifier to get at the symbol. Wasn't thinking very
hard when I switched over to the second approach and added the package
qualifier.

My excuse is (and I'm sticking to it) that I was too pleased with myself
over my "separated at birth" crack. More support, from GvR:

http://www.python.org/doc/essays/blurb.html

Wow. s/Python/Lisp/w!

And from http://www.python.org/doc/essays/comparisons.html :

"[CL and Scheme] are close to Python in their dynamic semantics, but so
different in their approach to syntax that a comparison becomes almost a
religious argument: is Lisp's lack of syntax an advantage or a
disadvantage?"

Arnold "Lisp" Schwarznegger and Danny "Python" de Vito?



kenny

--
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL Highlight Film

Your Project Here! http://alu.cliki.net/Industry Application

 

[Jon S. Anthony]

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 a difference between modules and name spaces, though modules
in many languages also serve as name spaces. The issue you are
talking about here really is a name space issue and Common Lisp has
had control over that from the start. Its construct is the _package_.

in Python you can do:

import os

files = os.listdir("/root")

In Common Lisp this is basically the same. The symbols from OS that
should be public are _exported_. You then can access them, for
example, as:


(os:listdir "/root")


You can also _use_ a package if you are in another so that the
_exported_ symbols become visible w/o qualification.

(use-package s)

....

(listdir "/root")


There are a lot of other things for controlling visibility of this
sort. For example, you can _import_ only specific symbols or you can
_shadow_ others, etc.



/Jon

 

[Harald Hanche-Olsen]

+ (e-mail address removed) (Jon S. Anthony):

| There's a difference between modules and name spaces, though modules
| in many languages also serve as name spaces.

I have heard this one before, but have never quite understood the
difference. I am quite familiar with Lisp's packages and python's
modules, and sure enough they are quite different, but I lack a clear
conceptual distinction between modules and name spaces. (I think it
was even mentioned during an earlier discussion on c.l.lisp that it
may be useful to have both available in the same language.)

So, can anyone either explain the difference, or point to a resource
(preferably on the web) that explains it?

 

[Erann Gat]

+ (e-mail address removed) (Jon S. Anthony):

| There's a difference between modules and name spaces, though modules
| in many languages also serve as name spaces.

I have heard this one before, but have never quite understood the
difference. I am quite familiar with Lisp's packages and python's
modules, and sure enough they are quite different, but I lack a clear
conceptual distinction between modules and name spaces. (I think it
was even mentioned during an earlier discussion on c.l.lisp that it
may be useful to have both available in the same language.)

So, can anyone either explain the difference, or point to a resource
(preferably on the web) that explains it?

Packages map strings onto symbols (identifier objects).

Modules map symbols/identifiers onto values.

Packages work at read/parse time.

Modules work at compile time or run time depending on the module system.

Common Lisp has a package system but no module system (but it's possible
to add one -- see e.g. http://www.flownet.com/gat/locales.pdf).

Python has a module system that works at run-time, but no package system.

Does that help?

E.

 

[Pascal Costanza]

+ (e-mail address removed) (Jon S. Anthony):

| There's a difference between modules and name spaces, though modules
| in many languages also serve as name spaces.

I have heard this one before, but have never quite understood the
difference. I am quite familiar with Lisp's packages and python's
modules, and sure enough they are quite different, but I lack a clear
conceptual distinction between modules and name spaces. (I think it
was even mentioned during an earlier discussion on c.l.lisp that it
may be useful to have both available in the same language.)

So, can anyone either explain the difference, or point to a resource
(preferably on the web) that explains it?

http://www.flownet.com/gat/packages.pdf and
http://www.flownet.com/gat/locales.pdf are excellent papers IMHO.


Pascal

 

[Harald Hanche-Olsen]

+ (e-mail address removed) (Erann Gat):

| In article <[email protected]>, Harald Hanche-Olsen
|
| > + (e-mail address removed) (Jon S. Anthony):
| >
| > | There's a difference between modules and name spaces, though modules
| > | in many languages also serve as name spaces.
| > [...]
| > So, can anyone either explain the difference, or point to a resource
| > (preferably on the web) that explains it?
|
| Packages map strings onto symbols (identifier objects).

Agreed.

| Modules map symbols/identifiers onto values.

Okay.

| Packages work at read/parse time.

Yep.

| Modules work at compile time or run time depending on the module system.
|
| Common Lisp has a package system but no module system (but it's possible
| to add one -- see e.g. http://www.flownet.com/gat/locales.pdf).

Ah. I had read that one before, but never realized that it describes
a module system. That gives me some idea what it's all about.
Thanks.

| Python has a module system that works at run-time, but no package system.
|
| Does that help?

Now I am getting a bit confused once more, since python doesn't have
symbols, and so the distinction between modules and packages gets
blurred (in my mind at least): A python modules maps strings directly
to values without symbols ever entering the discussion.

But the read-time vs run-time (or compile-time) distinction makes more
sense to me. If a python function references foo.bar then by changing
the value of foo I can make the function refer to a different foo.bar,
but if a Common Lisp function references foo:bar, then messing around
with the FOO package is never going to change the meaning of that
reference.

I guess what I am saying is that, while packages without symbols don't
make sense, modules don't require them. But then, neither did you
say they do, now that I read what you said over again.

 

[Henrik Motakef]

But the read-time vs run-time (or compile-time) distinction makes more
sense to me. If a python function references foo.bar then by changing
the value of foo I can make the function refer to a different foo.bar,
but if a Common Lisp function references foo:bar, then messing around
with the FOO package is never going to change the meaning of that
reference.

Well, not quite. It will still use the same /symbol/ foo:bar, but its
SYMBOL-FUNCTION may change, of course.

* (defpackage 1 use :cl))
#<PACKAGE "P1">
* (defpackage 2 use :cl))
#<PACKAGE "P2">
* (in-package 1)
#<PACKAGE "P1">
* (defun foo () :first-definition)
FOO
* (in-package 2)
#<PACKAGE "P2">
* (defun bar () (p1::foo))
BAR
* (bar)
:FIRST-DEFINITION
* (defun p1::foo () :second-definition)
STYLE-WARNING: redefining P1::FOO in DEFUN

FOO
* (bar)
:SECOND-DEFINITION

 

[Henrik Motakef]

But the read-time vs run-time (or compile-time) distinction makes more
sense to me. If a python function references foo.bar then by changing
the value of foo I can make the function refer to a different foo.bar,

[...]
Well, not quite. It will still use the same /symbol/ foo:bar, but its
SYMBOL-FUNCTION may change, of course.

Rereading your paragraph, it should be noted that changing the
/package name/ of any referenced packages afterwards (which is closer
to changing the value of "foo", i.e. having foo refer to another
module) indeed won't affect users. I.e., after the previous example:

* (defpackage p3 use :cl))
#<PACKAGE "P3">
* (defun p3::foo () :something-completely-different)
P3::FOO
* (rename-package 1 -old)
#<PACKAGE "P-OLD">
* (rename-package 3 1)
#<PACKAGE "P1">
* (bar)
:THIRD-DEFINITION

 

[Alexander Schmolck]

Now I am getting a bit confused once more, since python doesn't have
symbols,

True

'as

 

[Erann Gat]

| Modules work at compile time or run time depending on the module system.
|
| Common Lisp has a package system but no module system (but it's possible
| to add one -- see e.g. http://www.flownet.com/gat/locales.pdf).

Ah. I had read that one before, but never realized that it describes
a module system. That gives me some idea what it's all about.
Thanks.

I really should have called them modules, not locales. (Maybe I'll change
the name in the next version.) Locale nowadays has to do with
internationalization. But I chose the name out of respect for the
original design in T.

| Python has a module system that works at run-time, but no package system.
|
| Does that help?

Now I am getting a bit confused once more, since python doesn't have
symbols, and so the distinction between modules and packages gets
blurred (in my mind at least): A python modules maps strings directly
to values without symbols ever entering the discussion.

Modules map symbols/identifiers onto values.

instead of just "modules map symbols onto values."

Lisp uses symbols (and sometimes other things as well) as identifiers.
Python uses strings.

I guess what I am saying is that, while packages without symbols don't
make sense, modules don't require them. But then, neither did you
say they do, now that I read what you said over again.

That's mostly right. At some point you run into the problem of defining
what a symbol is. In some contexts "symbol" means nothing more than
"uniquified string", in which case Python strings are really symbols:
1

In Common Lisp symbols have extra stuff attached to them, and the term
"keyword" is sometimes used to refer to a uniqified string without that
extra stuff. But this usage is far from universal.

E.