From: Marco A. <ma...@pa...> - 2000-01-28 10:27:19
|
> Delivery-Date: Thu, 27 Jan 2000 23:47:25 +0100 > Date: Thu, 27 Jan 2000 14:47:07 -0800 > From: do...@co... (Don Cohen) > CC: st...@hi..., clo...@li... > Sender: clo...@li... > X-Mailman-Version: 1.1 > Precedence: bulk > List-Id: <clocc-devel.lists.sourceforge.net> > X-BeenThere: clo...@li... > > >> A comment on one of the requirements for code in this repository: > >> Self-contained, i.e. does not require packages not in this > >> repository, > >> I suggest that even reliance on this repository be minimized. > > NO WAY!!!! > then each and every package in CLOCC will reimplement the same stuff > over and over again. > I suggest mandatory support of defsystem by each package - this way we > can more or less be sure that people can get what they want to compile. > > I'm not arguing that there should be NO dependency. For instance, > anything that uses resources outside of lisp will probably use the > cross-implementation stuff. Also, cases where one facility clearly > depends on another are fine. I just don't want a tangle of packages > where in order to get one simple thing you end up getting 10 more that > seem to be unrelated. For instance, the record-calls package that I > just looked at contained a call to my pretty printer. I've removed > that and replaced it with a print-function parameter. I'd prefer all > your packages not to use things like your defcustom since it just > makes the reader go back and read a bunch of additional definitions. > If there are just a few small things then I'd rather have them > repeated than have to get an additional file. > > What does mandatory support of defsystem mean? You don't want any > file that can simply be loaded? MK:DEFSYSTEM is a 'make' for Common Lisp. It is one key piece of technology for the whole CL community and therefore it should be used by CL projects of a given size. Of course, "size does matter". :) If you have a single file utility, there is no real problem to provided it "as is", but for projects of larger size you need to have separate files, which means that you quickly end up needing a 'make', hence MK:DEFSYSTEM. For the CLOCC, I believe there is a consensus that your code should not come with a 'defsystem' different from MK:DEFSYSTEM, that's all. Not because MK:DEFSYSTEM is better than other ones, but because it reasonably runs on *most* CL implementations. > What's wrong with that? > > 4. I suggest GPL for "end user code" and LGP for what other programmers > will want to use. > will look ... > > >> A few other suggestions: > >> - Each piece of code, as much as possible should do one thing, so you > >> can take what you need without having to get a lot of extra stuff. > > do you want 100000 different files? :-) > memory is cheap. > > This is not a matter of memory. It's a matter of what the user of > this archive has to do. I want him to be able to read and understand > the code. If there's extra code that he doesn't need, well, ok, maybe > that doesn't do much harm, but if that code requires other packages he > has to either realize that he doesn't need those other packages and > modify the source to get rid of them, or he has to get these other > packages. That's what I really want to avoid. Let's take one egregious example: SPLIT-STRING or STRING-SPLIT, or whatever. Unfortunately this is not in CL and many packages (MK:DEFSYSTEM included) provide a special version of it, hence reinventing the wheel. Now the question is: how should CLOCC address this problem? What about MK:DEFSYSTEM. I'll tell you how I'd proceeed. I'd set up a package CL.EXT.STRINGS which contained extensions to the string handling stuff of CL, and put SPLIT-STRING in it. Then and only then, I would and could give up the special SPILT-STRING in MK:DEFSYSTEM. I.e. I am for Software Buddhism. The middle way (between Cathedral and Bazaar :) ) is best. The Romans also had the say "in medium stat virtus" (if my Latin is not failing me). :) Apart from that there is another thing I would like to stress out. Whatever ends up in CLOCC should strive to run in as many CL implementations as possible. 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 |