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.

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.

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.

I wouldn't call eLisp a DSL. True, it has a bunch of domain specific commands but is still a GPL (General Purpose Language).

That's pretty much like with JS which has DOM specific commands but can still be used for other stuff (actually eLisp was the role model for all those embedded scripting languages° - Brendan Eich was originally hired by Netscape to create a Scheme like language)

The best example for an (external) DSL is SQL. It is limited to a specialized domain, e.g. you will rarely see computer games realized entirely in SQL.

But if you are an SQL expert you can contribute to Perl, Python or PHP projects, without knowing much of the host language.

The case of this thread - Rex - is a configuration DSL realized "internally", i.e. by reusing language elements of the "host language" Perl. (SQL snippets are external strings)

You don't need to know much Perl to be able to use this DSL.(pretty much like SQL-expert can patch SQL code in a Perl project)

The advantage to JSON:

• to catch typos or grammatical errors. In JSON you'd need to write a parser which descends the data structure (Kind of reinventing a DTD). But Rex's DSL the commands must be predefined and can validate the input immediately
• you can extend this DSL to your needs by adding your own subs
• it's more expressive, because Perl offers much more syntactic sugar than nested hashes/arrays have

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

°) I only mentioned LISP because DSL's where invented there, especially with the use of reader macros* which bend the parser by overriding single symbols. For instance you can make LISP parse embedded JSON

*) not to be confused with LISP's syntactic macros or even C's preprocessor macros.

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.

Who defines the domain?

A lot of people are confused like that

Its in the name, javascript object notation

Data format or domain specific language?

format or language?

data or code?

Anyway you define it, any format/shape it takes, the monkey has to write the code

Totally!

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