Home | About | Partners | Contact Us

SourceForge Logo

Quick Links
Building XL
XL Mailing List

Understanding XL
Conceptual overview
XL examples
Inside XL
Concept Programming

In depth
Browse GIT
SourceForge Info

Other projects
GNU Project
The Mozart Project

XLR: Extensible Language and Runtime

The art of turning ideas into code

The Concept Programming Development Process

Prev: What is a concept?


Next: Concept Programming Metrics

The Concept Programming development process consists in the following steps

  1. Identify the application domain and the problem to solve. This defines the problem space for your program or software component.
  2. Identify in the problem space the individual concepts, in other words the aspects of the problem space that actually matter to the program and will need to be represented in the code.
  3. Identify the behavior of individual concepts and relationships between concepts.
  4. For each concept, define a code notation, if possible similar to the usual notation for the concept.
  5. Find a technology that can be used to represent that notation. Choose standard technologies whenever that is possible and the notation makes sense (function, operator, object, tasks, generic entity, etc).
  6. If no standard notation is appropriate, define and implement a specific language extension that represents the concept well.
  7. Verify that the selected representations preserves in the code the behavior and relationships between concepts identified above as much as possible. There will be differences, but minimizing them is a worthy objective.

These steps apply at any level in the design, from the top-level application design (where concepts model interaction between large components) down to the bits and bytes constituting each individual component (where concepts might represent individual machine instructions).

For instance, they can be illustrated on XL as a whole.

  1. The problem space for XL is defined in the Concepts section of this web site.
  2. The specific concepts that were isolated to address the problem are described in the Inside XL section.
  3. Relationship between concepts, for instance the relationship between successive source code characters, or the scope of variables (relationship between variables and blocks/procedures/modules), are largely imposed by existing practice in the field of programming languages.
  4. Notations for XL were inspired by either standard notation for non-programmers, existing practice in other languages or invented from scratch to fill a perceived gap.
  5. The technology for implementing most of these notations in the compiler itself is the core of the compiler, though some specific "standard" notations are implemented in the scanner in a more traditional way.
  6. The concept of translation as envisioned for XL needed a particular construct, the translation statements.
  7. The result looks like most other languages, even if the underpinning is very different. There are relatively few surprises for users of previous languages when learning the XL syntax or semantics. However, be aware that getting there took a surprisingly large number of iterations :-)

This process blends well with existing practice. Typically, the problem space would be identified during a requirements phase. The relationship between concepts and notations can be identified during the specification of the program or component. The implementation of the notation happens during early phases of the actual implementation, and can be refined as this implementation moves forward.

The correct application of this process can be evaluated using concept-programming metrics.

Prev: What is a concept?


Next: Concept Programming Metrics

Copyright 2008 Christophe de Dinechin (Blog)
E-mail: XL Mailing List (polluted by spam, unfortunately)