CASS is a tool in the PAKCS and KiCS2 distributions 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. 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 analysis results computed by CASS can be accessed in various ways:
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
> curry analyze 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
analyzeGeneric :: Analysis a -> String -> IO (Either (ProgInfo a) String)
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. The server mode of CASS is used in a recently developed 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
curry analyze --server [ -p <port> ]
where an optional port number for the communication can be provided. Otherwise, a free port number is chosen and shown. In the server mode, it 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:
error <error message>
if an execution error occured, or
ok <n> <result text>
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
<kind of analysis> <output type>
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.
StopServer terminates the CASS server.
For instance, if we start CASS by
cass --server -p 12345
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.
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 previous version of this paper has been presented at the 13th International Colloquium on Implementation of Constraint and Logic Programming Systems (CICLOPS 2013).