home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / lifeos2.zip / LIFE-1.02 / README < prev    next >
Text File  |  1996-06-04  |  30KB  |  723 lines
  1. ======================================================================
  2.                 Wild_Life 1.02
  3.  
  4. Intelligent Software Group                      http://www.isg.sfu.ca/
  5. Simon Fraser University                         isg@cs.sfu.ca
  6. ======================================================================
  7.  
  8. This is a new release of the Wild Life system that includes bug fixes
  9. and introduces a number of experimental extensions.  The system is
  10. subject to the same copyright restrictions as previous versions except
  11. for the new extensions which are copyright 1994-95 Intelligent
  12. Software Group, Simon Fraser University.
  13.  
  14. ----------------------------------------------------------------------
  15.             EXTENSIONS AT A GLANCE
  16. ----------------------------------------------------------------------
  17.  
  18. SYNTAX
  19.   The usual character escape sequence notation is now permitted in
  20.   strings; e.g. you can use \n to represent a newline.
  21.  
  22. HACKER'S INTERFACE
  23.   1. a declarative interface to handle arguments in C function /
  24.      predicate primitives.
  25.   2. an extensible way to add new opaque values using the "bytedata"
  26.      interface.
  27.  
  28. EXTENSIONS
  29.   At the moment, all extensions have been placed in module "sys" with
  30.   source code in file sys.c.  Documentation is available in
  31.   Doc/Sys.doc.
  32.  
  33.   * Bit Vectors
  34.   * Regular Expressions using Henry Spencer's regexp package
  35.   * Streams and stream based IO (unix interface + interface a la Perl)
  36.   * Unix file interface
  37.   * Unix socket + tcp/ip interface
  38.   * Unix fork / process interface
  39.   * lazy project
  40.   * wait on feature
  41.  
  42. INSTALLATION
  43.   The distribution now includes a "configure" script that will create
  44.   a make file and configure the system for your architecture.  In
  45.   addition to the usual GNU options, the configure script accepts the
  46.   following:
  47.  
  48.     --with-x=no    or    --without-x
  49.     --with-gc=no    or    --without-gc
  50.     --with-memory=nnnn
  51.  
  52.   INSTALL has additional information relevant to the use of the
  53.   configure script.
  54.  
  55.   Move to the subdirectory Source containing the source code of the
  56.   wild life interpreter:
  57.  
  58.     cd Source
  59.  
  60.   Configure the package for your architecture:
  61.  
  62.     ./configure
  63.  
  64.   If you plan to hack the code you may want to execute "make depend"
  65.   now, otherwise it's not necessary.
  66.  
  67.   Compile the wild life interpreter:
  68.  
  69.     make
  70.  
  71.   or e.g. "make CFLAGS=-O" to override the typicall "-g -O" default.
  72.   Finally install the package:
  73.  
  74.     make install
  75.  
  76.   This will move the executable to ${exec_prefix}/bin and will install
  77.   all libraries etc in ${prefix}/lib/life.  By default ${exec_prefix}
  78.   and ${prefix} are both "/usr/local" but can be overriden using the
  79.   following options to configure:
  80.  
  81.     --prefix="/another/prefix"
  82.     --exec-prefix="/another/exec/prefix"
  83.  
  84.   or you can edit the resulting Makefile.
  85.  
  86.   If your X include files and/or libraries are in non standard places,
  87.   you may also use:
  88.  
  89.     --x-includes="/your/X/include/directory"
  90.     --x-libraries="/your/X/libraries/directory"
  91.  
  92.   The automated configuration has been tested on:
  93.  
  94.       DEC Alpha OSF/1 v3        OSF/1        DEC Alpha
  95.     SunOS 4.1.3 1 sun4m        SunOS        Sun4
  96.     SunOS 5.4 sun4m sparc        Solaris        Sun4
  97.     IRIX 5.3 IP22 mips        IRIX        SGI
  98.  
  99.   If you succeed in configuring/compiling the release on some other
  100.   system, please send email with details to life-bugs@cs.sfu.ca or
  101.   duchier@cs.sfu.ca.
  102.  
  103. ----------------------------------------------------------------------
  104. Dr. Denys Duchier            Intelligent Software Group
  105. email: duchier@cs.sfu.ca        School of Computing Science
  106. tel: (604) 291-5711            Simon Fraser University
  107. fax: (604) 291-3045            Burnaby, B.C. V5A 1S6 Canada
  108. ----------------------------------------------------------------------
  109.  
  110.          THE REST OF THIS FILE IS A SLIGHTLY
  111.            UPDATED VERSION OF THE OLD 1.01
  112.                  README FILE
  113.  
  114. ======================================================================
  115.                 Wild_Life 1.01
  116.  
  117. Richard Meyer                            Digital Equipment Corporation
  118. Peter Van Roy                            Paris Research Laboratory
  119. ======================================================================
  120.  
  121. ----------------------------------------------------------------------
  122.                  INTRODUCTION
  123. ----------------------------------------------------------------------
  124.  
  125. The Wild_Life 1.01 system and all documentation and programs provided
  126. with it are Copyright 1991-93 Digital Equipment Corporation, Paris
  127. Research Laboratory.  All Rights Reserved.
  128.  
  129. LIFE is a programming language integrating logic and functional
  130. programming, feature types with inheritance, and constraint logic
  131. programming.  LIFE was conceived at MCC by Hassan Ait-Kaci.
  132.  
  133. The Wild_Life interpreter is the first implementation of the LIFE
  134. language available to the general public.  It is a product of the
  135. Paradise project and its follow-on, the Proteus project, at DEC PRL.
  136. Research activities of Paradise dealt with issues pertaining to
  137. general purpose programming by specifying executable constraints,
  138. including theoretical foundations, implementation, and development of
  139. applications.  Research activities of Proteus deal with LIFE
  140. implementation and application issues.  Since the demise of PRL,
  141. research and development of the LIFE programming language has moved to
  142. the Intelligent Software Group, at Simon Fraser University, chaired by
  143. Hassan Ait-Kaci.
  144.  
  145. Wild_Life has been designed to be a robust tool for prototyping
  146. applications that require representing and manipulating complex data
  147. structures or that have complex dependencies between data structures.
  148. It comes with several powerful tools (including a preprocessor,
  149. parsers, a graphical interface toolkit and an Emacs LIFE mode) to aid
  150. in prototyping.
  151.  
  152. Wild_Life has been extensively tested on DECstations running Ultrix
  153. and has been designed to be easily portable to many other systems.  We
  154. are committed to support this system.  We would appreciate for you to
  155. send your name and address to life-users-request@cs.sfu.ca.  That will
  156. make it easier for us to notify you of upgrades.  We solicit feedback
  157. on any aspect of the system: bug reports, functionality, extensions,
  158. user manual, user interface, examples, etc.  If you extend the system,
  159. we would like to know exactly what you did and why.
  160.  
  161. ----------------------------------------------------------------------
  162.                ACKNOWLEDGMENTS
  163. ----------------------------------------------------------------------
  164.  
  165. The Wild_Life interpreter was first implemented by Richard Meyer,
  166. under the guidance of Hassan Ait-Kaci, then considerably debugged and
  167. extended by Peter Van Roy.  It has been extended and is currently
  168. maintained by Denys Duchier.  Jean-Claude Herve wrote the X11
  169. interface. Seth Copen Goldstein added a number of built-ins.  Bruno
  170. Dumant has written many vital LIFE programs including a graphic
  171. toolkit, powerful accumulator and expander preprocessors and useful
  172. library functions.  Arnaud Venet wrote the profiler and SuperLint (a
  173. user configurable C style checker).  Kathleen Milsted wrote the
  174. extended user-interface shell.
  175.  
  176. Many thanks to the users who helped improve the portability of
  177. Wild_Life, in particular Osman Buyukisik, Jeremy Fitzhardinge, Sven
  178. Hartrumpf, Peter Ludemann, Fernando Pereira, Jose Pereira, Ralf
  179. Scheidhauer and Danny Thomas.
  180.  
  181. We also would like to thank Sergio Antoy, Mike Carifio, Denys Duchier,
  182. Adam Farquhar, Damien Genthial, Mark Graves, Georgios Grivas, Francois
  183. Jacquenet, Kim JongHyeok, Marija Kulas, Tim Lindholm, Pierre
  184. Malraison, Michael Mehl, Gilles Serasset, Kent Tong, Luis Torgo,
  185. A. Sadegh Saidi, Stefan Svenberg, and S. Bharadwaj Yadavalli.
  186.  
  187. ----------------------------------------------------------------------
  188.            CONTENTS OF THE Life-1.02/ DIRECTORY
  189. ----------------------------------------------------------------------
  190.  
  191. - README: This document.
  192.  
  193. - LICENSE: The license agreement for the system.  Essentially, the
  194.   system is freely usable and modifiable for non-commercial purposes.
  195.  
  196. - Doc/: The system documentation.  The PostScript document handbook.ps
  197.   is a tutorial and reference manual of roughly 150 pages.  The Ascii
  198.   text wild_life.1 is a man page for the system.
  199.  
  200. - EmacsMode/: Documentation and source code for an Emacs LIFE mode.
  201.  
  202. - Examples/: A large number of LIFE programs giving a good feel for
  203.   the language and how it can be used.
  204.  
  205. - Tools/: A series of toolkits to aid LIFE development, which includes
  206.   a sophisticated preprocessor, a debugger and a graphic library.
  207.  
  208. - Lib/: A number of LIFE program libraries.
  209.  
  210. - CLife/: A simple program showing how to call LIFE from C.
  211.  
  212. - Source/:
  213.   - The C and LIFE source code of the interpreter.
  214.   - A Makefile to build the interpreter (wild_life) and the C-LIFE
  215.     library (c_life.a and c_life.h).
  216.  
  217. - Tests/: A test suite to check that the interpreter has been
  218.   correctly compiled on your system.
  219.  
  220. - regexp/: Henry Spencer's regexp package extended with last_regsize
  221.  
  222. ----------------------------------------------------------------------
  223.                  INSTALLATION
  224. ----------------------------------------------------------------------
  225.  
  226. 1. Uncompress and untar the file Life-1.02.tar.gz.  This creates the
  227.    Life-1.02/ directory.
  228.  
  229. 2. Execute 'cd Life-1.02/Source'.
  230.  
  231. 3. Read and edit the Makefile to take into account all
  232.    platform-specific details (see also further on).
  233.  
  234. 4. Run 'make depend' to create the correct include file dependencies
  235.    for your system. You may get two benign warnings:
  236.  
  237.     makedepend: warning:  cannot open "Life.c"
  238.     makedepend: warning:  cannot open "Info.c"
  239.  
  240.    What to do if you don't have the 'makedepend' command:
  241.    a. You may have the 'mkdep' command instead.  Edit the definition
  242.       of variable MKDEP in the Makefile and try again.
  243.    b. If you don't 'makedepend' or 'mkdep', then you can try using the
  244.       Makefile as is.  This means you will use the dependencies that
  245.       are valid for MIPS/Ultrix.  If these dependencies are not
  246.       completely correct for your machine, you will have to edit the
  247.       Makefile to make them correct.
  248.  
  249. 5. Run 'make' to create the executable 'wild_life'.  The complete
  250.    system including the .o files and the executable needs about 6 MB
  251.    of disk space.
  252.  
  253. 6. Run the test-suite: do "cd Life-1.02/Tests" and "check_all".  This
  254.    is a useful step to ensure that everything works as expected.  The
  255.    Tests/ subdirectory may be removed to save space (see below).  See
  256.    Tests/README for more information.
  257.  
  258. 7. To get superlint (the 'testsl' test) working under Solaris, you may
  259.    need to edit Examples/SuperLint/c_utils.lf.  Change the definition
  260.    of cpp_name to cpp_name -> "/usr/ccs/lib/cpp" (or give directory
  261.    where cpp is stored).
  262.  
  263. ----------------------------------------------------------------------
  264.                  THE MAKEFILE
  265. ----------------------------------------------------------------------
  266.  
  267. The Makefile comes set up for the following standard configuration:
  268.  
  269.     4M words of memory available at run-time (=16MB on a 32-bit
  270.     machine)
  271.     compiles using "cc"
  272.     optimising level -O2
  273.     memory alignment is 8 (valid for both 32 and 64-bit machines)
  274.     include the garbage collector
  275.     include the X11 library
  276.     include the raw terminal I/O interface
  277.  
  278. All of these options can be changed as required for your system.
  279.  
  280. Remarks:
  281.  
  282. 1. The Makefile documents the list of changes necessary for the other
  283.    platforms.  Please read and edit the Makefile to incorporate these
  284.    changes.
  285.  
  286. 2. Always run "make depend" before compiling.  This is necessary since
  287.    different platforms have header files in different places.
  288.  
  289. 3. Some platforms have the X11 library in a nonstandard place.  If
  290.    this the case for your platform, you will have to add a '-I <X11
  291.    pathname>' to the definition of CCFLAGS.
  292.  
  293. 4. To compile Wild_Life without the X interface, remove the -DX11
  294.    macro from CCFLAGS and remove -lX11 from LOADFLAGS.
  295.  
  296. 5. To compile Wild_Life without the raw (unbuffered) terminal I/O
  297.    interface, add the -DNORAW macro to CCFLAGS.  The only program
  298.    provided that uses the raw interface is Tools/shell.lf.
  299.  
  300. 6. If you have automounted filesystems, then for safety you should
  301.    replace `pwd` in the Makefile by the absolute pathname.
  302.    
  303. ----------------------------------------------------------------------
  304.                  PORTABILITY
  305. ----------------------------------------------------------------------
  306.  
  307. The system passes the tests for the following platforms:
  308.  
  309.    DECstation (MIPS/Ultrix)
  310.    ALPHAstation (Alpha/OSF-1)
  311.    SPARCstation (SPARC/SunOS)
  312.    SGI machine (SGI/IRIX)
  313.    PC compatible 386 or 486 (Linux)
  314.    HP710 machine (HPUX)
  315.  
  316. The X interface works on all of these platforms.
  317. The unbuffered terminal interface works on Ultrix, OSF/1, and Linux.
  318.  
  319. If you get the interpreter to work on any other platform, we would
  320. appreciate it if you would send us a list of the changes that were
  321. necessary and if you would run the test suite and notify us of any
  322. non-trivial differences with the correct output.
  323.  
  324. ----------------------------------------------------------------------
  325.                SYSTEM-RELATED COMMENTS
  326. ----------------------------------------------------------------------
  327.  
  328. 1. On startup, the interpreter loads an optional .wild_life
  329.    customization file. It looks for this file first in the current
  330.    directory and then in your home directory. If none is found then
  331.    none is loaded.
  332. 2. The interpreter may be run from anywhere and copied to anywhere and
  333.    executed there. However, the Life1.01/ directory must remain in the
  334.    same place, since the interpreter uses several files in it during
  335.    startup.
  336. 3. The subdirectory Tests/ contains a series of test programs. They
  337.    may be run by cd'ing to Tests/ and running the script check_all
  338.    (without arguments). The script creates *.refdiff and *.errdiff
  339.    files (in the directories Tests/REFDIFF and Tests/ERRDIFF) that
  340.    show the differences between the obtained results and the correct
  341.    results. After running it, you may see some small differences.
  342.    Tests/README gives a list of those differences that may be safely
  343.    ignored.  The Tests/ directory is rather large (more than 3 MB). It
  344.    may be removed to save space.
  345. 4. By default, the system has a memory space of 4 MB and has a virtual
  346.    image of somewhat more than twice this size (because of the
  347.    dual-space garbage collection algorithm used). Size of the memory
  348.    space can be changed by specifying the command line argument
  349.    "-memory=NNNN" where "NNNN" is the number of words the system will
  350.    allocate. Because of the half-space GC, the total number of bytes
  351.    allocated will be 2*NNNN*word_size.
  352.  
  353. ----------------------------------------------------------------------
  354. PORTING LIFE PROGRAMS FROM VERSION 0.91 TO VERSION 1.01
  355. ----------------------------------------------------------------------
  356.  
  357. The cleanup of version 1.01 relative to version 0.91 results in the
  358. following changes that may have an effect on programs written
  359. originally for version 0.91.
  360.  
  361. 1. The following built-ins have changed names.
  362.  
  363.    In 1.01            In 0.91
  364.    ------             -------
  365.    root_sort          rootsort
  366.    X.F              project(F,X)
  367.    call_once(P)       prove(P)
  368.    real_time          realtime
  369.    local_time          localtime
  370.    cpu_time          cputime
  371.  
  372. 2. The following built-ins behave differently.
  373.  
  374.    X:Y                In 1.01 only one of the terms X and Y may be
  375.               different from @. In 0.91, if both are different
  376.               from @ then this is parsed as a call to X&Y. In
  377.               1.01 all calls to X&Y must be explicit.
  378.  
  379.    cond(C,I,E)        In 1.01, the condition C may be a predicate.  In
  380.               this case the behavior is identical to
  381.               cond(call_once(C),I,E). That is, success/failure
  382.               maps to true/false, and only the first solution
  383.               of C is used.
  384.  
  385.    A and B, A or B,   In 1.01, the boolean calculation functions do
  386.    A xor B, not A     all deterministic local inversions.
  387.  
  388.    has_feature(F,X)   In 1.01, this no longer residuates until the
  389.               feature name F is different from @. It
  390.               immediately returns true or false.
  391.  
  392.    children(X),       In 1.01, the behavior of the built-in sorts has
  393.    parents(X)         been cleaned up. The hierarchy of built-in sorts
  394.               has no more quirks.
  395.  
  396.    asc(S)          In 1.01, S must be a string.  The result is the
  397.               ASCII code of the first character of the string.
  398.               An error message is given if S is not a string.
  399.  
  400.    chr(I)             In 1.01, I must be an integer.  The result is a
  401.               string of length one containing the character
  402.               whose ASCII code is I.
  403.  
  404.    system(S)          In 1.01, this gives an error message if S is not
  405.               a string, instead of residuating.
  406.  
  407.    assert, asserta,   In 1.01, these four built-ins are non-strict,
  408.    clause, retract    that is, they do not evaluate their arguments.
  409.  
  410. 3. The following built-ins are boolean functions in 1.01 instead of
  411.    predicates, as is true in 0.91. This means that they no longer
  412.    need be arguments of call_once when used in a function position.
  413.  
  414.    var(X)
  415.    nonvar(X)
  416.    is_function(X)
  417.    is_predicate(X)
  418.    is_sort(X)
  419.  
  420. 4. The following built-ins have been removed.
  421.  
  422.    freeze(G)    
  423.    where
  424.    inf
  425.    undefined    The same effect is given by {}, which evaluates to
  426.         bottom.
  427.  
  428. 5. The syntax F(A) is parsed as apply(functor=>F,A) instead of
  429.    '*apply*'('*functor*'=>F,A). The function '*apply*' is now called
  430.    'apply'.
  431.  
  432. 6. The following operators have changed precedence and/or kind.
  433.  
  434.    Name         In 1.01    In 0.91      Reason
  435.    ----         ------- -------   ------
  436.    :          50      150      Prolog compatibility
  437.    `          75 fy      695 fx  Usability
  438.    &         100      150      Usability
  439.    - (prefix)     200      500      Prolog compatibility
  440.    \ (prefix)     200      500      Prolog compatibility
  441.    mod         400      300      Prolog compatibility
  442.    (comparisons) 600      670      Usability
  443.    and         650      680      Usability
  444.    or         675      690      Usability
  445.  
  446. 7. The following operators have been removed.
  447.  
  448.    Name Prec. Kind
  449.    ---- ----- ----
  450.    :-    1200  fx
  451.    +     500  fx
  452.  
  453. 8. The following operators have been added.
  454.  
  455.    Name Prec. Kind  Reason          Operation
  456.    ---- ----- ----  ------                ---------
  457.    .     150  yfx   Usability          Projection function
  458.    //     400  yfx   Prolog compatibility  Integer division function
  459.    \===  600  xfx   Usability          Negation of === (term identity)
  460.    not     625  fy    Usability          Boolean negation function
  461.  
  462. ----------------------------------------------------------------------
  463.         MAJOR CHANGES IN VERSION 1.01 FROM VERSION 1.0
  464. ----------------------------------------------------------------------
  465.  
  466. 1. Version 1.01 has been made much more portable than version 1.0.
  467.    With the aid of helpful users, it has been ported to MIPS/Ultrix,
  468.    Alpha/OSF-1, SPARC/SunOS, SGI/IRIX, and PC/Linux.
  469.  
  470. 2. Version 1.01 contains code for an Emacs LIFE mode written by Bruno
  471.    Dumant.
  472.  
  473. 3. Various bugs have been fixed.
  474.  
  475. ----------------------------------------------------------------------
  476.         MAJOR CHANGES IN VERSION 1.0 FROM VERSION 0.91
  477. ----------------------------------------------------------------------
  478.  
  479. 1. Version 1.0 corresponds to a large rewrite of the system. It now
  480.    much more mature and has been tested on large programs. In
  481.    particular, the data representation for lists has been completely
  482.    changed and is now consistent with all other psi-terms.
  483.  
  484. 2. Version 1.0 has a module system allowing the hiding of data and
  485.    splitting of large programs into smaller manageable chunks with
  486.    separate name-spaces.
  487.  
  488. 3. Two new concepts have been introduced:
  489.  
  490.    - Global variables: logical variables with module-wide scope.
  491.  
  492.    - Persistent terms: terms that do not go away on backtracking.
  493.      They can be used to record data generated in differents parts
  494.      of the search-tree ('bagof' is a typical example).
  495.  
  496.    We believe that these two concepts provide a clean replacement for
  497.    assert and retract in most cases.
  498.  
  499. 4. Built-ins have been polished. For example, all built-ins taking
  500.    variable numbers of arguments now do so in a consistent
  501.    way. Feature (field) selection is done using the '.' operator.
  502.  
  503. 5. The manual has been completely updated and made consistent with the
  504.    system.
  505.  
  506. 6. Various bugs have been fixed.
  507.  
  508. ----------------------------------------------------------------------
  509.        MAJOR CHANGES IN VERSION 0.91 FROM VERSION 0.90
  510. ----------------------------------------------------------------------
  511.  
  512. 1. It accepts the '-q' (q for quiet) command line option. Enabling
  513.    this option results in completely silent output, i.e., no user
  514.    interface information (prompts, variable values, Yes/No messages,
  515.    startup banner, exit banner) will be printed. This allows Wild_Life
  516.    to be used as an element of a Unix pipe with minimal
  517.    hassle. Errors, warnings, trace messages, program output (with the
  518.    write statement etc.), and file I/O are still output. As before,
  519.    errors and warnings are output to stderr, trace information to
  520.    stdout. In 'verbose' mode the user interface information returns,
  521.    which allows the user to inspect a misbehaving Wild_Life when it is
  522.    being used as a pipe element.
  523.  
  524. 2. Garbage collection messages are only printed in 'verbose' mode.
  525.  
  526. 3. It has a user-definable abort capability. A call to
  527.    'setq(aborthook,foo)' makes 'foo' the abort predicate. When the
  528.    system does an abort, it will initialize itself and then call 'foo'
  529.    as the first goal. This ability is used in the 'shell' example
  530.    program. A call to 'setq(aborthook,abort)' restores the internal
  531.    abort. If aborthook is undefined, then the internal abort is used.
  532.  
  533. 4. It is more portable: The system has been modified to compile and
  534.    run under SPARCstations and RS/6000 systems.
  535.  
  536. 5. The example program 'shell' has been added and the documentation of
  537.    example programs has been improved.
  538.  
  539. 6. Various bugs have been fixed.
  540.  
  541. ----------------------------------------------------------------------
  542.               THE LIFE LANGUAGE
  543. ----------------------------------------------------------------------
  544.  
  545. LIFE (Logic, Inheritance, Functions, and Equations) is an experimental
  546. programming language with a powerful facility for structured type
  547. inheritance. It reconciles styles from functional programming, logic
  548. programming, and object-oriented programming. It subsumes, and fully
  549. contains the functionality of, the precursor languages LOGIN and
  550. Le_Fun.  The syntax of Wild_Life has been kept as close as possible to
  551. that of the Edinburgh family of Prolog so that Prolog compatibility is
  552. easy to achieve.
  553.  
  554. From a theoretical point of view, LIFE implements a constraint logic
  555. programming language with equality (unification) and entailment
  556. (matching) constraints over order-sorted feature terms. The interplay
  557. of unification and matching provides an implicit coroutining facility
  558. thanks to an automatic suspension mechanism. This allows interleaving
  559. interpretation of relational and functional expressions which specify
  560. structural dependencies on objects.
  561.  
  562. The basic data structure is the order-sorted feature term, or
  563. psi-term.  Psi-terms are a natural generalization of first-order
  564. terms. A psi-term may be viewed as being to a Prolog term what an
  565. open-ended dynamic record is to a static array. That is, a psi-term
  566. has named fields and fields may be added at run-time. Psi-terms may be
  567. cyclic, which means they are rooted graphs and that the occur-check
  568. problem of Prolog goes away.
  569.  
  570. A program in LIFE consists of a declaration of the sort hierarchy
  571. constraining psi-terms, along with functions and predicates defining
  572. operations on psi-terms. Functions are called with matching (i.e., an
  573. implication constraint) and they suspend if the truth of the
  574. implication cannot be determined. Predicates are called with
  575. unification (i.e., an equality constraint) and they force the equality
  576. to be true. They may try more than one possible value with
  577. backtracking. In other words, a function waits for its actual
  578. arguments to carry as much information as imposed by its formal
  579. arguments, whereas a predicate takes the initiative of synthesizing
  580. missing information using its definition's argument patterns. These
  581. two modes of computation are complementary and allow an elegant
  582. programming style.
  583.  
  584. ----------------------------------------------------------------------
  585.           DOCUMENTATION AND EXAMPLE PROGRAMS
  586. ----------------------------------------------------------------------
  587.  
  588. The subdirectory Doc/ contains the Wild_Life handbook in both
  589. PostScript and dvi formats. It also contains a man page and
  590. documentation for the tools.
  591.  
  592. The subdirectory Examples/ contains example programs. These are in
  593. separate modules. They can be loaded from anywhere with the 'import'
  594. command without an explicit path, since import searches the same
  595. directories as the 'load' command. The argument of import must be a
  596. string (delimited with double quotes "..."). See the file
  597. Examples/DEMOS_README for more information.
  598.  
  599. The Paradise project has written many articles and research reports on
  600. various aspects of LIFE. Please check the WWW page at URL
  601. http://www.isg.sfu.ca/life/ or the ftp directory at
  602. ftp://ftp.isg.sfu.ca/pub/hak/prl
  603.  
  604. ----------------------------------------------------------------------
  605.          EXAMPLE: RUNNING THE SEND+MORE=MONEY PUZZLE
  606. ----------------------------------------------------------------------
  607.  
  608. This program finds all assignments of different digits from 0 through
  609. 9 to the letters in SEND+MORE=MONEY so that the addition is correct.
  610.  
  611. % wild_life
  612. Wild_Life Interpreter Version 1.02 Mon Jan 30 13:00:57 PST 1995
  613. Copyright (C) 1991-93 DEC Paris Research Laboratory
  614. Extensions, Copyright (C) 1994-1995 Intelligent Software Group, SFU
  615. No customizing file loaded.
  616. > import("solve")?
  617. *** Loading File "/usr/local/Life/Source/Examples/solve.lf"
  618.  
  619. *** Yes
  620. > solve?
  621.  
  622.  SEND     9567
  623. +MORE    +1085
  624. -----    -----
  625. MONEY    10652
  626.  
  627.  
  628. *** No
  629. > 
  630.  
  631. ----------------------------------------------------------------------
  632.                 BUG REPORTING
  633. ----------------------------------------------------------------------
  634.  
  635. If you find what you think is a new bug, please, first read the manual
  636. carefully to see if it really is a bug. If it is, try to find the
  637. *smallest* program that illustrates the bug and mail it to
  638. life-bugs@cs.sfu.ca together with a script that shows the bug. An
  639. especially sensitive way to find bugs is to do your work in 'verbose'
  640. mode, which tells you what is happening to the system stacks.
  641.  
  642. ----------------------------------------------------------------------
  643.             THE MOST IMPORTANT KNOWN BUGS
  644. ----------------------------------------------------------------------
  645.  
  646. 1. In most cases, the arguments of functions are evaluated before the
  647.    functions themselves. This rule is violated in one case: when an
  648.    argument is shared.  For example, in the expression s(f(X:g(Y)),X),
  649.    the call g(Y) is shared. g(Y) may in some cases be evaluated
  650.    _after_ the call to f. This is not a problem for user-defined
  651.    functions and "clean" (i.e., residuating, or order- independent)
  652.    built-ins (e.g., arithmetic). It is only a problem for order-
  653.    dependent built-ins (e.g., sort comparisons). The simplest way to
  654.    avoid this problem is to make sure that order-dependent built-ins
  655.    do not have shared arguments.
  656.  
  657. 2. Recursive sort declarations need special care: they should be
  658.    accompanied by a 'delay_check' directive and they must be used in a
  659.    particular way, otherwise the interpreter goes into an infinite
  660.    loop when trying to satisfy the sort's constraints. This is
  661.    explained in the handbook.  'delay_check' is propagated correctly
  662.    to a sort's children.
  663.  
  664. 3. The system is not complete for disentailment of equality
  665.    constraints that are introduced in the actual arguments of a
  666.    function call.  Specifically, the system does not detect that two
  667.    actual arguments are nonunifiable if this detection requires
  668.    looking at the subterms of the corresponding formal arguments.
  669.    However, the system _is_ complete for all other cases of
  670.    disentailment of equality constraints.  In particular, the system
  671.    is complete if all the equality constraints are in the definition
  672.    of the function.
  673.  
  674. 4. Arithmetic on non-IEEE machines may cause exceptions which
  675.    currently are not trapped by the system.
  676.  
  677. 5. The system incorrectly handles deep guards, that is, evaluable
  678.    terms (which includes functions, predicates, and disjunctions)
  679.    inside the heads of function definitions (but evaluable terms
  680.    inside the heads of predicate definitions are handled
  681.    correctly). This has to do with the global/local variable
  682.    distinction: function calls do not change their arguments.
  683.  
  684. ----------------------------------------------------------------------
  685.           RELEVANT ELECTRONIC MAIL ADDRESSES
  686. ----------------------------------------------------------------------
  687.  
  688. Here are email addresses that are relevant to LIFE and Wild_Life:
  689.  
  690.    life-users@cs.sfu.ca
  691.  
  692.       This is a moderated mailing list of people using LIFE or
  693.       interested in specific aspects of LIFE, whether theory,
  694.       implementation, or applications. It is meant as a public forum
  695.       to answer questions and share programs and ideas. It is not
  696.       meant to report bugs, although it may be used to ask public
  697.       opinions about surprising behavior of Wild_Life that may turn
  698.       out to be a bug and to warn others against confirmed bugs.
  699.  
  700.    life-users-request@cs.sfu.ca
  701.    life-request@cs.sfu.ca
  702.  
  703.       This address is to be used to request to be put on, or removed
  704.       from, the life-users mailing list.
  705.  
  706.    life-bugs@cs.sfu.ca
  707.  
  708.       When you strongly suspect a bug (i.e., after reading the manual
  709.       and possibly polling life-users's opinion about the symptoms),
  710.       please try to find the *smallest* program that illustrates the
  711.       bug and mail it to this address together with a script that
  712.       shows the bug.  Include information on the hardware and
  713.       operating system.
  714.  
  715.    isg-general@cs.sfu.ca
  716.  
  717.       This is SFU's local LIFE community.  That is, all the people
  718.       involved with some activity in the Intelligent Software Group at
  719.       Simon Fraser University, or interested in seminar announcements,
  720.       etc... Use this for general communication of matters of interest
  721.       to the local community only.
  722. ======================================================================
  723.