[Ecls-list] About possible projects [long]
Juan Jose Garcia Ripoll
worm at arrakis.es
Sat Oct 13 03:21:05 UTC 2001
I will try to answer all messages I have recieved both in and outside the
mailing list. There are many open paths in the development of ECLS. These
paths are not incompatible, and I will wellcome people wanting to work on
them. Some of the open projects, collected from previous messages and from my
1.- Interaction with emacs.
I had not thought about this before, but it must be pretty easy to tweak
ILISP to work with ECLS. I currently use bare naked emacs for that. Some
difficulties are related to the next point.
2.- On-line documentation.
ECLS' roots date back to KCL and one nasty feature is that property lists are
used for almost everything, including documentation and compiler properties.
As part of an incomplete process to remove this bug I dropped down support
for storing documentation associated to symbols, functions, etc.
Instead I just kept the help.doc file which plays the same role and can be
used with the #'help and #'describe functions. This help file is currently
maintained separately from the source code and it is probably out of date.
My idea is to take all the documentation from help.doc and put it back into
the source files *.lsp. ECLS should then have a help engine that
a) When loading a source file, stores documentation in hash tables.
b) When compiling a source file, stores documentation in a help file, to be
determined using a special proclamation.
Each time a file is recompiled, the associated help file should be updated
accordingly, without any user intervention.
The previous point could be achieved more easily if ECLS had some type of
persistence. The simplest way, and which could be first implemented, is some
sort of hashed text file in which objects are stored as text with a key of
arbitrary type. That would be enough for the help files.
Much more work would be required to have a type of database that would
preserve not only equality under #'equal, but also under #'eq. That is beyond
my current abilities and unless one finds a simple, slim implementation, it
should also be outside of the ECLS core.
ECoLisp had already a working implementation of threads. Support for this was
dropped by me from the very beginning, for no special reason other that it
was not a top priority and that I did not know whether ECLS was a feasible
Currently I am working again on reimplementing threads and I would like to
have something working by november. I am afraid I am probably the only person
who can do this because of the changes of call conventions that took place
between the first ECoLisp and the latest ECLS. However, once it works it
would be nice if somebody else could get involved in the testing and debuggin
5.- Interface to C.
This has the highest priority. Probably, the only advantages of ECLS with
respect to other lisps are ease of maintainability and extensibility. To this
respect ECLS should take the place of MzScheme in the scheme community and I
would like to come out with an interface to C which is simple enough to see
the first applications coming out.
The worst point here is finding a minimal set of functions and macros to get
people going. I know what I need, but probably *you* know better what
I mentioned the issue of namespaces. This can be problematic. ECLS uses
rather general names for functions. I mean, almost every basic function from
the HyperSpec has a corresponding function in C (just look at "external.h" to
get an idea). A simple fix would be using the "cl_" prefix for every
function. This should be about 1 month of one-man work.
6.- ANSI compatibility.
The main source of problems here is the LOOP macro. ECLS is shipped with the
old MIT LOOP system, which is pre-ANSI, but has a rather liberal license.
Therefore it does not support several key words and it does not support
desconstruction either. The problem with the newest Symbolic's LOOP is that
the license is incompatible with the LGPL license of ECLS.
The second missing point is the pretty printer. ECLS does not support the
pretty printing constructs in ANSI, nor the ~<~:> formatters of FORMAT.
CLOS should be basically complete, as far as PCL is. However I feel that the
metaobject protocol in PCL is too complex and things such as slot access and
generic functions can be optimized.
I am probably forgetting things.
7.- Third party libraries.
This largely depends on . It is probably good to try working on this to
find how ECLS should be improved.
8.- System builder.
Currently the main entry points are C::BUILD-ECLS and C::MAKE-LIBRARY (which
builds a static library). They are poorly documented but they are so small
that you can get an idea by inspecting "src/cmp/cmpmain.lsp". If anyone comes
out with a better interface --I mean a skeleton or draft--, we can discuss it
and implement it.
9.- Extensible streams.
You all should have noticed by now that the pathname systems of ECLS is
rather different from other lisps. The physical pathname in ECLS has the
Currently device must be either "file" or "" in all systems, although in
windows "a"-"z" are supported. Ideally the functions about streams and about
the file system should be made extensible by allowing other "devices", such
as "http", "ftp", etc. Even if these protocols are not in the core, it would
be very interesting to allow the user to teach ECLS about other means of
communication to the outside world.
10.- Graphical user interface.
If  is finished, it would be great to let ECLS know about graphics. I
dislike the CLX library, and I bet the future should be in first linking ECLS
with existing graphical user interfaces (wxWindows, gtk, qt, display
postscript?) and then trying to get it to work with CLIM. Indeed it should be
pretty straightforward project to get a ECLS window which is made of a simple
line of input with a larger window for text/graphical output, quite the LOGO
way. Other possibility is getting ECLS to work again with Tk, but the
existing interface (src/c/Tcl* etc) is not usable.
More information about the ecl-devel