Conference heron::euro_swas_ai

116.0. "Market requirement survey for LISP" by BONNET::COUTIER () Wed Jun 28 1989 10:54

PLEASE FIND BELOW A LIST OF MARKET REQUIREMENTS FOR A WORLD-CLASS LISP,
    WRITTEN BY EPITEC. WOULD THOSE OF YOU INTERESTED IN THAT MATTER
    PROVIDE YOUR FEEBACK ON WHICH ITEMS YOU BELIEVE ARE CRITICAL AND
    WHICH ARE ONLY "NICE TO HAVE".
    
    YOU CAN REFER TO THESE ITEMS BY MENTIONING THE DIGIT AND THEN A
    LETTER a, b, c, etc.. (for example the third item under 4. - "How
    many of the Epitool features ... would be refered to as 4.c).
    
    ======================================================================== 
MAIN FEATURES.
 
1. It should be a full implementation of Common Lisp as defined by Steele,
   including new propositions about CLOS and errorsystem etc.
 
2. Properties of runtime features are more important than
   development features. For example if memory requirements could be
   decreased with 30%, would be more valuable than a great step
   forward in debugging tools and editors. This is because the Epitool
   customers only see the runtime features, it is mainly the Epitool
   developers that take advantage of development features.
 
3. The Lisp should exist on several hardware platforms including
   PCs, (from simple, cheap to powerful and expensive).
 
4. Lisp versions on different platforms should be highly compatible.
 
   Since Epitool is (and will be even more) placed on top of several
   subsystems, such as Lisp, graphics, databases, file systems etc,
   the issue of a portation of Epitool is quite complex.
 
   How many of the Epitool features should be available on the new
   hardware? What will the cost be of developing the parts which rely
   on the different subsystems?
 
   Compatibility is an area where it is easy to specify plans saying
   "yes it will contain all the features" and it can be very hard to
   keep the promises. Therefore compatibility often comes in small
   steps, so we (and others that build on top of lisps and other
   subsystems) often have to rely on plans for the development of the
   subsystems.
 
5. The Lisp should integrate well with graphics on all platforms.
 
   Graphics is more important than other subsystems because it is a
   very important part that all users need (even if they run on PC's)
   and it is also a very large part which requires much work. I think
   that we have invested more mantime on graphics than all the rest of
   Epitool.
 
 
RUNTIME FEATURES
 
1. memory requirements should be small
 
   Todays Epitool EXE is 10 MB! and that is far too much. Probably
   only a minor part of all the code that is there is used, I think
   that Epitool itself takes about 2 MB.
 
   Working set requirements is perhaps the most serious drawback for
   Lisp based systems.
 
   We would like that only the functions that really are called are
   included in the system build process. That can be determined at
   system build time. Alternatively there could be a good autoload
   feature. But it is important that the "granularity" of pieces that
   are included or not is small. If there are packages of several
   hundred functions that are included, probably everything has to be
   included.
 
2. speed
 
   Of course we would like as much speed as possible.
 
3. gc
 
   We would like the garbage collection to be as continous as
   possible. The new VAXLisp gc is a step in the right direction.
 
4. integration
 
   First of all there should be a basic level with call-in, call-out
   and good, complete and reliable lowlevel tools for integration.
   Data of all types that are handled by programming languages,
   adresses, and procedural arguments should be handled,
 
   Then, all kinds of systems that can be integrated is good as far as
   there is no penalty if it not used.
 
   Most important is graphics (se above), then comes databases and
   file systems and then other systems.
 
5. It is important to have a flexible editor, which is basically a
   text editor but is highly programmable and fast (at least in
   character operations).
 
DEVELOPMENT FEATURES
 
1. Performance measuring tools
 
   It is important to be able to tune the programs. It was a very
   tedious work to optimize the Epitool compiler and execution
   environment. Better time-analysis tools could have helped us a lot.
   It is hard to find out where a large complex system spends its
   time.
 
2. debugger, program analysis tools, cross referencing, smart editors etc.
 
   The best of this kind of tools can be found in Interlisp (and to
   some degree in Xerox Commonlisp), but it is not straightforward to
   integrate with Commonlisp since many things in the basic philosophy
   are different.
 
   It would however be good if common lisp designers and developers
   had used Interlisp for a while to find out how productive it is and
   then pick the best parts out of it.
 
3. editor
 
   Best of all is a structure editor such as the one found in Xerox
   Commonlisp. 
 
4. clos
 
   We have had no need for an object oriented kernel, since we did it
   ourselves from the beginning. But we could probably have used it to
   our advantage if it had been there when we started.
 
 
 
 
MISC (VAXlisp specific)
 
   A large percentage of all major problems users have with Epitool
   have to do with installation and parameter settings in order to get
   good performance.
 
   Many system-parameters (swapfile size, various quotas, working-set
   etc) are critical for the performance of the lisp system and VMS
   experts are needed for the lisp-based Epitool and its applications
   to run well. Most of our customers do not have these experts since
   they are applications people. The problems are even too difficult
   for our knowledge engineers and product development people, in
   spite of all their experience. It is also a problem for people in
   Digital.
 
   When setting VMS parameters the operating systems fault tolerence
   is extremely low. If something is set wrong the machine will be
   unstable or not run at all.
 
-------