Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 15 Jul 2008 10:30:33 +0200

Hi Andrew

On Friday 11 July 2008 18:22, Andrew Johnson wrote:
> On Tuesday 08 July 2008 19:54:29 Ben Franksen wrote:
> > The problem might be solved by suitable generalization. I am thinking
> > about extensible syntax with pluggable handlers, an idea I've been
> > pondering for a long time. This would have a wide range of possible
> > applications, including pluggable field properties like
> > 'copy_to_partner' as proposed by Bernd, while retaining complete
> > backward compatibility. Let me explain what I mean.
>
> Funny, a pluggable parser is one of my plans for the future,

Great!

> although 
> there are a number of other major jobs that need doing first. 

'need doing first' as in 'technically required to implement this' or as 
in 'more important to have in the next release'?

> We 
> actually need two separate parsers since the IOC isn't going to be
> reading DBD files in the future, all that information will be compiled
> into the generated binary.
>
> The DBD files will still be needed though, they provide the meta-data for
> the DB files, and any plugin for a DB file parser must be described
> somehow in a DBD file to allow VDCT to understand and generate the DB
> file.  This is slightly contrary to your "unspoken assumption" about the
> parser ignoring items it doesn't understand — DBD files must declare all
> of the information needed to parse DB files so that generic tools like
> VDCT can understand and create them properly.

I can't see anything contrary. Imagine an additional field 
property 'copy_to_partner' as would be needed for a redundancy plugin. Why 
would a generic tool like vdct care any more about it than it does about 
things like the 'pp' field property.

Also, it doesn't matter whether we talk about db or dbd files. If vdct 
invented new db syntax like

  record(ao,"myrecord") {
    x_position(315)
    y_position(287)
    field(...)
  }

why should e.g. the runtime db loader on the IOC care to know anything about 
this? There is no necessity to declare this syntax in a dbd file.

My stance is that all tools simply use whatever part of the syntax tree is 
interesting to them and are /required/ to ignore the rest.

> Parsing of DBD files (record, device, driver, menu, registrar, function
> and variable definitions) will be done at compile time using Perl code
> that already exists (at this stage we're mostly just doing text
> manipulation and generating C code from the DBD descriptions, so Perl is
> much more efficient than writing it in C). [...]

A plugin-API similar to the one I sketched for C can be done in Perl as 
well. Whether the plugged-in Perl code generates C or plays a melodie 
according to the distribution of characters read, should be irrelevant to 
the caller (the parser).

> Unfortunately Bernd needs 
> to add information to the field descriptions which get converted to C 
> structures.  This may have to be incorporated 
> before Base gets built,

I don't understand the last remark, and unfortunately I can't look at the 
existing 3.15 code. (No access to the source repository because I don't 
have an account on an APS machine. I hope that this requirement is going to 
change with the planned switch to Subversion.)

> although it might be feasible to implement 
> something like the generic info items into the record field descriptors —
> that should be sufficient for his purposes.

While generic info items may be sufficient in simple cases, they are 
insufficient in general as they don't support presenting information in a 
structured way. They are a stop-gap measure at best and an invitation to 
ugly work-arounds at worst. The situation is quite similar to the way 
supports for new bus types currently use the predefined unstructured link 
type INST_IO, where everyone invents their own incompatible ad-hoc syntax 
for the parm string. I think we all agree that this is not what we want. 
There /is/ a reason why XML was invented ... ;-)

Cheers
Ben

PS:
> > Currently all syntax for db and dbd files is hard-coded into the
> > parser. That, however, need not be the case. The grammar itself is very
> > simple and regular: there is exactly one aggregate syntactical
> > structure which I will call <definition>. A definition consists of a
> > <head> of the form:
> >
> > 	<keyword> (<argument>,...)
> >
> > optionally followed by a <body>:
> >
> > 	{ <definition> ... }
> >
> > where an <argument> is either a number, or a quoted string
> > (unrestricted charset), or a bareword (restricted charset). The
> > top-level is simply a sequence of definitions (like the inside of a
> > body).
>
> With one exception: the body of a breaktable currently comprises a
> free-form list of raw+converted number pairs, space or comma separated. 

Yes, I have simplified matters a bit. There is also the path and addpath 
directives (which I find horrible; they should be deprecated ASAP) and 
include (which IMO should be restricted to the top-level and other uses 
replaced by more structured means). One can handle them all (including 
breaktables) in a built-in way, only the parts that follow the general 
scheme will be extensible.

And while we're at it, I hate it that currently the order of definitions in 
db and dbd files matters. It should not, that is, not in any user visible 
way, i.e. it should be possible to refer to items defined further below in 
a file, and the dbd compiler should be free to re-order menu choices, 
recordtype fields, etc. however it sees fit. Runtime data representations 
can be abstracted by generating header files or even completely hidden by 
generating suitable C code. Implementing inheritance with 'include' by 
requiring that the included fields are at the beginning of the recordtype 
definition is a horrible hack anyway.

Remember: storing huge amounts of tediously repetitive stuff away in memory 
while meticulously keeping track of their order and cross-references 
between them is something computers are much better at than humans. And 
since this is the 21st century there is really no longer any need to 
restrict the source language only so that applications processing it can 
use a one-pass implementation.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System