Quite why are you evaluating random code for configuration – doesn’t ruby have decent support for configuration files?

I replied before about this – the example you give is so unhelpful that I don’t see any case at all for what you’re going on about.

In my experience the occasions where you want some kind of ‘quick and dirty on the fly evaluated user input’ that you call a DSL, are exactly the times when you have a domain specific problem that a domain specific API should handle well with a proper parser.

For example in my work I handle human and computer created data feeds from Air Traffic services, The Met Office, US DoD, ICAO, etc, all of this data is parsed properly through a lexer with validation, edge case handling, and then fed into the system through the same clear and documented OO API that it will be retrieved through.

I’m trying but failing to see a good scenario for what you’re proposing – a good DSL is very hard to create, not technically but through the difficulty of the design decisions – the implementation in any language is the most trivial part – perhaps the reason we don’t use Quick/Dirty Pseudo-DSL like Ruby programmers is because many of us know that a better solution to the problem is usually available and done properly on CPAN or requires up front design time in doing it right (which rules out a DSL in 99.9% of cases).

That being said, it really sounds like you and I don’t have a significant difference of opinion here once we recognize that we’re using different definitions for similar terms, hence the disconnect.

I agree. Thanks!

While I like to promote the use of DSLs via string eval, I would not use it for any of the above examples that you present where a lexer and parser would be superior (further affirming your point that we agree on a lot). Your point about taking data in different formats is not one I considered, but I would not trust externally submitted data enough to pass to eval anyway.

I have never considered a situation where a parser might be taking input from any one of several lexers. Mine have always been married in a way because I was focused on one type of input. Nifty idea for me to churn on!

Do not use language-powered DSLs when writing a parser is clearly superior, such as when the input cannot be trusted.

This is perhaps one of the most significant issues I have with a “language-powered DSL” (a.k.a., fluent interfaces). If there’s even the slightest danger of untrusted input, then I strongly object to them. However, people will disagree as to what constitutes “untrusted input”. To my mind, this means any code coming from outside of the program, even it’s just a simple file that someone down in accounting can edit. I may be overly paranoid on this point, however.

More importantly, the who concept of fluid interface is just good programming. It’s a difficult skill to develop. That some people refer to these as DSLs where others do not makes a lot of the point moot. In Perl’s case, we do have a string eval which does this, but if implemented incorrectly, can lose some context (I’d love to easily be able to run an eval against a higher stack frame).

For myself, I distinguish between fluent interfaces and DSLs because the former, as mentioned, is just good programming and is not restricted to a problem domain while the latter is harder to implement, tends to be more restricted, but offers a greater expressiveness if suitably done. Plus, by separating the lexing and parsing, you can gain a lot of flexibility if someone needs to submit their data in an XML format but your DSL is natural language. Just write a separate lexer and use the same grammar! The decoupling of these steps is trivial and since Perl is so powerful when it comes to text manipulation, it’s well-suited for this.

That being said, it really sounds like you and I don’t have a significant difference of opinion here once we recognize that we’re using different definitions for similar terms, hence the disconnect.

(And I really wish you had a preview button here