[e-lang] Common Lisp and E concepts
ansible at xnet.com
Mon Aug 8 16:59:36 EDT 2005
Mark Miller wrote:
> In CLOS, given multimethods, what constitutes a "method definition for a
> given class"? If method foo has three parameters declared as having
> class types A, B, and C, doesn't that make foo effectively a method of
> all three classes? By the above rule, foo would need to be in the module
> defining all three classes, which would therefore all need to be in the
> same module as each other.
That's what I was thinking, that method FOO would need to be in the same
module which defines classes A, B and C.
We may come up with a method to explictly allow other modules permission
to add in methods.
So in the program text of module M1, we can explictly allow
modifications by modules M2 and M3.
We may also want a mechanism so that the program P1 which initially
loads module M1 can also grant permission to module M4 to modify the
methods of classes defined in M1. Probably not globally, but at least
for the objects that P1 creates.
Hmmmm.... I'm not sure that's going to work. This leads to a situation
where different subsystems have objects of the same class / type, but
the methods registered to them may be substantially different. That
could lead to interesting and novel classes of program bugs!
This area is going to require a lot more skull sweat.
> Alternatively, we could drop multimethods, consider foo to be a method
> of A, require it to be in the A module, and restrict it to only be able
> to access the public API of its B and C arguments.
> Note that the above rule would still allow multimethod dispatch based
> on the types of all arguments.
By public API for B and C, do you mean the exported methods of the
module(s) which define classes B and C? That doesn't seem as useful to
me at this moment.
I'll have to think about that some more too.
> I feel obligated here to warn against learning E's bad habits. E's
> "diverge/snapshot/readOnly" pattern is technically bad capability style.
> It violates the "subtypes shouldn't add authority" rule, and creates
> hazards, as discussed previously on e-lang. Since E continues to engage
> in this sin, it should eventually provide some empirical evidence as to
> how hazardous this actually is. It is up to you whether you wish to join
> the test group or the control group on this particular inadvertent
> experiment. ;)
So ideally IMMUTABLE-CONS is a subclass of CONS? Easier to do it now
rather than later. You'll still need DIVERGE/SNAPSHOT/READ-ONLY, or
what kind of pattern are we talking about?
BTW, I found this "Subject: impl: collections" from May:
Was there another discussion I should also pay attention to?
> I don't know CL style well enough to comment, but if it's at all
> possible, I'd encourage as much as possible immutable by default. Since
> the difference you mention above should be statically determinable, you
> could convert all cases where an empty container is created and then
> immediately filled in. For those cases where an empty container gets
> created and escapes, you could flag these for manual examination.
My concern here is that if most of the time the programmer is creating
an array, and then doing a DIVERGE on it right away, that's annoying.
Another trait of CL I definitely want to preserve is conciseness of
expression. By that I mean I want to minimize the repeated text needed
to get something done.
> James Graves wrote:
>> For my attempt at implemented a capability secure variant of CL, I've
>> settled on ABCL for now. It has the smallest codebase and the code
>> itself is the most comprehensible (to me anyway). So I haven't escaped
>> Java's clutches (and slow startup time) yet.
Heh, I may have already jumped ship. I was encouraged to look at ECL,
and it has the best-organized codebase of any of the CL implementations
I've reviewed so far.
I'm not at all considering CMUCL or SBCL for now because they are much
bigger in addition to being higher performance.
>> This is going to be my approach (opinions welcome):
>> 1. Change the semantics of CL to better support cap security.
>> 2. Experiment with some existing libraries and applications, and see how
>> painful it is to convert them.
One big area here will be breaking up the default COMMON-LISP package
into a bunch of smaller ones. So anything that can talk to the outside
world (file commands for example) won't be in the same package as stuff
everybody needs (CAR, CONS, REVERSE, etc.).
The real question is should the new default base package be called
COMMON-LISP, or should I leave COMMON-LISP alone, and create a new set
of package names?
On the plus side, existing code would work unchanged. It would be up to
the programmer to change which packages are required in order to gain
the additional security.
At any rate, there's gotta be a way for someone LOAD'ing a file to
specify which packages it is allowed to use.
> You're quite welcome! Thanks for sharing your thoughts about CL-E.
Cool. My goal here is to find the minimal set of changes needed to
bring CL fully into the cap security arena.
So I'm trying to keep everything I can. Even stuff like CLOS which
seems quite troublesome right now.
It can so tempting to make additional changes. Everyone's got their own
ideas for what would make a great programming language. And, if you
take a survey of all the programming languages out there, you'll see
that most people are wrong most of the time.
I am no exception to this rule. I've got a lot of "great" ideas, but
until they've been proven out over the course of a decade or so, we
don't know which ones are actually great.
I want to leverage the design of CL as much as possible, warts and all.
Not just because of the existing codebase, but because it (and Lisp in
general) has been in use for quite a while. While not as widely
accepted as other languages, it has withstood the test of time, in my view.
The flip side of that, is that I want to fully support cap security
programming. But I don't want to make any changes beyond what is
necessary for good support.
More information about the e-lang