From: Arun Welch
Subject: lisp environments summary
Message-ID: <>
>In article <····> you write:
>>Every file has a variable associated with it, called the COMS, which
>>is the database.  Thus, for the file FOO, there would exist a variable
>>FOOCOMS, which defines what's contained in FOO, what operations to
>>perform when loading foo, etc. Let's say that I want FOO to contain
>>the function definition for the function BAR, the variable definition
>>for the variable BAZ, which has the initial value 5, and for the file
>>RALPH loaded before the file FOO is loaded, and also, for the screen
>>background to be set to the blackshade after FOO is loaded. FOOCOMS
>>would then look like this:
>> (FNS BAR)
>> (VARS (BAZ 5))
>I have one question about this: how does this stuff get into the
>variable before the first time you refer to the file? 

There are a bunch of functions for manipulating the coms, like
ADDTOFILE, DELFROMFILE a so on.  When ADDTOFILE is called, the first
thing it does is check and see if the variable exists, and if not,
then it creates it. One can also directly edit the variable using the

> Are D-machine
>file multi-forked, like Macintosh files, with one fork containing the
>COMS related to the data in the other fork?  Or is the COMS just a
>header that Lisp files have, which is processed when the file is
>incorporated into the environment?  

It's closer to the latter.  The coms, being a variable, is defined in
the file too.  One of the things contained in the file is a statement
arguments, VAR and VALUE, that sets the top level binding of VAR to VALUE].

>Or is the COMS something like a
>file property list, like Symbolics Lisp Machines implement?

Files have property lists too, which define things like which compiler
to use, what sort of reader environment to use, what base to use for
numbers, etc.


Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
·····  (a guest account, but mail gets to me eventually)
From: ·······
Subject: Re: lisp environments summary
Message-ID: <168700010@uiucdcsb>
> ...
> What I would like to have is a hybrid editor that maintains both the
> structure of what you're editing and the text, and works really hard to
> keep them in sync.
> ...
> -Peter Schachte
> ···@quintus.uucp
> ...!sun!quintus!pds

TADA!  (Thanks for the cue.)  We have a hybrid editor that maintains
both the structure of what you're editing and the text and almost never
gets out of sync.  It uses GNU Emacs as the front end and an
incremental parser (Leif) to maintain the parse tree.  As changes are
made to the text, they are sent (via a change to Emacs) to the parser
which keeps quiet until you ask for error status or request structure

You can be editing multiple buffers each with a different language
simultaneously.  The language specification bundles loaded by the
parser are generated from lex and yacc (actually bison) specifications
(contributions greatly appreciated).  There is no restriction on where
you put white space or comments as long as you can specify them in the
lex specification without start states or other context sensitivities
(finite lookahead is OK).

And it's free.  We are in beta testing now.  We are sending out tapes to
a few people so mail if you are interested.  Eventually we'll distribute
it more widely.  For now, it's called the SAGA GNU Emacs Leif editor,
or Leif for short.

We are also accepting research funds to continue this work.

Daniel LaLiberte   217-333-7937
University of Illinois, Urbana-Champaign
Department of Computer Science
1304 W Springfield
Urbana, IL  61801