Expression Problemとは - goo Wikipedia (ウィキペディア)

Expression Problem

From Wikipedia, the free encyclopedia

Jump to:navigation, search

This article needs attention from an expert on the subject. See the talk page for details. WikiProject Computer science or the Computer science Portal may be able to help recruit an expert. (May 2009)

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.^[1] ^[2] ^[3] ^[4] ^[5]

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). ^[6]

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 has at least three important parts:

to produce a modular tree by using a sort of special functions called pseudoconstructors
to produce a modular language interpreter or a modular language evaluator using pseudoconstructors over monadic values instead of usual monadic semantics
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.

This article does not cite any references or sources.
Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (July 2009)