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
- Replies:
- Re: msi again Goetz Pfeiffer
- References:
- Re: msi again Linda.Pratt
- Navigate by Date:
- Prev:
StreamDevice/ASYN 'How To' tutorial Eric Norum
- Next:
RE: compressArray Kalantari Babak
- 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 Andrew Johnson
- Next:
Re: msi again Goetz Pfeiffer
- 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
|