RMS on why Emacs lisp doesn't have namespaces
lists.gnu.org
lists.gnu.org
Applied to code, it's really a matter of how you look up names. Prefixing is just the situation where there's no language assistance in looking up names. Namespacing is just prefixes plus some automatic help in looking up partial names.
Yes. With true directories, you can implement directory rename() with O(a+b) time complexity, where a and b are the depths of the paths to the directories. With a flat key/value store, directory rename() requires at least O(n) time complexity for n directory children, since each child must be renamed.
* rename all descendants on directory rename (expensive--takes O(n) time for n descendants).
* log each rename() and translate a key with a new directory name into a key with the original directory name (requires O(k) space for k renames and O(d) time in the worst case for translating a path of depth d whose directories have all been renamed; introduces the need to garbage-collect log records when all descendants of a renamed directory get deleted).
Granted, this is a more nuanced than what I said before about rename() requiring O(n) time complexity when implemented on top of a key/value store, but the second option is still more costly than rename() with true directories. I'm not sure (but cannot prove at this time) that we can do better than the second option above, but would love to hear your thoughts.
Instead of a flat list of file names for each directory, you store the file names in a trie, so that files with a shared prefix in their name have a shared ancestor node in the trie. To do a directory rename, you just have to find the node in the trie that corresponds to the directory, move that node to a different location in the trie and change the portion of the name that is stored in that node.
But then, if they behave like directories, and the software treats them like directories, aren't you effectively implementing directories in everything but name? (I mean, of course current software doesn't actually treat directory names this way; but it seems like changing the data structure is going a long way to maintain a directory-less fiction.)
I think that
$ mkdir -p a/bc; touch a/bc/{d,e}
$ cd a; mv bc Bc
If there are files with names bc, bd and be, `mv b B` now renames all of those to Bc, Bd and Be. With normal directories, there is no way to do that as one operation.
foo.subbar
foo.subduh
foo.submeh
S3 works closer to a key/value store than to a file system.
To be honest my comment was based on OpenStack Object Storage and I can't say if S3 works exactly like that, but being OpenStack kind of a clone I suspect it does.
Prefixes are more like an simple hack.
The idea of package has both advantages and disadvantages:
Advantages:
* packages prefix can be omitted if the symbol is accessible
* package is an actual data structure. This allows me to do calculations with it: for example I can find all symbols in a package or I can find all packages.
Disadvantage:
* more complicated
* conflicts possible when I want to use symbols from some other package in a package
WINDOW-STREAM-DRAW-STRING
What is the prefix of above symbols?
Although, `tcp-` and `window-` seem like they might be used in the way you expect.
(Not that I am against namespacing - I think being able to have namespaced packages is a really good idea).
import really_long_name as rln
I think RMS is having the same problem really smart people have: if it can't be made perfect I don't want it. I regularly see this in some smart people. They reject stuff because it's not the way they want it, without them being able to articulate why they don't want it.
In the early 90's I (and others) wrote not a small package and we used prefixes to avoid problems. It was ugly though, and a real package system would have been nice. For those interested, it's here: https://github.com/franzinc/eli
Packages were far from useless in my experience.
This has a few drawbacks that are obvious. It also has a few benefits that are perhaps not as obvious.
To list a few. If I want to override a function that a lot of other folks use, I can just redefine that function. I don't have to find a way to convince a module system that for every importer of "Foo" I want to override "do-baz." I just provide my own definition of "foo-do-baz."
Similarly, if I want to find all of the places that this method is used, a very simple textual search works. (This is debated in that thread a little.)
Finally, since emacs is ultimately made for direct user experiences, if someone wants to try their hand at creating some things, they don't have to learn about any module system. Simply prefix your functions with a name and you are done.
That last really needs underscoring for some of us. You want to try your hand at writing an emacs extension? Simply start defining stuff in the scratch buffer. If you want to make sure it is saved, do so in a file. No need to setup any sort of module system.
Now... all of this sounds like I am against a module system. I honestly just don't know enough to care at the moment. I suspect they are oversold. I also suspect they are somewhat useful at times. Don't know which way the needle ultimately falls.
Edit: Looks like I removed an opening sentence. Apologies. I meant to lead this off with, "Ah, that makes sense. I think I can see the difference..."
That's possible and easy using Common Lisp packages. Just use DEFUN with the symbol naming that function, and anyone using that function will now use the new name.
> Similarly, if I want to find all of the places that this method is used, a very simple textual search works.
That doesn't work, but a symbol-based search will.
> That last really needs underscoring for some of us. You want to try your hand at writing an emacs extension? Simply start defining stuff in the scratch buffer.
CL is not so great at that, but for other reasons.
Same for the second scenario? Isn't the symbol Foo essentially shadowed, depending on the package?
CL-USER> (defpackage #:foo (:use #:cl))
#<PACKAGE "FOO">
CL-USER> (in-package #:foo)
#<PACKAGE "FOO">
FOO> (defun func () 1)
FUNC
FOO> (export 'func)
T
FOO> (defpackage #:bar (:use #:cl #:foo))
#<PACKAGE "BAR">
FOO> (in-package #:bar)
#<PACKAGE "BAR">
BAR> (func)
1
BAR> (defpackage #:baz (:use #:cl))
#<PACKAGE "BAZ">
BAR> (foo:func)
1
BAR> (defun foo:func () 2)
STYLE-WARNING: redefining FOO:FUNC in DEFUN
FUNC
BAR> (func)
2
BAR> (in-package #:bar)
#<PACKAGE "BAR">
BAR> (func)
2
BAR> (in-package #:foo)
#<PACKAGE "FOO">
FOO> (func)
2
> Are you saying that if a package A has a symbol Foo, and another package B has a symbol Foo, how would I override only package B's?
Easily: A:FOO and B:FOO are completely different symbols (unless B imports A or vice-versa). Setting `(symbol-value a:foo)` has no effect at all on `(symbol-value b:foo)`. If package C imports package A, then C:FOO and A:FOO are the same symbol.
If C needs to import both A, but wants to use its own FOO, then it can shadow FOO, which means it would import all the exported symbols of A, except for FOO. IF C wanted to import both A and B, then a correctable error would be signaled; in a typical implementation the corrections would include: using A:FOO in preference to B:FOO; using B:FOO in preference to A:FOO; and aborting the attempt.
The only thing not portably possible to my knowledge is to rename a symbol in an importing package, e.g. making C:FOO2 be an alias for A:FOO. If one thinks about what a symbol is, that makes sense. What would `(symbol-name c:foo2)` be in that case?
All this, BTW, is why I am so keen on Common Lisp as opposed to Scheme: it really is an industrial-strength Lisp. They standardized a lot of stuff twenty years (and three days!) ago, after a lot of thought. Yeah, there's some compatibility cruft, but it's generally not a big deal (and can mostly be hidden, if one wanted to create a MODERN-LISP package).
And I understand what you are saying about CL being nice. I'm currently going through Land of Lisp and it is interesting to see how many things are covered. Granted, even scheme has this, to an extent. Reading SICP feels like reading a book on what was going to rise and fall in programming in the years to come.
Regardless, Thanks!
"using System.*";
"using Some.Namespace.SomeClass;"
"using Some.Namespace.SomeStaticClass.*;"
> The idea sounds nice in theory, but in practice multiple name spaces do not fit into Lisp very well. Common Lisp packages are an unclean kludge; this was clear to me when I implemented them in the 1980s in the Lisp Machine. It is impossible to use them in the way one would wish to use them. > > In practice, you have to write the package prefix whenever you refer to a symbol that has one. It might as well be part of the symbol name itself. Thus, packages complicate the language definition while providing no benefit. > > So in GNU Emacs I decided to make them part of the symbol name itself and not have packages.
Agree or disagree as you like, but there is a reason: based on his experience with Lisp Machine Lisp, RMS didn't see the point.
While packages may not be a great solution they do at least make the the concept of namespacing explicit and a first class citizen of the language.
Old-style programmers who came of age in the 70's and 80's were absolutely obsessed with keeping the number of characters typed as low as possible. There was a reason for this: the keyboards in those days were terrible. I typed my Master's thesis and my PhD dissertation on VT100 terminal keyboards that had a throw of about 1 cm and required a few hundred newtons to get the damned keys to move at all, much less make a clean contact at the switch. It was more like punching a speed-bag for your fingers than typing on a modern keyboard.
But reducing the number of characters typed is not the only reason for having namespaces, nor is it the most important one. When you add a feature to a language you are saying to the users, "The people who designed this language felt that this feature was important enough to implement so we think it is worth your time to use it." That kind of moral persuasion is not to be under-estimated.
In the case of namespaces, having the feature encourages developers working in that language to think more carefully about how to modularize their code.
This argument may also not be enough to justify the complexity, but when evaluating such things there should be some attempt to cover all the arguments for and against, not just pull out the one you happened to find persuasive.
One way is to assume that the user won't import the package; in this case you'd probably name your functions and types in very generic ways. For example your HTTP package would have a REQUEST class, which would be referred to from outside the package as HTTP:REQUEST. People trying to import packages written in this style will eventually run into symbol clashes, and resolving those through shadowing is no fun.
The other way is to design the package for importing. In this case the HTTP package would have a HTTP-REQUEST class, which would be referred to as HTTP-REQUEST from most places (and as HTTP:HTTP-REQUEST in the few cases where you didn't import the package -- but of course you would avoid that because HTTP:HTTP-REQUEST looks ridiculous).
So in that sense it's totally true that a CL-style package system doesn't really solve the problem of name prefixing. It's either going to be part of the name, or it will be in the explicit package name that you'll end up using to refer to the symbol. But who cares? There are other problems that a flat namespace causes, which would actually be fixed by a package system.
Moreover, packages enable one to do things like lock down certain packages, e.g. for security in a multi-user system.
https://archive.org/stream/bitsavers_cmuGosling_4195808/Gosl...
12.2. MLisp - Mock Lisp
Unix Emacs contains an interpreter for a language
that in many respects resembles Lisp. The primary
(some would say only) resemblance between Mock Lisp
and any real Lisp is the general syntax of a program,
which many feel is Lisp's weakest point. The
differences include such things as the lack of a
cons function and a rather peculiar method of
passing parameters.
When you called a function and passed it parameters that were MLisp expressions, they were not actually evaluated until the CALLED function PULLED the values with the (arg index "prompt") function, at which time the MLisp expressions from the CALLING were evaluated in the dynamic context of the CALLED function!!!
The official convention that we would use at UniPress to develop MLisp libraries that would work together without name clashes was:
Prefix all local variable names with an ampersand, then a (hopefully) unique abbreviation for the function name, then a dash, to make them unique across all known code.
So you could not use the same local variable names between functions that used each others parameters, because expressions passed as parameters would be evaluated with the bindings of the called function!
(I've written a couple of ; comments in the code to explain how it works.)
MLisp has a rather strange (relative to other
languages) parameter passing mechanism. The arg
function, invoked as (arg i prompt) evaluates the
i'th argument of the invoking function of the
invoking function was called interactively or,
if the invoking function was not called
interactively, arg uses the prompt to ask you for
the value. Consider the following function:
(defun
(in-parens ; The name of the function.
(insert-string "(")
(insert-string (arg 1 "String to insert? "))
(insert-string ")")
)
)
If you type ESC-X in-parens to invoke in-parens
interactively then EMACS will ask in the minibuffer
"String to insert? " and then insert the string
typed into the current buffer surrounded by
parenthesis. If in-parens is invoked from an
MLisp function by (in-parens "foo") then the
invocation of arg inside in-parens will evaluate
the expression "foo" and the end result will be
that the string "(foo)" will be inserted into
the buffer.
The function interactive may be used to determine
whether or not the invoking function was called
interactively. Nargs will return the number of
arguments passed to the invoking function.
This parameter passing mechanism may be used to
do some primitive language extension. For example,
if you wanted a statement that executed a statement
n times, you could use the following:
(defun
(dotimes n ; n is not a parameter, it's
; just being "declared" as a local.
(setq n (arg 1)) ; The first argument to dotimes
; is the number of times to do
; the second parameter.
(while (> n 0)
(setq n (- n 1))
(arg 2) ; The second argument to dotimes is
; an expression to evaluate.
; Each time you (arg 2) is called here,
; the caller's second parameter
; expression is evaluated in the
; current context.
)
)
)
Given this, the expression
(dotimes 10 (insert-string "<>"))
will insert the string "<>" 10 times. [Note: The
prompt argument may be omitted if the function can
never be called interactively].
http://bitsavers.informatik.uni-stuttgart.de/pdf/cmu/Gosling...
[1] http://erlang.org/pipermail/erlang-questions/2011-May/058768...
(require [blah-blah :as b])
(b/map f xxxx)
Of course, we could just name procedures like, say "list/map" and "this/that" and this is the simplest but clumsy solution.
The great idea from Erlang, is that we could export just few procedures from a module, and hide all the helper procedures, so they will not pollute the global namespace.
Together these ideas are good and, perhaps, worth implementing. But do not forget that just naming issues could easily be solved by having packages and "qualified imports" or "full path" naming like "list:map" or "list/map".
> Skype: No way! That's nonfree (freedom-denying) software.
> Use Ekiga or an ordinary phone call.
However, you'd think given his issues with UNIX he'd still be a staunch advocate of avoiding AT&T.
Mostly, the hilarity of RMS recommending AT&T for some reason makes me think of that scene in the Matrix where Agent Smith asks Neo what good a call is if you can't speak.
My apologies to the downvoters for questioning the dogma of St IGNUcius of the Church of Emacs.
It's a fine distinction to make, but I get it. I don't necessarily agree with it, and I think it's a strange place to draw the line, but I can understand the logic behind it.
If I'm understanding this right, then the only part of Skype that RMS objects to is the desktop client. The network and infrastructure being closed-source does not remove freedom. (NSA is a separate consideration)
What if your phone uses proprietary software?
As has been said, if the software is utterly hardware-specific firmware, such as the software that runs inside a hard drive that handles bad blocks and head movement and so on, he's OK with it being proprietary. A phone which somehow had software of that sort (to run an integrated answering machine?) would presumably be OK with him as well.
With Skype, you cannot connect your own client to their network; you must run their proprietary, highly secretive client.
With the phone system, you can attach any device that you want. You can use a dumb, analog phone, or a digital phone running free software, or a digital phone running proprietary software, or modem, or a fax machine, or whatever, to the phone system.
Note that this was not always the case (https://en.wikipedia.org/wiki/Carterfone, https://en.wikipedia.org/wiki/Hush-A-Phone_v._United_States).
Now, he also does have other concerns about the infrastructure; he would generally prefer to support infrastructure running on open tools and technologies, and may have various other concerns with particular providers.
But he sees that as a separate question of the ethical question about running non-free software on his own computers.
It doesn't bug me, because without people pushing as hard for freedom as RMS has, we'd wouldn't have what we have today.