Re: [Pika-dev] xl, xxl, and mxl

[Tom Lord]

    > From: "Jose A. Ortega Ruiz" <address@hidden>

    >> xl has the same property, there are no built-in language features that
    >> will allow you to express non-terminating programs. One natural side
    >> effect of this is most type errors can be statically detected. Another
    >> natural side effect of xl's design is that it is very easy to run an
    >> xl program on a parallel processor or distributed system, aka, do a
    >> make -j4.

    > i'm not sure i fully understand the link between non-termination and
    > type safety. 

Does anyone, really? :-)

Try it this way:

We know from math that there is a set of well-defined computation
specifications (e.g., the class of turing machines).

We know that that class is hairy.   Many computations specifications
specificy "divergent" computations --- those which have no clear
meaning, except operationally, as something you might coax a device
into doing, not that you know what it is it will do once you get it to
do that.  (!)

We know that a subset of that class are the "non-divergent"
computations:  those that either obviously terminate or obviously
continue forever (but while doing something useful).

We can observe, informally, that 99.999% (at least) of all
real-world-useful computing systems perform only (provably)
non-divergent computations.  An exception might be: a general purpose
automatic theorem prover.

Truly general programming languages (from brainfuck to Scheme) let you
specify divergent and non-divergent computations with equal ease.
Screw up all you like!

We also know that we can prove that every single truly non-general
languages (e.g., at the low end, grep) has gaps: there are some
non-divergent programs we want, but can't write in that language.
(You can write tic-tac-toe in grep+fixed-data-files .... you can't
write a (general) Fibonacci calculator.)

Some people add all that up and say: "Ok, we want a general language
(permits divergent computations) ... and just have to be careful how
we use it."

XL fans say: "Ok, we want a non-general language (kinda) --- just so
long as we can write in it, say, 99.999% of the 99.999% of desirable
programs."

See?!?    (It's new to me, too, but pretty vivid.   I'm searching for
ways (and suspecting that "code" is the best way) to communicate it.)

Another way to see XL is to view it as hardware design, extended to
the point where the hardware being constructed is thoroughly
virtualized.



    > anyway, the point is again that xl alone woulb be useless
    > for building, say, a program. you will have to rely on external tools
    > (the shell?) to do the job, and all the safety goes away. 

I don't quite follow what you are trying to say but it sounds
completely wrong.

    > well, i'm not sure if i really think that make is 'fundamentally
    > broken', 

I see it as make being a good approximation of something that is clear
and desirable.  The catch is that the accurate answer (rather than the
approximation) is not that hard to build.  So who really needs or
wants the approximation?  Whoever depends on the legacy the most, I
guess.

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

-t