Re: Any easy/build-in construct to extract submatrices from larger matrix?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:3u95tkqb1l8t$.t7lzt049tvq8.dlg@40tude.net...
> On Wed, 4 Jul 2012 20:33:32 -0500, Randy Brukardt wrote:
...
>> This is distributed overhead, which programs would  have to pay whether 
>> or
>> not they used any 2-d slices. It would make all array parameters more
>> expensive.
>
> By-value passed slices should impose no overhead.

Sure. but they're not a general solution. That is, they don't work for 
slices of arrays of by-reference types, which a compiler would have to 
support. Since this is not an important feature for our customers, we would 
not want to support more than one implementation of it. And even if we did, 
there would still be distributed overhead in any parameter type that could 
not be passed by copy (which is most of them, if new types are always 
controlled, as I recommend in most cases).


>>> Slices should be first class, that would remove the burden of
>>> implementation from compiler writers. The rest is just same problematic 
>>> as
>>> with referencing single array/container element. There is no big
>>> difference for one element or a set of elements.
>>
>> That's not really possible so long as slices are what C calls l-values. 
>> The
>> problem is passing slices as parameters and allowing assignments into 
>> them.
>
> Why does this work for array elements then?

(There is a "not" missing in what I wrote above.)

It works for array elements only because they are contiguous and passing a 
single address is sufficient to represent the slice, as it is for any array 
objects. (Recall that we're talking about *constrained* array parameters 
here.)

...
...
>> Value semantics only works for a small subset of types (for most 
>> compilers,
>> that subset is elementary types). Moreover, Ada has many types for which
>> value semantics is not allowed (immutably limited types and tagged types 
>> are
>> the best known). So this would be a feature of fairly limited value.
>
> I don't see big problem here. Arrays of referential elements are most
> likely internally are array of pointers. Slices of such arrays are again
> arrays of pointers. There is nothing difficult about that, except that
> usual problems that a reference shall not outlive the object.

That's not how our compiler handles by-reference types. They live like other 
objects in place, but are always *passed* by reference (there is no 
requirement to *allocate* them by reference). There are some cases where we 
use implicit pointers (such as in shared generics), but that's unusual for 
Ada compilers. I don't think GNAT ever uses them.

                            Randy.