Experimental Physics and
Industrial Control System

On Tuesday, September 07, 2010, Ben Franksen wrote:
> I am now convinced that the global definitions I proposed earlier have
> been a mistake and apologize for having presented them prematurely. The
> solution using static scopes (as sketched above) is clearly superior

I attached a complete (but rather terse) description of syntax and semantics 
that follows the mentioned sketch. Nested scopes are allowed, but (to keep 
things simple) not inside file blocks. I am not wedded to this or any other 
concrete detail; consider it as a request for comments.

I think we can move discussion to [email protected] from here on, so 
please direct your replies there (unless you think it is of interest to a 
wider audience).

Cheers
Ben

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH   
Hahn-Meitner-Platz 1, 14109 Berlin   
Vorsitzende des Aufsichtsrates: Prof. Dr. Dr. h.c. mult. Joachim Treusch   
Stellvertretende Vorsitzende: Dr. Beatrix Vierkorn-Rudolph Geschäftsführer: Prof. Dr. Anke Rita Kaysser-Pyzalla, Prof. Dr. Dr. h.c. Wolfgang Eberhardt, Dr. Ulrich Breuer   
Sitz der Gesellschaft: Berlin Handelsregister: AG Charlottenburg, 89 HRB 5583   

Disclaimer automatically attached by the E-Mail Security Appliance   
mail0.bessy.de 09/08/10 at Helmholtz-Zentrum Berlin GmbH. 

Syntax
------

This is an EBNF grammar for the template substitutions file format, to be
understood by msi and dbLoadTemplate.  These rules have been written to be
easily converted into a Yacc grammer, so they don't usually match nothing.

(Note that the second case in the (root) non-terminal <substitution-file>
is there to support "regular format", i.e. what msi expects if it gets a
template file on the command line.)

substitution-file ::= ( scope-definition | template-substitutions )*
                    | variable-substitutions

scope-definition ::= 'scope' '{' variable-definitions? substitution-file '}'

template-substitutions ::= template-filename '{' substitutions? '}'
template-filename ::= 'file' file-name
substitutions ::= pattern-substitutions | variable-substitutions

pattern_substitutions: 'pattern' '{' pattern_names? '}' pattern_definitions?

pattern-names ::= ( variable-name ','? )+
pattern-definitions ::= ( '{' pattern-values? '}' )+
pattern-values ::= ( value ','? )+

variable-substitutions ::= ( '{' variable-definitions? '}' )+
variable-definitions ::= ( variable-definition ','? )+
variable-definition ::= variable-name '=' value


These definitions are use by the lexer:

variable-name ::= variable-name-start-char variable-name-char*
file-name ::= file-name-char+ | double-quoted-string | single-quoted-string
value ::= value-char+ | double-quoted-string | single-quoted-string

double-quoted-string ::= '"' (double-quoted-char | escaped-char)* '"'
single-quoted-string ::= "'" (single-quoted-char | escaped-char)* "'"
double-quoted-char ::= [^"\]
single-quoted-char ::= [^'\]
escaped-char ::= '\' .


In R3.15 we'd like to restrict the bareword characters to these:

variable-name-start-char ::= [a-zA-Z_]
variable-name-char ::= [a-zA-Z0-9_]
file-name-char ::= [a-zA-Z0-9_+:./\] | '-'
value-char ::= [a-zA-Z0-9_+:./\<>;[] | '-' | ']'

but for R3.14.12 we'll stay with this for all of those:

*-char ::= [a-zA-Z0-9_+:./\<>;[] | '-' | ']'


Semantics
---------

In what follows, names surrounded by angular brackets (<...>) refer to
symbols in the grammar.

The semantics of substitution files (as interpreted by msi and
dbLoadTemplate) is defined as a translation from input to output. Input
either comes from files mentioned in a <template-substitutions> construct,
or is implicit by how msi is called (i.e. with an additional filename
argument). In order to avoid a case distinction, we can reduce the latter
case to the former one by treating the content of the substitution file as
if it were surrounded by

  file <file-name> { 

and

  }

turning it into a single <template-substitutions> section.

The complete output then consists of the concatenation of the output of all
the <template-substitutions> sections in the substitution file in the order
in which they appear in the substitution file.

We can avoid another case distinction by translating away the
<pattern-substitutions> syntax (that is, we treat it as sugar for the
(sometimes) more verbose <variable-substitutions> syntax):

    A block of <pattern-definitions> of the form

    pattern { n_1  n_2  ... n_k }
            { v_11 v_21 ... v_(k_1)1 }
            ...
            { v_1m v_2m ... v_(k_m)m }

    (where  n_i  are the macro names and  v_ij  the values,
     k>=0  is the number of macro names,  m>=0  is the number of
    substitution instances, and  k_j<=k  is the number of values for
    the j'th substitution instance)

    translates to the <variable-definitions> block:

    { n_1=v_11 n_2=v_21 ... n_(k_1)=v_(k_1)1 }
    ...
    { n_1=v_1m n_2=v_2m ... n_(k_m)=v_(k_m)m }

The output of a <template-substitutions> section is the concatenation of all
<variable-substitutions> instances contained in it.

The output of a single <variable-substitutions> instance in turn depends on
the input --as specified by the <file-name> in the surrounding
<template-substitutions> construct-- together with the list of /macro
definitions/ that are in scope (i.e. available for substitution) inside this
<variable-substitutions> instance.

How exactly the output relates to the input, given a list of macro
definitions in scope, is not defined in this document. This task is
delegated to the macLib macro substitution library (part of EPICS base),
which is therefore responsible for defining the syntax and semantics of the
actual macro substitution. This is also the reason why we must talk about
_lists_ of macro definitions (instead of _sets_). This means that more than
one definition for the same <variable-name> is allowed and also that the
order of definitions is relevant. Again, exactly in which way multiple
definitions for the same name are resolved and how the order of definitions
influences the substitution is (or at least should be) defined by the macLib
documentation.

It remains to define the list of macro definitions in scope inside a
<variable-substitutions> instance.

First, each occurrence of <variable-definition> in the substitution file
introduces a /macro definition/, associating a <variable-name> with a
<value>. A /scope/ is introduced by one of:

 * <scope-definition>
 * <variable-substitutions>

We define the list of /immediate macro definitions/ associated with a scope
as the list of all <variable-definition>s appearing *immediately* after the
opening brace. (Note: this excludes any <variable-definition>s
that appear inside nested scopes.) The order of definitions in the list is
the one in which they appear in the substitution file.

The list of macro definitions in scope inside a <variable-substitutions>
instance is then defined as the concatenation of the immediate macro
definitions associated with all enclosing scopes --including the
<variable-substitutions> instance itself-- in the order in which these
scopes appear in the substitution file. The resulting list thus starts with
the immediate definitions in the outer-most scope and and ends with those in
the inner-most scope.

References:

Re: msi again Linda.Pratt

Re: msi again Goetz Pfeiffer

Re: msi again Ben Franksen

Navigate by Date:

Prev: Re: what are you talking/asking about? Benjamin Franksen

Next: CSS on x86_64? John Dobbins

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <2010>  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: Re: msi again Ben Franksen

Next: MEDM/Motif problem Andrew Wagner

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <2010>  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024