The features of ASF+SDF that have been left out of CASL mainly concern lexical syntax and parsing.
These features are primarily of use when specifying the exact concrete syntax of existing languages. This was not regarded as a requirement for a general-purpose specification language for software, since the notation is here chosen by the specifier.
CASL does not allow the specification of lexical syntax rules for literal constants, nor for declared variables.
The lack of lexical syntax in CASL precludes declaring the conventional
notation for input of character strings, "..." (although display
annotations should allow such notation to be used when formatting CASL
specifications). Standard numerical notation for integer and real numerical
constants can be declared in CASL, albeit somewhat tediously.
In CASL each variable has to be declared explicitly. It is not possible to declare an infinite family of variables of the same form, as one can in ASF+SDF. Since variables are never exported from a specification (module) in CASL, this omission does not seem to be particularly significant.
CASL does not allow variable declarations to be exported.
This restriction reflects the semantics of CASL specifications (variables are not included in signatures), as well as the conventional treatment of scopes of variables in algebraic specifications.
CASL does not provide built-in list structures.
The list structures provided in ASF+SDF allow the declaration of operations with arbitrary numbers of arguments. Such operations are particularly useful when specifying the concrete syntax of existing languages, but they do not seem to be needed when specifying software, so they have been excluded from CASL, in the interests of simplicity. ASF+SDF specifications that exploit list structures will require auxiliary sorts and operations for lists when translated to CASL.
CASL does not allow the specification of priority or associativity for functions.
The CASL concrete syntax (tentatively) adopts a fixed priority scheme for user-declared operations: the infix operations have the lowest priority, then come the prefix operations, and finally the postfix operations. Moreover, infix operations always associate to the left. This would be inadequate for reflecting the concrete syntax of existing languages, but seems to be a reasonable compromise in a software specification language, since it is easy to remember and requires rather few additional parentheses for disambiguation in typical axioms.
CASL does not distinguish functions used for bracketing.
CASL provides ordinary parentheses for use in grouping.
CASL does not provide "otherwise" equations.
Such equations, which cater concisely for default cases, seem closely linked to assumptions of initial semantics and term rewriting implementation for ASF+SDF, which do not apply to CASL.
CASL does not allow cyclic module imports.
This unusual feature of ASF+SDF can indeed be useful, for instance when dividing a context-free grammar for the syntax of a programming language into modules--although the cycles can always be eliminated at the expense of introducing some auxiliary modules. The designers of CASL were unable to give a satisfactory semantics for cyclic references between CASL specifications, due primarily to complications caused by the presence of translation and instantiation--hence the restriction.
CASL could be extended with some of the above features.
Recalling that CASL is intended as the basis for extensions and restrictions, one might consider providing an extension of CASL including the above-mentioned features. One could also provide the restriction of CASL to the features that it shares with ASF+SDF. A combination of extension and restriction of CASL would be needed to provide a language in the CASL family with exactly the features of ASF+SDF.