On Freitag, 3. September 2010, Goetz Pfeiffer wrote:
> On 09/03/2010 11:22 AM, Benjamin Franksen wrote:
> >> (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.
> >
> > [...]
> >
> > I must admit to a certain amount of embarrassment that I let practical
> > considerations like these influence the design decision.
>
> 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)
(without using a parser generator, that is)
> 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.
I am now convinced that the global definitions I proposed earlier have been
a mistake and apologize for having presented them prematurely. The solution
using static scopes (as sketched above) is clearly superior (although the
syntax is a bit less regular and thus, perhaps, slightly harder to parse).
Indeed, when converting our applications to take advantage of the new msi
features, I found at least one existing substitution file where the intent
is much better captured (and errors more easily avoided) using scope
sections than with globals (where the second global section overwrites the
definitions in the first one and, as Götz pointed out, cannot remove any).
I am not sure whether nested scopes are useful enough to move away from from
a regular language ("regular" as in "regular expression"). Or whether they
should be allowed anywhere e.g. inside file sections. As always, my
instinct (or rather guiding principle) says to reduce basic components to
the minimum but allow combinations with as few restrictions as possible.
Yet, another principle says reduce the machinery to the least powerful (and
thus most simple and predictable) one that is appropriate for the job.
Any opinions?
BTW, leaving off the keyword ("scope", "begin", whatever) is not a good
idea, at least as long as we want to allow scopes in places other than the
top-level: note that seeing something like {X=a} we could no longer
decide w/o context whether this is a substitution instance of some file or
just a new scope with no substitutions in it. Even worse, an empty list {}
would become ambiguous inside a file section. I am not even sure the
resulting grammar would remain context-free, certainly the parser would
need more than one token lookahead.
Cheers
Ben
- Replies:
- Re: msi again Benjamin Franksen
- References:
- Re: msi again Linda.Pratt
- Re: msi again Benjamin Franksen
- Re: msi again Goetz Pfeiffer
- Navigate by Date:
- Prev:
Re: Please do not hijack threads [was: cPCI] Andrew Johnson
- Next:
Re: Please do not hijack threads [was: cPCI] Maren Purves
- 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 Goetz Pfeiffer
- Next:
Re: msi again Benjamin 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
|