Re: xl, xxl, and mxl
Tom Lord <lord-1tv/[email protected]> Fri, 10 Sep 2004 15:32:23 -0700 (PDT)
| Newsgroups | gmane.lisp.scheme.pika.devel |
|---|---|
| Message-ID | <[email protected]> |
> From: "Jose A. Ortega Ruiz" <jao-mXXj517/[email protected]>
> OK. And how do you prove that XL avoids divergent behaviour altogether
> while retaining the ability of expressing that 99.999 x 99.999 % of
> all programs? (i'm not doubting it, i'm just curious... provided i've
> really seen :-)
Proving that xl avoids divergent behavior will be simple.
Proving that it will eventually achieve 99.999% coverage --- that's an
empirical thing.
> I had got a totally wrong understanding of what xl is. I lose track of
> the furth/xl thread on gnuarch ml at some point which left me
> (with the false) impression that XL was just a configuration
> (language for GNU
> Arch based on furth (as an aside, Tom, i'd appreciate a quick note on
> how pika fits in the picture (if it fits at all)).
Please forgive me for evading the pika-relation question a little
while longer. I currently believe (with a fair amount of confidence)
that it relates in a simple way (xl as implementation language for
much of the parts of pika not written yet, *perhaps* as retroactive
re-implementation language for some parts that are written already).
But I'm not prepared quite yet to articulate that correctly and with
confidence. A little more thinking time, please.
(There are lots of other relations between the two besides just that.
That's part of why I'm asking for time here. It's all a (really good
looking but still messy) jumble, for the moment.)
> > > in short, i want _abstraction_. and Make users need it, too.
> > Make keeps getting pushed in that direction. It's only compatability
> > with legacy foo that keeps it from pushing more agressively.
> Just curious again: is package-framework your attempt to push on that
> direction or do you have other plans for a building tool?
package-framework is me saying "Ok, I know I need better programming
tools to do a package framework well. But those will cost way too
much for me to write, just now. Can I usefully approximate what I
know is right in a lightweight and easily replaced way?"
Answer so far: "Yes, I can. Here is package-framework. Based on the
amusingly handy but quirky GNU Make."
I don't know how much further I want to push the approximation,
though. Not much, I think.
-t