Cfengine 3 Syntax Part II

Mark Burgess was kind enough to respond to my earlier post about Cfengine syntax:

markburgess_osl: @saintaardvark (soothing) Syntax is definitely an acquired taste (re perl ;)). The list-ref prob can go away soon. Think doc not code 4 cf3

And then, via tweetsification, we were all like:

saintaardvark: .@markburgess_osl Heh, thanks for the reply -- I was going to ask you about this. Fair pt re: syntax being an acquired taste...[1/2]

saintaardvark: .@markburgess_osl ...but any chance the mess of brackets will be reduced? [2/2]

markburgess_osl: @saintaardvark trade one set of () for -> Don't see much point in that. $() has long precedence in sh / make etc. It delimits clearly in txt

saintaardvark: .@markburgessosl Fair enough, but I'm also thinking of eg "$(services.cfgfile[$(service)])": dollar bracket scopedot square dollar bracket

markburgess_osl: @saintaardvark I agree it's clumsy, but it's also an edge case. You rarely write this if you make good use of patterns. Perl also ugly here.

But this layout came from their own dang documentation! I feel like I'm stuck here:

• This config works fine for single-file config
• But there's lots of stuff that's not single-file
• Can't yet iterate over remote lists (though prob going away soon)
• So for now that leaves iterating over local lists
• Which seems to mean lots of duplication

[old entry recovered from backup!]

That last point: what I mean is that the whole appeal of that layout (pattern/whatever) was that you could just say fix_service('foo'), and The Right Thing(tm) would happen. Now I have to rethink this; it seems to mean either having lots of bundles like "fixntp", "fixautofs", etc -- with lots of sections like:

vars:
  SuSE::
    "files" slist => {"this", "that"};
  Centos::
    "files" string => "just_this";

...or else having separate "fix_service" bundles for each class. (Forgive me, I'm thinking about all this w/o having a Cf3 instance to play with in front of me.)

I'm trying not to sound whiny here; I'm grateful for Cf3, for the documentation (which is pretty extensive), and that Mark took the time to respond. But this is frustrating.