Thoughts on syntax shortcuts for class expressions

[Nick Anderson]

Curious for thoughts about a syntax suggestion from Ted.

https://github.com/cfengine/documentation/pull/1453#issuecomment-214758700

classes:
"myclass" ===> "any";

instead of

classes:
"myclass" expression => "any";

Note this only shortens for expression => not or => or and =>.

[Christian Linden]

I won't use it but if Ted will be lucky with it you could grant him this alias =)

[Ted Zlatanov]

On Tue, 26 Apr 2016 09:46:07 -0500 Nick Anderson <ni...@cmdln.org> wrote:

NA> Curious for thoughts about a syntax suggestion from Ted.
NA> https://github.com/cfengine/documentation/pull/1453#issuecomment-214758700

NA> classes:
NA> "myclass" ===> "any";

NA> instead of

NA> classes:
NA> "myclass" expression => "any";

NA> Note this only shortens for expression => not or => or and =>.

Kristian and jimis were against `==>` specifically.

But maybe there can be an alias or a shortcut. Some ideas:

classes:
"myclass" e => "any"; # minor parser change, but not beginner-friendly
"myclass:any"; # minor parser change
"myclass=any"; # minor parser change
"myclass any"; # minor parser change
"myclass" "any"; # bigger parser change
"myclass" => "any"; # bigger parser change

and an easy shortcut for the common case of "any":

classes:
"myclass"; # always defined, easy to implement

Ted

[Dimitrios Apostolou]

On Wed, Apr 27, 2016 at 11:38 AM, Ted Zlatanov <t...@lifelogs.com> wrote:
>
> classes:
> "myclass"; # always defined, easy to implement

This one looks good IMHO.


Dimitris

[Ted Zlatanov]

On Wed, 27 Apr 2016 12:57:09 +0200 Dimitrios Apostolou <ji...@cfengine.com> wrote:

DA> On Wed, Apr 27, 2016 at 11:38 AM, Ted Zlatanov <t...@lifelogs.com> wrote:
>>
>> classes:
>> "myclass"; # always defined, easy to implement

DA> This one looks good IMHO.

https://github.com/cfengine/core/pull/2596 with acceptance test

I hope the other syntax shortcuts get consideration too.

Ted

[Nick Anderson]

I can get on board with classes: "any";

There is some precedence with methods: "method";

I also think that classes: "x" => "my.expression" is a decent candidate.
Yes you lose the expression word. I would be interested to hear some
statistics about classes promises uses. I know I definitely tend to use
expression more frequently than the other options (I probably use or
next most frequently).

[P. Christeas]

I vote for this one, too.

[Aleksey Tsalolikhin]

I'm happy to see CF3 as a living language, with additions (such as the recent jq addition).

However, about this feature -- part of the improvement of CF3 over CF2 is the regularity of the languge.  CF3 has a very regular syntax pattern: promiser, context, promise body.  The promise body consists of constraint expressions (keyword/value pairs).   This pattern is maintained over all the different promise types.  

I recommend against departing from this regularity.  CFEngine is hard enough to learn without adding quirks.

If anything, I'd like to simplify the language by being able to define a class with

  classes:

   "myclass";

Not being able to do this is on par with having to have a class in reports promises (which language constraint was lifted in the last few years).

I do encourage innovation.  

Sincerely,

Aleksey

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/help-cfengine.
For more options, visit https://groups.google.com/d/optout.

--

Aleksey Tsalolikhin

CFEngine Training & Consulting

www.VerticalSysadmin.com

+1-323-393-0779

[Moore, Joe]

Am I reading this correctly--
A triple-equals-arrow means the same as the word expression followed by a regular =>?

So now we can define classes in several ways:

"stayhome" expression => "Friday" . "Day13" , persist => "4320" ;
"goout" ===> "!raining" . "have_umbrella" ;
"feed_fish" or => { "Monday", "Wednesday", "Friday" } , scope=> "bundle" ;
"feed_cats" expression => "have_cats.(Tuesday|Thursday|Saturday)";
have_dogs:: "feed_dogs" ===> { classmatch("Day[0-9][0-9]?") }, scope => "namespace";

And cfengine will avoid Friday the 13th, not get wet in the rain, and feed the fish, cats (if I have any) on their correct schedules, and dogs in this namespace every day (if I have any).

But this won't work:
"i_win" => or { "lucky", "higher_score", "forfeit" } ;

nor this:
"everybody" => any;

This seems too complicated.

--Joe

[Nick Anderson]

On 04/27/2016 02:34 PM, Moore, Joe wrote:
> Am I reading this correctly--
> A triple-equals-arrow means the same as the word expression followed by a regular =>?

===> was shot down pretty quickly by multiple people.

> So now we can define classes in several ways:

Yes, many many ways to define classes. Yes, this is one of the things
that can make CFEngine difficult to learn and use (the plethora of options).

This is just a proposal to make the simple and common things to require
less typing.

So far the only syntax proposal here that has gained traction is to
allow for classes defined in any context:

classes:
"myclass" expression => "any";

# proposed equivlance gaining traction

"myclass";

This one does have some precedence in the language.
For example, in 3.7+ if your using a methods promise with a bundle that
does *not* take any parameters you can use shortend syntax:

methods:
"Actuate my bundle"
usebundle => my_bundle;

# is equivalent to

"my_bundle";

[Ted Zlatanov]

On Wed, 27 Apr 2016 19:34:09 +0000 "Moore, Joe" <joe....@siemens.com> wrote:

MJ> Am I reading this correctly--
MJ> A triple-equals-arrow means the same as the word expression followed by a regular =>?

MJ> So now we can define classes in several ways:

MJ> "stayhome" expression => "Friday" . "Day13" , persist => "4320" ;
MJ> "goout" ===> "!raining" . "have_umbrella" ;
MJ> "feed_fish" or => { "Monday", "Wednesday", "Friday" } , scope=> "bundle" ;
MJ> "feed_cats" expression => "have_cats.(Tuesday|Thursday|Saturday)";
MJ> have_dogs:: "feed_dogs" ===> { classmatch("Day[0-9][0-9]?") }, scope => "namespace";

MJ> And cfengine will avoid Friday the 13th, not get wet in the rain, and feed the fish, cats (if I have any) on their correct schedules, and dogs in this namespace every day (if I have any).

MJ> But this won't work:
MJ> "i_win" => or { "lucky", "higher_score", "forfeit" } ;

MJ> nor this:
MJ> "everybody" => any;

MJ> This seems too complicated.

I proposed like 10 different ways and everyone is complaining about the
triple arrow. Read my earlier post please! There are more things to
complain about!

Ted

[Kristian Amlie]

On 27/04/16 21:55, Nick Anderson wrote:
> On 04/27/2016 02:34 PM, Moore, Joe wrote:
>> Am I reading this correctly--
>> A triple-equals-arrow means the same as the word expression followed by a regular =>?
>
> ===> was shot down pretty quickly by multiple people.
>
>> So now we can define classes in several ways:
>
> Yes, many many ways to define classes. Yes, this is one of the things
> that can make CFEngine difficult to learn and use (the plethora of options).
>
> This is just a proposal to make the simple and common things to require
> less typing.
>
> So far the only syntax proposal here that has gained traction is to
> allow for classes defined in any context:
>
> classes:
> "myclass" expression => "any";
>
> # proposed equivlance gaining traction
>
> "myclass";

This one makes sense I think, and doesn't break with syntax
expectations, since there simply are no attributes specified.

Otherwise I agree with what has been pointed out by many, the language
is hard enough to learn as it is, we should at least try to keep the
language relatively clean of "special" constructions. This trumps
number-of-characters-to-type IMHO.

--
Kristian

[Brian Bennett]

+1 everything Aleksey said.

-- 

Brian Bennett

Looking for CFEngine training?

http://www.verticalsysadmin.com/

You received this message because you are subscribed to the Google Groups "dev-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-cfengine...@googlegroups.com.
To post to this group, send email to dev-cf...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dev-cfengine/CANNWuVUuN6dgq%3DPYpHyHUcw-QmoT40HrSzb9%2Bs3HCWCbZvagdA%40mail.gmail.com.

[Dimitrios Apostolou]

On Wed, Apr 27, 2016 at 11:38 AM, Ted Zlatanov <t...@lifelogs.com> wrote:
>

> classes:
> "myclass"; # always defined, easy to implement

The consensus on this one was great, and since it was quickly coded by
Ted, and it has also been cherry-picked to the upcoming 3.9.0 Beta
release. Thanks everyone!


Dimitris

[mike.w...@verticalsysadmin.com]

One further thought on this:

Looking down the road a bit, we may want to consider handling the "if" attribute of a classes promise the same way as the "expression" attribute, or vice versa.

I would imagine that newcomers to CFEngine will have no particular reason to ever use the "expression" attribute at all, when the default expression is "any" and they can express the more complex conditionals they will need with an "if" attribute (or an "and" attribute, or "or" attribute, etc.) without ever learning "expression."

Currently, the verbose output based on "expression" is different from that based on "if" (example shown is running 3.7.1):

[root@hub tmp]# cat classes.cf
bundle agent main {
  classes:
    any::
      "set_by_expression"
        expression => "any";


      "set_by_if_and_expression"
        if => "any",
        expression => "any";


      "unset_by_if"
        expression => "any",
        if => "!any";


      "unset_by_expression"
        expression => "!any";
}
[root@hub tmp]# cf-agent -f ./classes.cf -vKC | sed -n '/pass 1/,/pass 2/p'
 verbose: C: BEGIN classes / conditions (pass 1)
 verbose: C: .........................................................
 verbose: C:     +  Private class: set_by_expression
 verbose: C:     +  Private class: set_by_if_and_expression
 verbose: Skipping promise 'unset_by_if', for if/ifvarclass is not in scope
 verbose: C: .........................................................
 verbose: C: BEGIN classes / conditions (pass 2)
[root@hub tmp]#

As illustrated above, a class whose "expression" is false is not even mentioned in the verbose output, whereas a class whose "expression" is true but whose "if" is false *is* shown.

Perhaps the handling should be the same?  (This would be a special case for the "if" attribute for classes promises only, to make it behave the same as an "expression" attribute.)

--Mike Weilgart

[Kristian Amlie]

On 14. mai 2016 01:30, mike.w...@verticalsysadmin.com wrote:
> One further thought on this:
>
> Looking down the road a bit, we may want to consider handling the "if"
> attribute of a classes promise the same way as the "expression"
> attribute, or vice versa.
>
> I would imagine that newcomers to CFEngine will have no particular
> reason to ever use the "expression" attribute at all, when the default
> expression is "any" and they can express the more complex conditionals
> they will need with an "if" attribute (or an "and" attribute, or "or"
> attribute, etc.) without ever learning "expression."

Good point, I never even considered that these two are essentially doing
exactly the same thing. It would be possible to deprecate "expression"
entirely, and it wouldn't even require introducing anything new.

> Currently, the verbose output based on "expression" is different from
> that based on "if" (example shown is running 3.7.1):

Under the hood, the execution paths are different, so this is not
surprising. I wouldn't be surprised if there are other, subtle
differences as well, but this requires more investigation.

--
Kristian