Curry Analysis Server System
Introduction
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.
Installation
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.
Usage
The analysis results computed by CASS can be accessed in various ways:
Batch mode
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):
> cass Groundness rev
rev.append ground if arguments [1,2] are ground
rev.main always ground result
rev.rev ground if argument 1 is groundAPI mode
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 cass)
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.
Server mode
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.
Server Protocol
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>
StopServerThe 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 CurryTermThe command 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 AnalyzeModule, whereas 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.
Further Information
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).