RICE@SUMEX-AIM.STANFORD.EDU (08/29/89)
Hello everyone, Well, I just thought that I'd let you know what happened at IJCAI. Luckily, since this was not a formal event of any sort I don't feel in any way obliged to generate minutes for the meeting, so this is more like just a note of thanks and a little request to our loyal readership. We did, indeed, have a meeting (actually a meetingette). No pizza was had, but that was more of a statement about Detroit than TI users (I've never seen so many closed restaurants in all my life). My thanks to TI for footing the bill and for showing up with non blue-suited types. It turned out that I was the only one to show up with a tape (sniff. I'd still like to see what others are doing) and so those who turned up had a chance to see the new inspector, grapher and sundry other bits that it is hoped will end up in Rel 7. It is also hoped that a sort of overload/patch tape will come out of TI in the not too distant future so that people can get used to the new features and will not be too frustrated by the lack of any tools that can deal with the new CLOS/CLCS/CLX/CLUE subsystems that TI have implemented for Rel 6. TI has been working hard to integrate this stuff, but being short staffed they are inclined to miss out certain bits of functionality that they think might be costly to integrate. What I'd like, if at all possible, is some feedback from those who saw this stuff, or from anyone who has any opinions, of course. If you have any comments on this code, having seen the rresults, please could you pipe up, CCing your message, as I have above, to Ed Humphrey (Humphrey@DSG.CSC.TI.Com) and Teri Crowe (Crowe@DSG.CSC.TI.Comand) so that they can know just how valuable (or useless) you think this stuff will be to you. We have been using this code at Stanford for a long time now and feel that it hugely increases the utility of our Explorers, but we're only one data point. Here are some questions that you might want to address: a) Is an integrated inspector tool that covers normal inspection, Flavor inspection and CLOS inspection all in one tool that also provides user definable multiple perspectives for viewing data structures a useful thing? (e.g. view a list as a plist or an alist, or a "rule" as your own magic thing or the flavor that implements it) b) Is a grapher a useful thing to have? (A grapher is a tool that allows you to display graphs of data in a window as a set of nodes connected by lines, the sort of thing that you see in KEE or in InterLisp D. It allows the graphical display of hierarchical data structures, such as CLOS/Flavors inheritance graphs or function call trees). c) What about bugginess? If you had to choose between having a grapher that occasionally left a few turds (stray pixels) on the grapher window or no grapher at all, which would you pick? If TI has to decide between releasing code with known, but minor, deficiencies or not releasing that code at all, which would you prefer? Question c) is of particular significance, since this is the sort of trade-off that is being mooted. Many thanks for reading to the bottom of this message. Many thanks once more to TI for catering for us at IJCAI, to John Mandell for providing the machine, to Ed Humphrey for helping to push this tool integration effort and particularly to Teri Crowe, who's on the coal face doing the horrible integration work. Rice.