[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)