[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Aug 13 13:37:24 1993 
Subject:Re: fourth/fifth generation languages? 
From:Robin Popplestone 
Volume-ID:930813.01 

> The projects and products that seem to be designed for maximum time
> saving seem to be those that are combine creation of the core code in an
> efficient 3GL (more and more C++) with most of the functionality in a 4GL.

I would certainly agree with this except that in my experience C is infinitely
preferable to C++ for this purpose. This is primarily because C++ tries to
do the things that the (so called) 4GL does, but does them wrong. Good systems
have been built this way (e.g. ACIS) but they depend on implementing the 4GL
in C++. C++ has a lot of hidden apparatus (extra arguments to member
functions, funny link names, method dispatch tables) over which it is easy to
trip, and moreover different implementations of C++ will trip over each other
- essentially they are *not* link compatible.  And suppose you want to combine
two pieces of commercially available software, supplied only as object code,
and generated by different compilers...

C by contrast behaves in a simple, easily understood way, that can readily be
interfaced to. I want it for the inner loops of my applications, to make up
for the performance deficiencies of current ICG's.

As an instance of a framework for supporting this kind of application within
Unix (and VMS), the POPLOG system, developed at Sussex University under the
direction of Aaron Sloman, offers:

Incremental Code Generation (ICG): POPLOG provides a *Virtual Machine(VM)*, in
effect a set of functions which
    (a) commence the creation of a new block of native code.
    (b) plant instructions into this code block
    (c) complete the code block.
Code block creation can be nested, with *proper* handling of free variables
(i.e. unlike the kludges that languages like Pascal have, and avoiding the
abdication of C). The VM model is a stack machine, but some optimisation is
performed to get a tolerably efficient match to real machines. (Native code
is machine code, but constrained by the requirements of garbage collection
etc).

Parser generator: The next release of POPLOG will contain a parser-generator
of the Yacc kind. (Personally I have long used one of my own, and Prolog
users have their own ..)

Languages provided as standard are: Common LISP, POP-11, Prolog and SML.

Garbage Collection: Fully automatic storage management is an essential for
proper software engineering. What is contentious is whether a tagged or
untagged approach is adopted. In general, parametric polymorphism demands that
some global way of indicating the type of some data is required. POPLOG adopts
a minimal tagging convention, where pointers are untagged, so that they
be passed direct to C, but (short) integers and floats are tagged in the ls.
two bits, so that conversion is required. Within a data-structure, POPLOG
supports non-tagged representations if required, so that it is easy to use
data-structures that are identical to those of C.

But compatibility with malloc is needed: Garbage collectors move objects
around. This avoids problems arising from store fragmentation - gets better
cache localisation, for example. However you cannot give such an object
to a non-native function, at least not if it is going to do anything other
than perform a computation on it and then forget about it, since the garbage
collector may move it and not know to tell the non-native that it has done it.
Poplog provides an ability to create static objects that is orthogonal to
other attributes of an object.

Incremental Linking: being able to load non-native code into the environment,
test it out, and reload if necessary. This is particularly useful where the
non-native code is well debugged and there is a lot of it, e.g. X-widgets (at
least in theory - not all widget sets are bug free).


                       =========================

HOWEVER ONE COULD ENVISAGE IMPROVEMENTS

(a) It would be comparatively easy to do a C-subset in POPLOG. Nobody has,
tho' I got my class in UMASS to do a feasibility demo. A full C, generating VM
code would be possible, but possibly not what one wants, because pointer
arithmetic could only be compatible with the garbage collector if pointers
were represented by complex objects (base pointer+offset).

(b) Poplog (like the LISP machines) uses an in-process editor, VED. This is
fine for the safe use of native languages. It has snags when you import C,
since your edit buffers are sitting there naked... I have not in fact
suffered more than minor inconvenience from this, but an out-of-process editor
like Gnu Emacs might be preferred.

(c) Debugging of non-native code: Poplog does not have built-in support for
symbolic debugging of non-native code. When non-native code is imported in
small chunks, this is not too problematic.

(d) The VM model does not support light-weight continuations, largely because
of the need to support dynamic local variables in POP-11 and special variables
in LISP. It is possible to envisage supporting light-weight continuations
*just* for the more modern languages.

(e) Keeping more description around would allow less tagging. In particular,
it would be useful if procedure activation records were less constrained
by tagging requirements.


Robin Popplestone.