[Ecls-list] About possible projects

[Alexander S A Kjeldaas]

[ I'm giving this thread a new subject since the original mail is
quite old and I don't like having active threads far down in my mailbox. ]

On Sat, Oct 13, 2001 at 12:01:25PM +0200, Juan Jose Garcia Ripoll wrote:
> 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:

[...]

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

Are you planning on implementing real thread support using a pthreads
library, a user-land threads implementation, or something else? The
threads support that I have seen documented in the manual looks like
user-land threads, but real thread support would be a _lot_ more
useful I think.

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

I think the namespace issue needs to be sorted out.  I am trying to
write a qt test program using a hacked ECL which compiles using g++,
but there are a few name collisions between the functions in
external.h and STL.  I have started to convert the names that collide
for me (alloc*, list, ...).  Also, a few functions collide with
reserved keywords in C++ (throw,...).

astor
-- 
Alexander Kjeldaas                Mail:  astor at fast.no