Programmer defined arrays

Programmer defined arrays

[Georg Bauhaus]

IIUC, an array can be seen as a mapping

  (Index_Type[1], ..., Index_Type[n]) -> Component_Type

where n is finite.
Similarly, a function can be seen as a mapping (*)

  (Param_Type[1], ..., Param_Type[m]) -> Return_Type

We can write a function's body (or its expression in Ada 2012).
We cannot, however, express how the function's mapping is to be
translated into instructions to be executed by some processor.
That's the job of the compiler.

Suppose translating a function into its instructions is to
remain the job of the compiler. (Therefore, recursively, that of
the persons writing the compiler.)

In this light, why should we be given means to express how arrays
should be translated into instructions?

__
(*) Both mappings are variable, since array components can be
assigned and since Ada functions are not pure, but that's an aside.

Re: Programmer defined arrays

[Dmitry A. Kazakov]

On Mon, 06 Aug 2012 16:28:59 +0200, Georg Bauhaus wrote:

> IIUC, an array can be seen as a mapping
> 
>   (Index_Type[1], ..., Index_Type[n]) -> Component_Type
>
> where n is finite.
> Similarly, a function can be seen as a mapping (*)
> 
>   (Param_Type[1], ..., Param_Type[m]) -> Return_Type

It is a too simplified view. Array is an interface of which the mapping is
only one of many operations.

> In this light, why should we be given means to express how arrays
> should be translated into instructions?

We have these means:

   overriding function ...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Programmer defined arrays

[Jacob Sparre Andersen]

Georg Bauhaus wrote:

> IIUC, an array can be seen as a mapping
>
>   (Index_Type[1], ..., Index_Type[n]) -> Component_Type
>
> where n is finite.
> Similarly, a function can be seen as a mapping (*)
>
>   (Param_Type[1], ..., Param_Type[m]) -> Return_Type

In practice functions of _discrete_ arguments may be seen as _constant_
arrays.  You can not assign a value to a function, and arrays can only
be declared with discrete indexes.

> In this light, why should we be given means to express how arrays
> should be translated into instructions?

What means do we have to express how arrays should be translated into
instructions?

Greetings,

Jacob
-- 
"Very small. Go to sleep" -- monster (not drooling)

Re: Programmer defined arrays

[Georg Bauhaus]

On 06.08.12 19:26, Jacob Sparre Andersen wrote:
> Georg Bauhaus wrote:
>
>> IIUC, an array can be seen as a mapping
>>
>>    (Index_Type[1], ..., Index_Type[n]) -> Component_Type
>>
>> where n is finite.
>> Similarly, a function can be seen as a mapping (*)
>>
>>    (Param_Type[1], ..., Param_Type[m]) -> Return_Type
>
> In practice functions of _discrete_ arguments may be seen as _constant_
> arrays.  You can not assign a value to a function, and arrays can only
> be declared with discrete indexes.
>
>> In this light, why should we be given means to express how arrays
>> should be translated into instructions?
>
> What means do we have to express how arrays should be translated into
> instructions?

We cannot do much more then suggesting layout, alignment and such.
But some have said they want more control over the translation of "array".
Apparently, though, a similar wish is not expressed for "function",
or callable. Why is that? A function also is an abstraction, just like
an array is.

I thought that these two concepts, "array" and "function", might or might
not be fundamental. If "function" is so fundamental that no one asks for
more programmer control over the translation process of a function, why
do some ask for more programmer control over the translation process
for arrays, via array becoming a type suitable for O-O, but function
not becoming an O-O type?

Re: Programmer defined arrays

[Dmitry A. Kazakov]

On Mon, 06 Aug 2012 21:05:39 +0200, Georg Bauhaus wrote:

> why
> do some ask for more programmer control over the translation process
> for arrays, via array becoming a type suitable for O-O, but function
> not becoming an O-O type?

Of course they do. But there is the rub - when function is a value of some
type then operations of that type are functions of different kind. There is
a potentially infinite hierarchy of such functions. So if you wanted first
class functions you would need some second class functions to operate them.
you would also have to take care about keeping types statically checkable
(static typing). But if you wanted first class arrays there would be
nothing special about them.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Programmer defined arrays

[Georg Bauhaus]

On 06.08.12 21:54, Dmitry A. Kazakov wrote:
> On Mon, 06 Aug 2012 21:05:39 +0200, Georg Bauhaus wrote:
>
>> why
>> do some ask for more programmer control over the translation process
>> for arrays, via array becoming a type suitable for O-O, but function
>> not becoming an O-O type?
>
> Of course they do. But there is the rub - when function is a value of some
> type then operations of that type are functions of different kind. There is
> a potentially infinite hierarchy of such functions. So if you wanted first
> class functions you would need some second class functions to operate them.
> you would also have to take care about keeping types statically checkable
> (static typing). But if you wanted first class arrays there would be
> nothing special about them.
>

More simply, (ceterum censeo Qi wouldn't need static typing, at the
risk of non-terminating translation), I had thought of it the other
way around.
I'll need something below arrays to make true arrays from below-array
things, or, addresses, TBH, silencing the fact that these establish
arrays of indexed storage cells.
Similarly, I had thought the analog would be to ask for lower things
for operations, too, like procedures that have multiple entry points
to serve as bodies for a host of functions. Just for the sake of
an example. Compact, efficient, simple, no inlining considerations.

Re: Programmer defined arrays

[Dmitry A. Kazakov]

On Mon, 06 Aug 2012 23:03:08 +0200, Georg Bauhaus wrote:

> On 06.08.12 21:54, Dmitry A. Kazakov wrote:
>> On Mon, 06 Aug 2012 21:05:39 +0200, Georg Bauhaus wrote:
>>
>>> why
>>> do some ask for more programmer control over the translation process
>>> for arrays, via array becoming a type suitable for O-O, but function
>>> not becoming an O-O type?
>>
>> Of course they do. But there is the rub - when function is a value of some
>> type then operations of that type are functions of different kind. There is
>> a potentially infinite hierarchy of such functions. So if you wanted first
>> class functions you would need some second class functions to operate them.
>> you would also have to take care about keeping types statically checkable
>> (static typing). But if you wanted first class arrays there would be
>> nothing special about them.
> 
> More simply, (ceterum censeo Qi wouldn't need static typing, at the
> risk of non-terminating translation), I had thought of it the other
> way around.
> I'll need something below arrays to make true arrays from below-array
> things, or, addresses, TBH, silencing the fact that these establish
> arrays of indexed storage cells.

Below means what? Hexadecimal code is "below." The question is whether you
stay typed or not. It is not really below, it is rather decomposable.

> Similarly, I had thought the analog would be to ask for lower things
> for operations, too, like procedures that have multiple entry points
> to serve as bodies for a host of functions. Just for the sake of
> an example. Compact, efficient, simple, no inlining considerations.

Within a typed framework operations are fundamental, arrays are not. You
can describe an array as a set of types, values of, and operations on.

P.S. "Free function" if you meant that is a class-wide operation.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de