[alicebot-archcomm] Blank condition values

[Anne Kootstra]

OK, I get the programmers vision of documentation. I might not be one
myself, but I do have some experience in working with them. It seems that
the only type of documentation most of them are willing to do is within the
code itself and only then to make sure they understand it themselves when
its time again to work on it.

The only reason I asked was to make sure that we don't get into votes again
such as the one where the change for "name=" to "var=" was suggested. This
was something that happened overnight and it seems to me that this may have
been a bit to fast. Then again, this may be just my perception.

In the last paragraph you mentioned the extension mechanism. I agree that
the extension mechanism would allow for the inclusion of non-AIML scripting
within the boundaries of the <template> tag. These extensions could be as
simple as calculating the hex value of the contents of <star/> or as complex
as a PHP or Lisp engine without the need for extra AIML tags. But the
question that I went through my mind was "Are extentions a part of the
interperter, like for example Program D, or are they a part of the AIML
specification?" Or is it the way people call them within the <template> that
should be standardised (ex. <extension name="javascript/php/asp/perl/Lisp"
...>) and the process of external computation would be up to the developer?

One could even wonder why people need these extensions in the first place.
Wouldn't this mean there's a latent need for  a functionality that can not
be achieved with help of AIML .

On the subject of AIML macro's my opinion is different, they would be the
best thing since sliced bread. Correct me if I'm wrong, but wasn't
<srai><star/><srai> shortened to <sr/>? This could be considered the first
AIML macro, couldn't it? However, I have a hard time seeing this being part
of the AIML spec. That would have be part of the implementation and
subsequent the developer. I've been doing a lot of copying and pasting the
last few weeks, especially regarding emotion, and all of it is exactly the
same AIML code. If there would be a file on startup where I could "declare"
an AIML function which I could use in every template than that would
certainly help in keeping the code neat and clean.

--Anne


-----Oorspronkelijk bericht-----
Van: alicebot-archcomm-admin@list.alicebot.org
[mailto:alicebot-archcomm-admin@list.alicebot.org]Namens Noel Bush
Verzonden: maandag 20 mei 2002 20:52
Aan: Alicebot and AIML Architecture Committee
Onderwerp: RE: [alicebot-archcomm] Blank condition values


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.

_______________________________________________
alicebot-archcomm mailing list
alicebot-archcomm@list.alicebot.org
http://list.alicebot.org/mailman/listinfo/alicebot-archcomm