🚀 go-pugleaf

In article <37695@uflorida.cis.ufl.edu>, bmr@buoy.cis.ufl.edu (Benedict Rafanello) writes:
> |> >>>  e) DEFINITION & IMPLEMENTATION merged.
> 
> |>  >>This was a really bad move.  Now you can't define the interface separately
> |>  >>and enforce it, and the "*" and "-" stuff is really kludgy, very atypical
> |>  >>of Wirth's work.  Even if you accept that merging the def and imp is good,
> |>  >>interface details like READONLY really deserve their own keywords.
> 
> |>  No, this is a good move.  The maintenance of only 1 file is a big
> |>  win.  If you are concerned about the definition being published with
> |>  the source, don't worry.  There is a `Browser' module which will
> |>  output a definition for a compiled module.  You can then ship the
> |>  defintion (sans comments, unless you provide them) with your object
> |>  modules.
> 
> If both the interface and the implementation are in one file, how do you
> tell when only the implementation was changed?  This is very important for
> large projects.  Some of the projects that I have been involved with contain
> more than a million lines of code.  These projects (done in Ada) would take
> several DAYS just to compile.  If the interface to a package was changed,
> we would have to go through that horrendous compile cycle whereas if just
> the implementation was changed, we only needed to relink.  How does Oberon
> handle this?
> 
> Ben

The Zurich Oberon compiler generates symbol files (interface definitions
for the compiler itself) like Modula-2 compilers for definition modules.
On compilation of a module, you may choose whether to recreate a
symbol file or not. If you don't recreate the symbol file but the
compiler detects differences between the new module and the old symbol
file, you get some nice error messages.

This, of course, makes compiling more difficult: usually you are trying
to compile without generating new symbol files. Only in case of error
messages, to try to recompile it with the \s flag.

Until now, I haven't detected any sufficient support for something like
make on UNIX-Systems, so it's a non-trivial task to compile greater
stuff under the Oberon-System. Please tell me if this has been changed
in the latest versions or if there is some work on this in progress.

Nevertheless, I still prefer the idea that I have a source file with
a time stamp which represents the interface. That's good for my makefiles
and my personal overview. A separately formatted and hand-written
definition module is a document which cannot be replaced by the
browser tool of the Zurich Oberon system.

-- 
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de