Experimental Physics and
Industrial Control System

Goetz Pfeiffer <[email protected]> · Fri, 03 Sep 2010 12:16:56 +0200

On 09/03/2010 11:22 AM, Benjamin Franksen wrote:

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

Hi,
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) 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.
Greetings
 Goetz
([email protected])

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System