[Ecls-list] About possible projects [long]

[Juan Jose Garcia Ripoll]

Hi,

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 
own wishes:

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.

3.- Persistence.

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.

4.- Threads.

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 
project yet.

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 
process.

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 
*others* need.

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 [5]. 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 
syntax

[device:][[//hostname]][/directory]*[filename][.filetype]

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 [5] 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.

Regards
	Juanjo

-- 
http://www.arrakis.es/~worm