Fergus Henderson writes:
No, different uids don't work fine in the multiprogrammer case.
The programmer that is compiling the source code needs read access
to all of it (for using tools like `grep', if nothing else). Once
he has that read access, nothing prevents him from violating the
encapsulation.
Let's see here --- you want him to be able to do reads like grep but
not refer to the units directly? You ask too much of *any* mechanism
(unless you restrict operations like grep and others, doing special
versions, in which case they can do the appropriate superuser stuff).
Either you can trust the programmer to follow conventions, or you
restrict any kind of read access; without that restriction, he or shee
can always make a local copy and do what he or she wills.
But even *if* you decide that some more sophisticated mechanism of
version control is necessary, it is properly an operating system
function, *not* a language function. If you decide that a "grep" is
OK, but compile access is not, there is no reason whatever to decide
that compilation is your only "forbidden" function. It makes a lot
more sense to add an operating system function --- say, granting
access by tool rather than by specific user or group ID --- that gets
you the finer grained access control you need. Then you only
implement it once. Under your suggestion, it not only gets
implemented by multiple tools, but it gets codified in the entry
format (whether a computer language or a document control system) of
multiple tools, each in a different way. Chaos!
It all boils down to: access control to files is the responsibility of
the operating system, *not* a programming language. The most a
language should do is make responsible conventions possible and
expressible, and Haskell can do that with a very limited extension.
> 2) The compiler can (and should) be intelligent enough to detect
> the importation of symbols only through non-functional
> (gather) modules. This is not a big test to perform.
So the compiler should enforce this convention?
No; detect it and take advantage of it.
Most of the below is variations on a theme, which make lots of sense
if you accept the basic assumption that enforcing access control
conventions is properly a function of the language feature; under that
assumption, I agree with most of it. So:
<snip>
I don't see how that helps. Every programmer on the team may need
to modify any file (in order to fix a bug, for example). So all
programmers need write access to every file.
This does not correspond to any configuration controlled project that
I have ever worked on, so I am at sea. In my world, if you need a
file that is outside your own package, you need to go to the
configuration manager (who may or may not be the project manager) for
permission to check out the file to make the change. This may be as
simple as an Email, or it may even require review. Allowing the
programmer to just do it, on his own hook, is well outside any kind of
configuration control guidelines I have ever worked under.
This may be a commercial / university kind of thing. I know of no
company that would work with these kinds of guidelines, which may
account for our different approach to this whole question.
Well, normally I check out all the modules in the system. With
CVS, I type out `cvs checkout mercury' and it checks out all the
modules in the entire system, giving me both read and write access
to all of them. Then I type `make' and it compiles everything.
This is nice and simple, and it works.
We work in very different environments!
Yes, you may be right. But I don't think a language should require
the use of a particular configuration management style. And
therefore I'm not keen on any solution which relies on the
configuration management style rather than the language to enforce
encapsulation.
And, again IMHO, it is the task of the language to *define* the
encapsuation (or to allow that encapsulation to be defined), and the
job of the operating system or programming environment to enforce it
(or to trust to convention, depending). And still IMHO, Haskell can
do this definition with very little change.
Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.averstar.com/~dlb
