In Smalltalk if I want a list of all existing instances of a class, I can use "classname allInstances" to get such a list. What is the equvialent in Lisp?
>>>>> On Sat, 16 Jun 2001 20:36:49 GMT, lispnewbie ("lispnewbie") writes:
lispnewbie> In Smalltalk if I want a list of all existing instances of a class, I can use lispnewbie> "classname allInstances" to get such a list. What is the equvialent in Lisp?
Common Lisp doesn't have an operator to do that. Can you tell more about how you would use such an operator?
I know where all my instances are because they are connected to some other data structure. In the simplist case, I might have placed them into a list. If you really wanted a global list of all instances of some class, you could write about two lines of code (an :AFTER method on INITIALIZE-INSTANCE) to record the instance in some list.
On Sat, 16 Jun 2001 21:42:21 GMT, Christopher Stacy
<cst...@spacy.Boston.MA.US> wrote: >into a list. If you really wanted a global list of all instances of >some class, you could write about two lines of code (an :AFTER method >on INITIALIZE-INSTANCE) to record the instance in some list.
As an example of how I would use it in Smalltalk, suppose I have a number of Smalltalk processes running, and because of some bug in my code, lose control of one of them, and can no longer find it. In Smalltalk I can terminate the process by first using "Process allInstances inspect" to find it, and then invoking its termination function. The same kind of thing is useful for a lot of different kinds of objects, not just processes. Of course allInstances is not very fast, so it should only be used in unusual situations such as debugging. But it's very handy in those situations.
Suppose I'm a Lisp newbie and don't know what a package is, and want a list of loaded packages so I can get a clue about packages by recognizing some of the names in the list. In Smalltalk I could ask the class browser to find all classes whose names have "package" or "pkg" in them, then I could inspect all instances of those classes. That kind of thing is what makes Smalltalk so easy to learn. Anything you don't understand, you can find the answer quickly by using Smalltalk's extremely powerful browsing and inspection facilities. Of course Lisp has special variables containing lists of packages, etc., but you can't expect a newbie to know that, or to know what special variables to look at.
By the way, is there an easy way to get a list of all special variables? What would the objects in the list be? Is a variable an object you can put in a list? Or can you only put its contents in a list? Or maybe a list of all special variables would just be a list of their names?
And how would I go about iterating through all existing objects? Would it be a nightmare to attempt such a thing? How would I avoid conflicts with the objects created by the iteration?
Obviously your way, of using :after etc., would be a lot better and more efficient, if the purpose was to build this kind of facility into some code. But I'm looking at this from a debugging, browsing, and learning point of view. How to make simple but powerful tools that can be used for finding all kinds of answers, like in Smalltalk, without having previous exposure to the code and objects you want to debug or browse or learn about.
lispnew...@questions.com writes: > Suppose I'm a Lisp newbie and don't know what a package is, and want a list > of loaded packages so I can get a clue about packages by recognizing some of > the names in the list.
lispnewbie> In Smalltalk if I want a list of all existing instances lispnewbie> of a class, I can use "classname allInstances" to get lispnewbie> such a list. What is the equvialent in Lisp?
If what you want is to keep track of all instances of arbitrary classes, then you may consider defining a new metaclass for this. This is certainly a viable reason to modify the nature of CLOS. It really depends a bit on the level of where you want this logic to go. Someone has already suggested using an :after method on I think initialize-instance. Another way is get into the heart of standard-class. If you wanted to define your new metaclass such that you can ask the class for all of its instances, I'd say that this would merit using the MOP.
Once you dive into it a bit, you'll see that this particular example is straightforward. Of course, there are other ways, but this is probably the one which is the most meaningful, since you're really adding a property to the way the class itself behaves.
>>>>> On Sat, 16 Jun 2001 22:42:30 GMT, lispnewbie ("lispnewbie") writes:
lispnewbie> That kind of thing is what makes Smalltalk so easy to learn.
Let me sum up the answer to your questions by just answering that one. Answer: Guess what language Smalltalk got all those ideas from?
You can do all the exploratory and debugging things in Lisp that you are used to in Smalltalk, and more. You don't do them all the same way.
Most of the rest of your message does not make very much sense -- wondering what a variable is and so forth -- so I'd suggest that you get a book on Lisp and learn a little bit about the language. Then come back and ask the questions that still puzzle you. As worded, your current questions almost seem like a troll!
lispnewbie> And how would I go about iterating through all existing objects?
That would not be a particularly meaningful operation.
On Sun, 17 Jun 2001 10:38:40 GMT, Christopher Stacy
<cst...@spacy.Boston.MA.US> wrote: > lispnewbie> And how would I go about iterating through all existing objects?
>That would not be a particularly meaningful operation.
For example, to find a "lost" object. I might have only vague knowledge of a particular object, and might want to inspect it to learn more about it. It would be handy to be able to iterate through all objects to find those that match a pattern, which might represent the vague knowledge I have of the object I'm looking for.
You might be thinking of small and medium sized projects done by one person, such that it's easy to keep track of all the details. But I'm used to working on very large projects, where I have to understand the work of large numbers of other programmers. Such work is often poorly documented, and best understood by browsing and inspecting the running code and objects. I might have no idea where to look among megabytes of source code for a particular bug, but might be able to find it fast by browsing and inspecting various objects related to it.
lispnew...@questions.com writes: > On Sun, 17 Jun 2001 10:38:40 GMT, Christopher Stacy > <cst...@spacy.Boston.MA.US> wrote:
> > lispnewbie> And how would I go about iterating through all > > lispnewbie> existing objects?
> > That would not be a particularly meaningful operation.
> For example, to find a "lost" object. I might have only vague knowledge of a > particular object, and might want to inspect it to learn more about it. It > would be handy to be able to iterate through all objects to find those that > match a pattern, which might represent the vague knowledge I have of the > object I'm looking for.
It might be very handy, but it might be extraordinarily expensive. You either have to maintain a table of such things (which potentially interferes with the GC's ability to collect them, and certainly adds bloat to your running image) or else you have to assume the system is marking the objects with enough state to find them again (which probably internally any Lisp system is, since the GC needs this to run) but you ALSO in that case have to touch and page-in every page in the Lisp system, and that can be very disk-intensive in some systems, slowing your system to a crawl. It might be a useful debugging operation, and if you have a support contract with your vendor, you might ask for it; maybe they can write it for you--I bet mostly it's not a lot of work. But as a LANGUAGE feature, it's DANGEROUS becuase if at arbitrary points in a user program you did this, you would basically touch all memory and that would be bad. Of course, there's a third case and that's that you identify which classes you will programmatically need to track all instances of and just for those classes you keep track of the instances. But if you have such foreknowledge, you can already do that by doing:
> You might be thinking of small and medium sized projects done by one person, > such that it's easy to keep track of all the details. But I'm used to > working on very large projects, where I have to understand the work of large > numbers of other programmers. Such work is often poorly documented, and best > understood by browsing and inspecting the running code and objects. I might > have no idea where to look among megabytes of source code for a particular > bug, but might be able to find it fast by browsing and inspecting various > objects related to it.
Here you are talking system-level questions, and this is an issue best left to the system vendor. It is generally agreed in our community that the language is about the commonality between all vendors, and is about the code we write in files, whereas the system is vendor-specific and is about the speed/quality/debuggability/productivity-yield that individual vendors offer in order to be competitive. There is no single right answer to this. The market will and does sort this out. If you are paying a vendor for support, they will surely listen to your issues. If you are not, then you are not likely to be viewed as a very serious "part of the market". Your comments are still heard, but are not likely to be acted upon individually.
lispnew...@questions.com writes: > For example, to find a "lost" object. I might have only vague knowledge of a > particular object, and might want to inspect it to learn more about it. It > would be handy to be able to iterate through all objects to find those that > match a pattern, which might represent the vague knowledge I have of the > object I'm looking for.
> You might be thinking of small and medium sized projects done by one person, > such that it's easy to keep track of all the details. But I'm used to > working on very large projects, where I have to understand the work of large > numbers of other programmers. Such work is often poorly documented, and best > understood by browsing and inspecting the running code and objects. I might > have no idea where to look among megabytes of source code for a particular > bug, but might be able to find it fast by browsing and inspecting various > objects related to it.
I suspect you should be able to get (most of) what you want by using some combinations of INSPECT, DESCRIBE, APROPOS, DOCUMENTATION, together with WITH-PACKAGE-ITERATOR, DO-SYMBOLS, etc. Also somewhat related, most CLOS implementations provide CLASS-DIRECT-SUBCLASSES and stuff, from which you can extract the hierarchy by doing a breadth-first-search starting from STANDARD-CLASS.
For example, the following kludge works for CMUCL (assuming some value of "works" which nonetheless should be adequate for explorative purposes):
Common Lisp features a garbage collector. If there is no way you can reference an object, it does not matter whether it exists (in memory) or not. Consequently, it saves on memory consumption to (re)use the space used by objects that people have "lost" for something they have not lost. If the system hangs on to objects after you lost them, there is probabl a very good reason for that, and an accompanying mechanism to delete those objects. Otherwise, there is no way you can both lose it and fint it. I wouls guess that only a few kinds of objects satisfy this condition, such as processes, streams, packages, symbols, etc. In fact, all operating system resources _should_ satisfy this condition, but they do not always do so. E.g., streams usually reflect a scarce system resource that you really want to be able to recover and your Common Lisp system should have a way to go from system resource to high-level resource, such as from a file descriptor to a stream. This particular mapping is astonishingly simple to accomplish and it is a shame that it needs to be done manually.
> I might have only vague knowledge of a particular object, and might want > to inspect it to learn more about it. It would be handy to be able to > iterate through all objects to find those that match a pattern, which > might represent the vague knowledge I have of the object I'm looking for.
Then it would serve your purposes much better to learn how to find objects that might satisfy your needs than to find all objects in order to test them to satisfy your needs. From what you keep telling me about SmallTalk, it seems like a seriously misdesigned language when it lets people rummage around the garbage to find something or other that may or may not have been "lost". However, since I do not consider SmallTalk misdesigned, I instead consider your usage of these features _abusive_.
Similar abuse may of course be accomplished in Common Lisp. The garbage collector will necessarily know about all (live) objects, and you may ask it nicely to return a list of all of them -- it necessarily has a way to reference all objects independently of all other references. In Allegro CL, you do that with the function (excl::get-objects <object-type-id>). Evaluate (room t) to see which object types and ids are available.
> You might be thinking of small and medium sized projects done by one > person, such that it's easy to keep track of all the details. But I'm > used to working on very large projects, where I have to understand the > work of large numbers of other programmers. Such work is often poorly > documented, and best understood by browsing and inspecting the running > code and objects. I might have no idea where to look among megabytes of > source code for a particular bug, but might be able to find it fast by > browsing and inspecting various objects related to it.
This leads me to believe that the existence of the features you want encourage the abuse you have described and apparently consider a plus, while I hold the view that if certain things are harder to do than others, people will do other things to avoid the hardest part of the job. In a nutshell: If it is harder to document than to browse, people will browse, but if it is harder to browse than to document, people will document. Programming languages are all about built-in convenience. In a twisted form, the Sapir-Whorff hypothesis, that languages shape the way we think, applies because of sheer laziness and/or intelligent use of resources (the two frequently coincide).
Incidentally, there is the function apropos, and some Common Lisps even feature an apropos-regexp function for those who think regexps are cool.
> If what you want is to keep track of all instances of arbitrary > classes, then you may consider defining a new metaclass for this.
* Christopher Stacy
> That is not available in ANSI Common Lisp (the MOP is not part of that > language), although some vendors support this.
Vote with your feet when it comes to supporting the MOP. If the vendor does not support it, just walk away. If people are told not to expect the most basic features above and beyond Common Lisp because it is not in the standard, the language will die. In fact, I consider the fact that people are willing to whine about feature X not being in the standard as the reason that Common Lisp has seen little development. The point with a standard is not to ask what is in it, it is to ask whether that which is in it is implemented, and whether that implementation is according to that standard. If it is not specified in one standard, it may be specified in another standard. MOP is a community standard that merits about the same level of authority within the community as ANSI does for the greater community. Similar efforts have been attempted with other features that people need, too, but instead of writing standards-quality stuff to support an implementation, some people prefer to post only the implementation, which is completely useless to people who are used to having a really good standard to refer to when they need to understand what to _expect_ from an implementation. (Many other languages are the other way around: That the implementation _is_ the specification.)
MOP _is_ part of the Common Lisp toolchest and the common environment that surrounds the language proper. This is one of the reasons it is not a lot of work to build a Common Lisp interpreter or compiler (as is often done with Scheme), but a lot of work to build a Common Lisp _system_ (as is ofte not done with Scheme). If we do not appreciate the systems, but only the language, we have no chance at all against languages that have successfull merged to two concepts, such as Perl and Java.
The only way to _make_ vendors support stuff people need is to make sure they are chosen if and only if they do. In the case of the "Open Sores" community, their biggest problem is that they do not want what they have not got, in particular, the lack of willingness to implement what is in the commercial offerings, coupled with a lack of willingness to use what is only in the commercial offerings, making sure that the willingness to implement it is never going to materialize, either.
You may not be aware of this, but this uses an implementation-dependent feature that clearly depends on some other feature that you should have investigated and used instead of letting describe use it for you. I get this Perl feeling from your example: It is easier to parse textual output from some useful function to look for some random text string you think will return all true positive and no true negative than to go look for the real answer. Yecch! Here's a trivial example that shows you what kind of bad Perl solution you came up with:
* (setq *top-level-auto-declare* nil) NIL * (setq foobar-random-noise '("this is not a special variable")) Warning: This variable is undefined: FOOBAR-RANDOM-NOISE ("this is not a special variable") * (describe 'foobar-random-noise) FOOBAR-RANDOM-NOISE is an internal symbol in the COMMON-LISP-USER package. It is a undefined variable; its value is ("this is not a special variable"). ("this is not a special variable") is a CONS.
In CMUCL, the function walker:variable-globally-special-p takes a symbol and returns true if it is globally declared special.
In Allegro CL, the function excl::variable-special-p does the same, but needs an environment, too. nil is the global environment, as usual.
> This version is about 7.5 times faster than the first, not that it > matters for "explorative purposes."
I later realised that this is wrong (read: complete rubbish) so I apologise if it confused anyone. (It is most likely that I am the only one who is confused around here.)
It appears that LispWorks' describe doesn't say whether a variable is special or not. I followed Erik Naggum's suggestion and found WALKER:VARIABLE-SPECIAL-P but it didn't work for me.
CL-USER 114 > (defvar *foobar* "This is a special variable.") *FOOBAR*
>>>>> On Sun, 17 Jun 2001 11:51:57 GMT, lispnewbie ("lispnewbie") writes:
lispnewbie> You might be thinking of small and medium sized projects done by one person, lispnewbie> such that it's easy to keep track of all the details. But I'm used to lispnewbie> working on very large projects, where I have to understand the work of large lispnewbie> numbers of other programmers. Such work is often poorly documented, and best lispnewbie> understood by browsing and inspecting the running code and objects. I might lispnewbie> have no idea where to look among megabytes of source code for a particular lispnewbie> bug, but might be able to find it fast by browsing and inspecting various lispnewbie> objects related to it.
I am thinking of systems with more than 100 MB of Lisp source code. I haven't ever needed a list of all the instances of all the objects in order to figure out what's going on, largely because Lisp and most of its development environments provide good tools for exploration and inspection of large systems. I think I already said that, though.
On Sun, 17 Jun 2001 23:21:31 GMT, Erik Naggum <e...@naggum.net> wrote: > Common Lisp features a garbage collector. If there is no way you can
By a lost object I don't mean unreferenced, but just that I don't know where to look for it.
> SmallTalk, it seems like a seriously misdesigned language when it lets > people rummage around the garbage to find something or other that may or > may not have been "lost". However, since I do not consider SmallTalk > misdesigned, I instead consider your usage of these features _abusive_.
"Classname allInstances" is a safe, consistent, and useful feature of Smalltalk. It doesn't rummage around in garbage. It only finds live objects. It typically takes a fraction of a second, and is only used at the top level, for purposes such as exploring and debugging. I might for example use "Process allInstances size" to see how many processes currently exist in the Smalltalk image, or "MyWindowClass allInstances select: #isHidden" to see any hidden windows I might have, or even "Metaclass allInstances size" to see how many classes are in the class library. None of those queries are abuse of any kind. They just mostly satisfy idle curiosity, but in some cases can save a lot of debugging time or learning time.
lispnewbie> By a lost object I don't mean unreferenced, but just that lispnewbie> I don't know where to look for it.
That is, perhaps, one of the most mysterious things I've ever read in any post. What are you talking about?
The *only* situation I can possibly see what you're saying as feasible is if you sat down at some elses Lisp prompt after they loaded code that you never saw. You can use the describe, inspect, list-all-packages, etc. to see what's around, and maybe even get lucky with function-lambda-list and function-lambda-expression. But, if it's _your_ program, then I think your question is absurd. *YOU'RE* the one writing the program.
lispnew...@questions.com writes: > "Classname allInstances" is a safe, consistent, and useful feature of > Smalltalk. It doesn't rummage around in garbage. It only finds live > objects. It typically takes a fraction of a second, and is only used at the > top level, for purposes such as exploring and debugging.
"used at top level" = "system command", not "language support".
Although we briefly dabbled, as a community, with specifying large amounts of required tools structure in the language, we have moved away from requiring that because too often it placed unnecessary implementation burdens on vendors, some of which have been quite commercially costly. Whether or not this one would be is tricky to say, but it's a fair bet that if it were program callable some vendor would object, and if it's not program callable, that's the line we defined for where the language definition should keep out of the vendor's hair.
Common Lisp does have a fixed amount of language baggage that we have not removed for historical reasons, although even there there is pressure to do so. In general, I think the right way to say it is that it's being gradually phased out of the language.
That is NOT to say that it not useful to have such support, but RATHER to say that it is just inappropriate to a LANGUAGE specification. We've largely decided that this is stuff a vendor should provide so that the vendor can control documentation on how to use it, and so that the vendor can assure that support for it is reliably removed from the image for delivery, where appropriate, and most of all so that the vendor can decide that the implementation constraints imposed are not onerous.
For example, the common lisp function ED will try to edit a function's definition, but not all implementations will find that it's worth the storage to hold onto the location of the function definition. In some implementations this is extremely handy, while in other implementations utterly useless. And worse, its presence in those implementations where it is useful makes it problematic to remove when applications are delivered.
Also, though I don't doubt your experience is that it takes a fraction of a second to do these things, I'm quite ssure that places a heavy constraint on an implementation to implement certain aspects of the system in certain ways EVEN AFTER the support has been removed for delivery. Our experience in Lisp systems is that such constraints are best evaluated by individual vendors; those that find it serves their user base are absolutely encouraged to provide them, but those that find it doesn't serve theirs are not required to go that direction.
I can tell you for sure there are Lisp systems in which walking virtual memory to find an object of a given class would take a LOT longer than a fraction of a second. Our requiring a command of the kind you ask for might force such implementations to revise their storage layout in order to not be embarrassing for this test you want, yet this test might not be used very often in practice, and the systems that were revised to make this fast might lose important optimizations that were less visible to newbies and more visible to veterans. These are questiosn best left to vendors.
> I might for example > use "Process allInstances size" to see how many processes currently exist in > the Smalltalk image, or "MyWindowClass allInstances select: #isHidden" to see > any hidden windows I might have, or even "Metaclass allInstances size" to see > how many classes are in the class library. None of those queries are abuse > of any kind. They just mostly satisfy idle curiosity, but in some cases can > save a lot of debugging time or learning time.
Idle curiosity can be a powerful thing.
But idly assuming that an implementation is broken for not providing you this can be an inadvertently powerful thing, too.
You get nothing in the world for free. Everything is a trade-off. This is one trade-off best left to vendors, who each economically feel the effect of making it (or not) in their own way.
> lispnewbie> By a lost object I don't mean unreferenced, but just that > lispnewbie> I don't know where to look for it.
> That is, perhaps, one of the most mysterious things I've ever read in > any post. What are you talking about?
> The *only* situation I can possibly see what you're saying as > feasible is if you sat down at some elses Lisp prompt after they > loaded code that you never saw. You can use the describe, inspect, > list-all-packages, etc. to see what's around, and maybe even get lucky > with function-lambda-list and function-lambda-expression. But, if > it's _your_ program, then I think your question is absurd. *YOU'RE* > the one writing the program.
I think the thing he's saying is that a piece of code is like a Rubik's cube. Ignoring the obvious reading order, which must double as a load order and might or might not be a good learning order, any given page might be the front page, with all other pages secondary. I wrote a code browser of this kind in a hypertext system I made back in the early 80's (pre-www). Even in the www itself, the page you view in focus seems "the front page" and everything else is a cross-reference.
In this context, I believe what he's saying is that he's chosen a front page but has no foothold into an instance from which to begin inspecting.
This used to be a problem on the Lisp Machine, and the answer was to go into Peek to get a plausible thing to root from. Usually a window or a file stream would do. Sometimes one would force a keyboard interrupt on a frame to get a debugger and then do (inspect *terminal-io*).
In this regard, I would say that "all instances" is no more the criterial thing than anything else. Just a way of getting a root. I think being able to inspect a function and be able to click on its closed contents may work as well. And also, many systems with multiprocessing systems also provide the equivalent of Genera's "Peek". I know LispWorks has a process browser and a windows browser and a half dozen other browsers which collectively do the same kind of thing, for example.
I think in the context of the "foothold for inspect problem", there is a real issue here. But describing the problem as "absence of an all-instances capability" probably was not an articulate way of describing the need.
> By a lost object I don't mean unreferenced, but just that I don't know > where to look for it.
Sigh. Then it is not the object that is lost, it is you. It is wrong to solve that problem in programming languages.
> "Classname allInstances" is a safe, consistent, and useful feature of > Smalltalk.
So you have made it clear that you think. I happen to disagree, based on the way you tell us that you use it. Incidentally, I use the same kind of function in Allegro CL, which I had hoped you would understand, but I consider it about as "safe and consistent" as that trick I did with changing the type information between bignum and bit vector. I know how to do both safely and without destroying anything, but the fact that you can get at _any_ object and meddle with it even if it was intended to be captured in such a way that code optimizers and all users expected a very consistent object between invocations does _not_ constitute "safe" to me.
> It doesn't rummage around in garbage. It only finds live objects.
So does the garbage collector. Please excuse the expression, which was intended to impart to you that you are using a feature that is necessarily looking for objects via a different mechanism than one usually _wants_ to use, and which is essentially the same as the garbage collector, namely that of following internal object chains or allocation patterns. Any other implementation of allInstances is really wasteful, but this _is_ the domain of the allocator (and garbage collector). (Maybe you do not understand what the garbage collector does, yet, and that is perfectl OK, but then you must not act as if you do, either.)
> It typically takes a fraction of a second, and is only used at the top > level, for purposes such as exploring and debugging.
If it is a safe, consistent and useful feature of SmallTalk, I _expect_ people to use it in very different ways than it was "intended". That is why it is a bad idea to publish such interfaces to the memory subsystem.
> They just mostly satisfy idle curiosity, but in some cases can save a lot > of debugging time or learning time.
Yes, sure, but my argument was actually that by so doing, you are not encouraged to write better code or learn by more efficient means. I see that you completely ignored this argument, and so my first hunch that it would be a waste of time to respond to you was probably correct.
Peter Buchlovsky <ug64...@cs.bham.ac.uk> writes: > It appears that LispWorks' describe doesn't say whether a variable is > special or not. I followed Erik Naggum's suggestion and found > WALKER:VARIABLE-SPECIAL-P but it didn't work for me.
(defun reliably-list-special-variables-in-package (package) (do-symbols (sym package) (when (eq (variable-information sym) :special) (print sym)))) -- Pekka P. Pirinen Global Graphics Software (incorporating Harlequin and Jaws) The great problem with Lisp is that it is just good enough to keep us from developing something really good. - Alan Kay
> > They just mostly satisfy idle curiosity, but in some cases can save a lot > > of debugging time or learning time.
> Yes, sure, but my argument was actually that by so doing, you are not > encouraged to write better code or learn by more efficient means. I see > that you completely ignored this argument, and so my first hunch that it > would be a waste of time to respond to you was probably correct.
I must be missing the point then. Wasn't MOP designed, in part,to provide information about the specifics of an application for the purpose of allowing greater understanding of it's inner workings? I think the ability to query a system to find out what it's current state it's in directly, instead of looking at source and making an educated guess, is a good thing. Especially on a large project where the majority of work has been done by other people before your inclusion. As a bad analogy, it's usually easier to fix a piece of machinery if you've examined one while it was working.
Most probably. I am unable to reconnect what have been talking about with your argument.
> Wasn't MOP designed, in part,to provide information about the specifics > of an application for the purpose of allowing greater understanding of > it's inner workings?
That is so not the point. Yes, wonderful tools exist to further both introspection in a system and learning and understanding in its users. Some of these tools actually make possible both thinking and solutions that would have been impossible to predict before it was deployed. That is the mark of a truly good idea. However, all good ideas can be carried too far and turn into _very_ bad ideas. E.g., the idea that members of a family pool their efforts and their earning so that the whole family can prosper as a result is a good idea, because of the preexisting commitment among the family members to the family. Doing exactly the same thing for a country of a hundred million people is not a good idea because there is no commitment from a citizen to a country on that scale.
> I think the ability to query a system to find out what it's current state > it's in directly, instead of looking at source and making an educated > guess, is a good thing.
I suggest that you look at the conditions that make it a good thing and see if you can find ways that some or all of those conditions can fail to be met with disastrous results. So far, all you have done is show us that you can think of positive consequences of having those conditions met. That is, frankly, utterly uninteresting. We all agree that all of this stuff has useful aspects. _Nobody_ is arguing against these things.
I am, however, arguing against the standard implementation of a _specific_ feature that has more negative aspects to it than positive because the conditions that are usually met by introspective functions are _not_ met by this particular feature. Somewhere along the line, I think you managed to conclude the general from the specific, when the general was already taken for granted, and argue for the specific based on arguments for the general. Both of which as disastrous logical fallacies. I have a hard time even coming to grips with the proportion of such an invalid argument. It is virtually a textbook example of how _not_ to argue for something.
We have been told that this allInstances feature is great _because_ of the lack of documentation in large systems. I know, from experience, that that documentation is lacking _because_ of the availability of features that obviate the need for proper documentation. Thus, a feature that is "good" has very, very bad consequences because it turns people who are resource-conscious into worse programmers when they _know_ that whoever has to deal with their code is probably going to skip reading the documentation when they have that tool, too, so they never bother to write it in the first place, in a wonderful process of proving themselves right: Of course they didn't read the non-existing documentation before they used the allInstances trick to discover the information they were looking for!
Please think things through, do not stop thinking just because of the sexy surface appeal of something.
Erik Naggum <e...@naggum.net> writes: > * Huaiyuan <huaiy...@rac5.wam.umd.edu> > > For example, the following kludge works for CMUCL (assuming some value of > > "works" which nonetheless should be adequate for explorative purposes):
> You may not be aware of this, but this uses an implementation-dependent > feature that clearly depends on some other feature that you should have > investigated and used instead of letting describe use it for you. I get > this Perl feeling from your example: It is easier to parse textual output > from some useful function to look for some random text string you think > will return all true positive and no true negative than to go look for > the real answer. Yecch! Here's a trivial example that shows you what > kind of bad Perl solution you came up with:
[example elided.]
Ouch! [374KB of to-be written text presenting a pseudo-philosophical argument masquerading my feeble after-blunder face-saving attempt elided.] ... But at the end, I have to agree with you that I was being sloppy. I should have known better and used (APROPOS "SPECIAL-P") instead of settling on a non-solution.
Hmm..., or should I? That is to suppose I knew "SPECIAL-P" was a hopeful candidate text string to be presented in the function-name I was looking for. I'd think "SPECIAL-P" is surely no less random than "special variable" when looking for something about special variable? Before someone makes public his/her implementation of SEMANTIC-APROPOS or WITH-TELEPATHY, we still can't escape entirely from a little bit of Perlism, it seems.
If there are better ways to handle this kind of things, pray tell. Thanks!
