Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 3 Sep 2010 11:22:01 +0200

Dear Linda

Andrew answered most of your questions in great detail. Apart from your last 
question, I merely summarize.

On Thursday, September 02, 2010, [email protected] wrote:
> So the question is how do the two features of global definitions versus
> macro default values sit together? Does a global definition in a
> substitution file override a default definition of a macro of the same
> name in a template or vice versa?

Yes, provided it appears before the default definition in the substitution 
file.

> Presumably a value specified in substitution pattern overrides a global
> defined value?

Yes.

> Also can we be assured that changes to the behaviour for missing macros
> and empty lists, etc under discussion would not break this usage?

I can't see how it could break anything, as we merely allowed expressions 
that were formerly regarded as syntax errors.

> (2) At what level are these truly globals?  

(substitution-)file level

> Since a database can be
> partially expanded again and again, will the global definitions be
> passed on to the expanded file recursively?

If you talk about repeated execution of msi, then the answer is that msi 
does not remember macro definitions across executions. Otherwise I don't 
understand the question.

> (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.

The reason I did not push for such a --more principled-- solution, is that 
it would be very unnatural not to allow nested scopes then, as in

scope {
	x=a
	scope {
		y=b
		file xyz {...}
		file ...
	}
	file ...
}

However, this would make the syntax non-regular. Here at BESSY we are using 
substitution files for more than just expanding them with msi, for instance 
we have a perl script that generates edm and dm2k panels from smaller 
component panels, using substitution files. Extending the syntax with 
definition blocks like sketched above would have meant that we could no 
longer (easily) parse them with Perl regex expressions. The syntax extension 
with top-level  global {}  blocks keeps the syntax regular and made it 
possible to adapt the regex-based parser by making local changes only.

I must admit to a certain amount of embarrassment that I let practical 
considerations like these influence the design decision.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System