Re: what sort of modules should be in clocc

[Marco A. <ma...@pa...>]

> Delivery-Date: Fri, 28 Jan 2000 21:23:42 +0100
> Date: Fri, 28 Jan 2000 12:23:56 -0800
> From: do...@co... (Don Cohen)
> Sender: clo...@li...
> X-Mailman-Version: 1.1
> Precedence: bulk
> List-Id:  <clocc-devel.lists.sourceforge.net>
> X-BeenThere: clo...@li...
> 
> I thought I saw defsystem doc in clocc before but now I don't.
> The source mentions
> ;;; For more information, see the documentation and examples in 
> ;;; lisp-utilities.ps.
> 
>   >  >> There are plenty of large projects with their own make programs.
>   > this is BAD.
> I disagree.  I think it's fine, for instance, that cl-http comes with
> its own build-cl-http function.  I don't know or care how it's
> implemented.

The question you should ask is "why does CL-HTTP comes with its own
build utilitiy?"

I believe the answer is "because up to now there was no acceptable and
docemented and stand-alone 'defsystem' running on all implementations.

I bet that the CL-HTTP developers would have chosen MK:DEFSYSTEM
(which does not have the pretense of "being better") had it been
"available" when they started (where "available" is to be intended in
a wide, license-encompassing, way).

> 
>   > there certainly IS a reason to drop your own home-grown tools when there
>   > is a standard one available which does the job better.
>   > do you make your car yourself or buy it from a well-established vendor?
> 
> Do you imagine that there is no cost to replacing something that
> already works?  Generally it takes a considerable effort even to
> determine that the replacement actually has all the capabilities that
> you need.  I don't know much about mk defsystem (other than what I've
> read in the last hour), but I'm willing to bet right now that it does
> not have all that I'd need to replace the homegrown defsystems that
> I've been maintaining.

Well, try MK:DEFSYSTEM out and make a list of missing features.  Then,
if you are still not satisfied advocate the use of your defsystem and
make it available as a standalone module.

     ...

> I think we can agree that this is a matter of degree.  The extreme
> that I fear is that I want a few functions from a few files, but these
> use other files and those use other files ...  I eventually get them
> all and then run into errors, e.g., maybe there are incompatibilities
> in the versions I got, or maybe there are incompatibilities between
> two different things I want to put together, or one of those things
> doesn't work cause of a bug in the lisp implementation I'm using.  Now
> I have to understand all that code.  Or more likely, I start from what
> I want and trace the dependencies and throw out all that I don't need
> in hopes that the errors come from stuff I didn't need anyway.

Allow me to say that this is the situation you run in C/C++
programming as well.  So you should not be terrified by it.  As far as
the CLOCC is concerned I'd hope that the code appearing here would be
tested as much as possible on as many platforms as possible.  So, the
possibility to run into errors should be minimized.

Just to make an example.  I was fooling around with DEFSYSTEM on LWPC
and ACLPC (the free editions).  I ran in the following problems:

1 - COMPILE-FILE does not work on ACLPC Free (as it should be - and
    yes, I know of LOAD-COMPILED).
2 - EXCL:CHANGE-DIRECTORY does not change
    *DEFAULT-PATHNAMES-DEFAULTS*, so, doing (LOAD "filename.lisp")
    does not work, even if you used EXCL:CHANGE-DIRECTORY correctly.
3 - LWPC chokes on files containing the idiom

         (format t "this is a line ~
                    and this is another")

    when the original file was modified on a UN*X system.

What are you supposed to do in this case?  Write code that does not
use these fetures because it may cause problems to somebody wanting to
use your code? Or do you work around them?  I choose to work around
them and hope the the full code will be therefore more useful.

> You're right that I do not know about MK defsystem.  However, the
> comment below from the source suggests that this ability is not even 
> available.  I suspect this refers to modules within one system, and
> that such dependencies between parts of different systems is even
> further out of the question.

Logically "a system" should be standalone.  If your system depends on
another system, then this should mean that you are using the
"advertised interface" provied to you by the designer of the
system/library/whatever.

It simply a matter of granularity.  Somewhere/sometime, interfaces do
get setup.  At that point it is an all or nothing situation.  Or
better, it is not up to you to decide what comes inn or not.

When in Java you do

     import java.util.StringTokenizer;

you have no guarantee that you will not load much more than you
bargained for.  The same goes for systems define with mk:defsystem.

Having siad that, I am all for providing more complex dependencies
within the implementations.

> More to the point, though, even if you could do this, the dependencies
> are only among files, right?  Or is there a model of dependency among
> individual top level forms?  (We used to have something like this in
> a project I worked on, but I've never seen it anywhere else.)

You may ahev dependencies among "modules" (i.e. collections of
components, e.g. files).  It seems to me that you are wanting a very
fine grained dependency definition.  What is the "semantic" ground you
base this request?

> I worry that something I don't even use in bar.lsp will need something
> in another file, and so on, so that I end up getting way too much.

See my comment above about Java.

> ;;; Current dependencies are limited to siblings. Maybe we should allow
> ;;; nephews and uncles? So long as it is still a DAG, we can sort it.
> ;;; Answer: No. The current setup enforces a structure on the modularity.
> ;;; Otherwise, why should we have modules if we're going to ignore
> ;;; it?

This is a design choiche I am aware of.  As I said, more complex
dependencies may be worked in.  The only requirement I'd set up, is
that the semantic imposed should be "at higher level" than "let's have
dependencies among single functions".

Cheers


-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa