Re: Gnat GPL 2010 available soon (conditional expressions)

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

On Wed, 7 Jul 2010 05:00:47 -0700 (PDT), Phil Clayton wrote:

> On Jul 6, 6:18�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Tue, 6 Jul 2010 09:31:05 -0700 (PDT), Phil Clayton wrote:
>>> The concept of an order is important because the function F could have
>>> side effects in the above example (though I would not advocate that as
>>> good practice).
>>
>> AFAIK, presently the order is not defined. So though this is legal
>>
>> � �X : String (1..80) := (others => Character'Read (Stream'Access));
>>
>> It is not a good idea.
> 
> It would be good if the order was not defined because that would
> prevent people depending on it, so making it easier for a compiler to
> parallelize.

But then the language should define pure functions (relatively to the given
context) and prohibit usage of impure ones in the constructs like above.

>>> However, we would be able to write
>>
>>> � (for I in reverse A'Range => A(I))
>>
>>> to represent the reverse of the array A is perhaps a little confusing.
>>
>> The effect is undefined. Theoretically the compiler could initialize array
>> elements concurrently on a multi-core processor.
> 
> There are really two concepts here:
> 1. the order of evaluation of the expressions for each index
> 2. the value the bound variable I gets for each index
> 
> I didn't make it clear that I was switching from [1] to [2], sorry.
> This above reverse example was really about [2] to show that the use
> of the keyword 'reverse' would result in I having the value A'Last at
> index A'First, A'Last - 1 at index A'First + 1, etc.

OK. The objection is that in this case I is not the array's index, but a
mapping of. That looks totally obscure.

>>> Also, it really only makes sense to have one variable holding the
>>> array index. �For example, if we could write
>>
>>> � (I, J : 1 .. 5 => ...)
>>
>>> surely I and J would always be equal: there are only 5 elements in the
>>> array. �Having
>>
>>> � (for I in 1 .. 5 => ...)
>>
>>> syntactically rules out multiple variables.
>>
>> Yes, but many other things as well. However I prefer an absolutely
>> different approach anyway, e.g. proper index types. In my world a diagonal
>> would be initialized like:
>>
>> � �(Diagonal (5, 5) => 1.0, others => 0.0)
>>
>> where Diagonal is a proper function.
> 
> Interesting.. how would you make the expression a function of the
> index?

I don't want such expressions at all. I mean if these are necessary it must
be a function returning an array. Reading aggregates containing some
inlined code is not readable to me.

This is yet another topic, but I favor user-defined aggregates instead of
hard coded special stuff like index dependent expressions. E.g. if you have
some frequently used special type of "array literals" you should  be able
to provide a custom aggregate of. For example, let you deal with band
matrices. The language should allow you to define a custom aggregate like

A : Square_Matrix :=
   (  Upper => (1.0, 2.4),
      Diagonal => (7.3, 8.0, 9.1),
      Lower => (3.0, 2.1)  );

P.S. This issue boils down to the interfaces. The point is that you should
be able to implement interface of any type for the given one. A record of
arrays is an interface which has aggregates like above. Hang it on
Square_Matrix and you will be able to do above aggregates and other useful
stuff, like A.Upper.

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