How do you organize your source code?

3264 views
Skip to first unread message

Peter Seibel

unread,
Apr 28, 2002, 3:34:58 PM4/28/02
to
Are there conventions for organizing Lisp source code? In particular
how do you break source code up by file and how do you organize your
files in a directory structure? Does it depend on what implementation
you are using or are the general standards?

I suppose I could just make something up that suits my needs but that
part of my brain has atrophied somewhat after several years of Java
programming. (Java's class and package system more or less mandates a
certain file organization.) And I'd rather not reinvent the wheel with
pointy corners.

-Peter

--
Peter Seibel
pe...@javamonkey.com

Joe Marshall

unread,
Apr 28, 2002, 3:47:46 PM4/28/02
to

"Peter Seibel" <pe...@javamonkey.com> wrote in message news:m2lmb76...@javamonkey.com...

> Are there conventions for organizing Lisp source code? In particular
> how do you break source code up by file and how do you organize your
> files in a directory structure? Does it depend on what implementation
> you are using or are the general standards?
>

I'm not aware of any standards, but I can describe what we did on our
last big project.

The code implemented a `change control' system that allowed you to model
changes. (Something like CVS on steroids.) There were several logical
divisions in the code: a `core' layer that implemented `versioned CLOS
classes', the `version management' layer that implemented `projects,
branches, and versions', the `file system' layer that used the versioned
CLOS and the version management layer to implement a version managed
file system model, a `server' layer that co-ordinated interaction between
the clients and the file system model, and a `utility' layer that contained
a whole bunch of stuff that was used everywhere and didn't `belong' to
any one subsystem.

Each layer had its own package and its own subdirectory under the
root. In addition, there were subdirectories for the build process,
for static web pages, and for the java client.

It was largely ad-hoc in that we didn't have an algorithm for
deciding what went there, but on the other hand it seemed logical
and obvious to us.

Marco Antoniotti

unread,
Apr 29, 2002, 11:17:05 AM4/29/02
to

Peter Seibel <pe...@javamonkey.com> writes:

IMHO Java does have some merit in mandating a certain file
organization.

Anyway, the way I do things follows in this pattern.

1 - set up a MK:DEFSYSTEM early
2 - have at least the following directory structure (IMHO single-file
systems are evil)

program.system
program-pkg.lisp
impl-dependent/
<vendor dependent code ges in here>
sub-module1/
...
sub-module2/

Of course you can add other amenities (shameless plug: CL-CONFIGURATION
from the CLOCC), and your revision control system of choice.

Having one CLOS class per file may or may not be good. It depends.

Cheers

--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

Joe Marshall

unread,
Apr 29, 2002, 2:55:41 PM4/29/02
to

"Marco Antoniotti" <mar...@cs.nyu.edu> wrote in message news:y6cu1pu...@octagon.mrl.nyu.edu...

>
> IMHO Java does have some merit in mandating a certain file
> organization.
>

The idea of storing your code in a hierarchical database is good.
Using the file system as a cheesy implementation of a hierarchical
database is bad.

Marco Antoniotti

unread,
Apr 29, 2002, 3:51:52 PM4/29/02
to

"Joe Marshall" <prunes...@attbi.com> writes:

Of course a hierarchical data base would be the best way to go. But
the Java solution is better than nothing.

Joe Marshall

unread,
Apr 30, 2002, 1:23:21 AM4/30/02
to

"Marco Antoniotti" <mar...@cs.nyu.edu> wrote in message news:y6c662a...@octagon.mrl.nyu.edu...

>
> "Joe Marshall" <prunes...@attbi.com> writes:
>
> > "Marco Antoniotti" <mar...@cs.nyu.edu> wrote in message news:y6cu1pu...@octagon.mrl.nyu.edu...
> > >
> > > IMHO Java does have some merit in mandating a certain file
> > > organization.
> > >
> >
> > The idea of storing your code in a hierarchical database is good.
> > Using the file system as a cheesy implementation of a hierarchical
> > database is bad.
>
> Of course a hierarchical data base would be the best way to go. But
> the Java solution is better than nothing.

I suppose it is better than no structure whatsoever, but it isn't a
good solution. The file system is for storing files (at least that's what
I hear. You'd think it'd be better at it.) The file system is
*far* too inflexible for configuration management.

It is a much better idea to let the file system store the files, and let
some other tool handle the configuration management.

Alain Picard

unread,
Apr 30, 2002, 5:26:56 AM4/30/02
to
"Joe Marshall" <prunes...@attbi.com> writes:

> I suppose it is better than no structure whatsoever, but it isn't a
> good solution. The file system is for storing files (at least that's what
> I hear. You'd think it'd be better at it.) The file system is
> *far* too inflexible for configuration management.

> It is a much better idea to let the file system store the files, and let
> some other tool handle the configuration management.

I don't understand your statement. Surely, the unix filesystem IS a
"hierarchical database"? But if you mean that tools like CVS make
moving files around directories a nightmare, then I'm all with you.

Marco Antoniotti

unread,
Apr 30, 2002, 10:40:24 AM4/30/02
to

Alain Picard <apicard+die...@optushome.com.au> writes:

On a side and OT. I used PRCS and it was heaven compared to CVS.

Marco Antoniotti

unread,
Apr 30, 2002, 10:43:59 AM4/30/02
to

"Joe Marshall" <prunes...@attbi.com> writes:

> "Marco Antoniotti" <mar...@cs.nyu.edu> wrote in message news:y6c662a...@octagon.mrl.nyu.edu...
...

> > Of course a hierarchical data base would be the best way to go. But
> > the Java solution is better than nothing.
>
> I suppose it is better than no structure whatsoever, but it isn't a
> good solution. The file system is for storing files (at least that's what
> I hear. You'd think it'd be better at it.) The file system is
> *far* too inflexible for configuration management.

I would tend to agree. I just do not have a clear picture of
"configuration management". My original remark was in the direction
of your first paragraph. The Java way is better than the
"nothing-way" of CL and C/C++. Adopting Java-like conventions makes
you life easier.

> It is a much better idea to let the file system store the files, and let
> some other tool handle the configuration management.

I have to agree here. However, you are adding an extra layer between
the programmer and the "host system" (quotes mandatory).

Joe Marshall

unread,
Apr 30, 2002, 1:04:55 PM4/30/02
to

"Marco Antoniotti" <mar...@cs.nyu.edu> wrote in message news:y6cu1pt...@octagon.mrl.nyu.edu...

>
> "Joe Marshall" <prunes...@attbi.com> writes:
>
> > "Marco Antoniotti" <mar...@cs.nyu.edu> wrote in message news:y6c662a...@octagon.mrl.nyu.edu...
> ...
>
> > > Of course a hierarchical data base would be the best way to go. But
> > > the Java solution is better than nothing.
> >
> > I suppose it is better than no structure whatsoever, but it isn't a
> > good solution. The file system is for storing files (at least that's what
> > I hear. You'd think it'd be better at it.) The file system is
> > *far* too inflexible for configuration management.
>
> I would tend to agree. I just do not have a clear picture of
> "configuration management". My original remark was in the direction
> of your first paragraph. The Java way is better than the
> "nothing-way" of CL and C/C++. Adopting Java-like conventions makes
> you life easier.

Oh sure, a Java-like convention can be a great aid, but having the software
tools rigidly *enforce* the convention is terrible.

Let me give you an example. Where I used to work we had a `java client'
for our software. This client came in two forms: a java application
that could be downloaded and run on the command line, and a java applet
that ran under the browser. Because our system did file-system
manipulation, the applet had to be `signed'. The java application did
not have to be signed as it didn't run in the `sandbox'.

There are two common conventions for enabling applets to run outside the
`sandbox': The Netscape Object Signing package, which is a set of class
files that allow your application to ask for permission as needed, and
`Authenticode' signing that enumerates the permissions the client needs.
There is a third convention for HotJava, but I don't know anything about it.

Since Java has an impoverished file system interface, we needed to not
only step `outside the sandbox' but also `outside of java'. (For
example, java.io.File has a canRead and a canWrite method for querying
the read-only state of the file, but there is no method for *modifying*
that state!) There are a couple of mechanisms for doing this, but for
the sake of portability we wanted to avoid using `native code' (we'd
have to maintain seperate C libraries for each platform, and the whole
point of using java was so that we wouldn't have to do this!) We opted
to use the ability of java to invoke other programs (like chmod) through the
java.lang.runtime exec method.

Microsoft's Java virtual machine has a `foreign function interface' that
makes it trivial to invoke native file system functions. A significant
number of users have this installed, so it made sense to wrap the
extended file system capabilities in an abstract class that would call
the native file system code if it were available and invoke commands
externally through the exec method otherwise. Since the Sun java machine
doesn't have an interface to the MS ffi, you can't load the code that
uses that ffi into a Sun Java. So the code has to use the java reflection
mechanism to load up the appropriate classes on the fly.

So ultimately, we had to deliver the client code in 4 formats:
Unsigned application for MS Java
Unsigned application for Sun Java
Netscape signed applet (Sun Java) (jar file)
MS signed applet (MS Java) (cab file)


Both the JAR and the CAB file format support hierarchical pathnames.
Because Java expects and requires hierarchical pathnames, the class
files *must* retain their relative position in the hierarchy. The
standard mechanisms for creating signed JAR and CAB files start at
a directory and bundle and sign everything underneath it.

We don't want to include the MS specific stuff in the Sun jar file,
nor do we want to include the Sun specific stuff in the MS cab file.
Since we had both applets and applications sharing components, we
wanted to partition the common code from the `wrapper'. Furthermore,
since some of the code was `third party' (the netscape javascript
classes), we wanted to keep that under a separate directory tree, too.

Symbolic links are problematic under windows. The solution is either
to replicate the entire directory structure for each `end product',
which would destroy the ability to share components, or put
everything into a single directory, which would make it difficult
to use the signing tools, add too much excess crap to each
application, and mingle our original code with third-party code.

For each configuration of the software, it was relatively easy to
describe what needed to go in the package, but the problem was
that Java wanted the file system layed out differently for each
configuration, and none of the layouts were compatible with our
own desired use of the file system.

(Our solution? Some hairy lisp code! We set up the directory
structure the way we wanted, then the lisp code would read a
configuration file that described the components that went into
a particular applet. The lisp code would compile the java code
and supply the appropriate classpath values to the command line
so the code would compile. Then it would create a temporary
directory hierarchy, copy the various class files to their correct
position within the hierarchy, and sign the directory. Logical
pathnames were a big win here.)


Peter Seibel

unread,
May 4, 2002, 9:59:05 PM5/4/02
to
Drew McDermott <drew.mc...@yale.edu> writes:

> Peter Seibel wrote:
>
> Are there conventions for organizing Lisp source code? In
> particular how do you break source code up by file and how do
> you organize your files in a directory structure? Does it
> depend on what implementation you are using or are the general
> standards?
>

> The key issues for organizing Lisp code (in my opinion) are:
>
> 1. How do you organize code into packages?
>
> 2. Where do you put datatype definitions (defstruct and defclass)?

[snip a bunch of good advice]

Thanks, that was just the kind of thing I was looking for. What about
macros? I read somewhere that it's a good idea/convention to put the
in a separate file. But it's also nice to keep them with the code that
uses them as they're likely to change together, at least early in
development. Any advice there?

-Peter

Erik Naggum

unread,
May 5, 2002, 8:45:20 AM5/5/02
to
* Drew McDermott
| <!doctype html public "-//w3c//dtd html 4.0 transitional//en">

Could you please post your messages in normal text format?
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.

70 percent of American adults do not understand the scientific process.

Edi Weitz

unread,
May 5, 2002, 1:00:58 PM5/5/02
to
Drew McDermott <drew.mc...@yale.edu> writes:

> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">

> <html>
> In response to complaints about HTML, I'm posting this again, hopefully
> in plain-text mode.
> <p>Peter Seibel wrote:
> <blockquote TYPE=CITE>Are there conventions for organizing Lisp source
> [...]

Nope, it's still HTML.

Edi.

Carl Gay

unread,
May 6, 2002, 10:12:13 AM5/6/02
to
Joe Marshall wrote:
>
> For each configuration of the software, it was relatively easy to
> describe what needed to go in the package, but the problem was
> that Java wanted the file system layed out differently for each
> configuration, and none of the layouts were compatible with our
> own desired use of the file system.
>
> (Our solution? Some hairy lisp code! We set up the directory
> structure the way we wanted, then the lisp code would read a
> configuration file that described the components that went into
> a particular applet. The lisp code would compile the java code
> and supply the appropriate classpath values to the command line
> so the code would compile. Then it would create a temporary
> directory hierarchy, copy the various class files to their correct
> position within the hierarchy, and sign the directory. Logical
> pathnames were a big win here.)

This is pretty much what Ant is for. (Though perhaps it didn't
have all the capabilities you needed at the time.)

Gisle Sælensminde

unread,
May 6, 2002, 3:37:09 PM5/6/02
to
In article <3CD56227...@yale.edu>, Drew McDermott wrote:
><p>Directory structure is not very important, and implementation isn't
> important either, except that different vendors have different 'defsystem's,
> so the tendency is to use the portable Kantrowitz defsystem if you want
> implementation-independence.

What is Kantrowitz defsystem?

--
Gisle Sælensminde ( gi...@ii.uib.no )

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)

Drew McDermott

unread,
May 6, 2002, 5:07:09 PM5/6/02
to

Help! I'm trapped in HTML! It's some kind of divine punishment for
reading newsgroups in Netscape and not Gnus.

-- Drew McDermott

Eduardo Muñoz

unread,
May 6, 2002, 5:15:49 PM5/6/02
to
Drew McDermott <drew.mc...@yale.edu> writes:

> Help! I'm trapped in HTML! It's some kind of divine punishment for
> reading newsgroups in Netscape and not Gnus.

You bet.
This message is fine but just because of the
mention to Gnus :)

--

Eduardo Muñoz

Arjun Ray

unread,
May 6, 2002, 5:52:06 PM5/6/02
to
In <3CD6F07D...@yale.edu>,
Drew McDermott <drew.mc...@yale.edu> wrote:

| Help! I'm trapped in HTML!

Pseudo-HTML, actually. A kind soul has gathered together this fine
resource to help victims, more of whom we can expect to see every day:

http://expita.com/nomime.html

| It's some kind of divine punishment for reading newsgroups in
| Netscape and not Gnus.

Or any competent newsreader (browser add-ons don't qualify):-)

ozan s yigit

unread,
May 6, 2002, 8:22:25 PM5/6/02
to
Drew McDermott <drew.mc...@yale.edu> writes:

> Help! I'm trapped in HTML! It's some kind of divine punishment for
> reading newsgroups in Netscape and not Gnus.

one alternative is to sign up with google and post from there;
the interface is simple, but threaded and more or less usable.
your posts will not get wrapped in html or other junk.

oz
--
you take a banana, you get a lunar landscape. -- j. van wijk

Joe Marshall

unread,
May 6, 2002, 10:01:08 PM5/6/02
to

"Carl Gay" <car...@attbi.com> wrote in message news:3CD673FA...@attbi.com...

From the Ant FAQ:
``Ant expects you to place your source files in a directory hierarchy
that mirrors your package hierarchy and to point Ant to the root of
this directory tree with the srcdir attribute.''

``Ant is not the only tool that expects a source-tree layout like this.''

And here is some Ant code:
<target name="cond" depends="cond-if,cond-else"/>

<target name="check-cond">
<condition property="cond-is-true">
<and>
<not>
<equals arg1="${prop1}" arg2="$${prop1}" />
</not>
<not>
<equals arg1="${prop2}" arg2="$${prop2}" />
</not>
<equals arg1="${prop3}" arg2="$${prop3}" />
</and>
</condition>
</target>

<target name="cond-if" depends="check-cond" if="cond-is-true">
<echo message="yes"/>
</target>

<target name="cond-else" depends="check-cond" unless="cond-is-true">
<echo message="no"/>
</target>

It can even generate DTD's for your build. Although,
``It may even be an invalid DTD. As Ant allows tasks writers to define
arbitrary elements, name collisions will happen quite frequently...''


I am not making this up.


Alain Picard

unread,
May 7, 2002, 7:28:24 AM5/7/02
to
"Joe Marshall" <prunes...@attbi.com> writes:

> And here is some Ant code:

[Amazing bogosity removed]

> I am not making this up.

I know. Incredible, isn't it? I don't like "me too" posts, but
Ant is _amazing_. I mean, _make_ is bad enough, but to re-invent
it so *badly* takes considerable talent. As if humans wanted
to program in XML!

Bring on a good DEFSYSTEM.


Daniel Barlow

unread,
May 7, 2002, 11:53:10 AM5/7/02
to
Alain Picard <apicard+die...@optushome.com.au> writes:

> Bring on a good DEFSYSTEM.

Define "good".

I like `asdf', but I would, I wrote it. There's also Marco's
mk-defsystem 4, which is billed as a complete rewrite of the current
version 3

- http://ww.telent.net/cliki/asdf
- http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/clocc/clocc/src/defsystem-4/README?rev=HEAD&content-type=text/vnd.viewcvs-markup


-dan

--

http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources

Marco Antoniotti

unread,
May 7, 2002, 11:34:28 AM5/7/02
to

Gisle Sælensminde <gi...@apal.ii.uib.no> writes:

> In article <3CD56227...@yale.edu>, Drew McDermott wrote:
> ><p>Directory structure is not very important, and implementation isn't
> > important either, except that different vendors have different 'defsystem's,
> > so the tendency is to use the portable Kantrowitz defsystem if you want
> > implementation-independence.
>
> What is Kantrowitz defsystem?

MK:DEFSYSTEM. You can find it in the CLOCC

http://sourceforge.net/projects/clocc/

there is a very recent file release for version 3.2 interim.

If you want you can access the CVS modules directly. The module for
version 3.x is 'defsystem-3.x'. If you are brave, check out the new
version 4.x: the CVS module is 'defsystem-4.x'.

Alain Picard

unread,
May 8, 2002, 5:53:02 AM5/8/02
to
Daniel Barlow <d...@telent.net> writes:

> Alain Picard <apicard+die...@optushome.com.au> writes:
>
> > Bring on a good DEFSYSTEM.
>
> Define "good".

* Anything with syntax I have a hope of understanding 6 months after I
write the rules.

* Anything which doesn't barf over itself if I put in a space instead of a tab

* Anything which can reason about multiple self-consistent plans and pick
an arbitrary one instead of just dying from indecision

Kent M Pitman

unread,
May 8, 2002, 10:28:33 AM5/8/02
to
Alain Picard <apicard+die...@optushome.com.au> writes:

> Daniel Barlow <d...@telent.net> writes:
>
> > Alain Picard <apicard+die...@optushome.com.au> writes:
> >
> > > Bring on a good DEFSYSTEM.
> >
> > Define "good".
>
> * Anything with syntax I have a hope of understanding 6 months
> after I write the rules.
>
> * Anything which doesn't barf over itself if I put in a space
> instead of a tab

[Heh. I think I heard that they realized at some point in the initial
deplyment of 'make' that the tab/space thing was a problem and wanted
to go back and fix it, but there were already 10 or 20 deployed users
(can't remember exactly, but the number was this order of magnitude)
and they didn't want to disrupt such a large number of people by
making a 'gratuitous' change. (My telling of the story is approximate
and from memory; if anyone has a pointer to a truer telling, they should
post it here.)]

> * Anything which can reason about multiple self-consistent plans
> and pick an arbitrary one instead of just dying from indecision

Can you elaborate on this last?

Have you read
http://world.std.com/~pitman/Papers/Large-Systems.html
and does its protocol-layer address this? Or are you saying you're
looking for a syntax?

My personal take (and why I wrote that paper) is that people need the
flexibility to disagree on syntax, and that that's why the protocol layer
is what should be made standard.

Also, while offering cross-references,
http://world.std.com/~pitman/CL/Issues/defsystem.html
contains the proposal that went before X3J13. This document
cross-references
http://world.std.com/~pitman/CL/Issues/defsystem-notes.html
which contains my personal notes on what the committee said about the
proposal at the time. [Not that my personal notes are an official
record or without bias, but they are at least contemporaneous accounts.]

Personally, I tried using MK:DEFSYSTEM about 8 months ago and found it
both full of bugs and lacking in support I needed, to the point that I
found it difficult to separate implementation from spec. I don't say this
to disparage the effort, but to note that there are probably multiple layers
at which this converstation must take place, and they need to be separated.
e.g., "Protocol layer vs syntax layer" is one layer (several sub-issues:
is separating these right? which layer should be standardized? what are the
appropriate qualities of the layers that are determined need standards?),
and "Specification vs Implementation" is another (making sure people don't
form opinions on the basis of a bug, since bugs are transient, or a lack
of featurism, since featurism can be added).

ozan s yigit

unread,
May 8, 2002, 3:14:27 PM5/8/02
to
Kent M Pitman <pit...@world.std.com> writes:

> My personal take (and why I wrote that paper) is that people need the
> flexibility to disagree on syntax, and that that's why the protocol layer
> is what should be made standard.

i suspect many people who actually thought about the issue would agree with
this. there was a little known attempt to extract out the guts of the make
engine so that other make-like tools could be written. i may be able to find
a reference. anyhow, even though make does not really scale well, and is
deficient in dependency and "build" expressiveness, many people insist on
putting more and more bletcherous features and structures on top of it. it
is amazing (and depressing) the type of contortions many software companies
get into just to get make to build their product. a good friend who has been
working on this topic (and arguing against make) since eighties calls this
"the tyranny of adequacy." his alternative system QEF [a free version was
included in an EUUG tape during late eighties under the name "dtree" - if
anyone has those tapes online, please let me know] is worth reading about
as well. some of his papers are in www.qef.com/html/additional.html

[online usenix proceedings have some papers on other make-like tools and
variants that are now lost in the mists of computing. that recent thing
called ant is not much better, IMO.]

oz
---
imagined forest -
we would be lost
without it. [oz/2002]


Kent M Pitman

unread,
May 8, 2002, 5:49:30 PM5/8/02
to
ozan s yigit <o...@blue.cs.yorku.ca> writes:

> Kent M Pitman <pit...@world.std.com> writes:
>
> > My personal take (and why I wrote that paper) is that people need the
> > flexibility to disagree on syntax, and that that's why the protocol layer
> > is what should be made standard.
>
> i suspect many people who actually thought about the issue would agree with
> this. there was a little known attempt to extract out the guts of the make
> engine so that other make-like tools could be written.

Maybe I'm misunderstanding, but if you read the paper, you'll see the
parts you're seeming to be talking about (the dependency processing engine)
are exactly NOT the part I'm talking about being protocol...

It is surely the case that 'make' has the deficiency of being very
single-purpose and the paper discusses his deficiency; that problem
is 'fixed' by just having one make-file per task, i suppose. but the
problem of not wanting to use a makefile is not as easily fixed if
the recipient is used to calling make. (I guess you could make a simple
make file that just had one task to do, but...)

The actual dependency stuff 'make' does is of no personal interest to
me at all, really. It's probably fine--maybe even quite helpful--but it's
'detail'.

What matters to me is just having a function like load-system or
print-system which is implemented any way someone wants.

In fact, the first thing _I_ would want to do if I had separate protocol
support is to make a version of 'make' that just used 'sh' instead
of all that baggage--that is, that just substituted an imperative
script for the complicated dependency junk.

>i may be able to find
> a reference. anyhow, even though make does not really scale well, and is
> deficient in dependency and "build" expressiveness, many people insist on
> putting more and more bletcherous features and structures on top of it. it
> is amazing (and depressing) the type of contortions many software companies
> get into just to get make to build their product. a good friend who has been
> working on this topic (and arguing against make) since eighties calls this
> "the tyranny of adequacy."

What a great term.

> his alternative system QEF [a free version was
> included in an EUUG tape during late eighties under the name "dtree" - if
> anyone has those tapes online, please let me know] is worth reading about
> as well. some of his papers are in www.qef.com/html/additional.html
>
> [online usenix proceedings have some papers on other make-like tools and
> variants that are now lost in the mists of computing. that recent thing
> called ant is not much better, IMO.]

No comment here.

ozan s yigit

unread,
May 8, 2002, 9:36:54 PM5/8/02
to
Kent M Pitman <pit...@world.std.com> writes:

? Maybe I'm misunderstanding, but if you read the paper, you'll see the
? parts you're seeming to be talking about (the dependency processing engine)
? are exactly NOT the part I'm talking about being protocol...

ok, i'll look at the paper again soon. i skimmed it a while ago.

? [...]

? In fact, the first thing _I_ would want to do if I had separate protocol
? support is to make a version of 'make' that just used 'sh' instead
? of all that baggage--that is, that just substituted an imperative
? script for the complicated dependency junk.

right, others have tried that sort of thing too, though i would have to
look around for references; one that jumps to mind is an inside-out tool:
a fully functional shell called mash (part of the inferno system) that can
load a make module to specify make-like rules for instance. i don't think
it can specify the relationships and dependencies in an imperative way,
though.

oz
---
the problem with being avant-garde is knowing who's putting on who. -- calvin

ozan s yigit

unread,
May 10, 2002, 10:04:10 AM5/10/02
to
Kent M Pitman <pit...@world.std.com> writes:

> [Heh. I think I heard that they realized at some point in the initial
> deplyment of 'make' that the tab/space thing was a problem and wanted
> to go back and fix it, but there were already 10 or 20 deployed users
> (can't remember exactly, but the number was this order of magnitude)
> and they didn't want to disrupt such a large number of people by
> making a 'gratuitous' change. (My telling of the story is approximate
> and from memory; if anyone has a pointer to a truer telling, they should
> post it here.)]

i checked with a few friends at the labs, but they could not recall
this story. did not check with feldman. make came out with v7. if the
deployed users had been different internal departments, with some time
invested in replacing many build scripts with make, the impact of the
'gratuitous' change may have been larger than the numbers suggest.
quarter of a century later, it is hard to tell...

oz
--
a technology is indistinguishable from
its implementation. -- marshall rose

Kent M Pitman

unread,
May 10, 2002, 10:25:41 AM5/10/02
to
ozan s yigit <o...@blue.cs.yorku.ca> writes:

Hmm. Curious. I'll see if I can track down a source at my end. I think I
remember who told me this. In any case, it'd be a shame if it weren't true.
So many of the best teaching tales turn out on close examination to be false.
Then again, I saw a nice talk on storytelling at the MIT biz school in which
the assertion was made that it is better to tell a good story than a true one.
(That flies against comp.lang.lisp tradition of demanding references when
people assert that the sky is blue, of course...)

ozan s yigit

unread,
May 10, 2002, 10:48:18 AM5/10/02
to
Kent M Pitman <pit...@world.std.com> writes:

> So many of the best teaching tales turn out on close examination to be false.

on the plus side, there are good, verifiable tales that are also useful
for teaching. evolution of scheme, common lisp, darwin awards... 8-)

oz
--
faster, better, cheaper, same old management - pick any three. -- h. spencer


Duane Rettig

unread,
May 10, 2002, 11:00:01 AM5/10/02
to
Kent M Pitman <pit...@world.std.com> writes:

> Hmm. Curious. I'll see if I can track down a source at my end. I think I
> remember who told me this. In any case, it'd be a shame if it weren't true.
> So many of the best teaching tales turn out on close examination to be false.
> Then again, I saw a nice talk on storytelling at the MIT biz school in which
> the assertion was made that it is better to tell a good story than a true one.

Stories do not have to be true to be useful. I doubt that any of Aesop's
tales were actually true, but they endure and provide insights.

> (That flies against comp.lang.lisp tradition of demanding references when
> people assert that the sky is blue, of course...)

Such a demand is usually a challenge - one that usually goes unanswered.
I personally prefer to research and _provide_ references. By, the way,
the sky is _not_ always blue.

References?

http://world.std.com/~mmcirvin/bluesky.html

:-)

--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)

ozan s yigit

unread,
May 10, 2002, 11:25:47 AM5/10/02
to
Duane Rettig <du...@franz.com> writes:

> I personally prefer to research and _provide_ references.

that is great, and appreciated. but what do you do when other people
casually claim things that you cannot with some reasonable effort find
any support for? if the claim is not explained in a way that indicates
expertise in the field, one would have to ask for references. i happen
to think that discussions in a usenet comp.group need to have somewhat
firmer grounding than the discussions about the nature of capricorn
vs aquarius. :)

oz [on usenet since 83]
---
the power of the unaided human mind is highly overrated. -- donald norman

Duane Rettig

unread,
May 10, 2002, 1:00:27 PM5/10/02
to

[sorry for being off-topic...]

ozan s yigit <o...@blue.cs.yorku.ca> writes:

> Duane Rettig <du...@franz.com> writes:
>
> > I personally prefer to research and _provide_ references.
>
> that is great, and appreciated. but what do you do when other people
> casually claim things that you cannot with some reasonable effort find
> any support for?

I think you partially answer your own question:

> if the claim is not explained in a way that indicates
> expertise in the field, one would have to ask for references.

Yes, the first step is to try to find references yourself, to honsestly
see if you can corroborate the other person's claim. If that fails,
the next step is to ask for references. However, it is always hard to
ask for references on the 'net, because people can't see your body
language, and what you might have meant as "I've searched all of the
places I know, and can't find the basis for your statement. Will you
help me?" ends up being taken as "You are absolutely wrong, and I
challenge you to find anything that proves your claim to be right". That
second interpretation is easier to make, because more often than not,
it was the intended meaning - as I said in my previous post, requests
for references are usually taken as a challenge. So if you really
intend the first meaning, you usually have to make it very clear,
sometimes including your reason for wanting the reference so that it
disarms a potentially defensive position which the other person has
taken.

The last step should never be to argue endlessly with the person. After
a reasonable number of exchanges, one must recognize the fact that
opinions will not be changed, and that it is not important who gets the
last word. As an argument goes on and on, there comes a point where
both sides look foolish, the one who is right and the one who is wrong
(and which one was that anyway? Who knows? Who cares? :-)

> i happen
> to think that discussions in a usenet comp.group need to have somewhat
> firmer grounding than the discussions about the nature of capricorn
> vs aquarius. :)

Yes, I agree, but the only person I can control on the net is myself.
So I recognize the fact that people will argue the nature of capricorn
vs aquarius, and strive not to contribute to it myself.

> oz [on usenet since 83]

Duane [on usenet since ... before 83]

Erik Naggum

unread,
May 10, 2002, 7:47:45 PM5/10/02
to
* ozan s yigit <o...@blue.cs.yorku.ca>

| i checked with a few friends at the labs, but they could not recall
| this story. did not check with feldman. make came out with v7. if the
| deployed users had been different internal departments, with some time
| invested in replacing many build scripts with make, the impact of the
| 'gratuitous' change may have been larger than the numbers suggest.
| quarter of a century later, it is hard to tell...

What a sad testament to the ability of Unix tools to process text. sed,
ed, shell scripts, find, whatever, and they _still_ could not figure out
how to change the syntax of the input files to a program like that? One
has to wonder if the cobbler's children are indeed barefoot.

Erik Naggum

unread,
May 10, 2002, 9:01:59 PM5/10/02