Re: Programmer defined arrays

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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