Experimental Physics and
Industrial Control System

Ben Franksen <[email protected]> · Tue, 7 Sep 2010 19:40:36 +0200

On Freitag, 3. September 2010, Goetz Pfeiffer wrote:
> On 09/03/2010 11:22 AM, Benjamin Franksen wrote:
> >> (3) We concatenate substitution files and database files together as
> >> part of our build.  Introducing global sections that only go out of
> >> scope at the end of a file could become interesting, since there way
> >> to "ifdef" or "undef" in files that will become part of a larger one
> >> and there is no proposed syntax to delineate their actual scope.  We
> >> probably won't be definining global variables in our systems, however
> >> we do use other people's modules so we would be concerned about side
> >> effects if widespread use of global variables appeared in synapps, for
> >> instance.  Would a naming convention be useful?
> >
> > This is a valid concern. I had similar reservations (about my own
> > proposal). The problem could be avoided by explicitly delimiting the
> > scope of no- longer-quite-global definitions, like in
> >
> > scope {
> > 	x=a
> > 	y=b
> > 	file xyz {...}
> > 	file ...
> > }
> >
> > where the macros named  x  and  y  would be undefined after exiting the
> > scope {...}  block.
> >
> > [...]
> >
> > I must admit to a certain amount of embarrassment that I let practical
> > considerations like these influence the design decision.
>
> I think the new "global" statement has a principal weakness that new
> definitions can only be added, but never removed. Although one could
> think of another statement that removes global definitions, it would be
> much more elegant to introduce a scope for global definitions.
>
> When you have such a scope you want, of course, be able to nest
> global statements, just as it is shown by Benjamin in the example
> above.
>
> I think it should be possible to adapt the perl parser library to that,
> but that shouldn't influence us here anyway. If it is possible to parse
> the files with C (msi) 

(without using a parser generator, that is)

> it will be with perl, too. 
>
> I would propose the "scope" definition as it is should above, with the
> possibility to nest these statements. Maybe we could select another
> keyword than "scope", e.g. "begin", or maybe we do not need a keyword
> at all ? The braces '{' and '}' would be sufficient to define a block.

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 (although the 
syntax is a bit less regular and thus, perhaps, slightly harder to parse). 
Indeed, when converting our applications to take advantage of the new msi 
features, I found at least one existing substitution file where the intent 
is much better captured (and errors more easily avoided) using scope 
sections than with globals (where the second global section overwrites the 
definitions in the first one and, as Götz pointed out, cannot remove any).

I am not sure whether nested scopes are useful enough to move away from from 
a regular language ("regular" as in "regular expression"). Or whether they 
should be allowed anywhere e.g. inside file sections. As always, my 
instinct (or rather guiding principle) says to reduce basic components to 
the minimum but allow combinations with as few restrictions as possible. 
Yet, another principle says reduce the machinery to the least powerful (and 
thus most simple and predictable) one that is appropriate for the job.

Any opinions?

BTW, leaving off the keyword ("scope", "begin", whatever) is not a good 
idea, at least as long as we want to allow scopes in places other than the 
top-level: note that seeing something like  {X=a}  we could no longer 
decide w/o context whether this is a substitution instance of some file or 
just a new scope with no substitutions in it. Even worse, an empty list  {}  
would become ambiguous inside a file section. I am not even sure the 
resulting grammar would remain context-free, certainly the parser would 
need more than one token lookahead.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System