The Curry Integrated Development EnviRonment
(Version of August 9, 2004)
CIDER is a graphical programming and development environment for
the multi-paradigm declarative language
CIDER is intended as a platform to integrate various
tools for analyzing and debugging Curry programs.
Currently, CIDER consists of
CIDER is completely implemented in Curry so that it is fairly
easy to extend CIDER by new analysis tools: a new analysis can be integrated
by providing a function which takes a program as input and produces
a list of analysis results, where each analysis result
is a pair consisting of a function name and the associated
result for analysing this function.
If an analysis is implemented in this way, only one line of code
must be added in the implementation of CIDER to provide
a graphical interface for this new analysis.
Note that Curry's lazy evaluation is quite useful here:
although an analysis is defined on an entire program, only those
parts are actually analysed that are relevant for showing
the currently requested result.
- a program editor with the usual functionality,
- various tools for analyzing properties of functions
in Curry programs (types, overlapping definitions, complete definitions,
non-determinism, operational completeness, dependencies etc),
- a tool for drawing dependency graphs,
- a graphical debugger, i.e., a visualization of the evaluation
To get an impression of the use of CIDER, here is the main
window after starting CIDER and loading a program:
The main window in the middle is an editor window for editing
the current program.
On the left- and right-hand side, there is a list of the top-level functions
in the current file and a list of the currently available analysis tools,
respectively. After selecting a function and an analysis in the corresponding list boxes,
the function is analyzed and the analysis result is either shown in the bottom window
(if it is a textual result) or, if it is a graph,
it is visualized with the graph visualization tool
Currently, CIDER offers the following analysis tools
(which are useful but not very complex and mainly included for
For instance, the analysis Dependency Graph computes the following
visualization of the dependency graph for the function qsort
in the program shown above:
- Get Type: Compute the function's type.
- Overlapping Rules: Is the function defined by overlapping rules
that might cause non-deterministic evaluations even for ground expressions?
- Pattern Complete: Is the function completely defined,
i.e., reducible on all ground constructor terms?
- Pattern Matching: Shows the pattern matching behavior,
i.e., a definition of the function in form of case expressions.
- Solution Complete: Is the function able to compute all
solutions? (This is the case if this and all functions used in
derivations are flexible.)
- Set-Valued: Does the function might have more than one
result to a ground call (due to a non-deterministic definition)?
- Indeterminism: Does the function behave indeterministically,
i.e., has a time-dependent behavior (e.g., due to the use
of external communication)?
- Depends on: Call dependency, i.e., all functions that
might be called during the evaluation of a call to this function.
- Dependency Graph: Show the dependency graph for this function.
- Called By: Compute the list of all functions that call
this function in their defining rules.
- Dead Code: Compute the list of all top-level functions that
are not reachable from this function.
Finally, CIDER contains also a graphical debugger/tracer
to visualize the evaluation of expressions.
Currently, the debugger always starts with the evaluation
of the expression "main" w.r.t. the currently loaded program,
i.e., if one wants to visualize the evaluation of an expression
e, one has to add the definition "main = e"
to the current program. The debugger always shows the
expressions as trees although some parts of the expressions
are actually shared. If a shared subexpression is reduced,
all shared identical subexpressions are also reduced in the
same step in order to be conform with Curry's operational semantics.
The subexpression reduced in the next step (the next redex)
is always emphasized in red (similarly, a variable is emphasized
in red if it will be bound in the next step).
One can trace forward and backward through all evaluation
steps. Furthermore, one can also set a breakpoint to skip
larger parts of a computation. However, the evaluator
used by the debugger is not very fast since it is based
on a meta-evaluator for Curry programs implemented in Curry.
A snapshot of the debugger is shown in the following picture:
The implementation of CIDER is freely available.
The implementation consists of a collection of Curry modules
which are available as a gzipped tar file
(see the README file in the distribution for installation instructions).
Requirements for installing CIDER:
Since CIDER is implemented in Curry, it requires an installed
Curry system. The implementation uses various system libraries
(for distributed programming, GUI programming, etc)
which are available in the
Thus, you should have PAKCS (Version 1.6) installed in order
to compile CIDER. Since the implementation is mainly based
on the Tk library of PAKCS, you need also a
(including the windowing shell wish)
which can be downloaded
If you want to use the graph visualization tool, you need
also an installed daVinci
system which can be downloaded
Currently, there is no user manual for CIDER (we hope that its
use is self-explaining) but there are a few papers where you can
find more details about CIDER and its implementation.
- Short overview of CIDER
- This short description of a system demonstration of CIDER provides
an introduction into the main functionality of CIDER.
An Integrated Development Environment for
Declarative Multi-Paradigm Programming
- This paper describes the functionality of CIDER
and the main ideas behind the implementation of CIDER.
It also contains a short description how to extend the functionality
of CIDER (e.g., adding new program analyses).
Diploma thesis (in German)
This is a diploma thesis on CIDER, written by
(the main implementor of CIDER). This thesis
contains details about the design and implementation of CIDER.
Curry Homepage |
PAKCS Homepage |