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])
- Replies:
- Re: msi again Ben Franksen
- References:
- Re: msi again Linda.Pratt
- Re: msi again Benjamin Franksen
- Navigate by Date:
- Prev:
RE: compressArray Kalantari Babak
- Next:
access security file Pierrick Hanlet
- 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 Benjamin Franksen
- Next:
Re: msi again Ben Franksen
- 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
|