Expression problem

The Expression Problem is a term used in discussing strengths and weaknesses of various programming paradigms and programming languages. The expression problem can treated as a use case in programming language design.

Philip Wadler coined the term:

The Expression Problem is a new name for an old problem. The goal is

to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts).

Wadler selected the term as a pun. On the one hand, the programmer is trying to "express" a solution to a problem. On the other hand, the standard illustrative example given is that of an interpreter for expressions in some simple calculator language.

The expression problem is also a fundamental problem in multi-dimensional Software Product Line design and in particular as an application (?) or special case(?) of FOSD Program Cubes.

News:

A modular solution of the expression problem was given by Lect.Drd. Dan Popa, from Bacau University during the summer of 2008. His idea have at least three important parts:

1)to produce a modular tree by using a sort of special functions called pseudoconstructors

2)to produce a modular language interpreter or a modular language evaluator using pseudoconstructors over monadic values instead of usual monadic semantics

3)to NOT use an interpret or an eval function but to make every expression an itself evaluator.

Basically, the main idea was to replace a typical case from the evaluator or interpreter which is written in Haskell as

do {vx <-interp x env;
    vy <-interp y env;
    return(vx +  vy); }:: M Float

by something very simple, a modular simple itself evaluator:

plus x y  =
do { vx <-x;
     vy <-y;
     return(vx +  vy); }:: M Float

supported by some definitions for numbers and classes of operations.Such functions can be spread in various modules.

As a result,an interpreter or an evaluator can be built by simply imported all the required modules in a main client module (program.)

In the figure above you may see GHCI including the modules and being able to evaluate an abstract syntax tree which is built using pseudoconstructors. Note the fact that pseudoconstructors did not use Capitals as the usual constructors from the data declaration.

References

• Direct modular evaluation of expressions using the monads and type classes in Haskell by DAN V. POPA ; UNIVERSITATEA DIN BACĂU ;STUDII ŞI CERCETĂRI ŞTIINŢIFICE ;Seria: MATEMATICĂ ; Nr. 18 (2008), pag. 233 – 248
• Home Page of Dan Popa - The User:Ha$kell
• Applications of FOSD Program Cubes
• Generic Programming