[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More on the Basic Datatypes
Dear Peter,
thanks for your comments on our specification of the natural numbers.
After having thought about the points you have made, we have decided
to propose the following:
- The natural numbers (and also integers and rationals) will be
specified in a very simple, easily readable way. Even if this
does not follow an optimal exploitation of structure in all cases,
you have convinced us that readability is essential here.
The new specification Nat can be obtained unter
http://www.informatik.uni-bremen.de/cofi/CASL/lib/BD_Discussion.html
Note that Nat is now entirely self-contained, and PreNat (and
together with it the library PreNumbers) has vanished.
The reason is that numbers and algebra are no longer specified
in an interleaved way.
- The simple and structured datatypes, machine numbers and
number representations remain structured as they are. Compared to our
original numbers (which have used a deliberate interleaving between
numbers and algebra), they are of a different nature.
In particular, we believe that the structuring is very natural
here (e.g. List[Elem]) and thus can and should be shown
to the general audience.
- Therefore, "documentation views" are a useful supplement in any case
(and we are going to include the signatures plus some text as
important and useful explanation of the specifications),
but they should not replace the original specifications.
For demonstrational purposes, we have also put the flattened
version of our older Nat specification under the above URL,
and we think that they are not presentable as "standalone".
- The RelationsAndOrders and algebra libraries will be simplified
in the following way: all the Ext-versions of the specifications
(they contain derived operations for the respective algebraic
structure) are moved towards the end. This makes the first part
of these libraries more readable, while the second part can be
skipped at first reading. Moreover, besides the (paramtererized)
Ext-versions of the specifications, there are also non-parameterized
versions ("Rich-xxx"), which are easily obtained from the Ext-versions.
We believe that in this way, the basic datatypes become simple enough
to be usable for the non-specialist.
We would like the readers of this list to comment on this proposal
until
*** February 17th ***
since we are afterwards going to produce a new (hopefully nearly final)
version of the basic datatypes.
> DETAILS
>
> > In accordance with the suggestions made in Berlin,
> >
> > -> the only sorts are now Nat and Pos
> > -> partial functions are not totalized by subsorting any more.
>
> Is the latter simplification essential? Perhaps the provision of the
> totalized functions might be useful for standardizing the interfaces
> to CASL libraries from sub-languages?
No, it is not essential.
The objection raised in Berlin was that there should not be too many
overloaded profiles, and that subsorts should be used only as an
auxiliary device. Hence, in the new specifications, subsorting generally
plays a less prominent role (e.g. the generation of Nat does not involve
subsorts - this also leads to easier induction principles).
> > II. The Signature of Nat
> > ========================
> >
> > Sorts and subsorts:
> >
> > Nat >= Nat,Pos
> > Pos >= Pos
>
> It may be less confusing to present the above lines using CASL syntax.
We have adjusted the CATS output now to be in accordance with the CASL syntax.
> In the present version of Note L-12, the specs for Relations and
> Orders, PreNumbers, Algebra_I, and Numbers are found in separate
> libraries. Hypertext presentations of the libraries would allow
> users to go directly to referenced specs, but it might still be
> preferable to show users everything involved in the Nat spec in a
> single library (as the whole specification text referenced above
> indeed does itself).
Nat is now self-contained.
> > (In fact, unlike in the case of libraries for programming
> > languages, there is not much of a point in writing separate interface
> > definitions for specification libraries, since these would not really
> > look very different from the specifications themselves. [...].)
>
> I don't agree with the last sentence above. While writing a library
> that uses natural numbers, I'd reference the Nat spec, and bear the
> exact signature in mind - but I probably wouldn't want to even look at
> the axioms of Nat unless I was in doubt about the details of some
> particular operation or predicate. (Similarly for a generic spec: I'd
> want to see any axioms that the parameter spec might have, but
> probably not those specified in the body.) I found the signature
> listed under II above to be very helpful (read: essential) to get a
> real overview of the Nat spec - if it hadn't been provided, I'd have
> had to construct it for myself. I trust the authors to get the axioms
> right!
>
> A related point is that the development of further libraries may
> suggest changes in the modular structure of the present libraries -
> but such changes shouldn't affect the normal use of the present
> libraries.
Agreed. Thus we suggest to include, besides the original specifications,
also the signatures of specifications together with some explanatory
text as part of the publication of the basic datatypes in the CASL book.
Greetings,
Till, Markus, and Lutz
--
Till Mossakowski Phone: +49-421-218-4683, monday: +49-4252-1859
Dept. of Computer Science Fax: +49-421-218-3054
University of Bremen EMail: till@tzi.de
P.O.Box 330440, D-28334 Bremen WWW: http://www.informatik.uni-bremen.de/~till