[marchett%cod@nosc: slotp]

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

The following came just to me, but as long as he's taken the trouble
to write all this down, it might as well be archived...

  Date: Mon, 21 Apr 86 07:20:53 PST
  From: David J. Marchette <marchett%cod@nosc.ARPA>
  To:   kmp@scrc-stony-brook
  Cc:   priebe%cod@nosc.ARPA
  Subject: slotp
  Message-Id: <8604211520.AA09291@cod.ARPA>
  
  I had several reasons for asking the question.  I admit it sounds
  silly that the person who did the programming wouldn't know what
  he called the slots.  That isn't what I'm talking about here.  The
  problem is that I am writing a rule parser similar to ops5, but with
  a more object-oriented view point.  A rule may deal with several
  objects, or structures, and there may be many different kinds of 
  data objects.  When the time comes to test the rules, the program
  needs a way of determining which objects are valid data for the
  rules, and this cannot be written in to the rule language.  I realize
  that there are other ways to do this, but it seemed to be an easy
  quick and dirty way to get things going if I could check the data objects
  to see if they had the necessary structure for that particular rule.  A
  second reason for doing this is that it would be nice to be able to have
  a simple way of viewing the data built in to the rule language.  The
  Symbolics has such a tool, called the inspector, which allows one to
  see the values of the slots and prints the "name" of the slot next to
  it.  The inspector of course cannot know ahead of time what kind of data
  it will be given.  Finally, the fact that a debugger may want to have
  this ability is another argument for making it a part of the language
  since this would make one more part of the debugger implementation
  independant.  After all, someone has to write debuggers.  Since, as I
  understand it, there is nothing forcing an implementation to store
  structures in a particular way, there may be no way to get this information
  in an implementation independant way unless the implementer also provides
  a function to do this.  I may be wrong, they may always store the names
  of slots in a property list, in which case I have no problem, but I don't
  want to write code that will only run on my symbolics.  If I'm going to 
  do that, I might as well stick with zetalisp with all the good stuff it
  gives me.