Re: [CoFI] Comments on CASL v0.99 DRAFT

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

Dear all,

(This message comes a bit late because I re-wrote it.)

[Thanks - and it is indeed the last message in this round of
 comments.  --PDM] 

I have the following suggestion concering concrete syntax of IDs:
Disallow dots (.) in IDs. I.e. remove DOT-WORDS as an alternative
for TOKEN in appendix C.

The reason:
In a CASL extension dealing with higher-order parameterization,
it might be useful to use the dot notation as in OBJ3.
I do not have the time at the moment to think of all implications
of incorporating this into a CASL extension. But I know that dot
notation is used in such higher-order frameworks. For example,
for ASL+, have a look at David Aspinall's thesis, available at

        http://www.dcs.ed.ac.uk/home/da/
        
especially the examples at page 25 to 37.
I have appended a non-higher order OBJ3 example from the OBJ3 manual,
but there are also higher-order examples for OBJ3.
I am not advocating the approach of ASF+ or of the higher-order extension
of OBJ3 here, but these languages allow higher-order parameterization,
and both do use dot notation. I do not know whether a CASL extension with
higher-order parameterization would be able to avoid dot notation
in the same manner we have avoided it in the first-order case.

[It would be preferable to clarify that before deciding... --PDM]

The main reason why dots in identifiers are needed seems to be the LSL 
tupling construction, which introduces selectors like __.hd. But one 
could rename them to, say, __hd when translating LSL into CASL.

[The "l.hd" notation is also familiar to many programmers, in connection
 with selecting components of records or packages (e.g. in Ada and
 many other languages).  For some reason, the Clear/OBJ "dot-notation"
 is written the opposite way round: ID.SP rather than SP.ID .  Perhaps
 a higher-order extension of CASL might rectify that, and allow terms
 of the general form TERM.ID, where TERM might denote either a spec
 (name) or a value?  Then there might be no conflict...  --PDM]

Of course, one could (mis-)use compound ids for the dot notation,
like M[n] instead of M.n. Indeed, last year I sent some proposal for 
qualifying specs with names along these lines to cofi-language. But it 
was not taken into account (although it makes sense already in unextended
CASL), so the general line seems to be not to use compound ids for dot
notation.

[The "general line" adopted in CASL was not to use OBJ-like dot notation
 - period!  If we change that, we should certainly reconsider your
 previous (elegant and economical) proposal, which is archived at:
 http://www.brics.dk/Projects/CoFI/MailingLists/cofi-language/97/msg00051.html
--PDM]

Greetings,
Till

th TRIV is
   sort Elt .
endth


obj 2TUPLE[C1 :: TRIV, C2 :: TRIV] is
  sort 2Tuple
  op <<_;_>> : Elt.C1 Elt.C2 -> 2Tuple .
  op 1*_ : 2Tuple -> Elt.C1 .  
  op 2*_ : 2Tuple -> Elt.C2 .
  var E1 : Elt.C1 .
  var E2 : Elt.C2 .
  eq 1* << E1 ; E2 >> = E1 .
  eq 2* << E1 ; E2 >> = E2 .
endo