Hi Xah,
I myself am proponent of namespace-lessness... That was until I
discovered CLOS and the multi-methods...
For any other language I would pick Apple's approach approach to
Objective C, and the frameworks that they've put (libraries) - e.g. use
couple of letters to prefix your class/functions - like NSObject,
ABAdressBok, UIButton. For these languages, where only single-dispatch
is available, there is no need to prefix their methods, as they are
always send to one object, and this object itself becomes a "package" -
basically it would grok certain "words", "messages", "id-s" whatever you
call them.
But let's go back to CLOS:
Take for example the Lispworks CAPI gui library. To display a component
you normally do:
(display ...)
If you haven't added the CAPI library to the (:use) list then you do:
(capi:display ...)
But let's say you have another library used in your application, that
has the same multi-method "display". For example a PDF library might
have such.
To call it, you would again do:
(display ...)
And if you haven't added the PDF library to the use list:
(pdf:display ...)
In the case where both libraries (:use "CAPI" "PDF") are used, there
would most likely be a problem, but at least you can solve it by
prefixing it with capi: and pdf:, but this would still keep short-naming
in the rest of the modules where that's not needed. The more decoupled
the system, the less you would run into such problems, and most of the
coupling is in the actual application code (not libraries) where you
assemble stuff.
And overall it would be better than naming your methods like this:
(capi-display)
(pdf-display)
Yes this would be safe everywhere, and granted such naming works well
for functions, classes, global variables, etc - but really for METHODS,
being a MESSAGE it makes it unattractive.
Other than that, packages (namespaces) in Common-Lisp are also used for
special cases: The KEYWORD package, The SETF one, and COMMON-LISP would
always be the bible :)
Dimiter "malkia" Stanev.
Xah Lee wrote:
comp.lang.lisp,comp.lang.functional,comp.lang.perl.misc,comp.lang.python,comp.lang.java.programmer
2008-11-25
Recently, Steve Yegge implemented Javascript in Emacs lisp, and
compared the 2 languages.
http://steve-yegge.blogspot.com/
http://code.google.com/p/ejacs/
One of his point is about emacs lisp's lack of namespace.
Btw, there's a question i have about namespace that always puzzled me.
In many languages, they don't have namespace and is often a well known
sour point for the lang. For example, Scheme has this problem up till
R6RS last year. PHP didn't have namespace for the past decade till
about this year. Javascript, which i only have working expertise,
didn't have namespace as he mentioned in his blog. Elisp doesn't have
name space and it is a well known major issue.
Of languages that do have namespace that i have at least working
expertise: Mathematica, Perl, Python, Java. Knowing these langs
sufficiently well, i do not see anything special about namespace. The
_essence_ of namespace is that a char is choosen as a separator, and
the compiler just use this char to split/connect identifiers.
Although i have close to zero knowledge about compiler or parser, but
from a math point of view and my own 18 years of programing
experience, i cannot fathom what could possibly be difficult of
introducing or implementing a namespace mechanism into a language. I
do not understand, why so many languages that lacks so much needed
namespace for so long? If it is a social problem, i don't imagine they
would last so long. It must be some technical issue?
Could any compiler expert give some explanation?
Thanks.
Xah
∑ http://xahlee.org/
☄
--
http://mail.python.org/mailman/listinfo/python-list
