Qualified specifications

[Till Mossakowski <till@informatik.uni-bremen.de>]

Dear friends,

1. Qualifying specs with their names
------------------------------------
Independently of the note of dissent L-3, I thought of the
following extension of CASL to simplify dealing with name
clashes in unions:

SPEC             ::= ... | QUALIFIED-SPEC
QUALIFIED-SPEC   ::= qualified-spec SPEC-NAME SPEC-NAME?

The effect of (qualified-spec spname) is a renaming
of all ids n in the specification to which spname refers
by ids of the form (compound-id spname n).
Thus in a union
union (qualified-spec spname1) (qualified-spec spname2) 
no name clashes can arise, we actually have a disjoint union.

This extension of CASL could coexist prefectly with
the suggestions of L-3, even if there are then
(1) qualifications in generics and (2) general qualifications
to be used everywhere, especially with UNIONs, and it
would be nice to unify both in some way. 

2. Naming of parameters of generic or architectural specs
---------------------------------------------------------
In case of generic or architectural specs with
two parameters of the same type (for example,
two partial orders PARTIAL_ORDER), with the
current proposal, one has to rename all the
symbols of one (or both) specification.
This is clumsy.

The note of dissent L-3 offers a partial solution to
this problem, namely, for the case of generic specs.
L-3 claims that the problem does not arise for architectural
specs. But consider a generic implementation of PAIRS
taking to *different* implementations of ELEM.

An alternative solution to the problem is to extend 
the above by:

QUALIFIED-SPEC   ::= qualified-spec SPEC-NAME SPEC-NAME?

The effect of (qualified-spec spname1 spname2) 
is a renaming of all ids n in the specification to which 
spname refers by ids of the form (compound-id spname2 n).

Example:
spec lexicographic = par (qualified-spec PARTIAL_ORDER x)
                         (qualified-spec PARTIAL_ORDER y)
...

We automatically would have the ids of the first
partial order prefixed with "x", while those
of the second prefixed with "y".

Thus the effect of named parameters would be simulated
in a purely syntactical way (yes I know, that is not the
best way of doing things, but I have the excuse that
generic specs and compound ids themselves have a rather 
syntactical flair).


As there is no dissent with the current language design,
I hope it is o.k. not to write a note of dissent in this case.

Greetings,
Till