Hi Tim. I have some suggestions for changes to the text of the document
that I think would make it clearer. I have to admit to not having done
a cover to cover read for some time. Sorry about that.
Anyway here are some suggestions. I was trying hard to think about what
someone being introduced to the language would see rather than read it
with knowledge of the components in place. I hope this is helpful Tim.
Cheers.
---
pg7 p3
Implementations of the language are expected to take place at time of
final delivery, when the message is moved to the user-accessible
mailbox. In systems where the MTA does final delivery, such as and
^^^^^^
traditional UNIX mail, it is reasonable to sort when the MTA deposits
mail into the user's mailbox.
sec 2.1. Form of the Language
I found that I wanted to use the term "tokens" to describe the language
(from a true language parser's point of view :-). You could substitute
"objects" "sequences" "doodads" -- whatever -- for tokens. Anyway,
something like:
The language consists of a set of commands. Each command consists
of a set of UTF-8 string tokens delimited by whitespace. The first
token is the command string followed by 0 or more arguments.
Arguments can be either literal data, tests, or blocks of commands.
The language is represented in UTF-8, as specified in [UTF-8]
sec 2.2 - 2.9 Reordering
I would suggest the following reordering:
2.2. Evaluation
2.3. Commands
2.3.1. Positional Arguments
2.3.2. Optional Arguments
Move discussion on tagged arguments here.
I think you need to mention that some commands will accept other
commands as arguments. Specifically the control commands accept
test commands and action commands as arguments.
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. Beyond saying that this is "optional"
I'm not sure what information it conveys. If optional arguments
always follow positional arguments, then even syntactically it
offers nothing useful.
2.4. Whitespace
2.5. Comments
2.6. Literals
Changes to "Literal data"
First paragraph is a bit awkward -- specifically with the definition of
execution. I tend to think in terms of "evaluation" for interpretters.
Now that we have a "token" concept introduced, perhaps something more like
Literal data tokens are evaluated "as is" by a SIEVE interpretter and
consist of two types; numbers and strings. Many commands accept
literal data arguments.
I'm not in love with this myself so feel free to hack it up. In
general when discussing syntactic elements I would always use the term
evaluation (because that is what the interpretter does) and use
execution when discussing the result of evaluation. Subtle difference
but important.
sec 2.6. Tagged Arguments
The discussion on tagged arguments needs to be moved up or introduced
sooner. They imply a structure that needs to be more clearly stated as
a "meta" structure for arguments. In particular there is reference to
"positional arguments" vs. "tagged arguments", but there is no
definition for positional arguments. I recommend that fold this into
the general introduction to commands and arguments.
sec 2.9. Evaluation
This section needs to be expanded to include:
- evaluation ordering
- control issues
- command argument processing
- evaluation results ie. what happens when you evaluate a control
command vs. a test command vs. an action.
Note that this provides a nice seguay into the next topic (in the reodered
list) on commands.
sec 3. Control Structures
Change the title "Control Structures" to "Control Commands"
sec 4. Actions
Change the title "Actions" to "Action Commands".
sec 5. Tests
Change the title "Tests" to "Test Commands"
---
Steve Hole
Execmail Inc.
Mailto:Steve(_dot_)Hole(_at_)execmail(_dot_)com
Phone: 780-424-4922