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