One more quick comment, and then I think I (at least) am done (to the
extent that the difference in opinion is clearly defined).
Fergus Henderson writes:
And, again IMHO, it is the task of the language to *define* the
encapsuation (or to allow that encapsulation to be defined), and
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
On 22-Oct-1998, David Barton [EMAIL PROTECTED] wrote:
S. Alexander Jacobson writes:
Programmers and organizations need control over which functions and
datastructures they expose to others. Gather nodes without a notion of
public/private do not provide this control.
I am
On 21-Oct-1998, S. Alexander Jacobson [EMAIL PROTECTED] wrote:
This discussion seems to be mixing a few different issues. I believe any
proposal here needs to satisfy three criteria:
1. it must allocate top level name space in a way that prevents collisions
Well, avoiding namespace
On 20-Oct-1998, David Barton [EMAIL PROTECTED] wrote:
I really do think that one additional level (from the module name
pair to a library module name triple) and mapping between
libraries and directories via user variables is all we need.
I don't think three levels is really satisfactory.
That being said, if Haskell simply added support for hierarchical
namespace and a standard path convention for finding
libraries and source,
I would be ecstatic. Better scoping, nicer import operators, and more
visibility control are just bonus.
Personally I'm quite sympathetic to the
This discussion seems to be mixing a few different issues. I believe any
proposal here needs to satisfy three criteria:
1. it must allocate top level name space in a way that prevents collisions
2. it must allow an implementation to resolve names to locations efficiently
3. it must give
S. Alexander Jacobson writes:
I am not sure what you mean by adding a library name. My objection to the
current model is that, for example with hugs, each new library requires
you to add a path to your hugs path and hope that two different libraries
both don't share the same module
And, as long as we are supporting more ADA-like import declarations,
I would like to renew my campaign for more ADA or Java like
module namespace (packages) (yes I know, this won't be in H98)
The existing module system is:
* too shallow for larger scale application development (because it is too
On Mon, 19 Oct 1998, David Barton wrote:
S. Alexander Jacobson writes:
And, as long as we are supporting more ADA-like import declarations,
I would like to renew my campaign for more ADA or Java like
module namespace (packages) (yes I know, this won't be in H98)
The existing
S. Alexander Jacobson writes:
And, as long as we are supporting more ADA-like import declarations,
I would like to renew my campaign for more ADA or Java like
module namespace (packages) (yes I know, this won't be in H98)
The existing module system is:
* too shallow for larger
11 matches
Mail list logo
