Re: [caplisp-devel] Greetings caplisp denizens!

[James G. <an...@xn...>]

David Mercer wrote:

> 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! :-)

I believe the primary issue is that the cap-security community is very
small now.  And we can't (in some sense) afford to split up into our own
little camps.

Unfortunately, for anything I'm not paid to work on, I can't deal with
anything other than what I really want.  And at this point, I really
want CL.

> 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!

The distributed case is the most interesting.   And the area where we
(the software development community in general) need to improve most.
Processors aren't going to just keep doubling in clock speed every so
often.  In fact, lately, the clock speed has been just inching up slowly
over time.

It is distributed computing where the big thing is.

I just don't want us to forget the local case either.

> 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.

Actually, I'm sure we don't want to get tied down to any particular
codebase more than we have to.  Ideally, we'd concentrate on keeping the
changes needed for a CL implementation as small and portable as
possible, because we're not likely to get our stuff accepted into the
main branch (because it won't be strictly CL anymore).

As far as darcs goes, I'm not saying I won't use it, I just haven't used
it yet.  I don't want anyone spending much time on infrastructure, and I
know that CVS is not a good long-term solution.  I've been meaning to
move my company over to Subversion or some such, but haven't had the
time.  I can learn darcs, don't worry.

>>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 posts!

What, using crit.org?  I'm a big fan to wikis myself.  We've got a
couple mediawiki sites set up for our company.  Very useful.

>>(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! :-)

It's really not that bad, I think it is mostly a matter of me learning
what's where.  If you want to see something more scary, look at CLisp or
GCL.  ABCL is also a pain to work with, all the code is basically in one
directory, and there are few comments.  It looks like Peter Graves (no
relation) wrote the whole thing himself.  Which is fine, I'm not
complaining.  I mean heck, I haven't pushed any big chunks of code out
there that others have used yet.

I still need to work on the ECL build system maybe, it often seems to
require a complete rebuild when making changes.  And it doesn't detect
when it needs to do it in some cases.  But at least it has a separate
build directory that all the object files get dumped into.

James Graves