[caplisp-devel] Re: [e-lang] "Fixing" the Common Lisp package system

[David M. <ra...@gm...>]

Sorry for the extremely delayed reply, I've been out of commission due to=
=20
oral surgery, and then
dancing like mad to stay on top of multiple math classes....my initial, ver=
y=20
late, thoughts on=20
Jonathan's excellent message are below. -David Mercer

On 8/26/05, Jonathan Rees <ja...@mu...> wrote:
>=20
> (Not cc'ing e-lang for uninteresting reasons related to my incomplete
> transition to new email client infrastructure. Feel free to forward
> but change the email address to ja...@mu.... Sorry I haven't
> followed the whole thread.)


That's ok, it branched out over on the new caplisp list, which I've cc'd=20
this to (cap...@li... running mailman, so if you'd=
=20
like to join us [myself, Kevin, James, MarkM and David Hopwood] there, you=
=20
know what to do! :-)
It's there for us to hash out heavily lisp-specific implementation issues i=
n=20
our various different capability lisp efforts.
Kevin is of course making good headway with E-on-CL, James is trying to=20
attack CL's defficiencies in re capability discipline (such as the numerous=
=20
problems you point out in detail below) which in the e-lang taxonomy of=20
flavors of E-ish things is a LispE, and I'm more dedicated to adding=20
distributed capability features to warts and all CL, with the lisp image=20
being the unit of trust, at least initially, making my efforts caplisp unde=
r=20
the same naming convention.=20

I think this is a herculean task. Good luck. There are scores of
> features in Common Lisp that show abysmal capability discipline. This
> is one thing that led me to give up on it (I worked on the first
> Common Lisp implementation, NIL) and do T and Scheme 48 instead.=20


I was at first (and still am in many ways) drawn to starting off with W7 an=
d
working from there, but I just can't stand to do actual heavy work in=20
Scheme.
I love it for proof-ish type things and minimalist stuff, but CL just has=
=20
such
better working libraries available, etc. that I always seem to get sucked=
=20
back
in that direction (perhaps it was the Maclisp exposure at the tender age of
14 that scarred me! :-)

I always had in mind the goal of running multiple mistrusting users in
> a single address space, which is tantamount to capability security.


I have the goal of using a hypervisor to control VM's that are mistrusting
on the same hardware, rather than in the same address space. I may
want to write such a 'landlord process' in a capsec Scheme variant for
easier provability (or even ML or Haskell or something, whoever has the
best proof engine at that point), but I wanna do some things that need
LOTS of libraries not available out of the box for scheme, but that are
available for CL.=20

**snip of some excellent gory details of the lisp package system that I=20
should cc over to James later**

I'm using Common Lisp now so the horrors of the package system and

> the rest of the language are fresh in my mind. I think your eventual
> language won't be recognizable as Common Lisp, but it will be much
> improved.


Yes, I think that James' LispE implementation will only look like Common=20
Lisp, with quite a bit of stuff
chopped out or heavily hacked!

Best of luck
>=20
> Jonathan
>=20

Cheers,

David Mercer
Tucson, AZ


--=20
"Nothing above represents the position or opinion of the University of
Arizona or the Dept. of Mathematics, so there! :-)"