[alicebot-archcomm] multiple patterns in a category

[Kim Sullivan]

> So, as everything affects everything else, before deepen multiple
> patterns,
> we have to discuss about the merge policy and later check for scaling
> problems that can rise with the adoption of multiple patterns.
>
> Do someone agree with this?

The merge policy might be a problem, but not one connected to multiple
patterns in a category, since you can (theoretically and practically) make
each multipattern category a set of multiple single-context categories. And
if you treat them the same way as well, you don't have any additional
demands on the merge policy. (I don't think that having an option to e.g.
prefer single pattern categories over multi-pattern ones would help
maintainability).

I'm also not sure if there really are any scaling problems. Sooner or later
you will get such an amount of categories that it will be hard to maintain
for a human - but this is inevitable. OTOH, multiple patterns will actually
increase scalability on the computer side of the problem, because they make
programmers who implement interpreters think about better ways than to store
the template directly inside the graphmaster. If you store the template
separately, you only have to keep memory for the reference and not the
template text itself, and a N:N correspondence becomes N:1, which is OK. Not
to mention the conserved disk space. And on low-end systems, you can save
yourself all the memory for the templates anyway, and just index the files
on disk.

> Can we get programmers to make these enhancements?

The grand question.

> The caveat delaying the implementation is the complexity of
> parsing multiple
> patterns into the Graphmaster search index.  Holding the multiple patterns
> while it iterates through the list is more work each engine would
> require to
> fulfill this standard.

I don't think this should be any major change in well-written
implementations, so the complexity shouldn't be a problem.

Kim