[alicebot-archcomm] Blank condition values

[Noel Bush]

On Mon, 2002-05-20 at 20:53, Anne Kootstra wrote:
> Nevertheless, I would like to know how a proposal would be made. Over the
> last few months I've been diving into the ArchComm archives and I've found a
> few proposals. Most of them where only a couple of paragraphs and some only
> a few lines. So, I'm curious what a *good* proposal would look like. Maybe
> someone has a few examples from their own business?

It would be great if we could come up with a proposal template, as Jon
mentioned.  Unfortunately, it's my experience that people tend to get
all whiny about things like this.  They fend off attempts to bring some
kind of order to a discussion by saying things like, "This hampers my
creativity", "I can just implement it faster than I can describe it",
"This idea is so simple that it doesn't need to be described", etc. 
Sometimes these claims turn out to be valid, but far less frequently
than these people seem to think.  Quite often, a short time down the
road, some unanticipated gaping hole in the specification (which never
existed) appears, and quite a lot of time can be spent arguing about a
re-tooling that requires re-education of users, retesting of code, etc. 
This might be acceptable and interesting in some academic environment,
but it is not so great when there's a group of people who need to get
some work done.  The fun part is that the same people who initiate these
mistakes tend to repeat them.

Okay, so I'm a bit pessimistic on the prospects of a template.  :-)

I do think that within certain areas we could have a pretty
straightforward, templated process: especially within the <template>
itself.  There's very little (with significant exceptions) in the
so-called "template-side" elements that couldn't be replicated (albeit
painfully) with a smaller set of AIML elements than what we currently
have.  We could look at a lot of the existing tags as just "macros" that
simplify the writing of AIML.

(I tend to think that we could also measure the "imperfectness" of AIML
by checking just how true the previous statement is: that is, the less
the set of functionality can be reduced to a smaller set of primitives,
the less perfect it is.  But I am not a computer science expert [insert
unsightly grin].)

New macros could be born via an extension-oriented process.  The
extension mechanism enables and encourages people to try out new ideas,
demonstrate them to the public, and then, if the ideas are well-received
or otherwise successful, push for inclusion in the AIML spec.  The
disadvantage of this is, of course, the general problem with
specification-phobia: ideas really don't get thought through
well-enough.  But the extension mechanism might at least give us a kind
of "buffer", so we wouldn't load up AIML with all kinds of stuff we
might later regret.