Re: [caplisp-devel] Greetings caplisp denizens!

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

On 8/25/05, James Graves <an...@xn...> wrote:
>=20
> Hello Everyone!
>=20
> I don't have a lot of time to chat, and for a quick intro into my
> motivations, you can check this post on the cap-talk mailing list from
> last year:
>=20
> http://www.eros-os.org/pipermail/cap-talk/2004-December/002435.html

I just re-read most of that post (thanks for the link!) and I recall
it pretty clearly.  The "why not just implement a fast E?" attitude of
Jonathan's in the message you were replying to is part of why this
effort exists.  Some on e-lang seem to be prejudiced against anything
non-E in capsec languages, and can't see IT'S theoretical limitations,
which smacks me as a bit ironic, considering how that attitude
somewhat mirrors the prejudice experienced by the cap community in the
wider computing world (god, an outcast among outcasts, that must be
the story of my life! :-)

> For whatever reason, unlike David, I seem to be most interested in the
> internals of implementing cap-security in Common Lisp.  So I guess I'll
> be working from the VM on out to the network.

And that's great! I'm just of the opinion that, from a theoretical
standpoint, since one can't even (usually) tell if they are running on
real hardware more and more these days, and are guaranteed to be on
some sort of VM if you're interpreted anyway, and language based
security can never be the whole enchilada (it mostly protects you from
yourself), Why Not start on the distributed case, since it's the
interesting one that's the goal!

> But I definitely want all the good bits from E, so I'm definitely
> looking forward to trying everything.

Oh yeah, that list you posted in the message linked above shockingly
mirrors a parallel computing quest of mine, and strikes me as a good
place to mine Things To Do for this project.

> Expect progress from me to be a bit slow.  My day job doesn't (yet)
> involve capability security, but I'll be steering things in that
> direction as time goes by.  In the mean time, however, Caplisp is a
> nights/weekends project for me.

Well I'm hip deep in a mathematics degree right now, so my activity
level on this will be fairly bursty too!

> I've chosen ECL as my implementation of choice, not because it's the
> fastest or anything, but because it seems to be the easist to hack the
> internals.  After some initial stumbling (1), I think I've gotten my
> feet under me and I should have something to show soon in regards to
> immutable types.  I'll need to send out another post on that stuff in
> regards to what kind of interface we want soon.

Oh that'd be great.  Nothing stops us from having seperate branches
('inside out' vs 'outside in', or something) and concentrating most on
specifying interfaces in a portable way, which will make porting
things between lisps easier.

> I'm not as worried about license issues right now.  I prefer the GPL for
> everything, but I'm not too picky.  As long as whatever we're using is
> compatable with whichever CL implmentations we're using, I don't see any
> problems.

I generally prefer the GPL too, especially for infrastructure level
code, but I'm more agnostic about it with regard to language/library
technology, and more concerned with GPL purity in regard to basic
infrastructure server apps.  In other words, even if any future
released code from this project is MIT licensed, I'm intending to use
it to write GPLed apps. for general release.

> I've never used darcs, but I suppose it wouldn't kill me to check it out.

It's really simple to use, but if you specifically prefer cvs, every
sourceforge project has cvs services, and you're more than welcome to
use it for your work, while I use darcs for the 'outside in' branch.=20
I can easily automate cross-updating between the two for any common
code, also (ssh, rsync and cron are your friends :-)  You need merely
create a sourceforge login, and I can give you write access to the
caplisp cvs (I may have to set it up, recursive dependancies, yay!)

> As far as what to post where... I really appreciate the feedback from
> the regulars on e-lang, so anything I have to say which isn't strictly
> an implementation detail is likely to be posted there.  I did ask
> recently, and MarkM said that we were quite welcome to discuss a
> cap-secure CL on the e-lang list.

Certainly! I just felt we were getting a bit too much away from E
proper, and more implementation specific than cap-talk would warrant
in some cases, and wanted things more easily collectable in one place.

> I _assume_, and I hope this will continue to be true for at least the
> near future, that everyone on this list is also subscribed to e-lang and
> cap-talk as well.

You betcha, I highly prize my annotated copy of the last couple of years po=
sts!

> (1) There are not one, not two, but three different routines called
> 'make_cons' to create CONS cells in ECL.  But only one of them is
> actually used.  I was, of course, modifying the wrong one, and wondering
> why my initialization code wasn't working.

Ew, now THAT's a messy codebase! :-)

Cheers,

-David Mercer
Tucson, AZ