Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need to develop a simple declarative language to drive an application. I have various computational modules, some of them depending on other modules which also need setup. The problem is that I don't know how to manipulate the keywords. I will explain myself with an example

Task optimize
Units meters
System {
   // input data

Optimizer {
     type Simplex
     convergenceCriteria 0.001

PointEvaluator {
     type MyEvaluatorTechnique
     convergenceCriteria = 0.1

this is a solution, which has header very generic entities which describe the meaning of each section, but I could also have sections that explicity concern specific techniques

Task {
     type optimize
     optimizer Simplex
Units meters
System {
   // input data

Simplex {
     convergenceCriteria 0.001
     PointEvaluator MyEvaluatorTechnique

MyEvaluatorTechnique {
     convergenceCriteria = 0.1

I would like to hear your opinion on which method may sound better in terms of design correctness, and pros and cons of both solutions. One thing I don't like in the first solution is, for example, the fact that depending on the type, I may have options that do not make sense for that specific type. In the second solution, however, I am setting up not the generic task (which then uses specific types of subsystem). Instead, I specify the specific subsystems performing the task.

share|improve this question

closed as primarily opinion-based by durron597, Snowman, MichaelT, Ixrec, ChrisF Sep 21 '15 at 16:34

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 4 down vote accepted

Designing DSL's is hard.

So hard, that I suggest that you avoid it until you are compelled to create the DSL.

My suggestion is this.

  1. Create a proper class hierarchy.

  2. Create pleasant, easy-to-use initializers and constants.

  3. Get things to work as simple object construction.

Later, after things work, and after you see what the DSL must express, consider designing a DSL.

Some class Definitions.

class  Task( object ):

class Optimizer( Task ):
    def __init__( self, optimizer ):

class Simplex( object ):
    def __init__( self, evaluator ):

class Evaluator( object ):
    def __init__( self, convergence ):

class MyEvaluatorTechnique( Evaluator ):

A Configuration

config = Optimizer( 
    MyEvaluatorTechnique( convergence=0.001 ) 

This avoids a lot of complexity of writing a parser and handling keywords. Instead, you use the parser for another language (i.e. Python or Java or Lua or something)

share|improve this answer
I read your blog post on this same topic. I did realize that declarative style is hard, and we are in fact probably planning to switch to an imperative style. For the moment, however, I must implement a declarative style. – Stefano Borini Feb 16 '11 at 17:08
+1 for Lua. This use case is more-or-less exactly what Lua was designed for from the ground up. That it is a pretty excellent and fast little language is a real bonus. – Adam Crossland Feb 16 '11 at 17:14
+1 for Lua idem. Even older versions, like Lua 4 could handle these type of requirements easy. – Machado Feb 16 '11 at 17:20
@Stefano Borini: This is declarative. – S.Lott Feb 16 '11 at 17:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.