order of discussion

[Raul Deluth Miller]

I should take responsibility as the one who raised LLL issues "out of
order".

I raised this issue because some of the specifications (e.g. must be
marketable, must provide correctness) seemed to be getting into the
"do what I mean" arena -- there's just too much that's implicit in
such specifications.

While I have the utmost respect for structured design principles, you
cannot ignore the physics of the underlying situation if you want to
have a hope of breaking new ground.  This means visiting issues such
as word size, mapping of proposed interfaces onto typical and exotic
hardware, and consideration of common failure modes.

On the other hand, I think it is perfectly alright to "waste"
computational facilities.  If machine (A) has some instruction that
doesn't map well onto the instruction sets of machine (B), (C) or (D),
we probably don't want it in our common instruction set model.  If we
can take advantage of such instructions in a particular implementation
of our communication model/kernel, all well and good.

That make sense?

-- 
Raul D. Miller          N=:((*/pq)&|)@                 NB. public e, y, n=:*/pq
<rockwell@nova.umd.edu> P=:*N/@:#               NB. */-.,e e.&factors t=:*/<:pq
                        1=t|e*d    NB. (,-:<:)pq is four large primes, e medium
x-:d P,:y=:e P,:x                  NB. (d P,:y)-:D P*:N^:(i.#D)y [. D=:|.@#.d