Curry Analysis Server System
CASS (Curry Analysis Server System) is a tool for the analysis of Curry programs. CASS is generic so that various kinds of analyses (e.g., groundness, non-determinism, demanded arguments) can be easily integrated into CASS. In order to analyze larger applications consisting of dozens or hundreds of modules, CASS supports a modular and incremental analysis of programs. Moreover, it can be used by different programming tools, like documentation generators, analysis environments, program optimizers, as well as Eclipse-based development environments. For this purpose, CASS can also be invoked as a server system to get a language-independent access to its functionality. CASS is completely implemented Curry as a master/worker architecture to exploit parallel or distributed execution environments.
The current implementation of CASS is a package managed by the Curry Package Manager CPM. Thus, to install the newest version of CASS, use the following commands:
This downloads the newest package, compiles it, and places the executable
cass into the directory
<HOME>/.cpm/bin. Hence it is recommended to add this directory to your path in order to execute CASS as described below.
The analysis results computed by CASS can be accessed in various ways:
In order to show analysis results for a given module, one can use CASS in the batch mode. In this mode, CASS is started with an analysis name and the name of the module to be analyzed. Then this analysis is applied to the module and the results are printed. This mode is useful to get a quick access to analysis information so that one can experiment with different abstractions, fixpoint computations, etc. For instance, the following command analyzes the groundness behavior of operations of the module
rev (here we assume that CASS is installed as part of PAKCS or KiCS2 so that it is invoked via
> cass Groundness rev rev.append ground if arguments [1,2] are ground rev.main always ground result rev.rev ground if argument 1 is ground
If the analysis information should be used in an application implemented in Curry, the application program could use the CASS interface operations to start an analysis and use the computed results for further processing. For instance, CASS provides an operation (defined in the module
CASS.Server of the package
to apply an analysis (first argument) to some module (whose name is given in the second argument). The result is either the analysis information computed for this module or an error message in case of some execution error.
If the analysis results should be used in an application implemented in some language that does not have a direct interface to Curry, one can start CASS in a server mode. In this case, one can connect to CASS via some socket using a simple communication protocol that is specified in the documentation of CASS and also sketched below. For instance, the server mode of CASS is used in an experimental Eclipse plug-in for Curry (see this master thesis).
The following figure shows some uses of CASS.
To start CASS in the server mode, execute the command
where an optional port number for the communication can be provided. Otherwise, a free port number is chosen and shown. In the server mode, CASS understands the following commands:
GetAnalysis SetCurryPath <dir1>:<dir2>:... AnalyzeModule <kind of analysis> <output type> <module name> AnalyzeInterface <kind of analysis> <output type> <module name> AnalyzeFunction <kind of analysis> <output type> <module name> <function name> AnalyzeDataConstructor <kind of analysis> <output type> <module name> <constructor name> AnalyzeTypeConstructor <kind of analysis> <output type> <module name> <type name> StopServer
The answer to each request can have two formats:
if an execution error occurred, or
where the number
<n> is the number of lines of the result text. For instance, the answer to the command
GetAnalysis is a list of all available analyses. The list has the form
For instance, a communication could be:
> GetAnalysis < ok 5 < Deterministic CurryTerm < Deterministic Text < Deterministic XML < HigherOrder CurryTerm < DependsOn CurryTerm
SetCurryPath instructs CASS to use the given directories to search for modules to be analyzed. This is necessary since the CASS server might be started in a different location than its client.
Complete modules are analyzed by
AnalyzeInterface returns only the analysis information of exported entities. Furthermore, the analysis results of individual functions, data or type constructors are returned with the remaining analysis commands. Finally,
StopServer terminates the CASS server.
For instance, if we start CASS by
we can communicate with CASS as follows (user inputs are prefixed by
> telnet localhost 12345 Connected to localhost. > GetAnalysis ok 42 Overlapping XML Overlapping CurryTerm Overlapping Text Deterministic XML ... > AnalyzeModule Demand Text rev ok 3 rev.append demanded arguments: 1 rev.main no demanded arguments rev.rev demanded arguments: 1 > AnalyzeModule Demand CurryTerm rev ok 1 [(("rev","append"),"demanded arguments: 1"),(("rev","main"),"no demanded arguments"),(("rev","rev"),"demanded arguments: 1")] > StopServer ok 0 Connection closed by foreign host.
Web Demo Installation
If you want try CASS on simple programs via a web interface, you can use the Web Demo Installation of CASS.
More details about CASS and how to implement new analyses with CASS can be found in the following paper:
A Modular and Generic Analysis Server System for Functional Logic Programs (PEPM 2014, longer version)
A previous version of this paper has been presented at the 13th International Colloquium on Implementation of Constraint and Logic Programming Systems (CICLOPS 2013).