[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
{Improved version} EXPORT-IMPORT and the other random commands
- To: CL.BOYER@r20.utexas.edu
- Subject: {Improved version} EXPORT-IMPORT and the other random commands
- From: "Robert W. Kerns" <RWK@ai.ai.mit.edu>
- Date: Fri, 5 Feb 88 23:56:53 EST
- Cc: common-lisp@sail.stanford.edu, edsel!jonl@labrea.stanford.edu, labrea!CL-Cleanup%SAIL@labrea.stanford.edu, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Date: Wed 3 Feb 88 21:48:23-CST
From: Bob Boyer <CL.BOYER at R20.UTEXAS.EDU>
I think that the "Put in seven extremely random user
commands" stuff needs to be documented much more rigorously.
I don't think that any collection of cross-references in
CLTL will suffice to make things clear.
You've identified an important issue, *BUT*:
Frankly, I think this approach would be a waste of time. I don't
think ANY amount of documenting and test suites has any chance
of working. The underlying idea that you define the package
environment by performing a series of side-effects on the package
system is so wrong it is beyond repair. It is so entirely sensitive
to complex and obscure order-of-events issues that even if you
were successful in getting all implementations to do exactly the
same thing, real-life users could not adaquately standardize their
workstyles and interactions to avoid problems, even if they could
understand all the rules!
I think the time would be better spent on specifying and adopting
a DEFPACKAGE macro. This would always be the first form of the first
file loaded. (Or at least, before any IN-PACKAGE's for that package).
I think it is much easier to specify the behaviour when you don't have
to consider all the order-of-operations issues. Of course, it still needs
to be carefully specified, but the problem is more constrained, and you're
not so burdened with issues of compatibilty or programing environment
issues.
There are quite a number of us who think the DEFPACKAGE issue is important,
but so far as I know there aren't any actual proposals being written up.
Presumably the issue is one of manpower to address it, not of lack of
interest, so I would be dissapointed to see us discuss ways of "fixing"
this rather bleak area of CL, rather than working on DEFPACKAGE.