[Ecls-list] More changes

[Hannu Koivisto]

Rudi Schlatte <rschlatte at ist.tu-graz.ac.at> writes:

> I am trying to get clocc running, adding functionality to ecl where it
> is needed.

So you cannot replace clocc's use of mkdir with
ensure-directories-exist?  I do realize that
ensure-directories-exist and your mkdir are different but I find it
hard to believe that the difference matters to clocc.

Adding just the functionality one person needs here and there is
one approach and, sadly, often taken in open source projects.  I
think it easily leads to a convoluted codebase and bad interfaces.
Of course, I don't have a better code to offer here so I should
probably just shut up.  (Well, except that in this specific case
I'm suggesting ensure-directories-exist to be used/implemented
instead because eventually it needs to be added anyway for ANSI
compliance and I cannot see what particular value your mkdir offers
as an interface that ensure-directories-exist doesn't).

> So, suggestions, anybody?  (For an overview of the functions I'd like
> to add, look at the port library in clocc; mostly, directory-related
> filesystem ops and a bunch of networking support.)

For mkdir I suggest ensure-directories-exist.

Considering the other functions, I don't know what clocc needs and
I'm not going to take a look at it (I once did and I'm not really
anxious to touch it again), but if you need to add random OS
interface functions for it, I'd suggest you add them to clocc
itself as FFI definitions or at least put them to a separate
library in ECL that can be either included (--with-clocc-support)
or omitted when building.  This way clocc users can have their
cruft in one place and it doesn't affect those who don't want it.

>> (FWIW, I also strongly oppose that this kind of functions are
>> written in C and not in Lisp using FFI.)
> 
> On what grounds?  It seems to me that the difference between writing

You are working on an unneccessarily low abstraction level.  For
example, your interface glue probably needs to be rewritten
(instead of likely no changes or at most some automated code
transformations in Lisp) if someone decides to write an assembly
backend and use a copying GC.

> things for dpp and for ffi:defcbody is just the file extension and
> style of writing function headers.  Could you expand on this?

I didn't say anything about defcbody.  Indeed, that should not be
used unless there is a special need for such a low-level interface.
defentry (or was it called defcfun that you also refer to below) is
the one that should be used.  It may be a bit limited (or not work
at all as you noticed) at the moment but if you face such
limitations, it should be fixed instead of falling back to C glue.

> wacky source tree.  I'll try it out again and submit some
> documentation if I get it running.

That would be cool!

-- 
Hannu
Please don't send copies of list mail