From: <dcc@ATHENA.MIT.EDU>
Message-Id: <8908312124.AA00309@THANATOS.MIT.EDU>
To: bgardner@ATHENA.MIT.EDU
Subject: Initial comments on Argus spec.
Date: Thu, 31 Aug 89 17:24:36 EDT


  I finished my first reading of the Argus design specification.
  For the most part I'm in the process of learning the concepts and
  structure that Argus presents, so I haven't too much feedback to
  give at this point, but one thing did grab my attention.  The
  rule language seems weak, and though your intention is to hide it
  with a rule editor/browser, you will ultimately be limited by the
  weakness of the underlying language.

  One goal is to have a language which is simple and easily
  interpreted.  I support these goals completely, but I think it could
  be much simpler and yet more powerful.  One alternative would be to
  look at a function language syntactically similar to LISP and EDIFF.
  
  Here is a quick attempt to define such a language:

    function :: (function-name [arg [arg [arg] [...]]])

    function-name :: identifier

    arg :: function | primary

    primary :: identifier | number | string

    string :: "identifier"

  Here is what the example in section 4.1.1 might look like, but
  remember that there is a lot of flexibility in how function
  protocols (names and arguments) are defined.

  (RuleSet
    (created 619398053)
    (updated 619398242)

    (Rule
      (created 619398053)
      (updated 619398242)
      (name SiftStaff)

      (if
        (or
          (contains "To:" "Staff@Athena" CaseInsensitive)
          (contains "cc:" "Staff@Athena" CaseInsensitive)
        )

        (
          (move-to 1)
        )

      )
    .
    .
    .

    )
  )

  There are a few advantages to this approach:

    (1) full recursion: nested conditionals, subfunctions, looping,
        macros, etc...  would be difficult in the current language,
        but could be done trivially here.  This is not to say that you
        would have to implement these things now or ever, only that
        you are free to do so if it becomes useful;

    (2) extensibility with compatibility: since everything is a
        function, old programs will always be as valid as new ones,
        even if new functions are defined.  Extending the protocol of
        an existing function may also be possible, that depends on
        design of the function and its current protocol, but not on
        the language;

    (3) separation of form and function: the form is simple, almost
        trivial, but functions could be arbitrarily complex;

    (4) you will need a more complete language if, in the future, you
        want to intermessage processing.

  Let me know if this is of interest to you and whether I can be
  helpful in further investigation.