Re: How to Design an Application Programmers' Interface (API)

["E. Robert Tisdale" <edwin@netwood.net>]

Gautier wrote:

> > I think that Ada numerical application programmers should be able to write
>
> >     C := alpha*product(A, B) + beta*C;
>
> > and let the compiler resolve the expression to a DGEMM procedure call.
>
> For scalar things or usage with small vectors
> or matrices as output of functions, I would do so.
> For bigger structures the procedure is better
> - no temporary object in expressions.
> In my own (partial) bindings I have both approaches.

Why do you assume that the above expression involves temporaries?
C++ programmers can implement libraries which resolve this expression
to a DGEMM subroutine call.  Why can't Ada 95 programmers do the same?

> > Calling DGEMM directly from an Ada application program
> > abrogates all of the safety feature built into the Ada language.
>
> It depends on the ratio of BLAS/LAPACK calls in the Ada code.
> For my finite element program the "adapter" fits:
> there are a few calls that well separate the 1960s programming models
> from my year 2000 sources...
> It firewalls efficiently the weak-typing headaches
> and I can add degrees of complexity with joy and decontraction...
>
> Anyway you can wrap the adapter into some "Multiply" etc. procedures -
> as well as "*" etc. functions.

But now you have two interfaces.
Wouldn't it have been better to redesign the API
and implement it with calls to the BLAS Fortran language binding?

> Seems very elegant, but it might be not very efficient
> - functional-only, and things like "RESULT := (others => (others => 0.0));"
> I don't know of a compiler that just zeroes rapidly RESULT
> (also a temp. variable BTW)...

We can nitpick forever about the implementation of the API.
The question is whether the API will permit us to substitute
a better implementation or not.  A good API will.  A bad API won't.