
(properties of instruction (true for all instructions) vs. slots (valid for a speccific instance))
(what are libraries?)
pragmas

\chapter{Introduction}

\section{Random Notes}

RANDOM NOTES FOR STUFF, NOT NECESSARILY THIS SECTION!

The compiler supports two different models for its use. In the first,
the compiler is invoked on regions of text, defining top-level
id-code, selected within an editor. In this case, each new compilation
command compiles and loads the region containing the top-level code
and stores all the information for its use in a symbol table indexed
by the names of the id-objects just defined. This is similar to the
environment LISP systems build up over the course of a session.  In
the second model, id files are compiled independently of the session's
symbol table. Each file must use the @include pragma to explicitly
reference any file that contains objects used but not defined within
it. The description of Exsym tables contains more specific
implementation details.


[confusion between property and property list]

Throughout the compiler particular instances of a general class of
data-structures share common information to save storage (always a
valuable resource in memory-hungry lisp systems).  Most objects the
compiler operates on (parse-tree nodes, dataflow-graph nodes etc.)
have a two-level structure. At the bottom level, instances of an
object have named fields, called slots, which can be read or modified
(often using special abstraction functions to remove much of the ugly
details), just like LISP structures. However, their top level defines
named fields, called properties, which are shared by every object in a
given class and can be read, but not modified.  The properties of an
object are defined before any instance of the object are created. For
example, a class of dataflow-graph nodes representing the '+'
instruction can be created with a property telling the number of
arguements it takes (2) and two slots for holding pointers to its
inputs.  How and where properties and slots are created and used
should become clear when specific data-structures are introduced.


\begin{verbatim}
;;; TARGET OPTIONS
;;; Jamey Hicks, July 11 1989.

;;; A target option is a variable whose value must change for each target for
;;; which the compiler is compiling.  DEFINE-TARGET-OPTION defines such an
;;; option, and provides an alist of targets and values.  SET-TARGET runs down
;;; the list of options defined, and sets their values appropriately for the
;;; given target.
;;;  e.g., 
;;;
;;; (define-target-option Id-Compiler-Float-Format *Id-Compiler-Float-format*
;;;   (:ttda 'single-float)
;;;   (:monsoon 'double-float))
;;;
;;; (set-target :monsoon) will set *Id-Compiler-Float-format* to 'double-float.
;;;
;;; The second item in each pair of the alist will be EVALuated at load time.
;;;
;;; If a new target-option is defined after a SET-TARGET has been performed, the
;;; option being defined will be set for the current target.  There is an
;;; implicit SET-TARGET TTDA performed when this file is loaded.

(export '(set-target define-target-option))

;;; *ID-COMPILER-TARGET* must be either :TTDA or :MONSOON.
(defparameter *id-compiler-target* :ttda)


VARIABLES , add extra slots with define-variable-slot

;;;; Scope Analysis.
;;;; Ken Traub, May, 1986.
;;;; Jamey Hicks, June, 1988.

;;; It has been recently noted that VARIABLE is properly an external
;;; symbol of the Lisp package, which may cause incompatibilities between
;;; TTDA files generated by the different systems.  We can fix this by
;;; shadowing VARIABLE.
(eval-when (compile load eval)
  (shadow '(variable) (find-package "ID-COMPILER")))

(export '(variable variablep variable-source-name variable-place variable-unique-name))

;;; The goal of scope analysis is to establish a correspondence between the definitions of
;;; identifiers and their uses.  It does this by annotating each identifier in the parse tree
;;; with a VARIABLE structure, which has three slots: the name of the identifier as given in
;;; the program source, the place where the identifier was defined, and a unique name
;;; generated by the analysis; each unique name corresponds to exactly one definition.
;;; Additional slots may be added to variables with DEFINE-VARIABLE-SLOT.

;;; A syntax-directed translation scheme is used to implement the scope analysis.  Each ptnode
;;; with tag :IDENTIFIER in the source program will have an attribute VARIABLE which holds the
;;; VARIABLE structure describing that identifier.  Identifier ptnodes denoting the same
;;; variable will have EQ VARIABLE attributes; EQ may be used to compare variables
;;; efficiently.

;;; In addition to the VARIABLE attribute, this file also contains definitions for the
;;; attribute FREE, which holds for each ptnode a list of VARIABLES that are free in the
;;; expression or program fragment denoted by that ptnode.

(defcompiler-module scope-analysis id-compiler
  (:input parse-tree procedure)
  (:output parse-tree procedure)
  (:before-function program initialize-scope-analysis)
  (:function scope-analyze-procedure))

(defstruct (variable
	     (:predicate variablep)		;Follow rules for naming predicates.
	     (:print-function print-variable))
  source-name
  place
  unique-name
  other-slots)

;;; DEFINE-VARIABLE-SLOT defines a slot of OTHER-SLOTS for VARIABLEs by making a selector
;;; macro for that slot.  A property VARIABLE-SLOT is added to the selector whose value gives
;;; the indicator used in the OTHER-SLOTS plist.
(defmacro define-variable-slot (selector-name)

\end{verbatim}