🚀 go-pugleaf

In article <5483@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> No, you claim is only _almost_ true.  The true restatement of the
> last line above is: the fast version will _usually_, in practice,
> be selected.

Good enough! You have admitted that a local analysis (``usually'')
suffices to detect this all-important nonaliasing. Thank you. I won't
bother to argue this further.

> Given what you've said above, you
> plan to give only two choices: fast or _very_ slow.

That ``_very_ slow'' is the speed of current C, which isn't a total
disaster. Especially if (as you admit) it usually doesn't happen.

> In addition, you still have an exponential number of separate cases
> to select since you don't know before hand what specific aliasing
> assertions the user will make.  But, that's right, you want to
> condemn anyone who uses _any_ aliasing to inefficient code which
> assumes _all_ possible aliasing.

Fgs, Jim, all I'm trying to do is disperse the overly negative aura
you've been trying to cast upon C. The fact is that C array code can run
as quickly as Fortran array code, even if the C compiler doesn't know
beforehand that there's no aliasing. I'm not saying that either language
is perfect; just that Fortran doesn't have a big advantage over C here.

> (at least, assuming the .h files are from the
> same version of your library routines as your .o files are).

Why do you keep bringing up this assumption? ``At least, assuming the
library doesn't have bugs that will make your computer explode.'' For
crying out loud.

  [ supposed counterexample ]
> That's just the thing!  I mean, it shouldn't, should it?  You stated
> above: "The fast version will always, in practice, be selected."
> What happened to that?  Certainly, Fortran would select the _fast_
> version.

As I said before, your example has NOTHING to do with Fortran, since
there is no real (visibility) equivalent to static.

> (My function
> overloading allows two functions with the same name which differ
> in any specifically declared way in the interface specification.)

The guy publicly proclaims the virtues of error checking, but privately
overloads his functions. Ungood.

> Why must you style of
> argument _always_ be confrontational?  I have that unfortunate trait
> to a great extent myself, but I _try_ not to supress it.

My style of argument is not always confrontational. I'm sorry you have
that unfortunate trait to such a great extent.

> Besides, it's not clear that the idea of using the loader to
> propagate the constraints through the call chain _isn't_ an original
> idea.  I _may_ have every right to call it "my scheme".  I don't

C++ uses it, as I've said before in this thread. Jeez.

---Dan