RE: [Cfengine-develop] Re: Homework

[Chris (Ducky) Chapin]

On Mon, 3 Mar 2003, Andrews, Martin wrote:

> It is all academic since I am generating my cfengine files now, but I found
> the perlisms noisy. Maybe since our audience is sysadmins and they are
> mostly fluent in perl it is okay, but it is adding a lot of punctuation.

I'm one of those mostly fluent in perl sysads. I like perl the way it is
(perl5) and like the direction of perl6. That said, the perl style of
excessive punctuation it's inappropriate for cfengine. Perl isn't
targeting to be a framework language, it's a general purpose language.

Sysads are intelligent folk for the most part - define a brand spanking
new language that fills one of their needs and they'd learn it.

Anyway, The syntax I do like is what we're all familiar with:

directive:
   class filter::
     directive-specific-command    directive args...
        extended data

Unfortunately, it's the directive stuff onward that tends to get unique.
The common syntax extends just to the class level. But, this is where a
plugin could define the inner syntax, supplying a parser callback to
cfengine for that block of text, or some such.

A thought that just popped into my head: Enough power in the parser to be
able to create custom directives inside the cf - a kind of shellcommands
on steroids =) I don't have any ideas on syntax for that, though. =(

> Maybe because of my recent efforts with pythin I was thinking that you would
> define a list with something like:
> 
> control:
>   myvals = [ a, b, c ]
> 
> And still reference it as plain
> 
> shellcommands:
>   "echo $(myvals)"

My take on lists was something like:

control:
   split = ( " " )
   myvals = Split(a b c)
   morevals = List( "var one", "var two", "var three" )

Same otherwise. The idea being a heavier use of functions to get the data
type you were after, pushing the burden out of the parser, keeping it
minimal.