ietf-mta-filters
[Top] [All Lists]

Re: Feedback on the document structure

1999-02-11 11:39:05
Date: 11 Feb 1999 13:10:36 -0500
From: Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu>

    Incidentally, it is still not clear to me why we need the tagged
    argument support at all.  The stated contract for the optional
    argument should be enough.

So this is probably just not clear.  First, all optional arguments are
tagged arguments that can be left out (otherwise, it's hard to tell
which arguments are which).  Otherwise, if a command has two optional
arguments, and you want to leave one out, you can't tell which one was
omitted.

Actually, there's an inconsistancy in the draft.  The MATCH-KEYWORD
argument is described both as being a tagged argument and an optional
argument; this is certainly my fault.

The MATCH-KEYWORD defaults to being ":is".

I have two questions:
        Should it be optional?
        Should it default to ":is"?

I don't care if it's optional, but if it is, should it default to
":contains" instead?


I've reworked the sections on arguments, put them all in one place,
better described positional arguments, and described optional arguments
as tagged arguments that can be left out.  The text from the nroff
source is this.

.xx "2.6. Arguments"
In order to specify how they function, most commands take arguments.  There
are three types of arguments: positional, tagged, and optional.

.xx "2.6.1. Positional Arguments"
Positional arguments are given to a command which discerns their meaning based 
on their order.  When a command takes positional arguments, all positional
arguments must be supplied, and must be in the order prescribed.

.xx "2.6.2. Tagged Arguments"
This document provides for tagged arguments in the style of CommonLISP.  These 
are also similar to flags given to commands in most command-line systems.

A tagged argument is an an argument for a command that begins with ":", and
consists of a tag naming the argument, such as ":contains".  This argument
means that zero or more of the next tokens have some particular meaning,
depending on the argument.  These next tokens may be numbers or strings, but
are never blocks.

So tagged arguments are similar to positional arguments, except that instead
of the meaning being derived from the command, it is derived from the tag.

Tagged arguments must appear before positional arguments, but they may appear
in any order.  For convienence, this is not expressed in the syntax
definitions with commands, but they still may be reordered arbitrarily
provided they appear before positional arguments.  Tagged arguments may be
mixed with optional arguments.

To keep the language simple, tagged arguments should not take tagged arguments 
as arguments.

.xx "2.6.3. Optional Arguments"
Optional arguments are exactly like tagged arguments except that they may be
left out, in which case a default value is used.  Because optional arguments
tend to result in shorter scripts, they have been used far more than tagged
arguments.

One particularly noteworthy case is the ":comparator" argument, which allows
the user to specify which ACAP comparator will be used to compare two strings,
since different languages may impose different orderings on UTF-8 [UTF-8]
characters.


-- 
Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu>


<Prev in Thread] Current Thread [Next in Thread>