cliff@CS.Cornell.EDU (Cliff Krumvieda) (06/21/91)
Hello:
A couple of us at IDS have been debating changes to the Isis/LISP
interface (Isis can be run from either Allegro Common Lisp or Lucid
Common Lisp), and this message details major modifications to the way
messages are created, modified, and read in Isis/LISP.
We would like to hear all comments, suggestions, and questions
regarding the proposed changes. Please reply to cliff@cs.cornell.edu.
--proposal follows this line-------------------------------------------
Proposal to change the Isis/LISP interface
==========================================
This proposal introduces five macros that would replace the 33 macros
and functions that currently exist for creating, modifying, and
reading messages in the Isis/LISP interface. These macros should not,
in general, run slower than the code in the existing interface.
In the discussion below, a format-string is the concatenation of zero
or more of the two character "format codes" listed below. Each of the
codes has a corresponding type, which is also listed next to it in the
table.
Code Type
------------ -------------------------------
"~a" address
"~b" bit vector
"~c" character
"~d" or "~l" long integer
"~e" event
"~f" single precision floating point
"~g" double precision floating point
"~h" short integer
"~m" message pointer
"~p" groupview
As in Isis/C, every code listed above except for "~a" and "~s" have
capitalized versions that correspond to arrays of the appropriate type
(e.g., "~A" indicates an array of addresses).
Of course, these "format codes" are almost identical to the "format
strings" used in Isis/C. In particular, not all of the codes
correspond to their meaning of their capitalized versions
in a Common Lisp format statement (especially "~a," "~s," "~e," and
"~p"). Eventually it may be possible to define new codes for
user-defined types by introducing an isis_define_type function to the
Isis/LISP interface.
The five proposed macros are listed below.
===========================================================================
msg-gen &optional format-string &rest field-values [Macro]
make-message &optional format-string &rest field-values [Macro]
The msg-gen and make-message macros are identical; which to use in a
given situation is purely a matter of programming taste. They both
create a new message, appropriately insert the field-values into it,
and return it.
If format-string is nil and field-values is not nil, the types of the
fields are inferred as they are inserted into the new message (an
error is signalled if one of the field types cannot be inferred).
Otherwise, the field types must correspond to the type format as
specified by format-string. If format-string is a "true" string
(rather than a symbol which evaluates to a string at run time),
it is parsed at compile time. These macros would subsume the
"msg-newmsg" and "message" macros currently in the Isis/LISP interface.
Example: The form
(msg-gen "~d~d" 1 2)
is functionally equivalent to
(make-message nil 1 2)
and
(message 1 2),
each of which return a new message containing the values 1 and 2. The
forms
(msg-gen) and (make-message)
each return a new, empty message.
===========================================================================
===========================================================================
msg-get message &optional format-string-or-number &key :field-id [Macro]
The msg-get macro is used to extract field values from message;
it returns a list of extracted field values. If format-string-or-number
is nil, all remaining fields in message are extracted (if their types
can be inferred). If format-string-or-number is a string, fields are
extracted from message according to the format string. If
format-string-or-number is an integer, the next format-string-or-number
fields in message are returned (if their types can be inferred). If
a :field-id number is specified, that field-id is used rather than the
system default, SYSFLD-SCAN (see section 5.3 and the documentation of
msg_getfld in the Isis manual for more information). If
format-string is a "true" string (rather than a symbol which evaluates
to a string at run time), it is parsed at compile time. This macro
would subsume the "message-list" function currently in the Isis/LISP
interface.
Example: If msg is a message containing the values 1 and 2, the code
(msg-get msg)
returns (1 2), and both
(msg-get msg "~d") and (msg-get msg 1)
return (1).
===========================================================================
===========================================================================
next-field message &optional format-string &key :field-id [Macro]
If format-string is nil or consists of exactly one format code (all
other cases signal an error), the next-field macro is semantically
equivalent to
(first (msg-get message
(if format-string format-string 1)
:field-id field-id))
If format-string is a "true" string (rather than a symbol which evaluates
to a string at run time), it is parsed at compile time. This macro
would subsume the "msg-any," "msg-long," "msg-short," "msg-byte,"
"msg-char," "msg-string," "msg-address," "msg-message," "msg-long-vector,"
"msg-short-vector," "msg-byte-vector," "msg-address-list," "msg-bitvec,"
"msg-event," and "msg-groupview" functions currently in the
Isis/LISP interface.
Example: If msg is a message containing the values 1 and 2, both
(next-field msg) and (next-field msg "~d")
return 1. The second form is useful if the next field of the message
cannot be properly inferred, or if efficiency is important (the
second form is as efficient as (msg-long msg)).
===========================================================================
===========================================================================
msg-put message format-string &rest field-values [Macro]
The msg-put macro is used to insert field values into message; it
returns the modified message. If format-string is nil, the types of
the field values are inferred as they are inserted. Otherwise, the
field value types must correspond to the type format as specified by
format-string.
In addition, if one of the field-values is the keyword :field-id,
the field-value following it must be an integer; neither argument is
inserted into the message, and together they are treated as a
keyword/value pair. When this occurs, the specified field-id is used
rather than the system default, SYSFLD-SCAN (see section 5.3 and
the documentation of msg_getfld in the Isis manual for more
information).
If format-string is a "true" string (rather than a symbol which
evaluates to a string at run time), it is parsed at compile time.
This macro would subsume the "msg-put-any," "msg-put-long,"
"msg-put-short," "msg-put-byte," "msg-put-char," "msg-put-string,"
"msg-put-address," "msg-put-message," "msg-put-long-vector,"
"msg-put-short-vector," "msg-put-byte-vector," "msg-put-address-list,"
"msg-put-bitvec," "msg-put-event," and "msg-put-groupview" functions
currently in the Isis/LISP interface.
Example: If msg is already defined as a message, both
(msg-put msg nil 1 2)
and
(msg-put msg "~d~d" 1 2)
add 1 and 2 to msg. The forms
(msg-put msg nil 1 :field-id 1)
and
(msg-put msg nil :field-id 1 1)
both add 1 to msg using field-id 1.
===========================================================================
--
Clifford D. Krumvieda E-mail: cliff@cs.cornell.edu
Isis Distributed Systems, Inc. Office: 4110 Upson Hall,
111 South Cayuga St., 2nd Floor Cornell University
Ithaca, NY 14850 Pseudonym: T. G. Taft