nysus has asked for the wisdom of the Perl Monks concerning the following question:

I've been studying the Rex module. Rex allows you to manage remote servers over ssh using a configuration file. It uses a crude "DSL," or "domain specific language" for adding tasks through a configuration file. Here's a sample of the configuration file:

set user => "root"; group "frontend" => "server1", "server2", "server3", "server4"; group "local" => "mango", "debian01"; desc "Show uptime"; task "uptime", group => "local", sub { run "uptime"; }; desc "Show free space"; task "show_disk_free", sub { run "df -h"; }; desc "Upload file"; task "upload", "mango", sub { upload "/tmp/test.txt", "/tmp/test.txt"; };

The idea behind this DSL is straightforward. Each keyword is a call to a function and the arguments are separated by commas. I'm not even sure if this is the true definition of a DSL but that's what they call it in their documentation.

Anyway, I've never seen anything like this before and I'm wondering if there are any advantages to this approach to a configuration file. Are there any big advantages/disadvantages to this approach? And why not just use something more universal like JSON? My experience with config files is limited to writing my own Simple::Config files and .ini files with Dist::Zilla. So I'm interested in learning more about best practices for setting up config files. Thanks.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

Replies are listed 'Best First'.
Re: Is use of a simple DSL for a configuration a good idea?
by LanX (Saint) on Oct 18, 2018 at 02:36 UTC
    IMHO this interpretation of nested function calls as "DSL" is connected with the rise of Ruby, and Rex was inspired by Puppet.

    The term was originally coined in LISP, where data and code are almost the same.

    But Ruby is monopolizing this somehow now and people tend to call any function calls without parens a DSL.

    > if there are any advantages to this approach to a configuration file.

    It has some advantages like

    • better expressiveness than nested data structures like json,
    • you can have immidiate validation when run
    • and its easier to extend with your own code.
    But this is far from the only possibility to create a DSL, defining a class allowing chained method calls is one of many.

    Martin Fowler's book is an interesting read about DSL, though it often shows his origins in statically typed languages.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

    update

    *) I couldn't find chromatic's original blog post anymore, but he commented once about the hype.

    1. Have you ever programmed in a language other than Ruby? (PHP and HTML don’t count.) If not, it’s a DSL.

    2. Is the defining syntactic feature that youÂ’ve cleverly left the parentheses off of a list of function arguments? If so, it’s a DSL.

    3. Is the code primarily a list of key-value pairs? Welcome to DSL Town, population you!

    5. Have you ever used the phrase "… and it reads just like English!” in seriousness? You’d better get to the hospital; you’re coming down with a case of the DSLs!

      I was thinking that using perl in a configuration file could be a pretty big security hole as it allows someone to basically run arbitrary perl code through the configuration file.

      $PM = "Perl Monk's";
      $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
      $nysus = $PM . ' ' . $MCF;
      Click here if you love Perl Monks

        yes, that's a limitation of most internal DSLs.*

        Perl has some means to disable/override built-ins but normally the possibility to extend the internal DSL is considered a feature.

        Just try to define a JSON format with the same flexibility and start hacking a DTD which is validating it, to see what I mean.

        In the end this might turn out to be the better approach but designing a DSL works out much faster and could be used as a preliminary step.

        Especially if the design needs to be adapted constantly you'll never reach the phase to finalize a JSON format.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        update

        *) in the case of Rex you are distributing centralized configs via SSH. But if the centralized server is compromised you are already in much deeper shit.

      Better expressiveness.. Immediate validation.. Easier to extend.. Yeah JSON sure sounds like a dsl

        Yeah JSON sure sounds like a dsl

        In my understanding is does not since JSON is not domain specific. Same thing with Lisp. Lisp is not a DSL, but Emacs Lisp is, since it's domain specific.

        Totally!

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Re: Is use of a simple DSL for a configuration a good idea?
by Anonymous Monk on Oct 18, 2018 at 01:03 UTC
    How do you suppose "JSON" and "simple DSL" differ? They don't really, its the same thing, a practice, a format...