Re: Does Ada need elemental functions to make it suitable for scientific work?

[Brian Drummond <brian@shapes.demon.co.uk>]

On Mon, 09 Jul 2012 18:27:54 -0500, Nasser M. Abbasi wrote:

On Mon, 09 Jul 2012 18:27:54 -0500, Nasser M. Abbasi wrote:

> The most important feature which I found missing is that Ada functions
> do not automatically work on arrays and matrices.

Everyone moving from a domain-specific language to a general one will have
a "most important missing feature".

> In Fortran, I can just write V**2, where V is a vector. In Ada,
> I can't do that. Since ** is not defined on this array type and this
> number type.
> 
> ... I really do not want to write packages and
> define operators each time and for each type I make to have it work as
> elemental function each time.
> 
> This is something that should be build into the language.

No, it is something that can be added to the language where necessary, 
with the minimum of wasted effort.

For example, write ONCE, a generic ** function, which you can instantiate 
with any (numeric!) array type.

Now a package of such generic functions, extending
Numerics.Generic_Real_Arrays, might be a useful addition to Ada.

O course it would have to be clear from the package documentation which of
the possible meanings of "**" was implemented. You might want separate
packages implementing element_wise operators or array operators.

Or you may want different ad-hoc operator symbols, like "^" or ".^" in
your Octave examples, to distinguish the different meanings. (But in your
examples, even the domain-specific languages can't agree to use the same
symbols!)

This would be one use case for my recent proposal to allow user-
defined operator symbols in a future Ada. Given a few restrictions, (e.g.
on operator precedence) it looked like a relatively harmless addition to 
Ada, and fairly general in application (not specific to one domain).

- Brian