% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %
%                                                                           %
% File:            all.dtr                                                  %
% Purpose:         provide support for multiple value queries               %
% Author:          Roger Evans, 4 August 1993                               %
% Email:           Roger.Evans@itri.bton.ac.uk                              %
% Address:         ITRI, Univ. Brighton, Lewes Road, Brighton BN2 4GJ, UK   %
% Related files:   polysemy.dtr                                             %
% Version:         1.01                                                     %
%                                                                           %
%      Copyright (c) University of Sussex 1993.  All rights reserved.       %
%                                                                           %
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %

%   The node ALL provides support for returning all the results
%   represented in a DATR theory that implements multiple values using
%   <and> path-prefixing (like Kilgarriff's use of <alt>).
%
%   It should be used as follows.  In the basic definition, encode
%   multiple values for a path by prefixing successive values
%   with <and>, e.g.:
%
%   NODE:   <x> == value_1
%           <and x> == value_2
%           <and and x> == value_3.
%
%   On its own, this is a reasonable description in DATR, but it's hard
%   to get hold of ALL the values of <x> - you need a bit of external
%   querying code.  This file provides such code in DATR itself (n.b.: it
%   is probably best to think of this as external to the main
%   description, rather than actually part of it, since it uses
%   techniques you probably don't need elsewhere).  You simply add:
%
%   NODE:   <> == undef
%           <all> == ALL:<>.
%
%   and then you will find that by prefixing <all> to query paths, all
%   the defined values for the path will be returned (as a sequence):
%
%   NODE: <all x> = value_1 value_2 value_3.
%
%   Note that the <> == undef case might be pushed up to the top of
%   the inheritance hierarchy - as long as otherwise-undefined values
%   get the value 'undef' from somewhere, it will work.
%
%   The definition also allows you to specify that certain paths are
%   or are not functional, that is they only have one value.  This is
%   achieved by asserting statements such as
%
%   NODE: <functional x> == isfunctional
%         <functional y> == nonfunctional.
%
%   Specifying that a path is functional doesn't actually constrain the
%   description to be functional - it merely tells the ALL node that it
%   need only fetch one value.
%
%   Finally the special value 'no_definition' (distinct from 'undef')
%   indicates there is no definition here, but there may be further
%   definitions to be sought on <and> paths.
%
%   The comment following the code explains how this all works.

ALL:
    <> == <<result "<>">>
    <result undef> == undefined
    <result no_definition> == skip
    <result> == defined
    <undefined> ==
    <skip> == "<all and>"
    <defined> == <"<functional>">
    <isfunctional> == "<>"
    <nonfunctional> == "<>" "<all and>".

%   How it works:
%
%   A query of, say <all x>, gets passed to ALL simply as <x>.  This
%   evaluates <x> globally and turns the result into a path, prepended
%   by <result>.  This path is evaluated locally - if the result of <x>
%   was 'undef', <result> returns  'undefined', if it was 'no_definition',
%   it returns 'skip', and if it was anything else,
%   it returns 'defined'.  This result value is itself interpreted as a
%   path (locally), with the original path (<x>) still appended.
%   <undefined> returns nothing, <skip> just seeks values from <all and
%   x> (i.e. ignore the present alternative but still look for more).
%   <defined> does a further evaluation of <functional x> and uses the
%   result of that to do either just <x> if it's functional, or <x> and
%   <all and x> (i.e. seek alternatives) if it's not functional.

% The next line is the Revision Control System Id: do not delete it.
% $Id: archive.dtr,v 1.1 1997/04/09 20:40:33 root Exp $