On Tue, Aug 27, 2013 at 09:40:51AM +0200, Nicolas Sebrecht wrote: > The 27/08/13, Guido Trotter wrote: > > On Tue, Aug 27, 2013 at 8:52 AM, Jose A. Lopes <[email protected]> wrote: > > > From: "Jose A. Lopes" <[email protected]> > > > > > > This patch series introduces a transitional infrastructure for > > > generating Python constants from Haskell. This infrastructure > > > introduces several new Haskell modules that contain the constants on > > > the Haskell side, the constants to be generated to Python, and the > > > Template Haskell code for performing the generation. > > > > > > * move instances of PyValue to a separate module for reuse > > > * add Template Haskell for constant generation > > > * introduce the constant infrastructure > > > * update Python constants module to fetch value from the generated > > > code > > > * eliminate Haskell duplicated constants introduced by the > > > infrastructure > > > > > > Jose A. Lopes (6): > > > Move some 'PyValue' instances to a separate file > > > Add Template Haskell code for constant generation > > > Setup constant generation infrastructure > > > Update 'ADMINST_DOWN' reference to '_constants.py' > > > Rename 'Constants.hs' to 'PyConstants.hs' > > > Import original constants instead of generated > > > > As discussed in person, this is a good "intermediate state" with the > > following changes: > > > > - the list of constants filtered out from py to hs has to be read from > > the hs file, and not hardcoded > > - the "map of haskell constants to be generated" has to be also generated > > > > Thanks a lot for preparing this first draft! > > I'm sorry I could be sightly out of scope. I'm not following development > as much as I'd like. > > I don't get the point of generating Python constants from Haskell with > templating code (and/or vice versa). What I mean is that if different > languages need read access to the same configuration definitions, it's > usually done with a static configuration file (whatever it's YAML or > so).
Beside what Jose replied: this is not configuration definitions. Those are already in the config database, in JSON format. What is in the constants file is much more basic data: like where is the configuration located, and other things that are constant across the software. Like daemon names, which things were enabled at build time, etc. > Same goes for dynamic definition/data whose tend to be shared to each > other by using a shared (simple?) protocol. That is, again, the configuration database. > What I'm wondering is why to go with templating code which might reveal > too much limited at some point in the future instead of tackling the > problem with a "standard" approach? Constants in software is very much a standard approach… regards, iustin
