On 2014-07-17 23:41, Henrik Lindberg wrote:
On 2014-17-07 14:56, David Schmitt wrote:
On 2014-07-12 04:50, Henrik Lindberg wrote:
On 2014-11-07 10:55, David Schmitt wrote:
[...snip...]
[1] It might be worthwhile to start requiring to always write
'realize(Type<| expr |>)' for this side-effect. This looks annoying.
it could be
Type <| expr |>.realize
Ugh.
A positive Ugh, or a Ugh of agonizing pain? :-)
The latter.
[...snip ...]
I think this may just move the problem to dueling defaults, dueling
values, and dueling overrides. (This problem occurs in the binder and
there the problem is solved by the rules (expressed in the terms we use
here (except the term 'layer', which I will come back to):
- if two defaults are in conflict, a set value wins
- if two values are in conflict, an override wins
- if two overrides are in conflict, then the one made in the highest
layer wins.
- a layer must be conflict free
Don't you mean "the highest layer with a value must be conflict free" ?
yes, that is true, since some higher layer must resolve the issue. Not
meaningful to enforce resolution in every layer.
Good.
Highest (most important) layer is "the environment", secondly "all
modules" - this means that conflicts bubble to the top, where a user
must resolve the conflict by making the final decision.
The environment level can be thought of as what is expressed in
"site.pp", global or expressed for a "node" (if we forget for a while
about all the crazy things puppet allows you to do with global scope;
open and redefine code etc).
If you mean what I think you mean, I think like it.
Another example to try to understand this:
class somemodule { package { "git": ensure => installed } }
class othermodule { package { "git": ensure => '2.0' } }
node 'developer-workstation' {
# force conflict on Package[git]#ensure here: installed != '2.0'
include somemodule
include othermodule
# conflict resolved: higher layer saves the day
Package[git] { ensure => '2.1' }
}
How would the parser/grammar/evaluator understand which manifests are
part of what layer?
We will have a new catalog model (the result built by the new catalog
builder slated to replace the current compiler). There we have a richer
model for defining the information about resources. We also have a new
loader system that knows where code came from. Thus, anything loaded at
the environment level (i.e. node definitions) knows it is in a higher
layer.
Slick. The next question then is: How does the user know? ;-) And How
fine-grained are "levels"? Each entry on the module path? Will I be able
to query the puppetmaster for a report on which sources influenced (or
did not influence) a specific value?
[snip]
If we make variables be part of the lazy logic you would be able to
write:
$a = $b + 2
$b = 2
I think this will confuse people greatly.
Hehe, I can imagine that. When accessing variables across files/classes
I do not see that as a big problem, though. Within a single file/scope
it can be forbidden, or at least warned/linted.
We will see what we end up with - this is currently not a primary
concern. One neat thing you can do with the future parser (and in 4.0)
is to evaluate code in a local block using the function 'with', and then
pass it arguments, the variables in the lambda given to with are all
local! Thus you can assign the final value from what that lambda returns.
I see, I'll have to read up on the future parser...
The crux here is that just having one expression being followed by
another - e.g:
1 1
is this a call to 1 with 1 as an argument, or the production of one
value 1, followed by another?
Is the parser and the evaluator so intertwined that that cannot be
interpreted in context? "1" is not a callable, therefore it cannot be a
function call.
They are not intertwined except that the parser builds a model that the
evaluator evaluates. The evaluator does exactly what you say, it
evaluates the LHS, and if that is not a NAME it fails, and if the NAME
is not a reference to a Function it fails. But the evaluator can not do
that in general, there may be a sequence of say if statements, they all
produce a value, should the second if be an argument to attempting to
call what the first produced ?
if true { teapot }
if true { 'yes I am'}
The evaluator would have no way of knowing, except doing static analysis
(which limits the expressiveness).
Currently the parser rewrites NAME expr, or NAME expr ',' expr ... into
a function call. I do not want to add additional magic of the same kind
if it can be avoided.
Accepted.
[snip]
I am hacking on ideas to fix the problematic constructs in the grammar.
I have had some success, but it is to early to write about. Will come
back when I know more.
Good hunting!
Regards, David
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/53CA317D.30506%40dasz.at.
For more options, visit https://groups.google.com/d/optout.
