[Puppet-dev] late binding values (was: Re: [PATCH/puppet 1/1] Fix #2389 - Enhance Puppet DSL with Hashes)

2009-11-17 Thread David Schmitt

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.

Regards, DavidS

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: [Puppet-dev] late binding values (was: Re: [PATCH/puppet 1/1] Fix #2389 - Enhance Puppet DSL with Hashes)

2009-11-17 Thread Luke Kanies
On Nov 17, 2009, at 2:57 AM, David Schmitt 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.

I think this is somewhat of a concern, but I really do think that the  
vast majority of cases will just work correctly more easily.

As Markus has mentioned earlier, I think very people are intentionally  
using the existing buggy behaviour, so I don't really think it'll be a  
problem.

-- 
I don't deserve this award, but I have arthritis and I don't deserve
that either. -- Jack Benny
-
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-...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=.