> Those are not symbols. This is critical to a representation that says > that conses are containers and symbols are terminals. If terminals are > conses that contain symbols, then it becomes painful programmatically > (not to mention much slower) to detect leafness on recursive descent.
So I did mention the need for a uniqueness step (just like one gets for "free" with symbols--that is, not free, but built in).
However, that doesn't take care of everything, and I thank you for your comments; they have brought out several issues I had not thought about in that way before.
> Those are not symbols. This is critical to a representation that says > that conses are containers and symbols are terminals. If terminals are > conses that contain symbols, then it becomes painful programmatically > (not to mention much slower) to detect leafness on recursive descent.
So I *did* say that uniquification was a part of the solution. I do grant that this is an increased cost (perhaps a very high one, depending on the context).
However, thanks for your reply; I think I now understand what you were getting at better than I did before.
> Conversation is give and take, and you are not giving. Moreover, you > have self-identified as trying to manipulate me, and I do not appreciate > that whatsoever. This will hamper my desire to respond further to you > in conversation.
Eek, you've totally misconstrued my point.
It's that I had thought pretty seriously about the topic, and concluded that packages don't add much if you already have modules and other relevant facilities. I was asking you to give some of your examples and reasoning that conclude the following.
When I criticized particular examples, it was not to take a "pot shot", but rather because I thought those examples did not quite prove your point, and my goal is to see if that point is really true or not. (I'm still not sure, but now I see more of the depth of the issue than I did at first.)
When I said "I want to provoke you to make the strongest possible argument", that's not a desire to manipulate! I'm sorry if that was an unhelpful way for me to express my desire. I was just saying what what seem to be pot-shots are not pot-shots, but actually cases where it seemed to me that your argument was weak in a relevant way.
> Because mine is not the only opinion here and much though I have a desire > to offer my arguments, I have no desire to offer them against a vacuum. > I can't even tell if you are hearing me unless I see you do a more elaborate > example than you do because I can't tell if (a) you are not reading what > I wrote, (b) not thinking hard about it, (c) thinking hard about it but not > articulating a perfectly sound alternate theory.
I'm certainly doing A and B; I'm a little too modest to do C.
> I feel a lot like a monkey in a box being prodded right now. "Oh, let's > see if we can make him make a new sound." I do NOT like it.
Eek, that was *not* my intention. I want to understand the subject, but that takes more than just taking someone's word for it. That's why I argue back--because I want to test the *argument* (not you), and to understand.
I'm sorry you abandoned reading just because you misunderstood my intention.
> You can write simple, self-contained Scheme code to do X. However, when > you start mixing in code from different sources, the things you have to > do in Scheme to avoid name conflicts are not as clean or convenient as > with CL packages.
> In this case, X happens to be symbolic processing. Couldn't you say > the same thing for any X?
The identity-level issues are the same but central to the notion of a symbol is interning, which folds two objects into the same object.
In other situations, as with (MAKE-INSTANCE 'MY-CONTAINER) the default is not to fold but to separate.
Identity folding should not be done without a strong understanding of the consequences of confusion. It comes down to a statistical question of whether it is better in the face of no information to assume two objects distinct or to assume them the same. I think there's no way you can argue that people should defaultly assume every object is the same object. (Though I'll listen while you try to make such a case.)
So the question is really over names, and the question goes on in the prsence of an understanding that everyone likes short names. Folding all objects named JOHN into the same space means every parent in the world has to name they're kid differently. By separating namespaces, one can stay in the realm of names but still refer to different objects. That's what packages do. That's what the Scheme system does not do.
Yes, you can move to non-symbols, but then that's just to say that you can move to a paradigm which doesn't do as much name-folding by default, which is to say you're admitting that the name-folding was the problem, which is to say you're admitting that the CL naming system is less prone to the problem than the Scheme one, which is kind of losing the argument. Or so it seems to me.
> It's interesting that CL packages partition > symbol plists and not just their associated functions/variables, but > we're still talking about the same concept.
No, we're only talking about identity.
The use of functions, variables, and plists is just felicity because it means we have some sample operations to try. People seem to be not understanding that functions and variables are already carefully described by the language not to be "slots" so that you can store them outboard by doing [approximately]: (defun symbol-function (name) (gethash name *the-functions*)) since many symbols don't have functions and vendors involved in the design of the standard didn't want to require storage to be consumed by all symbols. As such, we are talking only of identity, and nothing else. This is not about symbol structure nor primitive operations. It might as well be (defun get-favorite-movie (person-name) (gethash person-name *peoples-favorite-movies*)) There is no structural difference other than that we supposedly had to define one fewer function to make a coherent example. But since people have managed to get confused by the choice of an existing function, I guess we can't use short examples. (And I find that sad.)
Identity. Identity. Identity.
That is the only thing under discussion. Everything else is a derived consequence of identity or an orthogonal issue.
> > - The information is manifest in symbols, a primitive data structure > > in the language
> I'd like an example that stresses this feature of CL apart from the > package system.
I've lost too much context because you elided stuff. I'm not going to go digging, but if you dredge up more context and reask the question I will try to answer.
> Regardless of the discussion among CLers about whether its package > system is the best solution, I think it's a given that CL's package > system is better than nothing, which is what R5RS Scheme has.
A happy outcome for me in this would be an agreement to just refer to scheme symbols, at least in a language-neutral discussion, as "keywords" and not really as "symbols". This discussion is starting to look to me very similar tot he question of whether C has integers. I think Lisp has the moral right to say it has integers, and I'm happy calling C's truncated integers ints. And these languages can call their internal data structures whatever suits their language community. But when interchagne is needed, I think either you have to agree that no one may use the name that occurs in more than one place or you must agree that someone has more moral right to it in an interdisciplinary conversation than someone else... Of course, we're not involving the Scheme people in this discussion, so I'm not likely to get a useful agreement on terminology in this forum. But let's call it part of the "consensus building" process toward some greater end.
> > The above programs are contrived, but I hope show enough meat that you > > can see the problem. Try casting them into Scheme in whatever way suits you > > and we can proceed to the next conversational step from there.
> I doubt whether Erann is likely to take you up on this, but with a less > package-centric example I would.
> The interesting thing is that this separation of symbols will help you > in all cases where symbols are used as data (either keys or values or > whatever) in "global" data-structures, including, but not limited to, > the property lists of symbols themselves (when the same symbol is > shared between applications), but also other "global" lists, or > hash-tables, or other data-structures.
Kent pointed out something broader--which I had missed until recently.
This is not just true of global data structures. It's also true of data structures that the packages export to some third place, which then combines them. That is, even if it is all really local, it still works.
However, it seems to me that there is still a curious kind of "global variable" thing going on here, though I can't quite put my finger on it yet. I need to think more.
> [Mathemeticians reason by reducing a difficult problem to a specific set > of problems with known computational complexity. So they say a problem > is a "traveling salesman" problem even when it has nothing to do with that. > This effectively avoids spinning one's wheels uselessly. > I have, as a career philosopher engaged regularly in this kind of thing, > sought to reduce philosophical problems to problems of known difficulty > in the philosophy domain, and when I find one that is an unresolved paradox, > I do not descend further into it conversationally for the same reasons. > I think philosophers routinely do this, though I don't think they have good > terminology for talking about the fact that they do or the thing it solves.]
As an actual career philosopher here:
Suppose one wants to talk about P, but it looks like one's opinions about P are going to depend on (say) how one deals with the other-minds problem. And the other-minds problem is a famous rats nest.
So one thing to do is called "bracketing". You bracket the other-minds problem, which means to leave it unexplored for the moment, and see how far you can get in talking about P without worrying about the deeper harder problem. This is close to the operation you describe above.
However, thinking about the other-minds problem is part of the bread and butter of philosophy--that is, bracketing is a strategy for making progress in talking about P, but it's not a satisfactory strategy full stop--because we don't mark areas "off limits" and say "you can't talk about this one any more". Another way to put it is that there isn't such a thing as an unresolvable paradox, really, only paradoxes that haven't yet been resolved.
A lighter weight version of bracketing is noting that something is controversial. I might say "ah, P is true, because the right solution to the other-minds problem is XXX." But the person I'm talking with will say "oh, but the other-minds problem is very controversial". That's a signal that the conversation has two turns. One, I need to prove XXX--and then we will probably never get back to P. Or, I can try to demonstrate P without presuming the solution XXX to the other-minds problem. If the other person does not *want* a discussion of XXX, rather than leaving both options, they will say "let's bracket XXX for a moment" (read, "forever").
For example, I think that the solution to the other minds problem is nicely given by taking Turing's test seriously; I'm a Turing-test-believer. If I'm talking to someone else who shares that opinion, then we can assume it in talking about P--no need for bracketing.
> Yes, you can move to non-symbols, but then that's just to say that you can > move to a paradigm which doesn't do as much name-folding by default, which is > to say you're admitting that the name-folding was the problem, which is to > say you're admitting that the CL naming system is less prone to the problem > than the Scheme one, which is kind of losing the argument. Or so it seems > to me.
When I think about this, my inclination is to say that for many of these programming problems, the answer in Scheme is going to be "don't use the symbol type". Indeed, that means the Scheme symbol type is less suitable for certain kinds of computations.
But the Scheme advice is going to be to use things like procedures instead for all these things. Now, you point out that whatever other things you use might well have uglier print syntax--but this is not inherently clear to me, but even if true, it doesn't really matter all that much to me. I don't think it's a huge problem, or much of a problem at all.
Of course, I'm not saying anything here more than a somewhat vague sketch. It seems to me that in a language like Scheme one simply does symbolic programming by using different (more flexible) datatypes than Scheme symbols. I don't think any serious reduction in expressive power is going on here, though, but I admit I have no good argument for that at present other than my general intuitions and experience.
In article <sfwadt7rm61....@shell01.TheWorld.com>, Kent M Pitman
<pit...@world.std.com> wrote: > I'm not questioning your credentials.
I didn't think you were.
> I thought you had asked effectively > for mine since your question seemed to ask "is it just the case that the > other side is speaking out of ignorance".
No, that wasn't my intent. What did I say that gave you that impression?
> No quibble with your credentials here. I'm not suggesting you are not > entitled to engage in this conversation in any way. I'm just suggesting > you're wrong in point of fact if you think there is no valid defense of a > package system. Packages and modules are orthogonal structures and both > have a place. I'm not anti-module, I'm anti-module-qua-panacea.
I never said nor meant to imply that there "is no valid defense of a package system." (I called it a "necessary evil", which is not a glowing review, but not a condemnation either.) But the only reason I asked the question that began this thread is that people I respect have a differing view, and I want to understand why.
> > I feel fairly confident that I'm sufficiently non-idiotic that if > > someone can't explain something in this area so that I can > > understand it there's a good chance that it's their fault and not > > mine.
> I use this same rule of thumb myself, so I can relate. Then again, I > think you should not conclude from someone's inability to articulate a > natural langauge rule to explain a philosophically complex behavior > that they do not have deep-seated and real beliefs, nor even perhaps > well-founded beliefs.
I have drawn no such conclusions. If I had I would no longer be participating in this discussion. (If you want to see how I participate in an arena where I *have* drawn such conclusions go look up my postings on comp.lang.perl.)
> I have neither any doubt that > my belief in packages is technically, not just emotionally or > historically, well-founded.
Yes, I believe you, and that's what I want to understand.
> I'm happy to engage in this discussion with you on that basis.
Good! That's the basis on which I want to hold the discussion.
> I'm even happy for you to conclude "Because > Kent and others cannot say what I need to hear, I will continue to > believe what I believe."
My position is: because Kent and others have not explained it to my satisfaction (yet) am going to tentatively continue to believe what I believe, but fully open to the possibility that I might be wrong. (It is my hope that anyone engaging me in conversation is also open to the possibility that they might be wrong, but that's not a prerequisite. What I *do* insist on is that people not try to ascribe my lack of understanding to some character flaw, like a refusal to listen or being an idiot. That point of view I reject a priori. You certainly haven't done that, Kent, but you are not my only correspondent.)
> (That is, I'm happy to live with the belief > that you are wrong. Heh... Which incidentally is on a statement that > you are wrong, it is just a statement about my belief structure.) I'm > not happy for you to assert (and I hope you are not asserting, I'm > just checking) that "The inability of various people to articulate a > defense is a de facto proof that no such defense exists." or that kind > of thing.
No. I just want the person on the other end of this conversation to accept part of the responsibility for successful communication. I am weary of Erik and Rahul who just rail at me for being an idiot when I don't get it. Maybe I am an idiot, but being repeatedly told so just doesn't help.
[Technical discussion begins here.]
[Much snippage]
> No. The critical value is the ability to TYPE the symbol without > doublequotes or other impediment in most cases.
I presume you mean "type" as in the action of pushing keys on a keyboard, not "type" as in data type.
This sounds like you're saying that being able to type:
'FOO
is significantly better (on *technical* grounds) than having to type:
(setf foo (make-symbol-object :name "foo"))
and then typing "foo" rather than "'foo" from then on.
Is that right?
[T alternative syntax description snipped]
> This is a computationally ok answer, but it is a refutation > of any claim that the language is using "symbol" processing at that point.
OK, this tells me what symbol processing *is*, but I still don't understand your reason for believing that symbol processing on this definition is a Good Thing (tm). In fact, you seem to implicitly be making the counter argument here. If the T way is "computationally OK" as you say, what are the technical grounds for preferring symbol processing? The amount of typing involved can be the same either way with appropriate reader macros.
Have you read Drew McDermott's paper "Artificial Intelligence Meets Natural Stupidity"? There he argues that AI gets itself into trouble by attaching too much implicit meaning to the print names of symbols. This is (I just realized) implicitly a general argument against what you seem to be calling "symbol processing". Do you agree with that assessment? If so, do you disagree with McDermott's argument? (BTW, McDermott is not the mentor I alluded to in the posting that started this thread, though as my thesis advisor's thesis advisor he has of course had a significant influence on my own intellectual development.)
> FOO is a symbol. foo is a symbol. I don't mind typing 15\r or |15r| > to preserve case. I don't mind typing tv:foo if I'm not in package TV > to get to that symbol. But basically I want unimpeded access to the name > as part of my syntax for literals if it's going to be what I think of as > a symbol.
Why is it not enough to bind the symbol to a variable (or a global constant) and refer to the symbol by the name of the variable?
> I don't mind quoting symbols. In Macsyma, I could do > X:10; > F(X,Y):=X+Y; > F(X+3,'X+3); > and get back X+16 which contains one symbol and one number.
Ah! This is an enlightening example. The crucial point here, it seems to me, is that you can refer to the symbol whose name is the string "X" by typing "'X", and you can refer to the value of that symbol by typing simply "X". Is that right?
So consider the following alternative design. Define a reader macro, say, =X, that expanded to (symbol-value X). (Note that there is no quote in front of the X.) Now we write:
(defconstant x (make-instance 'symbol-class :name "X" :value 10))
> > The interesting thing is that this separation of symbols will help you > > in all cases where symbols are used as data (either keys or values or > > whatever) in "global" data-structures, including, but not limited to, > > the property lists of symbols themselves (when the same symbol is > > shared between applications), but also other "global" lists, or > > hash-tables, or other data-structures.
> Kent pointed out something broader--which I had missed until recently.
> This is not just true of global data structures. It's also true of > data structures that the packages export to some third place, which > then combines them. That is, even if it is all really local, it still > works.
That is what I label under "global", or "shared" as I've also put it (since a resource that is shared between two, even unrelated, packages might not necessarily be available just for everyone).
> However, it seems to me that there is still a curious kind of "global > variable" thing going on here, though I can't quite put my finger on > it yet. I need to think more.
And this global vs. local thing is completely unrelated to the issue of global vs. local variables. E.g. a hash-table can be a global, or shared resource, even if it is only ever bound to a lexical variable, like in:
(let ((my-secret-hash (make-hash-table))) (defun add-definition (name definition) (setf (gethash name my-secret-hash) definition)) (defun lookup-definition (name) (gethash name my-secret-hash)))
Given that other packages/programs are given access to add-definition and lookup-definition, the hash-table bound to my-secret-hash becomes a shared or possibly global resource. The package system will ensure that people in different packages can use symbols as definition names, without having to worry that they trample on other people's definitions.
_Furthermore_ the package system even allows distinct packages to cooperate in an orderly fashion, allowing one package to see the definitions of another package for some things, but not clash with other things.
You can either disallow shared data structures, or disallow interned symbols (i.e. people will have to explicitly share gensyms/uninterned symbols/strings in order to both refer to the same symbol), or use a package system to deal with such a situation. I'm very certain that I don't want to live with the former two "solutions".
[ Aside: Many CL programmers would prefer making the hash-table in the above available through a special variable, instead of hiding it away inside closures, aiding interactive debugging ]
Regs, Pierre.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
> ... It seems to me that in a language like Scheme one simply does > symbolic programming by using different (more flexible) datatypes than > Scheme symbols. ...
It's fine to do this, but then you are inventing at the user level things that the compiler won't be able to recognize idiomatically and help you with using operators and data layouts that are primitively efficient.
I feel about this the same as I felt in Maclisp when people used to do copy-tree by (subst nil nil x) or in Teco when people would compute absolute value by using -3^@^@ [don't ask--just take my word for it that control-@ was not intended to do absolute value]. There is a difference between implementation and expression, and CL allows me to express my need, not just implement my need. I don't want to substitute an alternate implementation when I can say directly my desire and let CL do the data layout and management.
> I don't think any serious reduction in expressive > power is going on here,
Yes, it is. The shift from expressive tasks to implementation tasks is the essence of the difference between Lisp and other languages for me. Every time you chip away at it, you chip away at Lisp's power. I said before that this is not about Turing power, and this remark on yours is an appeal to Turing power. Expressive power is exactly about concise targeted notation.
Suppose we forget Lisp for a moment and talk only Goedel numbers. Your argument is the same as saying "you don't need a low-numbered function, since a higher numbered function will work just as well". But if you really think this, then you don't understand why foo.com is more valuable as an intellectual property than thisnameshouldsellforjustasmuchasfoodotcomdoes.com They may be turing equivalent (each just a pointer) and you might claim there is more "character" in the longer name, but expressiveness of languages is about choosing the right things to be short. What Goedel numbering tells us is that there are a finite number of short names and after that there are only long names. Expressiveness is about keeping programs short in the face of that. It's a form of huffman coding, if you will, but the game is not linearly arranged so you don't always recognize it thus.
> though, but I admit I have no good argument > for that at present other than my general intuitions and experience.
I'm not denying you have intuitions, and I value intuitions, but intuitions cannot win the day. They inform goalsetting but they cannot dictate goalsetting without forcing bad decisions.
As to experience, its power and relevance is only correctly judged in the context of a correct (possibly "subjectively correct" and "subjective judgment", alas) understanding of the problem. Let me be concrete about this subjectivity: It happened several times that I came up against people in the design of ISLISP who were national representatives much older and "more experienced" by some metric. Certainly they had been programming longer. But I had done 10 years of Lisp language design, and they had not. And moreover, I had been present for the design, deployment, and later bug reports of several dialects of Lisp, something they had never done. Those people brought important experience that I did not have but also vice versa. We learned to inform and respect each other.
Although a standard resume would have shown them to simply be "more experienced than I". I have come to understand experience as massively a multi-dimensional issue. People are used to this distinction in resume-writing when they say "n years experience in buzzword-37" but they are not used to making this distinction at a finer granularity. But I think the fact that they are not articulate about their microexperience doesn't mean it doesn't matter. Whether or not you have experience in general is not in question; whether or not you have experience at all in the issues I'm raising is an open question. (You might legitimately say the same of me. I don't mean this to be insulting in any way. I would not be insulted by the same statement said back.) The conversationally tricky part is getting to a point of view where people even agree on the problem.
... And, incidentally, part of the problem in so doing is that words we use in English have delayed attachment of semantics until the point of use; they might do better by early attachment of semantics according to package systems so that more refined uses of words (or, as I once in a while do in the HyperSpec because I know there is only one glossary of relevance, subscripted uses of words) are possible. We say we are all talking about symbols, but we trip over our failure to say cl:symbol or (scheme symbol) in the conversation in order to disambiguate whose notion of symbol we mean... So your experience in having navigated this conversation, and its complexity, due to late-binding and the absence of an English-based package system should perhaps tell you that a package system would be helpful. But somehow it doesn't. So maybe you mean something different about experience than the experience I see you having. Getting a foothold for an intelligent conversation is much harder than people generally acknowledge. They often prefer to ascribe the difficulty to people being obstinant. It's often more fun to punch someone out than to ask them for a detailed explanation of how they define all the words they're using. (And if you're like Clinton and helpfully volunteer that you've observed a difference in your own meaning of "is" and the meaning that others are inferring, people don't say "thank you", they accuse you of obfuscating... go figure.)
> > > > Geez! Erann actually *likes* CL, probably more than Scheme, but > > > > (I'm guessing) doesn't happen to think it is Absolutely Perfect. > > > > As a result, he perhaps complains about things once in a while.
> Once in a while? What else has he done in c.l.l in the entire time > I've been reading it?
It is not my impression that that is what Erann does. I don't always agree with his approach but I am interested in his opinions and his accounts of his personal experiences.
> > > He seems to not like actually using it, then.
> > So he must like everything about it, or he's against it?
> No, but he doesn't seem to like anything about it that he couldn't get > elsewhere, along with other features that he would like better.
I think that sentiment is more than being overly sensitive to criticism/confusion/disagreement. (Just MO)
> Because mine is not the only opinion here and much though I have a desire > to offer my arguments, I have no desire to offer them against a vacuum.
But there isn't a vacuum here. I read this newsgroup every day with the hope of reading code or practical examples of CL solutions and I must say that your last three posts (that I have bookmarked) have given me a lot of food for thought.
It's considered bad netiquette to post "me too" or "I agree" on USENET, so I don't, but maybe this post makes you feel somewhat better. You helped at least one newby to better understand CL.
> > > > READ causes noticable side effects. This can create dependencies > > > > on the order in which things are read.
> > > EVAL and/or COMPILE-FILE causes noticeable side-effects too. This > > > creates dependencies on the order in which Scheme expressions can be > > > processed.
> > Woah!!! Who said anything about Scheme?
> This whole discussion of packages came from a discussion of modules vs > packages which came from a discussion of what symbol processing is which > came from a discussion of what is criterial to a lisp which came from a > discussion of whether Scheme is a Lisp... or so I thought. Wasn't it > obvious. ;)
> Ok, sorry for misjudging your sense of context. My reply was probably > out of frame if you weren't in the same frame of reference...
The discussion has been all over the map. I've been trying to limit my comments to *only* those things about the package system that have bothered me. In Erann Gat's original post, he says
``So I've always considered packages as more of a necessary evil than a feature. I was told that this view was common in the CL world.''
That is pretty much my opinion, and that's what I said initially.
> You've raised a lot of problems but you haven't said what featurism you > expect. As long as your only complaint is that it can be used wrong, it's > hard to respond to. If you are looking for it to keep you from doing a > certain thing or allow you to do a certain thing, it would be easier to > respond to. As detailed as you've been, I still can't generalize from > your specific examples to anything other than "this isn't good for me" > and so I can't do much to help. Even a guess at what would be better would > again make the discussion concrete for me.
Well, I cited a number of anecdotes that have made me say `damn this @#$%! package system!' What I'd prefer is for the package system to do what it is doing now, but without the annoyances. Yes, it's a subjective problem, and yes, the solution is hard.
> I think honestly that you were wrong when you said you aren't arguing for > Scheme. Scheme has a solution (with its incumbant problems--they are not > being inconsistent per se, they are just trading one problem for another). > I don't like the problems created by their solution. But you sound like > you would.
Is there a post where I said `Scheme solves the problem'? And what is the Scheme solution? Scheme48 has a module system. MzScheme has a different one. MIT-Scheme has yet another.
> > > In general, I think the > > > problem is more that CL does not seek to handle this problem than that > > > CL would not be capable of handling this problem with available data > > > structures if it chose to provide you the necessary operators. I don't > > > see a data structure problem here; perhaps an API weakness. But new APIs > > > can be written without changing the language spec.
> > Well, I'm not suggesting a change to the language spec. I just want > > to not see spurious `name conflict' errors.
> The errors are not spurious. They happen for a reason. I'm sure you > realize this, but I'm not sure you see the significance of realizing this.
Well, when I type => foo Unbound variable `foo'
=> (use-package "FOO") Error: symbol 'foo' already exists
This, to me, is a spurious error. I made a single typo, but I have to make two trips through the error handler?
g...@jpl.nasa.gov (Erann Gat) writes: > > No. The critical value is the ability to TYPE the symbol without > > doublequotes or other impediment in most cases.
> I presume you mean "type" as in the action of pushing keys on a keyboard, > not "type" as in data type.
Yes.
> This sounds like you're saying that being able to type:
> 'FOO
> is significantly better (on *technical* grounds) than having to type:
> (setf foo (make-symbol-object :name "foo"))
Yes.
Though actually you meant to say (or (find-symbol-object-named "foo") (make-symbol-object :name "foo"))) or perhaps just (intern "foo") since that's what INTERN does. As to whether a SETQ is done or not, that's a context thing in code; because of INTERN, the SETQ is sometimes not needed.
> and then typing "foo" rather than "'foo" from then on. > Is that right?
Yep.
> [T alternative syntax description snipped]
> > This is a computationally ok answer, but it is a refutation > > of any claim that the language is using "symbol" processing at that point.
> OK, this tells me what symbol processing *is*, but I still don't > understand your reason for believing that symbol processing on this > definition is a Good Thing (tm).
Because although designed before there was an issue over this, its importance came to be understood later as a counter-theory to what we came to know as "procedurally embedded data". The more information one can put into data, the less is in the code. That in turn leads (not all at once but in many tiny design steps) to the notion of the program that is reprogrammable without recompilation. Every time you pull a decision back into the code, you must recompile the code in order to change that decision. I'm not saying that every datum in a program should be symbolic, but I am saying that in the cases where people make that information symbolic, there is substantial opportunity to revise the program behavior by merely pushing symbols around.
> In fact, you seem to implicitly be > making the counter argument here. If the T way is "computationally OK" as > you say, what are the technical grounds for preferring symbol processing?
There were a lot of programs in the mid-1980's at the advent of AI Winter where the assertion was made "this program can be translated to C++ therefore C++ is better". But there was never any proof that those programs could have arisen in C++. It's _often_ the case that once you have gone through design and reached stability, you are going to have a good chance that knowledge can be procedurally embedded for better effect. I think this is what newell and simon meant by practice effects. I think if you look even at massively reflective systems like 3lisp, you'll see that the reflectivity is not used most of the time and that in those cases 3lisp will compile down to the same kind of code as other languages will, or at least, I understand that to be the thesis. But the ability to compile 3lisp out of a deployed program is not a proof that 3lisp has no place. The ability to play tennis better after the mechanics are optimized into something rigid and non-symbolic is not proof that tennis is better learned mechanically than abstractly. Symbol processing is a tool for abstract manipulation and it's hardly surprising on a case by case basis that you can work the symbolic processing out in the end. What would be surprising is if you could show that FORTRAN or C could just as well have been a straightforward implementation strategy for AI systems.
> The amount of typing involved can be the same either way with appropriate > reader macros.
Not unless you make A, B, C etc be reader macros, IMO. But even then, the point is that you will only make an isomorphism to symbols at that point. Show me a worked example and I'll be clearer.
> Have you read Drew McDermott's paper "Artificial Intelligence Meets > Natural Stupidity"? There he argues that AI gets itself into trouble by > attaching too much implicit meaning to the print names of symbols. This > is (I just realized) implicitly a general argument against what you seem > to be calling "symbol processing". Do you agree with that assessment?
If I've read it, I don't recall. But I am not arguing for what symbolic processing is useful for, except as an auxiliary issue when you ask if one could do without it. I don't see that as what this main debate is about. I am arguing for what it _is_, and I can't imagine that Drew can make his arguments without first acknowledging a framework such as what I'm saying. I'm sure there are people who don't like symbol processing, but that's different than saying those people should be in charge of what symbol processing is. That's like putting C people in charge of Lisp design. Design and control of terminology and tools should be done by advocates, not opponents. It's too easy to sabotage a facility you don't beleive in. The question is whether an advocate can do something fun with it.
> If so, do you disagree with McDermott's argument?
I have no info. Is it webbed? If not, maybe he'll volunteer to either web it or physmail me a copy.
> (BTW, McDermott is not the > mentor I alluded to in the posting that started this thread, though as my > thesis advisor's thesis advisor he has of course had a significant > influence on my own intellectual development.)
Drew was at Yale when I was there designing T. He's a smart guy with some interesting perspectives on things, which is why I'd be interested in the paper, whether it disagrees with me or not.
Incidentally, nothing I've said suggests that a reliance on symbol names is a good thing. So I might not disagree with him. I keep saying "identity". As it happens, symbols have a name, and that's important to obtaining the identity. But that's all bootstrap and coding. What the program operates on at runtime is not the name, but the pointer id. The significance of the name is not that it has _that_ name, but that it has _a_ name; that is, that it _can be named_. This is a different issue entirely than the question of whether (concatenate 'string 'foo- x) is going to work; that is a use of a symbol as a designator for a string, and I personally tend to use (concatenate 'string "FOO-" x). I don't see that as symbol processing since a symbol was never used for its identity here, only its name. If you substitute (concatenate 'string 'tv:foo- x) you get the same answer. But if I do (get 'tv:foo- 'author) or (get 'foo- 'author), it matters what package the various key symbols are, not by their name but by their identity, and the effect is not changed if I later do [which isn't allowed in CL, but you get the idea]: (setf (symbol-name 'tv:foo-) "BAR-"). The symbol that was previously TV:FOO- and is now TV:BAR- will still be the same identical symbol and all prior operations on it will be the same; it may just be harder to find, in exactly the same way that (3 4) will be harder to find in an EQUAL hash-table if you SETF its CAR to 5.
> > FOO is a symbol. foo is a symbol. I don't mind typing 15\r or |15r| > > to preserve case. I don't mind typing tv:foo if I'm not in package TV > > to get to that symbol. But basically I want unimpeded access to the name > > as part of my syntax for literals if it's going to be what I think of as > > a symbol.
> Why is it not enough to bind the symbol to a variable (or a global > constant) and refer to the symbol by the name of the variable?
Because there is no operational way to tell there is a symbol there. And that's not what symbol processing is about. If I could find that symbol independently and use its identity as a key to other operations, then the symbol is a symbolic name for some other data.
> > I don't mind quoting symbols. In Macsyma, I could do > > X:10; > > F(X,Y):=X+Y; > > F(X+3,'X+3); > > and get back X+16 which contains one symbol and one number.
> Ah! This is an enlightening example. The crucial point here, it seems to > me, is that you can refer to the symbol whose name is the string "X" by > typing "'X", and you can refer to the value of that symbol by typing > simply "X". Is that right?
It is the notion of interning. And the notion that this name-reference accesses an object that will be compared by identity, not by string, even though the access to get it in the first place was by name. In DB terms, it is the object, not the name, that is the foreign key to the database reference backing up SYMBOL-VALUE if you store your values in a database.
> So consider the following alternative design. Define a reader macro, say, > =X, that expanded to (symbol-value X). (Note that there is no quote in > front of the X.) Now we write:
> (defconstant x (make-instance 'symbol-class :name "X" :value 10))
In this case, all you've done is haired up the syntax of symbolness needlessly. That doesn't make it a non-symbol. But it does make your language "designed badly" if you want it to be a symbolic processing language.
You've left out the interning issue, which is central. I'll continue as if you had not.
> (f x =x) ; == (f 'x x)
> Is that "just as good"? If not, why?
MDL (the language in which Zork was programmed) does this, I think. I'd have to study it further to see if I think it a Lisp but I'm not informed enough.
But certainly a problem with this syntax is that you need (f x =x) to be quoted data because otherwise you have no way to denote the list containing F, X, and =X. If (f (f x =x) x =x) means not to evaluate the first arg, then why does the outer form get evaluated? And if the inner form _is_ evaluated, then you'll need a quoter to inhibit it. As in (f '(f x =x) x =x). But that means 'x and x are the same thing. And that means that '=x has to be explained. Or else you have to have =(f (f x =x) x =x) which is really kind of bizarre if you have to always be forcing evaluation. My intuition from afar was that MDL addressed this by
"Joe Marshall" <prunesqual...@attbi.com> writes: > > > Well, I'm not suggesting a change to the language spec. I just want > > > to not see spurious `name conflict' errors.
> > The errors are not spurious. They happen for a reason. I'm sure you > > realize this, but I'm not sure you see the significance of realizing this.
> Well, when I type > => foo > Unbound variable `foo'
> => (use-package "FOO") > Error: symbol 'foo' already exists
> This, to me, is a spurious error. I made a single typo, but I have > to make two trips through the error handler?
But there _is_ a reason for this. When you do
(defun bar (x) (foo x)) (defun foo (x) (+ x 3)) (bar 4)
you get a useful result. That is, when you forward-reference a symbol, it creates it. It preserves the illusion that all symbols always exist by demand-creating any symbol upon mention.
I dunno if you use any speech recognition software but it's often incumbent upon you that you correct it when it gets something wrong because if you don't you're going to get it thinking it has confirmation it did the right thing. Same deal here.
You said FOO and you didn't immediately do (UNINTERN 'FOO). That means CL took it as a given that there should be a symbol FOO there. From the tiny window that INTERN is looking through, there is no difference between that use of FOO and the use of FOO in the DEFUN of BAR above.
Late, when you (USE-PACKAGE "FOO") you are not just saying "get a package FOO" [which I assume from your context has a symbol FOO in it that is defined as a variable]. You are saying consolidate my uses with the FOO package's uses. At the level of the package system, FOO has been used, but the reason for the use is not recorded. It can't tell that you haven't typed the three forms that I offered above, and it can't tell that FOO is not important for its identity. So it doesn't want to discard the problem.
In my papers on error handling, such as http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html I make the point that an error is a situation where there are multiple pending continuations (to use Schemish terminology) and you can't from available program data select the right one. Advice is required and the second error break seeks advice. The call to USE-PACKAGE does not know how substantial your prior use of FOO is and must ask rather than do the wrong thing some statistical number of times. People might not report that quiet problem I mention because people tend to report problems that enter debuggers and not report things that don't enter the debugger, but all the more reason to enter the debugger.
You might think it could do (AND (NOT (BOUNDP X)) (NOT (FBOUNDP X)) ...) to tell. But this assumes there are a finite number of such tests. If you believe me when I say that BOUNDP and SYMBOL-VALUE are just accesses to hash tables provided by the system, but that there are an unlimited number of things the user might have used this as a key for, then you know only a full GC could possibly keep you from losing. (And that GC would probably fail within 3 command lines from the failure since +, ++, +++, *, **, or *** probably refer to the FOO symbol so it wouldn't get quickly GC'd without your help.)
Curiously, _sometimes_ the reason you do not do (UNINTERN 'FOO) immediately after typing the stray FOO is you may not be sure that FOO is something you want to unintern. Maybe someone _does_ have a pointer and maybe your doing the unintern will break things. So if you are wary about calling UNINTERN randomly, why would you want a simple program like USE-PACKAGE with far less brainpower and visual scope than you have to do it?
> In article <sfwadt7rm61....@shell01.TheWorld.com>, Kent M Pitman > <pit...@world.std.com> wrote:
> I never said nor meant to imply that there "is no valid defense of a > package system." (I called it a "necessary evil", which is not a glowing > review, but not a condemnation either.) But the only reason I asked the > question that began this thread is that people I respect have a differing > view, and I want to understand why.
Erann,
When it comes to programming languages I try to not attach words like evil to them. As people have pointed out the package system in many ways is necessary. When it was decided to have one the people who put the work into developing it (I am 99% sure) went through the thought processes, discussions and value judgments that this thread is discussing. The package system is what they developed.
I can think of three quick approaches to learning about packages is by:
1) Using it, getting familiar with it, trying it out (in real situations), is one way to get a feel for what the designers had in mind.
2) Trying to develop a package system yourself. With this approach you get immediate insights into the ideas and problems behind it.
3) Teaching the subject. This forces you into actually learning the material so you do not fall apart when the first challenging question comes around.
Most of the time if I have sat down and seriously applied these methods to a real world product it becomes evident that the designers have thought about it. It dawns on me that they actually know what they are doing.
Imagine if you have put your sweat and thinking into was brought up for comment on a newsgroup, not just once but year after year after year. How would you feel? This is the kind of pressure that is put on the people who put CL together. I am sure they would appreciate intelligent questions on their ideas, or even better, someone to build and improve on them.
It is more respectful to strive to comprehend by the above 3 methods (and then asking questions) than asking critical questions based on just curiousity.
> The significance of the name is not that it has _that_ name, but > that it has _a_ name; that is, that it _can be named_.
"His name is Robert Paulsen."
You know, in a way, that's very relevant to this discussion. :)
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
> > > > Where it *was* a problem was on the Lisp Machine. When you opened > > > > a file in Zmacs, it would parse the file mode and it would > > > > parse some of the file contents. It would attach properties to > > > > the symbols mentioned in the file.
> > > I'm familiar with the problem you're talking about, but you can't > > > blame this on the package system. I don't think this is a fair > > > criticism. The Zmacs editor chose to put things on the property list > > > of symbols prematurely and got in trouble.
> > I think I'll still blame this on the package system. If Common Lisp > > did not have a package system (let's imagine that namespace conflicts > > don't occur and we can intern everything in one package), then Zmacs > > would have no problem at all attaching properties to symbols.
> As nearly as I can tell, this argument comes down to what in legal terms > would be called an "attractive nuisance". That is, by virtue of having the > data structure available, it seems to invite use in some cases.
> The reason I think the editor is "special" is that code to be edited > is not code in core. It stands at the brink and is really just a huge > large string in stringquotes. I regard your bug the same as if > someone had written some tool that scans files and was interning > symbols it found in stringquotes or comments. There are very > dangerous things that one finds quoted and there is a reason that > evaluation is suppressed. Programs which have only a superficial > understanding have no business doing what you are suggesting oughtt to > be the right answer in a universe with packages but ought not be the > right solution in a universe without packages.
I think that finding things that look like syntactic tokens in a file and making notes about them is a fine thing for an editor to do. In the cases where the code you were editing *was* already read into the system, the interning of symbols caused no problems and enabled some really fancy features.
> You know, I had a similar problem with Zmail a few years back when I revived > my old mail files (from the mid 1980's) from backups and it tried to parse > and intern all the domain names. You may or may not be aware (heh) that > the host names have changed since then. I got a lot of failed parses for > missing hosts like MIT-MC.ARPA or even PLANTAIN.SCRC.Symbolics.COM and it > was a mess. Does this mean the domain name system is wrong? Or does it mean > that some editing programs that are not actually trying to talk to the net > yet shouldn't be prematurely doing host lookup just based on the fact that > they saw some plausible looking text go by? Because I think the latter.
The latter, obviously. But to draw a symbol analogy, suppose that by attempting to resolve `PLANTAIN.SCRC.SYMBOLICS.COM' it *created* the domain rather than generating an error if it was not found. Would you still say the problem is with premature lookup?
[Lots of Zmacs stuff elided]
Well, mumble. We both agree that Zmacs did things wrong if it tried to intern symbols in packages that were not set up.
> > > > So, on to more obscure problems. You can't use `forward references' > > > > to symbols that don't exist in packages that don't exist (yet). > > > > In your init file, you'd *like* to be able to customize some > > > > parameters before you start building the system. Perhaps you have > > > > some macros that are parameterized, whatever. As an example, I > > > > once worked at a place that had a `verbosity' switch that I wanted > > > > set.
> > > > The obvious thing is to write (setq utility::*verbosity* t) > > > > but the utility package isn't loaded yet. Never mind that the > > > > utility package *will* be there when I call this function, it > > > > isn't there when I *read* the code. Instead I write: > > > > (let* ((utl-pkg (find-package :utility)) > > > > (verbosity (intern (symbol-name :*verbosity*) utl-pkg))) > > > > (setf (symbol-value verbosity) t))
> > > > The same goes for functions that I want to call. I can't > > > > write (progn (load "java-tools.lisp") (java-tools:make-all))
> > > > The way around this problem is to write a function that > > > > defers interning until runtime. Then you can write > > > > (progn (load "java-tools.lisp") (funcall-in-package :java-tools > > :make-all))
> Sure it is. I don't know what you're talking about. I have files that > say just exactly that. (Well, different function and package names.)
But when you load the init file, the reader ought to fail because there is no package named `java-tools' at the time the reader reads the init file. Never mind that java-tools:make-all *will* be a fine thing to invoke *after* we load "java-tools.lsp". (I have verified this on ACL and Corman.)
> > interning the name "FOO" in package "BAR" would yield 'FOO::BAR, yet > > in another interning the name "FOO" in package "BAR" would yield > > 'SYS:BAR. There were degenerate cases where you could end up with > > a symbol associated with a `non-existant' package.
> You mean with package not found errors, like in any package universe that > was absent a package, no?
Not exactly. Conventionally, if you evaluate this:
> > > > Well, I'm not suggesting a change to the language spec. I just want > > > > to not see spurious `name conflict' errors.
> > > The errors are not spurious. They happen for a reason. I'm sure you > > > realize this, but I'm not sure you see the significance of realizing this.
> > Well, when I type > > => foo > > Unbound variable `foo'
> > This, to me, is a spurious error. I made a single typo, but I have > > to make two trips through the error handler?
> But there _is_ a reason for this. When you do
> (defun bar (x) (foo x)) > (defun foo (x) (+ x 3)) > (bar 4)
> you get a useful result. That is, when you forward-reference a symbol, > it creates it.
I understand this. What the package-system doesn't understand is that when I mentioned `foo' the first time (and got the unbound variable) was that I *didn't* want that symbol. (Yeah, I know it cannot read my mind.)
> It preserves the illusion that all symbols always exist > by demand-creating any symbol upon mention.
The illusion is imperfect. When I (use-package ..) I can tell if a symbol had been created on demand or not: I get errors for those that were.
> You said FOO and you didn't immediately do (UNINTERN 'FOO). That means > CL took it as a given that there should be a symbol FOO there. From > the tiny window that INTERN is looking through, there is no difference > between that use of FOO and the use of FOO in the DEFUN of BAR above.
From the tiny window *I* am looking through, I can't tell if my typo interned a new symbol or found an existing one. I can't just (UNINTERN 'foo) without knowing this.
> Curiously, _sometimes_ the reason you do not do (UNINTERN 'FOO) immediately > after typing the stray FOO is you may not be sure that FOO is something > you want to unintern. Maybe someone _does_ have a pointer and maybe your > doing the unintern will break things. So if you are wary about calling > UNINTERN randomly, why would you want a simple program like USE-PACKAGE > with far less brainpower and visual scope than you have to do it?
No, I don't want a DWIM. What I do want is something that is a bit more clever. Consider this behavior: when I make a typo and get an unbound variable error, why not have the system unintern the symbol just created if and *only if* it was created by the typo itself.
Or this: When loading a fasl file (with appropriate switches) the following error appears:
The symbols 'frob', 'tweak', 'twiddle', and 'transmogrify' are not currently visible in package FOO, but package UTILITY exports symbols of these names. 1: IMPORT just those symbols from UTILITY 2: USE-PACKAGE utility. 3: Create new symbols in package FOO.
These two behaviors (and note that I'd like that latter to be a user controlled switch so no one *has* to monitor the load process looking for these things) would greatly improve my relationship with the package system.
[Warning: this post contains no technical content whatsoever. If you don't want to waste your time on such posts stop reading now.]
What an interesting day. I decided to take a usenet break this weekend, and I got up this morning to find 200+ unread postings in c.l.l. It took me three hours just to make an initial pass through them to select the ones that I wanted to go back and study and think about in detail and maybe respond to. There turned out to be about twenty of those, so I thought I would consolidate my responses in two posts.
I decided on two posts because there are two classes of resonses I want to write. The first is technical. The second is responding to posts from people expounding on what I think, and making various kinds of accusations against me. This is the non-technical response.
I must say that it has been absolutely fascinating watching myself be discussed in the third person. It's been almost as educational as reading the technical discussions (from which I have learned a lot already).
Since I happen to believe that I am somewhat of an authority about what I think I thought I would weigh in on some points of this discussion.
* Rahul Jain:
> You seem to complain about it more than enough and intentionally > misunderstand it enough. And as one of the basic principles of Common > Lisp, a dislike of packages implies a dislike of Lisp and symbolic > processing itself.
...
> He seems to not like actually using it, then.
As I have said before, I like CL very much. I also like using it. It is by far my favorite programming language and has been for over twenty years. CL has been very good to me. In fact, my affection for CL, the reasons behind it, and why that affection has been somewhat atenuated recently, is documented in some detail in the post that started the "How I lost my faith" thread.
Nonetheless, there are things about CL that I don't like, and there are things about CL that I don't understand. Affecting change about those things I don't like and achieving understanding about those things I don't understand has to start with a question that has at least implicit within it some level of discontent. If everything were perfect there would be nothing to say. (Likewise if everything were hopeless.)
It is truly ironic hearing people here in c.l.l. tell me and others how much I dislike CL. At JPL (and Google) my reputation is the exact opposite. I am the Lisp Freak, the one who thinks Lisp is perfect and the Answer to Everything. My enthusiasm for Lisp has actually been detrimental to my career.
The truth is you're all wrong. I'm not a CL fanatic, and I'm not a CL hater. And if you want to know more about what I think just ask. I'm not shy about discussing my opinions if I think someone actually cares.
* Rahul Jain:
> He [Erann] claimed that he agreed with someone who said that they [packages] > should be replaced.
Not so. I fact, I explicitly disclaimed agreement by saying that I merely recalled this person's opinion, and not necessarily that I agreed with it. The only opinion of my own that I have expressed about packages is calling them a "necessary evil", the emphasis in this case being on the word necessary.
* Rahul Jain:
> > > As a result, [Erann] perhaps complains about things once in a while. > Once in a while? What else has he done in c.l.l in the entire time > I've been reading it?
How long have you been reading it? I've been posting on c.l.l. since 1990.
But that aside, could you please cite a few examples of postings of mine that you consider complaints? I believe that what I've been mostly doing recently is asking questions.
* Erik Naggum:
> Only those who are against it, express their dislike of it.
This, like much of Erik's rhetoric, is so ridiculous as to barely deserve response. Nonetheless, people on usenet seem to glom on to lots of ridiculous ideas, and this particular idea is dangerous if too many people start to think that Erik might be right about it. So for the record I express my absolute dissent from this view. This is the rhetoric of the demagogue. It serves no purpose but to marginalize dissent, which is the first step on the road to fascism.
* Erik Naggum:
> This arrogance is probably the reason why you never _listen_ to anyone.
Being lectured on arrogance by Erik is so funny that words fail me. Erik, you should really stop confusing not listening to *you* with not listening to anyone. They are not the same thing. But in point of fact I listen even to you, because people I respect keep telling me you have worthwhile things to say if one takes the time to dig through the crap. So I keep digging, despite the fact that my personal opinion is that I long since passed the point of diminishing returns. Such is my respect for some people's opinions that differ with my own.
* Rahul Jain: (Do we begin to notice a pattern here?)
> Erann never asked questions about what is better,
Yes, that's because I didn't want to start a flame war. What I asked to start this thread is why the people who like packages like them. This is because what I am trying to do is not resolve the question of which is better (I don't think that question can be resolved) but simply to understand the point of view of people who think differently from me.
* Rahul Jain:
> he complained to us that Python is better than CL, > and it's our fault that he thought otherwise.
Excuse me? When did I ever say anything of the sort? The closest thing I can think of is: "For example, my language of choice for doing Web development now is Python." That was an offhand, almost throwaway comment at the end of a *very* long post. And note the disclaimer "for doing Web development." Web development is only a very small part of what I do.
* Nicolas Neuss:
> Your CV looks impressive, but after having this conversation with you > and reading so much about your problems on c.l.l., I do not believe > anymore that it tells the truth.
Wow. I've been accused of a lot of things, but this is the first time anyone has actually accused me of fraud. Nicolas, I will provide you with documentation for any claim on my CV that you find questionable with the proviso that if I do so you must agree to apologise pulicly for defaming me. (Actually, you can verify everything on there yourself if you wish, and you would have been well advised to do so before making your libelous acusation.)
This really pisses me off much more than I care to express at the moment.
Erann Gat, Ph.D. Principal Scientist Jet Propulsion Laboratory California Institute of Technology Pasadena, California g...@jpl.nasa.gov
The views expressed here are my own. I do not speak for JPL.
> Yes, it is. The shift from expressive tasks to implementation tasks > is the essence of the difference between Lisp and other languages > for me. Every time you chip away at it, you chip away at Lisp's > power. I said before that this is not about Turing power, and this > remark on yours is an appeal to Turing power. Expressive power is > exactly about concise targeted notation.
I do understand the difference between expressive and computational power, and I did intend the former. I grant that there is *some* reduction in expressive power, but I'm not sure that it's a serious reduction. But your examples have "gotten my juices flowing" and before I say something more concrete, I have to give it more time and thought to get my thoughts together.
* "Joe Marshall" <prunesqual...@attbi.com> | Unfortunately, at one place I worked the boss was insistent that we | always do a `clean build' before every check-in.
But this is not a problem with Common Lisp, is it? :)
I think making a clean build of the packages with a good defsystem, then loading them into a virgin image to dump a clean image should have been a satisfactory solution to your boss.
If anyone has the kind of problem you have described, I think the proper answer is to teach them to use the implementation's ability to save the world and dump a new image, not to futz around with weird hacks.
/// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
In article <3c949fc...@news.bluewin.ch>, "Samuele Pedroni"
<pedro...@bluewin.ch> wrote: > A question: what is for you the relation between "L has X", > and "X can be implemented (with effort, without effort) in L"?
I think I'd say that if X can be implemented without effort in L then L has X. If X can be implemented with a little effort in L then L doesn't have X, but it doesn't matter.
> > A question: what is for you the relation between "L has X", > > and "X can be implemented (with effort, without effort) in L"?
> I think I'd say that if X can be implemented without effort in L then L > has X. If X can be implemented with a little effort in L then L doesn't > have X, but it doesn't matter.
So, for example, if safety can be implemented without effort in sex, then sex has safety. If safety can be implemented with a little effort (say, wearing a condom) in sex then sex doesn't have safety, but it doesn't matter.
Just wanted to make sure you really meant what you said. ;)
To quote a childhood mantra: "almost only counts in horseshoes and hand grenades" though in more recent days the expression "and atom bombs" got added by some kids I knew.
> > > This is obviously not quite kosher in a file.
> > Sure it is. I don't know what you're talking about. I have files that > > say just exactly that. (Well, different function and package names.)
> But when you load the init file, the reader ought to fail because > there is no package named `java-tools' at the time the reader reads > the init file. Never mind that java-tools:make-all *will* be a > fine thing to invoke *after* we load "java-tools.lsp". (I have verified > this on ACL and Corman.)
This is IMHO not true. The loader must process the forms one by one, including the reader. Otherwise forms such as (in-package :foo) would not work in loaded files.
I don't know what you tested, but with the following two files, everything works as expected, in all CL implementations I've tested, including ACL, LispWorks, CMUCL and CLISP:
If you want to compile init.lisp without manually loading java-tools.lisp beforehand, you'd have to wrap the load form with an appropriate eval-when form, and then even that will work just fine, including loading a compiled init file into a fresh core, IMHO, though CMU CL seems to exhibit a bug there.
Regs, Pierre.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
