On 2014-17-07 20:53, Reid Vandewiele wrote:
On Friday, July 11, 2014 7:50:47 PM UTC-7, henrik lindberg wrote:
Here we have another problem; variables defined in classes are very
different from those defined elsewhere - they are really
attributes/parameters of the class. All other variables follow the
imperative flow. That has always bothered me and causes leakage from
classes (all the temporary variables, those used for internal purposes
etc). This is also the source of "immutable variables", they really do
not have to be immutable (except in this case).
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.
Slightly off-topic so I'll keep it short.
I have a huge appreciation for immutable variables in the Puppet
language as I think it helps keep people centered in the mindset of
declarative configuration and not procedural programming. The fact that
variable values are parse-order dependent is detrimental in that it
forces users to hold and visualize a more complex model in order to not
get tripped up by parse-order dependencies. Resources can only be
declared once
This is going to change - many want to be able to declare the a resource
multiple times, and that the non conflicting result is merged.
The resource does not exist until it is evaluated; you can have
references to it (or to any non existing resource) - things must resolve
at the end naturally.
and can be referred to before they've been hit by the
parser.
The are never hit by "the parser" - the parser is what translates the
source text into something that can be acted on, it does not evaluate
anything, or schedule lazy evaluation etc. That is the combination of
the evaluator (in the future parser), and an invisible evaluator that is
split up between all the AST objects in the current implementation.
I think you meant, can be referenced independently of the evaluation
order... but that is always true - you can reference anything even
things that do not exist (only you get an error at the end).
It is the instruction / operator that have lazy evaluation; say $a -> $b
which evaluates $a and $b to produce references to resource and then
asks the compiler to "make it so that everything in $b is after
everything in $a. It is at the point where the lazy operator is
evaluated that it is an error to reference something that does not exist.
I would strongly support variables being the same. Today they
are immutable and so have one foot in that door. Making them part of the
lazy logic sounds like it could get them the rest of the way.
Well, there are different kinds of variables; those in a class are not
really variables; they are more like the class' attributes/parameters.
For a define the variables are not attributes (only the declared
parameters are).
Outside of technical implementation challenges, it would be a good thing
if variables were immutable and lazily evaluated in such a way as to
make the example given above work.
Is there an existing thread or Jira ticket that would be a more
appropriate place to discuss further?
There have been several tickets in the past where this has been
discussed (starting with various ideas). We already have complex
dependency orders in our evaluation, adding yet another such mechanism
on top seems like more opportunities to create endless loops and
deadlocks. The capability "lazy values" must be introduced in a safe
way. On that topic we do have some ideas, but it will take a while to
write them up into a coherent proposal.
I do not think lazy evaluation is appropriate for all kinds of variables
because we have an imperative language that constructs a lazily
evaluated catalog that in turn is declarative.
As David Schmitt pointed out, having to use multiple variables is a pita
in several use cases because imperative programming (discrete steps) has
to be taken to get the task done. We eventually would end up with
something F# or Haskel like, or something resembling Prolog, since doing
this for variables is just the tip of the iceberg. Would be cool to see
a full function oriented puppet language variant...
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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/lq9o47%249na%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
