I'm afraid you may have misunderstood slightly the intent of my reply
of the other night.  I thought that I'd made it pretty clear that I
wasn't going to go making changes to debugged code unless I was
prepared to spend sufficient effort to ensure that it was properly
debugged & documented -- especially if the changes were likely to
affect existing programs.  At the least, this will involve more work
on polishing the record stuff as a necessary precondition to any of
the process changes I mentioned.  -- By the way, SAIL.PUB[DOC,AIL]
does include preliminary documentation on records.  -- I was
presenting the ideas more in order to get your technical ( as opposed
to political ) reaction as to the long-term desirability of such
changes.  My personal belief is that the process item datums and
event-type datums can be made into records without introducing either
bugs or incompatibilities into existing code, providing suitable care
is taken in doing so.  (The situation is somewhat like introducing
expandable string space -- actually, much simpler than that, since
there are not the large number of hidden assumptions &
compiler-specific kluges that caused difficulties there.  Perhaps a
better example is SPROUT(id,APPLY(proc)), which was introduced with
no difficulties that I can recall, although some of the runtimes had
to be modified a bit.) Using records as return values for resume &
interrogate is probably too late, considering everything, but that's
probably ok, since you can always send record items.  Again, I have
no immediate plans to do any of this.  If I make any, I'll be sure to
let you know & arrange to get it working, debugged, & documented in a
reasonable period. 

As to changing SETPRI, perhaps the cleanest way for you to get the
effect you want is to introduce a bit (called "FIFO"?, say bit 33) in
the options to SPROUT.  Setpri can then check this bit & enqueue the
process either at the front or rear of its priority queue.  Also,
perhaps the sign bit of the PRIOR entry in the process descriptor can
be used to remember this fact, so that URSCHD will know to where to
put the process it decides to run (perhaps this should be a separate
bit?). -- by the way, in the note I sent yesterday my comments on
Urschd may have seemed a bit garbled.  I was typing while distracted
& seem to have suffered a momemtary transposition of LIFO-FIFO, hope
it made sense.-- As it turns out, I've also got a use for this sort
of thing, so if you have not already done something I'll endeavor to
make the changes here along the lines indicated.  If you want to do
things there, tell me (so that we don't get competing versions) &
I'll snarf your changes.  SAIL-8 seems to be stable now -- no bugs
for a week or so, & only a couple when it was put up -- so you might
as well snarf it, if you haven't already done so.  Alternatively, you
can wait until Wednesday, by which time I'll have setpri hacked.  I
plan to make up a new [X,AIL] either tonight or tomorrow night, but
you may as well gobble [s,ail].  We may want to add a few more
goodies, but there won't be anything that will cause
incompatibilities.  I.e. you can put up another one a month hence
without your users ever finding out.  Let me know what you decide. 

Concerning SAIL maintainence policy, I suppose I'd just as soon keep
with the present setup, at least for the next six months or so. For
one thing, the effort involved in changing is apt to exceed the
effort involved in fixing whatever bugs I can anticipate.  For
another, I'm apt to have my hands in various pieces of the system
anyhow, in adding facilities to support my thesis programming -- I
don't think this will lead to a bad situation bug-wise, since (a) I'm
apt to discover right away that whatever language feature I've hacked
got broken in the process, (b) we have a number of SAIL users here,
(c) the sorts of things I anticipate doing haven't caused trouble in
the past.  Also, I'll be careful not to introduce incompatibilities.
If need be, I'll try to get you a bit quicker response on things that
are causing you real difficulties -- it seems to me that our major
misunderstanding in the past was over the role of HACKSW; hopefully,
we can avoid this difficulty in the future, since we will have better
synchronized versions.  As near as I can tell, all your changes are
in fact in SAIL-8.  One thing to bear in mind is that some of your
suggestions can cause difficulties for the rest of the world.  In
these cases, of course, we can have a CMU < ... > for whatever you
cannot be talked out of wanting.  In these cases, it is helpful if
you figure out exactly where the switches should go, rather than just
saying "oh, put that under a switch".  We'll try to do it, but may
guess wrong.  I don't know that either of these problems can really
be cured organizationally, since some control over the general
language will be necessary, and since no one, no matter how
dedicated, is going to guess wrong at least some of the time. 

This message is getting altogether too long & cumbersome.  I'll give
you a phone call tomorrow around noon or 1pm (PST), & we can discuss
things further. 

Russ