Search                        Top                                  Index
REF SUBSYSTEM                      John Williams, Robert Duncan Jul 1991
                                           Revised John Gibson, Feb 1993

        COPYRIGHT University of Sussex 1993. All Rights Reserved.

<<<<<<<<<<<<<<<<<<<<<                             >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<<          SUBSYSTEMS         >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<<                             >>>>>>>>>>>>>>>>>>>>>>

A description of the facilities used for installing and controlling  the
language subsystems  of Poplog.  If  new subsystems  make use  of  these
facilities, then  operations such  as switching  from one  subsystem  to
another can be achieved in a general way. For an overview of this topic,

         CONTENTS - (Use <ENTER> g to access required sections)

  1   Subsystem Records

  2   Standard Subsystems

  3   Subsystem Initialisation

  4   Current Subsystem and Current Compiler Subsystem

  5   Invoking Subsystem Compilers

  6   Subsystem Image Startup

  7   Ved and Subsystems

  8   Subsystem-Sensitive Procedures

1  Subsystem Records

Subsystem  records  are  data  structures  held  in  the  list  variable
sys_subsystem_table. However,  you do  not  normally access  this  list,
since user access  to a subsystem  is always in  terms of the  subsystem
name (there can only be one subsystem for a given name).

A subsystem contains the  following fields:

    Field Name        Type          Description
    ----------        ----          -----------
    SS_NAME           word          The subsystem name: e.g. "pop11"

    SS_PROCEDURES     substructure  A      sub-structure      containing
                                    procedures -- see below.

    SS_FILE_EXTN      string        The  default  file  extension:  e.g.

    SS_PROMPT         string        The  default   prompt   string   for
                                    interactive input: e.g. ': '.

    SS_SEARCH_LISTS   list          Table of search-lists  for Ved:  see
                                    section Ved and Subsystems below.

    SS_TITLE          string        A descriptive  title, typically  the
                                    full language name.

The  SS_PROCEDURES  field  contains  a  sub-structure  holding  all  the
procedures associated with the subsystem compiler, as follows:

    Field Name        Type          Description
    ----------        ----          -----------
    SS_COMPILER       procedure     The subsystem compilation procedure:
                                    e.g. pop11_compile. Used to  compile
                                    files   and   as   an    interactive
                                    top-level;  may   be  applied   to a
                                    filename, a  device or  a  character

    SS_RESET          procedure     Reset    procedure,    called     by
                                    pop_setpop_compiler      immediately
                                    before re-invoking  the compiler  at

    SS_SETUP          procedure     Initialisation procedure, called  on
                                    system startup (from syssetup) or by

    SS_BANNER         procedure     Procedure for  printing the  banner,
                                    called  on  system  startup  or   by

    SS_INITCOMP       procedure     Compiler  initilisation   procedure:
                                    e.g. sysinitcomp.  Called on  system
                                    startup or  by  sys_subsystems_init.
                                    Typically compiles  user and  system
                                    "init" files.

    SS_POPARG1        procedure     Procedure  for  processing   command
                                    line arguments  on  system  startup.
                                    Usually  calls   sys_process_poparg1
                                    with arguments  appropriate  to  the

    SS_VEDSETUP       procedure     Ved initialisation procedure, called
                                    from vedsetup.

    SS_XSETUP         procedure     X Windows initialisation  procedure,
                                    called   on   system   startup   (if
                                    popunderx  is   non-false)   or   by

Currently, the outer subsystem record is  simply a list with the  fields
ordered as above,  and the SS_PROCEDURES  field is a  vector (also  with
elements in  the  order  given).  However, to  avoid  reliance  on  such
implementation details, the procedure subscr_subsystem is provided: this
allows any field to be accessed in an implementation-independent way.

The  first  argument   to  subscr_subsystem  is   an  integer   'virtual
subscript', whose encoding specifies either one of the outer fields,  or
one of the  inner SS_PROCEDURES fields.  All the field  names above  are
defined  as   suitable   integer   constants   by   the   include   file

Note that the SS_PROCEDURES field may contain either a vector  directly,
or an identifier/identifier name whose idval/valof is the vector. If the
field contains an identifier name (ie, a word), the identifier need  not
actually be  defined: this  enables  the outer  subsystem record  to  be
present without  any of  the compiler  procedures being  loaded, and  is
useful for those facilities (such as subsystem_searchlist) which  access
only the SS_FILE_EXTN and SS_SEARCH_LISTS fields, etc.

sys_subsystem_table -> list                                   [variable]
list -> sys_subsystem_table
        List of active subsystem records.

is_subsystem_loaded(ss_name) -> bool                         [procedure]
is_subsystem_loaded(ss_name, include_no_compiler) -> bool
        Tests whether (the word) ss_name is a known subsystem name, i.e.
        whether sys_subsystem_table contains a subsystem record of  that

        If the optional  boolean include_no_compiler  argument is  true,
        then true is returned  for a subsystem which  is present in  the
        table, but whose SS_PROCEDURES field is an undefined  identifier
        (that is, one  whose procedures are  not loaded). Otherwise,  if
        include_no_compiler  is  false   (the  default  when   omitted),
        subsystems whose procedures are not loaded will produce a  false

subscr_subsystem(field, ss_name) -> item                     [procedure]
item -> subscr_subsystem(field, ss_name)
subscr_subsystem(field, ss_name, err_p) -> item
item -> subscr_subsystem(field, ss_name, err_p)
        Access or update a field of  a subsystem.

        field is the integer 'virtual subscript' for the field, and must
        be one of the constants defined by INCLUDE * SUBSYSTEM.

        ss_name must be the name of an entry in sys_subsystem_table, and,
        if field refers  to one  of the  SS_PROCEDURES sub-fields,  then
        SS_PROCEDURES must not be an undefined identifier name (i.e.

            is_subsystem_loaded(ss_name, false)

        must be true).

        If ss_name  is  not  present in  sys_subsystem_table,  or  field
        specifies a procedure field and  the procedures are not  loaded,
        then by  default  the  mishaps  'SUBSYSTEM  NONEXISTENT  OR  NOT
        LOADED' or 'SUBSYSTEM  COMPILER NOT LOADED'  occur. However,  if
        the optional procedure  err_p is supplied,  then this is  called
        instead with the relevant  mishap message (prefixed by  ss_name)
        as argument, viz

                err_p(ss_name >< message)

        err_p  is  then  expected  to   cause  an  abnormal  exit   from

        For example,

          subscr_subsystem(SS_COMPILER, "foo", vederror) -> compiler;

        could be used to  the get the  compiler procedure for  subsystem
        "foo", but with  a Ved  error message if  subsystem or  compiler
        were not loaded.

app_subsystems(p)                                            [procedure]
        Applies the procedure p to the SS_NAME field of every  subsystem
        in sys_subsystem_table. i.e. runs


        for every subsystem.

subsystem_add_new(ss_name, procedures, extn, prompt,         [procedure]
                                search_lists, title)
        Constructs a new (outer)  record for a  subsystem named by  (the
        word) ss_name, and  adds it at  the end of  sys_subsystem_table.
        (If pop_debugging is false, the subsystem ss_name must not exist
        already; otherwise, any existing entry is removed first.)

        extn, prompt and  title are  strings for the  initial values  of
        SS_FILE_EXTN, SS_PROMPT and SS_TITLE respectively;  search_lists
        is list for the initial value of SS_SEARCH_LISTS.

        For  SS_PROCEDURES,  procedures  may  be  either  a  vector   of
        procedures directly, or just a compiler procedure (in which case
        a 1-element  vector is  constructed around  it). procedures  may
        also be a word (whose valof will contain the procedure vector).

        (Note that the outer structure is declared writeable.)

2  Standard Subsystems

The following subsystems are provided as a standard part of Poplog.

pop11                                                   [subsystem name]
        The base Pop-11 subsystem, always present in the normal  system.

prolog                                                  [subsystem name]
top                                                     [subsystem name]
        The Prolog subsystems.  These are  defined in  the library  file
        LIB * PROLOG_SUBSYSTEM.  Their  SS_PROCEDURES  fields   indirect
        through the  identifier  names  prolog_subsystem_procedures  and
        top_subsystem_procedures  respectively:  these  identifiers  are
        defined when  LIB * PROLOG is  loaded (as  in the  Prolog  saved
        image). See HELP * PROLOG.

lisp                                                    [subsystem name]
        The Common  Lisp  subsystem.  Its  definition  can  be  found in
        LIB * LISP_SUBSYSTEM. Its SS_PROCEDURES field indirects  through
        the identifier name  lisp_subsystem_procedures: this  identifier
        is defined when  LIB * CLISP  is loaded (as  in the CLisp  saved
        image). See HELP * CLISP.

ml                                                      [subsystem name]
        Standard  ML subsystem,  defined   by   LIB * ML_SUBSYSTEM.  Its
        SS_PROCEDURES  field  indirects  through  the  identifier   name
        ml_subsystem_procedures:  this   identifier  is   defined   when
        LIB * PML is loaded (as in the PML saved image). See HELP * PML.

csh                                                     [subsystem name]
sh                                                      [subsystem name]
dcl                                                     [subsystem name]
csh_subsystem -> "csh"                                        [constant]
sh_subsystem  -> "sh"                                         [constant]
dcl_subsystem -> "dcl"                                        [constant]
        Subsystems for the Ved 'immediate mode' operating system command
        interpreters (csh  and  sh in  Unix,  dcl in  VMS).

        They are defined by the autoloadable identifiers  csh_subsystem,
        sh_subsystem (Unix) and dcl_subsystem  (VMS), all of which  have
        the subsystem name as  their value. (This  makes it possible  to
        have a entry in * vedfiletypes such as

            [ '.csh' {subsystem csh_subsystem} ]

        which will both  autoload the subsystem  and supply the  correct
        value for subsystem.)

        (These  subsystem  libraries  load  their  compiler   procedures
        automatically and do not  indirect through identifier names  for
        their SS_PROCEDURES fields.)

3  Subsystem Initialisation

sys_init_subsystem(ss_name)                                  [procedure]
        Initialises the named subsystem ss_name by calling its SS_SETUP,
        SS_INITCOMP, SS_XSETUP and SS_VEDSETUP procedures.

        The SS_INITCOMP procedure is called only if pop_noinit is false.
        The SS_XSETUP procedure is called only if popunderx is true, and
        sysxsetup is called before running it.

sys_subsystems_init(pfield)                                  [procedure]
        Where  pfield   specifies  a   subsystem  procedure   field   in
        SS_PROCEDURES, applies  the  procedure  in that  field  for  all
        subsystems in sys_subsystem_table (that is, all which have their
        SS_PROCEDURES loaded).

        If pfield is  SS_BANNER, and  popheader has a  true value,  then
        popheader  is  printed  (and  set  false)  before  running   the
        SS_BANNER procedures.

        If pfield is SS_XSETUP, then sysxsetup is called before  running
        the procedures.

4  Current Subsystem and Current Compiler Subsystem

There are two notions of 'currency' with respect to subsystems:  current
subsystem  and  current   compiler  subsystem.   They  are   represented
respectively by the variables subsystem and pop_compiler_subsystem.

On the one hand,  subsystem is simply  the name of  the subsystem to  be
used for  any  operation which  is  subsystem-dependent (such  as  which
documentation searchlists to use, or subsystem_valof, for example). Each
file  in  Ved  has  its  own  value  for  subsystem  (usually  set  from
vedfiletypes), and determines the compiler used when loading all or part
of the file,  etc. subsystem can  be (locally) set  by any procedure  if
this is required.

pop_compiler_subsystem, on  the  other  hand,  defines  which  (if  any)
language subsystem compiler is currently executing. This is a  protected
variable, and  is set  only by  those system  procedures which  invoke a
compiler in 'subsystem' mode, viz


These procedures locally set  both subsystem and  pop_compiler_subsystem
to  the  name  of  the  subsystem   being  run;  by  virtue  of   having
pop_compiler_subsystem as a  dynamic local,  they define  points in  the
calling sequence  at which  commands to  switch between  languages  will
operate. E.g. if Prolog were invoked on a file with

        subsystem_compile(file, "prolog");

then the Prolog command

        :- pop11.

occurring in file would chain out  of the call of prolog_compile  inside
subsystem_compile, and  replace it  with a  call to  pop11_compile.  The
procedure   which    implements   this    switch   (the    updater    of
sys_compiler_subsystem), knows at  what point in  the calling chain  the
switch     should     operate     because     subsystem_compile      has
pop_compiler_subsystem as a dynamic local.

An important point in this respect is that subsystem compiler procedures
do not  in themselves  set either  subsystem or  pop_compiler_subsystem.
Thus an ordinary call to one, e.g.


is not equivalent  to

        subsystem_compile(file, "prolog");

since it will not be recognised as a 'subsystem' invocation.

Note that  the variable  pop_compiler_subsystem is  normally  referenced
with sys_compiler_subsystem (see below).

subsystem -> ss_name                                          [variable]
ss_name -> subsystem
        The  name   of  the   subsystem  currently   to  be   used   for
        subsystem-dependent operations.

        Each file in Ved  sets its own  value for subsystem  (usually, a
        value got from vedfiletypes),  and this determines the  compiler
        used by ved_lmr, ved_x, etc.

        pop_setpop_compiler uses this variable to decide which subsystem
        compiler  to  run  at  top-level  outside  of  Ved,  or  in  Ved
        'immediate mode'.

sys_compiler_subsystem(which) -> ss_name_or_false            [procedure]
ss_name -> sys_compiler_subsystem(which)
        In access mode, this procedure  returns the name of the  current
        or 'top-level' compiler-subsystem invocation,  or false if  none
        is running. In  update mode,  it switches  to a  new current  or
        top-level compiler subsystem.

        (As  described  above  in  the  introduction  to  this  section,
        compiler-subsystem invocations  are  calls of  procedures  which
        locally set the protected variable pop_compiler_subsystem,  i.e.
        pop_setpop_compiler, subsystem_compile and ved_lmr.)

        The which argument  is an integer  character with the  following

           which    Meaning
           -----    -------
            `c`     The   current   compiler-subsystem   invocation,
                    relative to Ved.

            `t`     The  top-level  compiler-subsystem   invocation,
                    relative to Ved.

            `C`     The   current   compiler-subsystem   invocation,
                    external to Ved.

            `T`     The  top-level  compiler-subsystem   invocation,
                    external to Ved.

        In the above, 'relative to Ved' means 'within Ved' if the system
        is currently  inside  Ved  (i.e. vedinvedprocess  is  true),  or
        'external to  Ved' otherwise.  Thus the  lowercase values  treat
        vedprocess as  the outer  limit of  the system  when inside  it.
        (Outside Ved, upper and lowercase are the same.)

        For `t` and `T`, a  'top-level' invocation means one to  which a
        setpop would reset,  i.e. one being  run by  pop_setpop_compiler
        (either inside or outside Ved).

        Base Procedure
        The  base   procedure  returns   the  subsystem   name   ss_name
        corresponding to the  which argument, or  false if none  exists.
        (For  argument   `c`,  the   result  is   just  the   value   of

        Note, for example,  the following circumstances  in which  false
        will result: for `c` or `t` if inside Ved, but not in a compiler
        (e.g. when executing  a Ved command);  for `t` when  compiling a
        file or marked range in Ved, and not in immediate mode; for  `C`
        or `T`  in the  XVed standalone  image, where  no compiler  runs
        outside of Ved.

        The updater  switches  the compiler-subsystem  corresponding  to
        which  to  be  the  new  subsystem  specified  by  ss_name.  The
        corresponding one must already exist (i.e. it is an error if the
        base procedure would  return false for  which); if the  existing
        one is already ss_name, the updater does nothing.

        Only values `c`  and `t`  are allowed  for which  (that is,  the
        compiler external to Ved cannot  be switched from inside Ved  --
        use ved_pop for this).

        The  updater  performs  the  switch  by  chaining  out  of   the
        currently-executing compiler, back into  the environment of  its
        first procedure call; the value of cucharin in that  environment
        is then  taken  as  the  input  argument  for  the  new  ss_name
        compiler. (This ensures that local redefinitions of cucharin  at
        other points inside the old compiler are ignored.)

        Both  subsystem  and  pop_compiler_subsystem  are  then  set  to
        ss_name, and finally, before chaining the new compiler from  the
        old, if  the  subsystem being  replaced  is actually  the  outer
        top-level compiler (i.e. that  being run by  pop_setpop_compiler
        outside of  Ved), and  cucharin is  charin, then  the  procedure
        subsystem_changed_warn is called with ss_name as argument. (This
        happens regardless of whether which is `c` or `t`.)

subsystem_changed_warn(ss_name)                     [procedure variable]
        User  hook  called  by  the  updater  of  sys_compiler_subsystem
        whenever there is a change  to the top-level compiler  subsystem
        (i.e. that being run by pop_setpop_compiler, outside of Ved). It
        is called only if cucharin for the compiler is charin. ss_name is
        the new subsystem name. (Default value erase.)

pop_compiler_subsystem -> ss_name_or_false          [protected variable]
        The  system  variable   used  to  implement   compiler-subsystem
        invocations, as described above.

5  Invoking Subsystem Compilers

See also subsystem_libcompile in REF * LIBRARY.

subsystem_compile(source, ss_name_or_false)                  [procedure]
        Invokes  a  subsystem  compiler  to  compile  the  input  source
        argument, where the  second argument may  be either an  explicit
        subsystem name, or false.

        If a  subsystem name  is supplied,  then the  compiler for  that
        subsystem is  used; in  this case,  source may  be any  argument
        suitable for that compiler.

        Otherwise, the subsystem is deduced from the filename  extension
        got from source. To effect this, source must be either

          # a filename string, or a word;

          # a device whose device_full_name is a filename;

          # a character  repeater  (or other)  procedure  whose  pdprops
            (dereferenced by recursive_front) are a filename.

        If the  filename derived  from any  of the  above has  an  empty
        extension, then pop_default_type is used instead.

        To deduce the subsystem name, vedfiletypes is first searched  to
        see if it contains a setting for subsystem corresponding to  the
        extension; if not,  then all  subsystems in  sys_subsystem_table
        are searched for one whose SS_EXTENSION field matches it.

        Before calling  the compiler,  subsystem_compile_warn is  called
        with the input  filename as  argument. (This is  also done  when
        ss_name is supplied directly,  providing source yields a  string
        or word as a filename, in  the way described above. It will  not
        be called if source  is e.g. a list,  or a procedure with  false

        The compiler  for  the  subsystem is  then  invoked,  with  both
        subsystem  and   pop_compiler_subsystem  locally   set  to   the
        subsystem name.

subsystem_compile_warn(filename)                    [procedure variable]
        Called by subsystem_compile before  compiling a source  argument
        from which  a string  or word  filename is  derivable.  (Default
        value erase.)

loadcompiler(filename)                              [procedure variable]
        This procedure  is called  by  the Pop-11  syntax word  load  to
        compile filename. Its default value is defined as:

            define vars loadcompiler(filename);
                lvars filename;
                dlocal subsystem_compile_warn = erase;
                subsystem_compile(filename, false);

        That is, call subsystem_compile on filename with a false ss_name
        argument, allowing  the  appropriate subsystem  compiler  to  be
        selected on the basis of filename's extension.

loadwarning(filename)                               [procedure variable]
sysloadwarning(filename)                                     [procedure]
        loadwarning is called by the load syntax word to print a warning
        message  when  filename  is  compiled.  The  default  value   of
        loadwarning is sysloadwarning, which uses sysprmessage to  print
        the message

            ;;; LOADING filename

load                                                            [syntax]
        A Pop-11  syntax  construct  for loading  files  containing  any
        subsystem language. Its format is:

                load filename

        where filename is read with rdstringto up to ";", end of line or

        It plants Poplog VM code to print a warning message (by applying
        loadwarning to filename),  and then plants  code to compile  the
        file (by applying  loadcompiler to  filename).

6  Subsystem Image Startup

LIB * MKIMAGE provides  a  standard  method for  building  saved  images
containing one or more subsystems -- see HELP * MKIMAGE.

By default (that is, if not given other entry points), both the standard
Poplog executable image and  images built with  LIB MKIMAGE perform  the
following code on startup:

        sysexit -> interrupt;
        interrupt();        ;;; sysexit unless syssetup redefines it

(In both cases, this happens after processing any command line arguments
beginning with %, which  result in assignments  to pop_noinit, etc.  See
General System Startup in REF * SYSTEM.)

The procedure syssetup implements the standard Poplog language-subsystem
startup protocol, and is described  below. Its principal control  aspect
is that

  # When poparglist contains a (non-Ved startup) argument, interrupt  is
    left unchanged; the argument is compiled, and the call of  interrupt
    will therefore cause system exit.

  # Otherwise, interrupt is reset to setpop (and pop_first_setpop is set
    true). Thus after the  call of syssetup  returns, setpop is  called:
    this performs  all  necessary  resetting  actions,  and  then  calls

pop_setpop_compiler is the handle by  which control is regained  after a
setpop. It is actually a (protected)  variable, and can be redefined  to
provide other forms of top-level control (which is done, for example, by
the XVed  standalone  saved  image). However,  its  default  value  is a
procedure which (re)starts  the interactive compiler  for the  subsystem
specified by the variable subsystem. See REF * pop_setpop_compiler.

syssetup()                                                   [procedure]
        This procedure implements the standard Poplog language-subsystem
        startup, as follows:

        It first assigns true to pop_first_setpop, and then calls


        to run the SS_SETUP procedures for all (fully-loaded) subsystems
        present in sys_subsystem_table.

        Further action then depends on  poparglist. If this contains  an
        argument which is not one of the Ved commands:

            doc help im ref teach ved src showlib showinclude man

        then  the  SS_POPARG1  procedure  for  the  subsystem  given  by
        subsystem is  called  to  process  the  argument,  and  syssetup

        (A special exception to the above is the argument 'mkimage'.  In
        order to  make the  LIB * MKIMAGE  facilities available  to  all
        language subsystems, this argument  invokes the Pop-11  compiler
        on LIB MKIMAGE instead.)

        Otherwise, if poparglist is empty or starts with a Ved  command,
        this is a subsystem compiler  or Ved startup, and the  following
        initialisations are performed:

          # setpop is assigned to interrupt.

          # If  pop_nobanner  is  false,  and  pop_charin_device  is  an
            on-line terminal, then


            is called to print appropriate banners.

          # If pop_noinit is false, then


            is called  to compile  'init'  files for  each  fully-loaded

          # If popunderx is true, then


            is called to perform any required X setups.

        Finally, if the first  element COMMAND of  poparglist is one  of
        the Ved commands listed above, then

             popvedcommand(consword('ved_' <> COMMAND))

        is called to  invoke Ved  with the given  command (with proglist
        locally   set   to    the   remaining    argument   list,    see
        REF * popvedcommand).

7  Ved and Subsystems

A  feature  of  the  subsystem   library  is  the  ability  to   specify
documentation or  program libraries  specific  to each  subsystem.  When
searching for files in response to  a HELP command or similar, Ved  will
search first in the search-list specific to the subsystem determined  by
the variable veddocsubsystem (see below) before looking in the  standard

Subsystem-specific search-lists should be entered in the SS_SEARCH_LISTS
field of  the subsystem  record.  This is  an association  list  mapping
documentation names to search-lists, in the form:

    [ docname1 list1 docname2 list2 ...]

The documentation names are those used by vedgetlibfilename, such as

    vedhelpname       (for HELP requests)
    vedteachname      (for TEACH requests)
    vedrefname        (for REF requests)
    vedsrcname        (for SRC requests)
    vedlibname        (for SHOWLIB requests)
    ved_??_name       (for ? and ?? requests)

The corresponding search-lists are as described in  HELP * SEARCH_LISTS.
For example, a typical value for the SS_SEARCH_LISTS field might be

     vedhelpname    [['$subsystemroot/help/'  help]]
     vedteachname   [['$subsystemroot/teach/' teach]]

veddocsubsystem -> item                                       [variable]
item  ->  veddocsubsystem
        Determines how Ved decides the  subsystem to use when  searching
        for  documentation  or   library  files.   Possible  values   of
        veddocsubsystem and their effects are:

                Uses the value  of subsystem external  to Ved (i.e.  its
                value outside of vedprocess).

                Just uses the current value  of subsystem, (i.e. as  set
                for the current Ved buffer).

            Any other word
                Taken as the name of the subsystem to use.

            A string
                Taken as a  file extension:  uses vedsearchfiletypes  to
                determine a value of subsystem from vedfiletypes.

        The default value is "EXTERNAL",  meaning that the search  paths
        for documentation and libraries are  determined by the value  of
        subsystem outside of Ved  (normally, the language compiler  from
        which Ved is being called).

subsystem_searchlist(docname, ss_name)        -> list        [procedure]
subsystem_searchlist(docname, ss_name, false) -> list
subsystem_searchlist(docname, ss_name, true)  -> (list, ss_extn)
        Returns a  search-list from  the  SS_SEARCH_LISTS field  of  the
        nominated  subsystem.  docname  identifies  the  search-list  to
        return (see above  for example values).  ss_name is  typically a
        subsystem name -- "pop11", "prolog", etc -- but may be any value
        appropriate to veddocsubsystem.

        If no search-list matching docname is found, the empty list ([])
        is returned.

        The procedure  may  also  be given  an  optional  boolean  third
        argument: if  this is  true, a  second result  is returned.  The
        second  result  ss_extn  is  the  subsystem  SS_FILE_EXTN   if a
        search-list was found, or false otherwise.

ved_subsystem [ss_name]                                      [procedure]
        Ved command: changes the the value of subsystem for the  current
        file to be ss_name. Without an argument, it reports the  current
        value of subsystem.

veddo_in_subsystem(ss_name)                                  [procedure]
        If vedargument  is a  non-empty  string, executes  it as  a  Ved
        command, but with subsystem locally set to ss_name.

        If vedargument is nullstring, behaves the same as

                <ENTER> pop ss_name

        i.e, Ved  is exited  and control  transferred to  the  top-level
        compiler for the subsystem ss_name (see REF * ved_pop).

ved_lisp   [command]                                         [procedure]
ved_pml    [command]                                         [procedure]
ved_pop11  [command]                                         [procedure]
ved_prolog [command]                                         [procedure]
        These Ved  <ENTER> commands  use veddo_in_subsystem  to  execute
        command as if the current subsystem were "lisp", "pml", "pop11",
        or "prolog" respectively.

8  Subsystem-Sensitive Procedures

The procedures described below  provide a consistent, modular  mechanism
for  making   procedures  "sensitive"   to  the   current   subsystem. A
subsystem-sensitive procedure is one whose behaviour varies according to
current value of subsystem.

subsystem_valof(word, ss_name) -> p                          [procedure]
p -> subsystem_valof(word, ss_name)
        Returns/updates the procedure  p which would  be invoked if  the
        value of word were applied while the subsystem name ss_name  was
        the current subsystem. An error is signalled if ss_name is not a
        known  subsystem  name.  false  is  returned  if  word  is   not

        An example:

            my_jcp -> subsystem_valof("ved_jcp", "mysubsystem");

        This ensures that the procedure my_jcp is invoked if ved_jcp  is
        called while "mysubsystem" is the  current subsystem. It has  no
        effect on the behaviour of ved_jcp relative to other subsystems.

is_subsystem_sensitive(word) -> bool                         [procedure]
bool -> is_subsystem_sensitive(word)
        Tests whether  the  value  of  word  is  a  subsystem  sensitive
        procedure.   The    updater   may    be   used    to    return a
        subsystem-sensitive identifier to its original value, e.g.

            false -> is_subsystem_sensitive("ved_jcp");

--- C.all/ref/subsystem
--- Copyright University of Sussex 1993. All rights reserved.