Ned Freed wrote:
We need to focus of documenting what a suitable mechanism is rather than
assuming that some specific mechanism will always be used. We can, if we think
it necessary, define something very specific, but doing so does not obviate
the need to lay down some general requirements.
That's fine with me. Actually, I would welcome a discussion on general
requirements which is not ACAP tainted. Not that I dislike ACAP in
general, but I have some difficulty to view it as the great savior for
all kinds of inter-agent communication either.
The ACL facilities in ACAP are more than flexible enough to do this.
Okay, I believe you.
I think we need to assume that all sorts of paths will exist with varying
capabilities. Mind you, this doesn't mean we cannot standardize a set of
errors
for Sieve programs as part of laying out what the minimal capabilities have to
be.
However, I think the notion of standardizing a very precise set of errors
and mandating when they are to be produced goes much too far. For one thing,
people are going to use all sorts of different parsers and requiring that
certain errors be detected in certain ways is far too limiting. And for
another, I do not believe that doing stuff like this actually results in a
more
useful and user friendly facility. As it happens my initial compiler
experiences were with languages set up with sets of errors along these lines,
and that experience was anything but good.
Okey, so, a minimum set of error capabilities would at least be
something. We might be lucky, Sieve is a sort of minimalistic language
and as such may limit the amount of possible parsing errors. And I think
a categorized (i.e. not too detailed) status report will suffice.
--Tomas