DDLm implementation discussion
doug.duboulay at gmail.com
Sun Mar 15 23:12:34 GMT 2009
On Wed, 11 Mar 2009, David Brown wrote:
> There seems to be a consensus here that branching is built into dREL and
> is desirable in a definition. It is not clear if this has to be
> achieved using if-then constructs or an ordered loop defining the
> different branch methods. If one goes for the if-then construction, how
> does one ensure the tested item is present, or can one make provision
> for a default procedure if it is not? If the definitions form a tree
> (rather than a network with closed loops) it should not be possible to
> get stuck in a loop as mentioned below by DD.
If-then branching works in the case where the adp_type flag exists,
but if it didn't, and there was no defalt value, the dREL implementation
of that method should (and probably does), behind the scenes raise
an exception. The nearest parent up the call hierachy that invoked
this method should (but probably doesn't) catch it,
look for the next comparable method in the adp_type method list and
try that instead (this wasn't implemented that I know of).
If the next alternative fails, or doesn't exist, the exception should
propagate up to the next level of the call-stack hierarchy.
I *think* the proto-prototype might just have caught it at the top
level of the evaluation chain and aborted the whole evaluate call
(probably because multiple eval methods weren't on the drawing board)
One alternative would be littering the dREL syntax with
try: except: blocks for in case the data_item access/evaluate methods fail.
Once upon a time I thought that it would be a good idea to have the full
flexibility of python available in the methods, but actually
the syntax and expressions are easier to read and understand without it
and I think Syd and Nick got that right.
Another alternative would be just to add a builtin function to test
availability of a data item, trap any exceptions generated and return
true or false on success - for if-elsif-else testing.
Actually, that might be more like a preprocessor/compile-time macro
function than a run time function. Not sure.
It could look like
but that might force the eval before the function call. Or it
might be simpler as a quoted string?
About method calls in a recursive loop, that *might* be trappable
by the dREL parser. It could be that a given method might be called
more than once in an eval call-stack hierarchy but with a different
argument for each call. That might be quite complicated to check.
Possibly you would need to duplicate the whole CIF instance with each
call so you could check that absolutely nothing had changed in between
each repeated method call. Not sure how that would work though.
> AMBIGUITY IN THE USE OF THE BETA FORM OF THE ADP
> IDB Comment:
> Nick is referring here to the way matrices are constructed from the
> individual matrix elements stored in the CIF. The assumption is that
> experimental information will be given as matrix elements and the
> matrices themselves would only be created under dictionary control. So
> Nick is right as long as no-one enters the beta matrix as a matrix
> because individual matrix elements do not appear in the dictionary.
> However, there is nothing I am aware of in DDLm that prevents the matrix
> from being generated by external software or a word processor, and the
> convenience of doing so may encourage users to take this shortcut. The
> question is how to prevent this.
Assuming the current generation of CIF editors read the dictionaries
and expose the text based descriptions to users,
could you not simply add a warning to the description saying
something like: "Don't use this in a real CIF"? I know some items
have deprecation warnings already (despite the fact that any
backwards compatible CIF reading software still need to check and
handle such items).
Also people are free to put all manner of junk in a CIF file, but if
they want to get it published they typically need to go through checkcif.
So you still have that as a beta blocker, and any other use they make
of it would be entirely at their own risk.
> A further danger is one that
> Herbert pointed out in Osaka. He suggested that DDLm CIF dictionaries
> would make CIF more dynamic compared with the static character of CIF1
> and CIF2, and if some experimental or assigned value (e.g., the cell
> constants), were changed there would be no way we could ensure that all
> the derived items would be automatically updated.
Syd and Nick used to talk of adding validation methods as
well as evaluation methods. Presumably a validation method would
establish an item's veracity, even if it was included.
> Which seems perfectly logical to me. dREL is a Turing complete language and
> while there is one evaluation method in an item definition you can create a
> multitude of paths to the answer - and that is a GOOD THING.
except for the halting problem.
> As is well known, the devil is in the details, and in adapting the CIF
> dictionaries I will have to make many decisions in matters of detail.
> But if there is agreement on splitting the dictionaries into archive and
> derived-item dictionaries as described above, I will have a guideline to
> work with. I will undoubtedly come back with other problems in the
> future but this split seems to be in the spirit of DDLm and appears to
> solve a number of important problems.
One possible fly in the ointment might be some of the category.id elements,
which I gather are important for uniqueness in the relational database model,
but were significantly redundant e.g. _geom_torsion.id, at least in the early
DDLm core dictionary. Don't know if that would have any impact by being
relegated to a backup method dictionary?
> Is this plan acceptable to everyone? If so, I will start to apply it
> and move this discussion on to the next problem.
Sorry, my info is quite old, but hopefully it might help
a little bit.
More information about the comcifs