perm filename MINUTE[DOC,AIL] blob sn#081237 filedate 1974-01-17 generic text, type C, neo UTF8
C00001 00001
C00003 00003		 		MINUTES
C00007 00004	2. Installation Reports
C00016 00005	3. Discussion.
C00023 00007	2. File format.
C00031 00008	3. Communication Files.
C00037 00009	4. Getting Started
C00041 00010			       EXAMPLES
C00047 00011			       UNSETTLED ISSUES
C00049 00012				ATTENDEES
C00052 ENDMK

On August  24, 1973, representatives  of installations which  use the
SAIL language system  (for the PDP-10) met at the Stanford Artificial
Intelligence Laboratory  in Palo Alto,  Ca., to  consider matters  of
common   interest.     Of  particular   importance  were   issues  of
maintenance,  communication, and operation  under the TENEX operating

The names  and addresses  of those who  attended are  included in  an
appendix to this report.

						Dan Swinehart
						10 October, 1973

1. Recent Additions to SAIL

The meeting began with  a brief summary of recent  Stanford additions
to SAIL.  They include:

   Enhanced control structures, in the form of  Processes,  Events,
   Interrupts,  Procedure Variables; the storage (stack) structures
   which   support   these   features   was   briefly    described.
   Improvements  in the LEAP facilities: typed datums, better print
   names, Matching Procedures, and  more  flexible  provisions  for
   binding  Items  to  Itemvars  (mostly  in  support  of  Matching

   Backtracking provisions, in the  form  of  named  Contexts,  and
   primitives   for   Remembering  and  Restoring  variables  using

   Improved macro  facilities,  of  which  specifiable  macro  body
   delimiters,  conditional  compilation,  and  access to variable
   type information at compile time are most significant.   Use  of
   some of the more complex facilities cause incorrect listings.

   Error  handling  facilities.  Currently available are additional
   responses to the error (or Usererr) sequence, to allow switching
   of  error  messages  to a disk file (logging) for later perusal.
   Current error handling is a hodge-podge, and we are planning  to
   make  all  error  conditions  more  uniform,  and to extend user
   options  with  regard  to  errors   (allowing   interface   with
   interrupts or user-specified procedures).

   Debugging  facilities.   Kurt  VanLehn  is  designing  a  set of
   debugging facilities for SAIL.

We also announced the availability of hard-copy SAIL manuals from the
Stanford Computer Science Dept. publication service.  To order one or
more manuals (at about $3 each, I think), contact:

        Stanford Computation Center
	Polya Hall
	Stanford University
	Stanford, California, 94305
	Attn: Publications

The manual is not yet available in LPT-ready form.  We believe we can
create a fairly nice manual, with lower case and other 96-char. Ascii
characters,  but  without  our  super-special   Stanford   characters
(equivalence,  "circle-times", double-arrow, etc.).  Its availability
will be announced later, via  the  ANNOUNCEMENT  mechanism  described
2. Installation Reports

We asked each representative  to tell us about SAIL use  at his site,
with   emphasis  on  the   modifications  required  to   run  at  his
installation, and the  kinds of  things people there  need, or  would
like to see, in SAIL.

Bill Merriam  reported on  the work  BBN has been  doing to  create a
SAIL system  which could operate smoothly under TENEX.  This work was
undertaken as part of a  contract with JPL.  Some of the  agreed work
is done  (predominantly TENEX-compatible runtime  routines written by
R. Smith at IMSSS), and BBN is willing to see it through, although  I
think it's safe to say  their heart isn't in it.  They  would seem to
welcome suggestions for graceful withdrawal from the SAIL game.

Bob  Smith  from  IMSSS  (Inst.  for  Math.  Studies  in  the  Social
Sciences, at Stanford)  described his  TENEX-compatible SAIL  runtime
routines,  which BBN  has included  in their  package.   His routines
include  routines  (e.g.,  OPEN,  LOOKUP,  RENAME),  which  allow old
programs to  run, although  they  use TENEX  facilities directly,  so
that  the DEC-compatible  facilities need  not be  present.   He also
provides routines  to use  the  TENEX features  more directly.    The
package  is designed  to  allow  smooth  transition between  the  two
systems.   The  concensus is  that this  is a  very nice  design, and
requires little to be generally accepted as the SAIL TENEX runtimes.

Given the  willingness of  BBN to  provide  certain modifications  to
TENEX,   and some financial support,  IMSSS is willing to  finish the
TENEX  conversion,   and  presumably  to  maintain  it.    The  major
unfinished business is completion of a TENEX-oriented SAIL compiler.

John Metzger,  from CASE, reported  that the  LOGOS project there  is
writing  a new set of  LEAP facilities, which will  allow storage and
inquiry into a  massive data base  (on the order  of 2↑27 items  (and
their datums!), a corresponding number  of associations.  They expect
to have a working program within six months.

Lee  Erman  reported  that  CMU  is  the  first,  and  probably  most
extensive,  "expo" user  of  SAIL.    Their speech  system  is  truly
monstrous.   CMU  has converted  the whole  thing to  a  quite recent
version of SAIL, and did not find the conversion terribly difficult.

CMU makes heavy use of  the conditional compilation facility, and  of
an inter-job communication  system of their  own design.   They would
like  to see  the  merger of  inter-job communication  with  the SAIL
process structure.  Perhaps  we  can  convince them  to  aid  in  the

Other Carnegie  facilities, which they suggest  we consider including
in the standard SAIL, are:

  The ability to add sharable routines to SAISEG segments.

  Additional input modes (automatic lower to upper case conversion,

  User  interrupt  before  String  garbage  collection  or  storage
  allocation routines are called  --  should  be  merged  with  the
  Stanford interrupt structure.

  A  timing  package, which works better if a reasonably fast clock
  is available.

Lee reiterated a  commonly-expressed need for  "dynamically allocated
arrays", (or perhaps  Algol W-like record structures), and for a SAIL
compiler which can  generate PDP-11  code (C. Wilcox  at Stanford  is
working  on  that).   He  can  offer  very  little manpower  to  help
implement any of these things.

Mike  Dervage,  representing  the  University  of  Utah,  was chiefly
interested in the  assurance that no  matter what we  do to SAIL,  it
will  still run  on a  standard DEC  system, and  will  still operate
correctly under the  DEC TENEX  compatibility package  -- since  they
have one of each system.  I believe he can rest easy.

Gary Knott,  from NIH, represents  a user  community which uses  SAIL
chiefly  for numerical and graphical  problems.  He has  a variety of
suggestions for improvements, including:

   Dynamic allocation (records, or equivalent).
   Numerical routines to replace the current Fortran package.  

Bob Sproull  modified the  Fortran routines  to operate  in the  SAIL
environment,  when he was  at NIH.   They use  an interrupt structure
("on-conditions")  which  Bob  also  included  in  the  SAIL  runtime
environment,  and the  SAIL error  message facilities,  to provide  a
much  better integrated package.   Gary would  understandably like to
see equivalent facilities included in the standard  release,  because
he is  anxious to install a newer  SAIL than the one he  has, but has
no manpower available to modify it.  We intend to do something  about
this before the next release.

John  Wedel, speaking  for  JPL, would  particularly  benefit from  a
fairly  standard SAIL system, since  his group uses  SAIL under three
different operating systems  (Stanford, ISI,  and Cal Tech).   He  is
quite interested in  a TENEX-compatible SAIL.  He would  also like to

  An efficient way to save entire leap environments.
  Better numerical routines.
  A reasonable interface to the TENEX IDDT.
  A good SAIL maintenance procedure.
  A mechanism for communicating useful packages among users in the 
   SAIL community.
3. Discussion.

The   discussion  which   followed   centered  on   Maintenance   and
standardization  issues.  We  quickly reached a  concensus on several

  a) Most of the users who have custom-tailored  SAIL  systems,  or
     who  need  frequent  updates,  have  ready  access to the ARPA
     network.   We  can  therefore  concentrate  our   efforts   on
     convenient  network-oriented  file maintenance facilities.  We
     can  limit  DECUS  releases  to  a  tape  sent  bi-yearly,  or
     thereabouts.   DECUS need no longer also publish SAIL manuals,
     since they are now available in  quantity  from  the  Stanford
     Computer  Science  Dept.  The volume of non-network users will
     probably be low enough that Stanford people can handle special

  b)  One major difficulty with obtaining a new SAIL system is that
     of re-incorporating local features in the Stanford files.   We
     decided  that  we  would maintain at Stanford a master copy of
     SAIL   sources,   containing   recent    versions    of    ALL
     installation-dependent  features,  using  conditional assembly
     macros to select  a  particular  configuration.       We  will
     provide  communication  mechanisms to help keep these files up
     to date.  Although we  will  not  necessarily  try  to  update
     installation- dependent things when making changes, we will at
     least try to inform the appropriate people when changes  might
     affect  their code.  This will be a lot easier when we can see
     what that code is.

  c) People at other sites need to be warned of impending  changes,
     both  to  be allowed a chance to protest or comment, and to be
     able to know when the master files are going to change--  when
     it  is inadvisable to copy master files in order to make their
     own modifications.

The  following  file  maintenance  protocol  is  a  result  of  these
decisions.   It is  a preliminary attempt  to design  a manual system
which will  make remote  installation  of new  SAIL systems  go  much
smoother.   Please let me know  what you think  of it.  We  will soon
implement  this  plan (or  a  modified  version), and  will  ask that
affected installations take appropriate steps (see  below) to provide
us with their installation-dependent code.

1. Master files maintained at Stanford (SU-AI).

We will maintain,  on the file area  [X,AIL], a master set  of source
files,  comprising:

  a) The compiler.

  b) The runtime routines (DEC systems, TENEX systems).

  c)  Auxiliary files -- PTRAN, RTRAN, PROFIL, etc. -- leaving out
     some of the  random  programs  (DIRMAK,  etc.)  included  with
     previous  releases  --  only those programs needed by users or
     system maintainers.

  d) Auxiliary processors, such as FAIL, CREF (block  structured),
     or  DDT  (block structured) -- or pointers to them (the master
     versions for these programs are typically stored on other file

  e)  Documentation:  TELLEM (maintenance manual), and citations to
     a SAIL manual and a FAIL manual, contained on other file areas
     at  SU-AI.  These will be in a single-column form suitable for
     printing on any device which can handle 96-character Ascii.

Files  in  the  first  three   categories  will  contain  conditional
assembly/compilation macros, whose names will be mutually decided.

Changes to master  files will be made only by "authorized personnel",
which currently  means SU-AI  people,  or IMSSS  person.   They  will
perform  updates on  behalf  of other  installations  in response  to
requests,  as described  below.   We may  limit the  update frequency
(for  the  sake of  stability),  although  this  has  not  yet  been
2. File format.

2a-- Installation-Dependent Facilities.

We will extend the conditional  assembly and bug-indication notations
of  the current SAIL files,  and will attempt to  use these notations
religiously.  The  former (conditional  assembly) is more  important,
because we  want to maintain the  integrity of installation-dependent
features.  However,  a  well-maintained  bug  and  feature indication
policy will make it a lot easier for people to  see what has changed.
The  remainder of  this  section sketches  the  proposed source  file

The inclusion  of  each installation-dependent  (or  other  optional)
facility will  be  controlled by  a pair  of macros  (e.g., EXPO  and
NOEXPO),  which  expand  to  conditional  assembly  statements.   The
current  SAIL files  contain  macros  like  this.    We  have  placed
additional  restrictions on  their appearance  (see TELLEM),  so that
programs  may be  simply  written to  manipulate files  which contain
them (see IFN below).  

We should probably replace the EXPO/NOEXPO pair of macros  with a set
of  feature  names,  each  controlling  a  different  aspect  of  the
difference between Stanford's  system and others.   This has  already
been done,  to  some extent, with [p,pn] specifications,  etc., since
some sites  have implemented the Stanford conventions.   This is also
in line with our desire for mnemonically meaningful macro names.

The macro  pairs will include  the option  for XLISTing  non-included
features (turning off listing of  these features during assembly), as
an option to the IFN-procedure below.

In  some cases  --  for  instance,  the TENEX  runtimes  --  entirely
disjoint files will be maintained for the different versions.

A single  file, FILSPC, will contain  the name, complete description,
and default setting  for each conditional feature.   It will  include
the names of the installations which  use each feature.  It will also
include such  specifications as the file names used for libraries and
START_CODE  opcodes.     This  file  should   be  modified  at   each
installation to configure that installation's system.

The   IFN.SAI  program  is   provided  on   [X,AIL],  to   allow  any
installation to remove  the conditional assembly  from its copies  of
the system,  leaving only the  installation's customized code.   This
should make local  files smaller and more readable, at the expense of
extra effort when next  comparing to the master  files.  Use of  this
facility is  completely optional.  Instructions  for modification and
use of IFN will be included in its prologue.

2b -- Indication of Bugs and Features.

For  the past three years, we have  been giving each discovered bug a
unique,  two-letter   identifier.    This   tally  has  reached   the
embarrassing  figure of  "OP" --  something over  400 entries.   More
recently, we have  begun including  these identifiers  in the  source
code for each fix,  in a specialized notation (whose  details will be
included in  TELLEM).  Bugs in the code  are denoted by comment lines
containing #bb#, where "bb" is the two-letter bug identifier.   These
lines also identify  the author of the change, and  the date on which
it  is made.  (Edits  specified by remote  colleagues will bear their
identification, not those of the "editor".)

We  will  now  begin  including  a  similar  notation  for  new  SAIL
features,   which   have  heretofore   been   inserted   without  any
indication.  The  format for features  is similar  to that for  bugs,
except for  the delimiter:  %ff% will denote  the feature  denoted by
the two-letter identifier "ff".

An   introductory  page  of  each   file,  contained  within  comment
delimiters, will  be reserved  for "version information".   For  each
edit to  a master file  an entry will  be made in  this page denoting
the bug or feature for which the  change was made, the author of  the
change, and  the  date on  which  it was  made.   The  editor we  use
enforces   this  convention,   and  in   addition  assigns   to  each
independent edit  a  sequence  (edit)  number, which  is  part  of  a
"version number"  for the file  (standard DEC version  number format,
if you're interested).

Each  time the master files  are updated, the  major or minor version
number will be  bumped.   For instance, version  16-C might yield  to
16-D,  or  17  to  16-F  (changes  of the  numerical  component  will
accompany major updates).   A  complete version number  for the  file
includes the  sequential edit number,  as: 16-E(132).   Again, TELLEM
will contain details.
3. Communication Files.

In addition to the software sources and  documentation files, we will
maintain a  set of communication files.  In  them we will store lists
of bugs,  features, requests,  announcements, changes,  and  warnings
("coming  soon...").   These files  will  be changed  in response  to
local  needs,  or to  requests  made via  ARPANET  or US  mail.   The
following lists our best guess about the files which will be needed:

BUGS  Known  bugs,  listed by bug identifier (two-letter code).  Each
      entry, for solved bugs, will contain the file names  containing
      fixes for these bugs, the author of each fix, and the date.  If
      the fix pertains only to  some  configurations,  that  will  be
      appropriately documented.

FEATS  Planned  or  installed features, listed by feature identifier.
      Maintained in a fashion similar to BUGS.  No entry will be made
      here  until  the  feature  is completely designed, and has been
      definitely scheduled for inclusion in SAIL.

CHANGES Changes to be made to  master  files--  fixes  to  bugs,  new
      features,  etc.   Some take the form of specified patches, some
      are citations to files, remote (non-Stanford) or  local.   Each
      also  cites a bug or feature number.  This file is organized by
      individual change, and  does  not  necessarily  follow  bug  or
      feature  number  order.   It  exists  mostly for the benefit of
      local people who actually do the master file maintenance.

REQUESTS This is an informal, running  list  of  comments,  requests,
      complaints,  suggestions,  etc.   Requests will be numbered for
      reference.  This file will be used  for  communication  between
      remotely  located  people, interested in common segments of the
      system.  This file will be used to generate features.

ANNOUNCEMENTS Before a set of changes is made to the master files, an
      announcement will be placed in this file, detailing the change.
      The lead time has not been settled, but will probably be on the
      order  of  a  week.  Each announcement will also be mailed (via
      ARPANET  or  US   mail)   to   each   installation.     Another
      announcement  will  be  issued  when  the  changes are actually
      installed.  Each announcement will be labelled by  the  version
      number to which the system is being updated.  It will include a
      list of the features and bug fixes to be installed.

PACKAGES A list of programs, written  in  SAIL,  which  might  be  of
      general interest.  Each will contain a citation to the relevant
      files.  This file will only be maintained if anybody uses it.

LIES It is suggested that we also have a file to specify bugs in  the
      manual,  and  in other documentation.  This would be similar in
      format to the BUGS and FEATURES files.

Additions  will  be  made to  these  files,  in  response  to  mailed
requests,  hopefully  on  a  "same-day"  basis.    It should  not  be
necessary to  include  in  each  message the  file  which  should  be
updated.   Have we left anything  out?  Is  there too much here?   Do
you think we can keep up with this mess?
4. Getting Started

The  initialization  of   the  above  procedures  will   be  somewhat
difficult. First, we will  have to do a few things to prepare for its

   a)  Modify the on-line version of the manual, so that it is more
      universally printable.

   b) Expand the EXPO/NOEXPO  pair  into  several  feature-specific

   c)  Replace  special  characters  in  all  source  files by more
      universally printable characters.

   d) Integrate the numerical routines (trig, log  functions)  into
      the  runtime  structure  of SAIL (including interrupt routine

   e) Increase the speed of the SU-AI FTP, if  possible  --  it  is
      particularly slow.

Then  we  will collect  installation-dependent  features  from  other

  UTAH, NIH, MIT, etc. -- those who haven't installed  a  new  system
  recently  --  will  do  best  to copy over all of [X,AIL] (after we
  announce its readiness), add their special features, and  send  the
  results  of  any changed files back, in the form of file citations.
  We will not change anything on [X,AIL]  during  this  interval,  so
  that  comparison  to locate the appropriate features will be fairly
  easy.  Each installation should  include  a  list  of  its  special
  features, and their names.

  CMU, JPL(?), CASE -- who have more recent  installations  --  could
  try   to   make   source   compares,   and   send   back  only  the
  installation-dependent changes.  They could revert to the  previous
  procedure if this proved too onerous.

It would be useful  if those who plan major  contributions could plan
to spend  a week or so in Palo Alto, to  help perform the merger.  We
hope, however, that this is not a requisite. 


  December 1, 1973.  At this time, the  communication  files  of  the
  previous pages should be on [X,AIL] and in good shape.  The precise
  formats and mechanisms  for  managing  them  should  be  completely

  December 1, 1973 to January 31, 1974.  This is our current plan for
  the merger interval, during which time no changes will be  made  to
  any but communication files on [X,AIL].

  Just  about  any  time.   We  will begin sending ANNOUNCEMENTS, and
  filing them in the file of the same name, sometime between now  and
  December 1.

These examples are suggestions of formats to  be used to record bugs,
features, announcements, etc.,  in the various files which need them.
Some are currently used,  others are proposed  new formats.  All  are
subject to change-- they are simply my suggestions.

1. Bug format in source files.
   This is (approximately) the form currently used.  We have not been
   quite consistent enough in these to allow any machine-analysis of 
   these things.  We do not intend to unless a need for it arises.

;;#CR# 6-21-72 DCS (2-4) Better TTY listing
; (bug id, date, author, 2d of 4, explanation)
; (used to terminate a group of lines modified by bug CR).


;;#CR#2↓ 6-21-72 DCS (2-4) Better TTY listing
; (two lines changed, no terminating line is needed)

The sequence indication is not needed for a fix  which can be done in
one  group  of  lines, or  in  a  couple of  groups  which  are close
together. We  have been  known to  reverse any  or all  of the  above

2. Bug format on "history" page.
   The first or second page of our source files are reserved for a
   "history" of bugs and features.  Along with some other junk, this
   page contains a list of lines, resembling:


The version number follows DECs most recent (I think) format.  In
its most general form, it is:
		MMm-c(nn), where
	MM is the major version number,
	m  is an optional minor version letter (we seldom use it),
	c  is a code identifying whether DEC, a software type, or
	   a lowly user made the edit, and
	nn is an edit number, which begins at 1, and is bumped by 1
	   for every edit, independent of the other parts of the code.

We have an editor which maintains this page semi-automatically.  Some
effort could be expended to put more bug/feature aids into our editor,
but none is currently planned.

3. Bug (feature) format in BUGS (FEATS) file.

	[GEN/29] RHT (9-22-72) OK JRL

  Bug ID, description, and person who detected the bug (designed the
    feature, entered when bug is discovered, or when feature has
    been firmly specified.
  Files (and page numbers) changed, date of fix, and initials of fixer
    entered when the fix has been made and tested (in SOME set of files).
  We may need yet another entry to specify when the fix makes its way
    into [X,AIL], but that data is calculable from BUGS and ANNOUNCEMENTS.

4. Changes.

   Changes will be entered as citations to (Stanford-local or Stanford-remote)
   files, for large changes;  SRCCOM-type indications for medium-sized changes;
   or simple fix-specifications ("change the HRR after ABCDE: to HRRZ").  Each
   should have some identification of the author and date of the change.  The
   CHANGES file should be organized by file, then by lexical order of change
   within the file (as described above).  I don't believe we need any more
   formal format for this.

5. Other files.

   These will probably be quite informally organized.

1.  Who   will  design   and  implement   the  merger  of   inter-job
    communication with the SAIL process facilities?

2. Can  we extend these methods to  universally-used SAIL programs --
   like PUB?

3. Should we have a protocol for removing bug indications from source
   files after a certain interval (say two years)?  This would help
   keep the files from looking too cluttered (they will still look
   pretty cluttered).

4. It has been suggested that there ought to be a way to denote changes
   and features which fall under the general category of "cleanliness".
   Examples are bad instruction sequences, poorly commented sections, etc.
   We could just make these in [X,AIL] without any special markings, or
   perhaps generate on "feature identifier" between each set of [X,AIL]
   changes, which could denote all the cleanliness changes.  Please comment.

Bill Merriam (@BBN)
Bolt Beranek and Newman, Inc.
Research Computer Center
50 Moulton Street
Cambridge, Massachusetts 02138

John Metzger (METZGER@CASE-10)
Case Western Reserve University (METZGER@CASE)
Computing and Information Sciences Div.
10900 Euclid Ave.
Cleveland, Ohio, 44106

Lee Erman (A610LE03@CMU-10A)
Computer Science Dept.
Carnegie Mellon University
Schenley Park
Pittsburgh, Pa., 15213

Robert Smith, Rainer Schultz
Institute for Mathematical Studies in the Social Sciences (IMSSS)
Ventura Hall
Stanford University
Stanford, Ca., 94305

John Wedel, Meir Weinstein (@USC-ISI,WEDEL, WEINSTEIN)
California Institute of Technology
Jet Propulsion Laboratory
4800 Oak Grove Drive
Pasadena, Ca., 91103

Gary Knott
Bldg 12A, Room 3053
National Institutes of Health
Bethesda, Md. 20014

Jerry Feldman, Kurt VanLehn, Jim Low, Hanan Samet,
   Dan Swinehart, Russ Taylor  (@SU-AI,JAF, KVL, JRL, HJS, DCS, RHT)
Stanford Artificial Intelligence Laboratory
c/o Polya Hall
Stanford University
Stanford, Ca., 94305
(415)321-2300 x4971

Mike Dervage (DERVAGE@UTAH-10)
University of Utah
Computer Science Dept.
Merrill Engineering Bldg.
Salt Lake City, Utah, 84112

Xerox Palo Alto Research Center
Porter Drive
Palo Alto, Ca.

Not present, but also receiving copies of this report:

Jim Goodwin (GOODWIN@BBN)

Alan Rosenfeld, Jim Calvin (@CASE,ROSY, CALVIN)

Donald Williams (WILLIAMS@USC-ISI)

Thomas W. Burtnett
Univ. of Illinois
Coordinated Science Lab.
Urbana, Il. 61801

Pitts Jarvis (PJ@MIT-AI)
Project MAC
Artificial Intelligence Laboratory
545 Technology Square
Cambridge, Mass., 02139

Louis Knapp
Computer Sciences
Syracuse Univ.
Syracuse, N.Y.