[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compilation units
Dear Frederic,
your question relates to the deeper issue of library management,
and associated annotations, which we discussed here recently.
In a larger library managed by resp. tools (e.g. INKA/VSE or UniForM
Workbench) one would like to represent each LIB-ITEM separately, with
links to other named LIB-ITEMs, as the structure prescribes.
On the other hand CASL clearly allows named libraries, so one would
assume (athough this is perhaps not clear) that a file could contain
a whole library.
In re-reading the text in the Summary, there is nothing conclusive
about this except that a syntax is given and a whole library (and not
a scpeification inside it) is given a version number etc. so it is
pretty clear that a file per library is intended.
Alternatively, the library structure could just reflect the usual
concept of a folder with a list (linearly ordered!) of LIB-ITEMs.
It would be better if it could be a set partially ordered by the links,
but that is perhaps for the future.
In any case, we need an annotation of the list (partially ordered set)
of LIB-ITEMs for the library, and each LIB-ITEM has its own separate
AS plus annotations. This is necessary (even for not so fancy library
managers) since we do not want to download the whole library in a
distributed situation, just the LIB-ITEMs we need. Hence a different
structure (see above) might be better.
Thus my conclusion is:
At the moment, the root of the concrete syntax is undoubtedly LIB-DEFN.
There is a need for an AS node LIB-DEFN as well, but the ASs for the
individual LIB-ITEMS should be accessible one by one; this is easier,
in a conventional file system, if there is one file each.
Frederic Voisin schrieb:
>
> Dear friends,
>
> 1.
> I have a doubt about the simplest unit(s) we have to compile - and therefore
> the label(s) of the roots of the abstract syntax trees that we have to produce
> (or to read for the forthcoming tools). For instance if a file contains
>
> spec fv = sort my_sort end
>
> What are we defining: a SPEC-DEFN or a LIB-ITEM
> What is the label of the root of its syntax tree ?
LIB-ITEM
>
> Is it a SPEC-DEFN or is it rather a LIB-ITEM vertex whose single child is the
> subtree labeled by SPEC_DEFN ?
LIB-ITEM, which contains other annotations than SPEC-DEFN (or does it not?)
>
> Or, to word it in a different way, what are the productions for the axiom
> of concrete grammar. The question come from the fact that we have
> a set of rules (Section C.2.4)
>
> LIB-ITEM ::= SPEC-DEFN | VIEW-DEFN | ...
>
> 2. Do we allow a file to contain more than one such unit (hence the
> output file will contain a sequence of independent such abstract trees)
The trees must be independent, whether better in one file or several is
a different matter (see above).
>
> Frederic
Best regards
Bernd
--
________________________________________________________________
Prof. Dr. Bernd Krieg-Brückner courier mail only:
Bremer Institut für Sichere Systeme MZH 8071
FB3 Mathematik und Informatik FB3
Universität Bremen Universität Bremen
Postfach 330 440 Bibliothekstr. 1
D-28334 Bremen D-28359 Bremen
Telefon: (+49) 421-218-3660 telefax: (+49) 421-218-3054
bkb@Informatik.Uni-Bremen.DE privat: (+49) 421-25-1024
http://www.informatik.uni-bremen.de/~bkb, ~agbkb
http://www.uni-bremen.de/~sppraum (Kognitive Robotik)