Bubbles_glow

≡ Literary Systems ≡

 
Corner_fold
  • Citation
  • Extension
  • Response
  • Comment
Hopo_catalog
Literary Systems
 
Flowchart_grey_24

Domain-Specific Languages

One of the most promising developments in programming today is the increasing use of domain-specific languages. DSLs are mini-languages designed for a particular problem, with all of their conventions and idioms created to make it easy to talk about the task at hand. They often originate as thought-experiments: Imagine that you had a language that was perfectly suited to describe the ideas that you are trying to get across. What would that language look like? How would its semantics work? At this point, the compromises begin. You take your dream language and try to map it onto a set of literary forms in an existing language, making it real, and, if it happens to be code, making it run.

With programming, what this often entails is treating the DSL code as a kind of data, analyzing it, and using it to generate the larger bodies of functional code that actually perform the work. All of the boilerplate syntax and setup is abstracted into the language, and suddenly you can speak fluently and constructively about the ideas. With traditional literature, DSLs are often developed of the course of immersive novels. At each turn of the page, the author builds up a back-story, psychological profiles of the characters, motifs, metaphors and symbolism, patterns of speech, forms that she can then call upon later with fluency.

Domain-specific languages also help authors write about new areas of experience. Often the language that one has ready-to-hand is misleading under changed circumstances. If you shift the isomorphisms that map from language onto the real world, without changing that language, then your intended meaning will often fall off the mark, still tinted by the habitual understanding of the words. In non-Euclidean geometry, for example, because the underlying axioms have changed, a "line" is not a line. At least, not any sort of line that we would recognize as such. A DSL can be an escape from getting trapped in the old isomorphisms.



 
Here's a bit of a DSL that I'm working on for doing context-free drawings. It's a series of rules, defined in terms of each other, which get executed probabilistically. Here, you see the seed rules, which determine the possible things that could happen at each step that "seed" is executed. In the first rule, you can see the seed draw a square, and then call itself with a slightly smaller size, slightly dimmer color, and a bit of rotation.
@tree = context_free do
  rule :seed do
    square
    seed :size => 0.985, 
	 :rotation => 30/size, 
	 :brightness => 0.9856
  end
  
  rule :seed, 0.1 do
    square
    seed :flip => true
  end
  
  rule :seed, 0.045 do
    square
    split do
      seed :flip => true
      rewind
      seed :size => 0.8, :flip => true
      rewind
      seed :rotation => rand(60)
    end
  end
end
The simple version of how it works is this: When you define those rules, in code, the Context-Free code grabs it as if it were data to be processed, generating code based on what it says.

In more depth, it works by saving each of those rules as blocks of code (or closures), and storing them away inside of a data structure. When the rule is called, the DSL probabilistically determines which block of code to run, and evaluates it in the context of the DSL object, so that all of the method calls end up going to the DSL, instead of the Sketch where it was originally written. The hooks for doing this in the first place are dynamically added to the Sketch when the Context-Free DSL is included.

*Whew.*