Re: [complib-talk] Method categories

[Richard S. <ri...@ex...>]

(Catching up...)

Don Morrison wrote:

> Ripping up a piece of sofware and starting over isn't a big deal. I
> think we all know that nearly every serious piece of software gets
> written more than once before it's done.
>
> But populating a database and throwing that away and starting over
> again is a different matter entirely.

Yes and no.  I don't object to throwing the database schema 
away as long as we can programatically convert all of the 
data from the old format to the new format.

The bigger problem is retaining compatibility with the wire 
protocol between server and client.  That's the one thing 
that I really don't think we can afford to break.


>> So far as I recall, his [Ander's] idea was that we start 
>> with a minimum of hard-coded ideas. Basically, rows, 
>> changes, and the notion of truth.
>
> No, we don't need a notion of truth. That's simply an attribute that
> gets considered when we think about whether or not a composition
> should be added to the database, but doesn't need to be included in
> the database.

Yes, that's a good way of thinking about it.  And that 
neatly side-steps any problems with differing levels of 
truth such as whole extents, MEBs, every row at hand and 
back, an 840 of spliced doubles and minor.  Excellent.

> The important thing to capture isnt' "what's good about this
> composition" it's "what is this composition". It's higher level tools,
> querying the database, that should be worrying about the various
> attributes, good or bad, of the compositions it contains.

Agreed.  Though it *might* be worth having some facility for 
annotating the database with this information too.  But if 
we do we can probably do it with opaque flags -- i.e. some 
external flag comes along later and sets some piece of 
metadata (a flag, a value, ...) on a composition.  Anyway, I 
think we can defer discussion of that, at least for the 
moment.

>> But my suggestion here is that instead of hard-coding these,
>> we instead equip the system with a way of defining these
>> concepts ourselves. GSiril goes some way towards this:
>
> To a lesser extent (no pun intended) this is also, sort of, what I do
> in Duckworth. I think it is less flexible than GSiril sounds, though,
> as it does hardwire some assumptions in: compositions are always
> composed of leads (ok, divisions), or at least contiguous fragments of
> leads; there are no more than 2 calls within a lead, and they replace
> changes without altering length. Clearly having something even more
> flexible than that would be an advantage for this database.
>
> The point in Duckworth, though, is that composition is really just a
> sequence of chunks of changes, where the chunking obeys conventions
> that may vary by method and composition style. And I think that's an
> important observation. Any higher level way we find to describe a
> composition that just as chunks of conveniently grouped bits of place
> notation will fail to work for some possible compositions; and not
> just outrageously pathological ones. Imagine someone undertaking this
> effort 100 years ago: they probably would have considered something
> like cyclic part heads as a ridiculous thing to support.

Yeah, that's precisely the flexibility I'm keen to support. 
Perhaps a better way of describing what I envisage is a 
platform on which it is poossible to implement specialist 
systems for different styles of compositions, but without 
enforcing any specific style.  And on top of that we produce 
a few stock systems (rulesets per my earlier terminology) 
for common types of composition.

>> So instead of telling the system with various standard
>> compositional devices, we provide it with a way of defining
>> our own rules on top of the basic concepts.  Here, instead
>> of M, W, H, we have the idea of repition and pattern
>> matching a row.
>
> As alluded to in my previous paragraph, I don't see how we can come up
> with a rule language that will be sufficient to express every case one
> might come up with in practice. I would love to be shown to be wrong
> about this, though.

I don't think it's necessary to try.  We produce a 
basic definition for change ringing: no jump changes; no 
cylindrical; every bell rings once per row.  That's probably 
sufficient.

Then we provide a rule definition 'language' for defining 
higher-level concepts.  It doesn't matter too much if 
definig rules is aomething of a dark art -- it's not 
something that ordinary users will ever do or probably even 
be aware of.

>> If you're writing a client, perhaps you only care about
>> touches in a single method on an even number of bells.  If
>> so, you might hard-code an assumptions about the relevant
>> ruleset into client.  Similarly, a client only interested in
>> twin-bob compositions of Stedman Triples might hard-code
>> assumptions about that ruleset.
>
> Yes, I think it's perfectly reasonable for particular clients to deal
> with only a subset of what's in the database. But none of that should
> float back into the database itself, which should be designed to
> support as wide a variety of potential clients as possible.

Agreed.

>> Anyway, how does an approach like this sound?
>
> My principle worry is that we can't define a sufficiently flexible and
> expressive rule language. Though clearly it's an improvement on the
> status quo.

That's largely why I'd like to prototype its semantics in 
GSsiril and test it with a large range of test cases.  And 
to that end it would be good to start accumulating a set of 
test compositions wreiten out in their natural form -- i.e. 
how you would publish them on the web or in the RW.

Richard