On Nov 17, 2009, at 10:10 AM, Markus Roberts wrote: > > > On Tue, Nov 17, 2009 at 12:57 AM, David Schmitt <da...@dasz.at> wrote: > > Markus Roberts wrote: > > > > It'd be great if you could abolish the parse-order dependency > > > > > altogether. As long as all variable/value reference chains > form a > > > directed acylcic graph, they could be evaluated after > finishing the > > > parse, regardless of order. > > > > Could you elaborate on this? > > > > > The best I can think of is to do something like store a reference > > > to a variable and a scope during compilation, and then only deref > > > them when we're converting the catalog at the last minute. > > > > That's basically it; the more general form is to use the futures > (aka > > promises) mentioned earlier in this thread. Instead of stashing a > > (variable,scope) reference you create a placeholder object which > either > > holds a value or the tree to evaluate to get that value. > > > > After parsing is done (and the full forest is known) you fulfill all > > futures that contain values, than iteratively fulfill all futures > which > > only depend on fulfilled values. If it's a DAG, you're set. If > there > > are loops, you'll be left with unfulfillable nodes and it's an > error. > > Yes. You make it sound so easy :-) I'm worried because this also > affects > function evaluation including include() and template(), both of which > might alter the manifest significantly, including autoloading new > stuff. > > Not saying it can't be done, just that it is really a sweeping change > through many parts of the language. > > First, this isn't late binding (determining which function to call > at run time, which puppet already does) it's (semi-)lazy evaluation > (waiting to evaluate expressions).
You people with your definitions. :P > In principle, it shouldn't effect the semantics of an existing > program in any language (with the caveat that to preserve order of > side effects in languages that have them you have to walk the tree > in the proper order), it should only effect efficiency and the > ability to process programs that couldn't have been written without > it. In a pure declarative language, things are generally much > easier, as by definition such transformations can't effect the > meaning (though they can effect the efficiency). > > While puppet isn't as pure as it could be, the intent is > fundamentally declarative. There are a few cases where the model > fails, but these are generally (and rightly) considered bugs. If > people are relying on these bugs to get proper results it could > affect their manifests, but my understanding is that it isn't > particularly common (because the bugs aren't particularly useful). > > (This is where someone can challenge my assumptions by jumping in > with a concrete example of such bugs being indispensable, if they > have one.) I think your points are essentially true, with the only real result being that some code that's currently used to get around this shortcoming will be wasted cpu time, but otherwise, it's all fine. I never said it wasn't possible, though, just that I didn't really know how to do it. There's some extra complexity because what people really want is the ability to have a template in a base class using a variable in a base class, and then override that variable -- and thus change the contents of the template -- in a sub class. I have *no* idea how we'd accomplish this. If we ignore that bit, I think it's still pretty complicated. -- Smoking is one of the leading causes of statistics. -- Fletcher Knebel --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
