initialize an array (1-D) at elaboration using an expression based on the index?

initialize an array (1-D) at elaboration using an expression based on the index?

[Nasser M. Abbasi]

Ada experts:

I am not able to find an example on this.

I was wondering if in Ada I can initialize some array, where I can fill 
the content of each entry in the array based on some function of the index?

For example, in Fortran one can do this:
-----------------------
program main
   integer, parameter :: N = 10
   real, dimension(N) :: a=(/(j**2,j=1,N)/)

   print*, a
end program
------------------------
$ gfortran t3.f90
$ ./a.exe
    1.0000000       4.0000000       9.0000000       16.000000 etc....


In Ada, what would I need to do in the initialization below?
---------------------------
procedure t2 is
    N: constant integer := 10;
    a: array(1..N) of float := (others=>0.0); --??
begin
    null;
end t2;
-----------------------------

I know ofcourse I can initialize it in the body by a loop, just wanted 
to see if it is possible to do it in the elaboration.

thanks
--Nasser

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Vinzent Hoefler]

On Sat, 16 Oct 2010 01:03:52 +0200, Nasser M. Abbasi <nma@12000.org> wrote:

> I was wondering if in Ada I can initialize some array, where I can fill
> the content of each entry in the array based on some function of the index?

Not that I know of.

At first, you don't have an index at the point of the expression, so
you can not parametrize a function with the "current" index returning the
appropriate value.
At second, if you try to be smart and provide a non-pure function that
counts the number of calls to it and provides an appropriate new return
value on each call, this is not guaranteed to work, because the evaluation
order is "arbitrary".

Still, you can use an array aggregate like:

a: array(1..N) of float := (1 => Eval (1), 2 => Eval (2), ...);

but I wouldn't recommend that due to its lack of flexibility if the
index constraint changes.


Vinzent.

-- 
There is no signature.

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Adam Beneschan]

On Oct 15, 4:31 pm, "Vinzent Hoefler" <nntp-2010...@t-
domaingrabbing.de> wrote:
> On Sat, 16 Oct 2010 01:03:52 +0200, Nasser M. Abbasi <n...@12000.org> wrote:
>
> > I was wondering if in Ada I can initialize some array, where I can fill
> > the content of each entry in the array based on some function of the index?
>
> Not that I know of.
>
> At first, you don't have an index at the point of the expression, so
> you can not parametrize a function with the "current" index returning the
> appropriate value.
> At second, if you try to be smart and provide a non-pure function that
> counts the number of calls to it and provides an appropriate new return
> value on each call, this is not guaranteed to work, because the evaluation
> order is "arbitrary".
>
> Still, you can use an array aggregate like:
>
> a: array(1..N) of float := (1 => Eval (1), 2 => Eval (2), ...);
>
> but I wouldn't recommend that due to its lack of flexibility if the
> index constraint changes.
>
> Vinzent.

It seems like it would be simple to add syntax to array aggregates in
the language like

a : array(1..N) of Float := (for I in 1..N => Float(I)*Float(I));

The legality rules and rules about applicable index constraints would
be the same as if "for I in" were not present.

Perhaps someone has already made a similar proposal, but I can't find
it.  Since Ada 2012 is already putting "if" and "case" in expressions,
though, it shouldn't be too big a leap to include "for" in an
expression.  Of course, it's too late to make it into Ada 2012, but
perhaps I'll propose it for the next version of Ada (what is that
going to be?  Ada 2020, where we add all the features that we realize
in hindsight that we should have added earlier? :-)).

                                       -- Adam

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Nasser M. Abbasi]

On 10/15/2010 5:16 PM, Adam Beneschan wrote:
> On Oct 15, 4:31 pm, "Vinzent Hoefler"<nntp-2010...@t-


>
> It seems like it would be simple to add syntax to array aggregates in
> the language like
>
> a : array(1..N) of Float := (for I in 1..N =>  Float(I)*Float(I));
>
> The legality rules and rules about applicable index constraints would
> be the same as if "for I in" were not present.
>
> Perhaps someone has already made a similar proposal, but I can't find
> it.  Since Ada 2012 is already putting "if" and "case" in expressions,
> though, it shouldn't be too big a leap to include "for" in an
> expression.  Of course, it's too late to make it into Ada 2012, but
> perhaps I'll propose it for the next version of Ada (what is that
> going to be?  Ada 2020, where we add all the features that we realize
> in hindsight that we should have added earlier? :-)).
>
>                                         -- Adam
>

That would be neat if this can be done. Because many times one needs to 
init an array or a matrix to some initial values, it is a bit more 
concise if one can do it in the 'same place' but Mr Robert Duff send me 
a nice solution to use, which is to use an init() function. Here is my 
code now using his idea. So, using his solution, it is almost as good as 
doing the initialization 'in place'.


-----------------------------------
-- gnatmake main.adb
-- platform: gcc 4.5 with Ada support.
--
with ada.float_text_io; use ada.float_text_io;
with ada.text_io; use ada.text_io;

procedure main is
      initial_h : constant float   := 1.0/8.0;
      nIter     : constant integer := 6;
      type h_type is array(1..nIter) of float;

      -- INIT function to use to initialize array h below
      function Init_h return h_type is -- NEED THIS HERE
      begin
          return result : h_type do
              for i in Result'Range loop
                  Result(i) := 1.0/(2.0**i);
              end loop;
          end return;
      end Init_h;

      h : constant h_type := init_h; -- INIT the array here

begin
     for i in  h'range loop
         put(h(i));
         new_line;
     end loop;
end main;
-------------------------------------

$ gnatmake main.adb
$ ./main.exe
  5.00000E-01
  2.50000E-01
  1.25000E-01
  6.25000E-02
  3.12500E-02
  1.56250E-02


--Nasser

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Robert A Duff]

"Nasser M. Abbasi" <nma@12000.org> writes:

> ... but Mr Robert Duff send me
> a nice solution to use, which is to use an init() function.

Oops, sorry, I meant to post that to the newsgroup instead of
mailing it just to you.  Thanks for cleaning it up and posting
the result!

>...Here is my
> code now using his idea.

- Bob

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:4b8f7f06-a817-4545-9fc6-67740c67b9d3@a4g2000prm.googlegroups.com...
...
>It seems like it would be simple to add syntax to array aggregates in
>the language like
>
>a : array(1..N) of Float := (for I in 1..N => Float(I)*Float(I));
>
>The legality rules and rules about applicable index constraints would
>be the same as if "for I in" were not present.

There was a proposal to allow this for Ada 9x. It got dropped somewhere 
along the line (don't recall why, might simply have been "scope reduction"). 
It hasn't been reconsidered since, so far as I remember.

                               Randy.

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Phil Clayton]

On Oct 16, 1:16 am, Adam Beneschan <a...@irvine.com> wrote:
> On Oct 15, 4:31 pm, "Vinzent Hoefler" <nntp-2010...@t-
>
>
>
> domaingrabbing.de> wrote:
> > On Sat, 16 Oct 2010 01:03:52 +0200, Nasser M. Abbasi <n...@12000.org> wrote:
>
> > > I was wondering if in Ada I can initialize some array, where I can fill
> > > the content of each entry in the array based on some function of the index?
>
> > Not that I know of.
>
> > At first, you don't have an index at the point of the expression, so
> > you can not parametrize a function with the "current" index returning the
> > appropriate value.
> > At second, if you try to be smart and provide a non-pure function that
> > counts the number of calls to it and provides an appropriate new return
> > value on each call, this is not guaranteed to work, because the evaluation
> > order is "arbitrary".
>
> > Still, you can use an array aggregate like:
>
> > a: array(1..N) of float := (1 => Eval (1), 2 => Eval (2), ...);
>
> > but I wouldn't recommend that due to its lack of flexibility if the
> > index constraint changes.
>
> > Vinzent.
>
> It seems like it would be simple to add syntax to array aggregates in
> the language like
>
> a : array(1..N) of Float := (for I in 1..N => Float(I)*Float(I));
>
> The legality rules and rules about applicable index constraints would
> be the same as if "for I in" were not present.
>
> Perhaps someone has already made a similar proposal, but I can't find
> it. ...

There was a recent discussion about exactly this on c.l.a. that
spawned off a thread on conditional expressions:

http://groups.google.com/group/comp.lang.ada/browse_thread/thread/334f9012742e58fc/bc4410d521cd9e9c#bc4410d521cd9e9c

Phil

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Adam Beneschan]

On Oct 16, 3:08 am, Phil Clayton <phil.clay...@lineone.net> wrote:
>
> > Perhaps someone has already made a similar proposal, but I can't find
> > it. ...
>
> There was a recent discussion about exactly this on c.l.a. that
> spawned off a thread on conditional expressions:
>
> http://groups.google.com/group/comp.lang.ada/browse_thread/thread/334...
>
> Phil

Yep, perhaps I subconsciously remembered something about that thread.

I was trying to find it in the AI's, and I couldn't.  But Randy's
comment suggests that someone may have made a proposal like this
before Ada 95, and I was only looking in the AI95 and AI05's---not the
AI83's.

Anyway, if I feel up to submitting this as a proposed language change,
I'll make sure you get credit.  I do think this syntax, which you
mentioned in the previous thread and which I apparently unconsciously
plagiarized, is the cleanest.

                              -- Adam

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:f0f05ceb-11c9-4e7c-bd7c-a3d20154b922@o23g2000prh.googlegroups.com...
>I was trying to find it in the AI's, and I couldn't.  But Randy's
>comment suggests that someone may have made a proposal like this
>before Ada 95, and I was only looking in the AI95 and AI05's---not the
>AI83's.

I just looked, and didn't find it in any of the Ada 9x drafts back to ILS 
1.2. So maybe my memory was bad, or maybe I looked in the wrong place. But I 
*know* this is not a new idea.

                         Randy. 

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Phil Clayton]

On Oct 18, 4:03 pm, Adam Beneschan <a...@irvine.com> wrote:
> Anyway, if I feel up to submitting this as a proposed language change,
> I'll make sure you get credit.  I do think this syntax, which you
> mentioned in the previous thread and which I apparently unconsciously
> plagiarized, is the cleanest.

I'm sure I'm not the first to suggest this sort of thing and certainly
wouldn't expect any credit for it!  (Thank you, all the same.)  As you
mentioned, it's not a big leap from conditional expressions.

It would be great if you submitted a proposal along these lines.  I
think it would be genuinely useful in many respects.

Phil

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Britt Snodgrass]

On Oct 15, 7:16 pm, Adam Beneschan <a...@irvine.com> wrote:

> perhaps I'll propose it for the next version of Ada (what is that
> going to be?  Ada 2020, where we add all the features that we realize
> in hindsight that we should have added earlier? :-)).
>

Ada 2020!  I had the same thought a couple of days ago. That's a name
that would catch on. And hopefully by then there will be more than one
vendor who's motivated to implement the current standard.

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Jeffrey Carter]

On 10/19/2010 09:34 AM, Britt Snodgrass wrote:
>
> Ada 2020!  I had the same thought a couple of days ago. That's a name
> that would catch on. And hopefully by then there will be more than one
> vendor who's motivated to implement the current standard.

Considering that the major versions of the standards were published in 1983, 
1995, and 2007, I'd expect the next one in 2019. But since we're supposed to 
call Ada 07 "Ada 2005", I wouldn't be surprised if the next one was called "Ada 
NT" or something like that.

-- 
Jeff Carter
"Hold your temper. Count ten.... Now let 'er go.
You got a good aim."
Never Give a Sucker an Even Break
105

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Vinzent Hoefler]

On Tue, 19 Oct 2010 20:05:09 +0200, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:

> Considering that the major versions of the standards were published in 1983,
> 1995, and 2007, I'd expect the next one in 2019. But since we're supposed to
> call Ada 07 "Ada 2005", I wouldn't be surprised if the next one was called "Ada
> NT" or something like that.

Ada'TweNTy?


Vinzent.

-- 
There is no signature.

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Georg Bauhaus]

On 16.10.10 02:16, Adam Beneschan wrote:

> It seems like it would be simple to add syntax to array aggregates in
> the language like
> 
> a : array(1..N) of Float := (for I in 1..N => Float(I)*Float(I));

I have an array of library level task objects.
Each task is supposed have a unique identifying number,
fixed and assigned at compile time.  Perhaps starting from
a task type definition like the following one:

   task T (Identity : Job_Id := No_Job) is ...

Could some variation of the (for ...) expression solve this,
i.e. provide the initial value?

   Jobs : array (Job_Id) of T := (for D in Job_Id => ???(D));

Borrowing from limited types, I'd think "???" might be just "T"?

   Jobs : array (Job_Id) of T := (for D in Job_Id => T (D));

Georg

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Adam Beneschan]

On Nov 10, 6:33 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 16.10.10 02:16, Adam Beneschan wrote:
>
> > It seems like it would be simple to add syntax to array aggregates in
> > the language like
>
> > a : array(1..N) of Float := (for I in 1..N => Float(I)*Float(I));
>
> I have an array of library level task objects.
> Each task is supposed have a unique identifying number,
> fixed and assigned at compile time.  Perhaps starting from
> a task type definition like the following one:
>
>    task T (Identity : Job_Id := No_Job) is ...
>
> Could some variation of the (for ...) expression solve this,
> i.e. provide the initial value?
>
>    Jobs : array (Job_Id) of T := (for D in Job_Id => ???(D));
>
> Borrowing from limited types, I'd think "???" might be just "T"?
>
>    Jobs : array (Job_Id) of T := (for D in Job_Id => T (D));

This seems like an orthogonal problem.  That is, it's a problem even
when arrays aren't involved.  If you have a record that contains a
task---say you want to create a linked list:

   type Rec;
   type Rec_P is access all Rec;
   type Rec is record
      Job  : T;        -- T is defined with a discriminant
      Link : Rec_P;
   end record;

and you want to create an object of this type and initialize it with
an aggregate:

   Single_Job : aliased Rec := (T(J), null);

where J is some variable or parameter or something, I don't think
there's any current syntax that would allow this.  But I think you can
set up a function:

   function Task_With_ID (Identity : Job_ID := No_Job) return T is
   begin
      return X : T(Identity);
   end;

and use that in your aggregate:

   Single_Job : aliased Rec := (Task_With_ID(J), null);

Warning: I have not tried this.

If this does work, then assuming that a "for" syntax is added for
array aggregates, it can be used in conjunction with a function call
as above.  If you don't like the need for a function call and would
like a different syntax, then one can be proposed, but any solution
should also work in the non-array case.  So this doesn't really have
anything to do with array initialization.

                           -- Adam

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Dmitry A. Kazakov]

On Wed, 10 Nov 2010 07:51:07 -0800 (PST), Adam Beneschan wrote:

> This seems like an orthogonal problem. That is, it's a problem even
> when arrays aren't involved.  If you have a record that contains a
> task---say you want to create a linked list:
> 
>    type Rec;
>    type Rec_P is access all Rec;
>    type Rec is record
>       Job  : T;        -- T is defined with a discriminant
>       Link : Rec_P;
>    end record;

But this is illegal if T has discriminants, they must be given for Job.
(And task components do not work in Ada anyway)

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

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Adam Beneschan]

On Nov 10, 9:19 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Wed, 10 Nov 2010 07:51:07 -0800 (PST), Adam Beneschan wrote:
> > This seems like an orthogonal problem. That is, it's a problem even
> > when arrays aren't involved.  If you have a record that contains a
> > task---say you want to create a linked list:
>
> >    type Rec;
> >    type Rec_P is access all Rec;
> >    type Rec is record
> >       Job  : T;        -- T is defined with a discriminant
> >       Link : Rec_P;
> >    end record;
>
> But this is illegal if T has discriminants, they must be given for Job.

T was declared with a default discriminant in Georg's example, so I
think it's legal.

                           -- Adam

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Georg Bauhaus]

On 11/10/10 4:51 PM, Adam Beneschan wrote:

>>     Jobs : array (Job_Id) of T := (for D in Job_Id =>  ???(D));
>>
>> ...

> ... But I think you can set up a function:
>
>     function Task_With_ID (Identity : Job_ID := No_Job) return T is
>     begin
>        return X : T(Identity);
>     end;
>
> and use that in your aggregate:
>
>     Single_Job : aliased Rec := (Task_With_ID(J), null);
>
> Warning: I have not tried this.

Tested with GNAT GPL 2010, it works.  In particular,

    Jobs : array (Job_Id) of T := (others => Make);

works, where construction function Make advances Job_Id
values for T's discriminant internally.  The setup is less
static, though.   The (for ...) syntax
will leave little doubt as to which index values Make
(or something in its place) is using to produce a T object.
That is not obvious  now.
(All as long a T can have a default discriminant.)

Just an ad-hoc idea:

    Jobs : array (X: Job_Id) of T := (others => Make(X));

where X: Job_Id is a little like a record discriminant
passed on to constrain components, for example,
only with a different "multiplicity".

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Dmitry A. Kazakov]

On Thu, 11 Nov 2010 02:07:39 +0100, Georg Bauhaus wrote:

> Just an ad-hoc idea:
> 
>     Jobs : array (X: Job_Id) of T := (others => Make(X));
> 
> where X: Job_Id is a little like a record discriminant
> passed on to constrain components, for example,
> only with a different "multiplicity".

That is by no way ad-hoc, I had this idea for a long time. The array
indices should have been named (optionally of course). It was missed in the
Ada 83 design.

Then the above could simply become:

   type Worker_Set is array (ID : Job_ID range <>) of T (ID);
        -- No discriminant default value needed

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

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Robert A Duff]

Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> writes:

>    Jobs : array (Job_Id) of T := (others => Make);
>
> works, where construction function Make advances Job_Id
> values for T's discriminant internally.

The calls to Make can happen in any order.  So every task
gets a unique job id, but the N'th element of Jobs does
not necessarily have job id N.

- Bob

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Georg Bauhaus]

On 11.11.10 13:02, Robert A Duff wrote:
> Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> writes:
> 
>>    Jobs : array (Job_Id) of T := (others => Make);
>>
>> works, where construction function Make advances Job_Id
>> values for T's discriminant internally.
> 
> The calls to Make can happen in any order.  So every task
> gets a unique job id, but the N'th element of Jobs does
> not necessarily have job id N.

Ouch, yes. Though it had not mattered in my particular case,
expressly ordering construction parameters makes a (for ...)
loop or similar look even more desirable---for the static
case.

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Jeffrey Carter]

On 10/15/2010 04:03 PM, Nasser M. Abbasi wrote:
>
> I was wondering if in Ada I can initialize some array, where I can fill
> the content of each entry in the array based on some function of the index?
>
>
> In Ada, what would I need to do in the initialization below?
> ---------------------------
> a: array(1..N) of float := (others=>0.0); --??

Of course, if you're willing to avoid the evil that is anonymous types and write 
a function:

type Meaningful_Type_Name is array (1 .. N) of Float;

function Meaningful_Function_Name return Meaningful_Type_Name is ...

Meaningful_Object_Name : Meaningful_Type_Name := Meaningful_Function_Name;

-- 
Jeff Carter
"Strange women lying in ponds distributing swords
is no basis for a system of government."
Monty Python & the Holy Grail
66

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Gene]

On Oct 15, 7:03 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> Ada experts:
>
> I am not able to find an example on this.
>
> I was wondering if in Ada I can initialize some array, where I can fill
> the content of each entry in the array based on some function of the index?
>
> For example, in Fortran one can do this:
> -----------------------
> program main
>    integer, parameter :: N = 10
>    real, dimension(N) :: a=(/(j**2,j=1,N)/)
>
>    print*, a
> end program
> ------------------------
> $ gfortran t3.f90
> $ ./a.exe
>     1.0000000       4.0000000       9.0000000       16.000000 etc....
>
> In Ada, what would I need to do in the initialization below?
> ---------------------------
> procedure t2 is
>     N: constant integer := 10;
>     a: array(1..N) of float := (others=>0.0); --??
> begin
>     null;
> end t2;
> -----------------------------
>
> I know ofcourse I can initialize it in the body by a loop, just wanted
> to see if it is possible to do it in the elaboration.

It's ugly, but you can get the effect with something like:

  Initializer_Index : Natural := 0;

  function Initial_Function_Of_Index return Float is
  begin
    Initializer_Index := Initializer_Index + 1;
    return 2.0 * Float(Initializer_Index);
  end;

  A : array(1 .. 100) of Float := (others =>
Initializer_Function_Of_Index);

What you're asking about is called a comprehension or list
comprehension. I agree it would be nice to have them.

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Vinzent Hoefler]

On Sat, 16 Oct 2010 02:54:05 +0200, Gene <gene.ressler@gmail.com> wrote:

> It's ugly, but you can get the effect with something like:
>
>   Initializer_Index : Natural := 0;
>
>   function Initial_Function_Of_Index return Float is
>   begin
>     Initializer_Index := Initializer_Index + 1;
>     return 2.0 * Float(Initializer_Index);
>   end;
>
>   A : array(1 .. 100) of Float := (others =>
> Initializer_Function_Of_Index);

Don't try this at home, kids.

See ARM 4.3.3(23) about evaluation order.


Vinzent.

-- 
There is no signature.

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Chad R. Meiners]

On Oct 15, 7:03 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> Ada experts:
>
> I am not able to find an example on this.
>
> I was wondering if in Ada I can initialize some array, where I can fill
> the content of each entry in the array based on some function of the index?
>
> For example, in Fortran one can do this:
> -----------------------
> program main
>    integer, parameter :: N = 10
>    real, dimension(N) :: a=(/(j**2,j=1,N)/)
>
>    print*, a
> end program
> ------------------------
> $ gfortran t3.f90
> $ ./a.exe
>     1.0000000       4.0000000       9.0000000       16.000000 etc....
>
> In Ada, what would I need to do in the initialization below?
> ---------------------------
> procedure t2 is
>     N: constant integer := 10;
>     a: array(1..N) of float := (others=>0.0); --??
> begin
>     null;
> end t2;
> -----------------------------
>
> I know ofcourse I can initialize it in the body by a loop, just wanted
> to see if it is possible to do it in the elaboration.
>
> thanks
> --Nasser

We can borrow a page from either ocaml and F# and set up a generic
initialize function.

I don't have access to a compiler and I haven't programmed in Ada for
years, but below is the general idea.

generic
  type T is array (I) of E;
  with function expression(Index: I) return E;
function init return T is
  val : T;
begin
  for index in I'Range loop
    val(index) := expression(I);
  end loop;
  return val;
end function;

procedure t2 is
  N : constant Integer := 10;

  type Foo is array(1..N) of float;
  function exp(j : Integer) return float is return float(j**2); end
function;
  function initFoo is new init(Foo,exp);

  a : Foo := initFoo;
begin
  null;
end t2;

for those interested how it would be done in F# (which has a type
generic init function for arrays):

let t2 () =
  let N = 10 in
  let a = Array.init N (fun j -> let j = j+1 in j*j |> float)
  in ()

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Shark8]

Interesting.
It doesn't look like it would be very extensible into multidimensional
arrays though.

Perhaps something like an 'Initialize attribute [on the type, not the
variables thereof] which would take an Access to Function returning
that type. It would have to be called only in the case of K :
Array_Type because K : Array_Type:= (Others => <>) is providing an
initialization of the default value to all the elements [which is
unlikely to match the initialization's value].

However, it is the internals of the function which are interesting if
this route were taken.  The indexings need to be discrete types,
however they need not be numeric or even all the same type. This
results in the following being valid:
  Type A_HighSchool_Letterjacket_Type is Array (Size, Color,
Character) of Byte; -- A jacket-maker's inventory for letter-jackets.

So we can't have an "array" representing the indicies for use in the
initialization-function.
(ex: ---Invalid
  For Index_1 in Index(1)'Range loop
    For Index_2 in Index(2)'Range loop
      For Index_3 in Index(3)'Range loop
        -- do stuff for calculating the value stored;
      end loop;
    end loop;
  end loop;
)

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Phil Clayton]

On Oct 24, 5:40 pm, Shark8 <onewingedsh...@gmail.com> wrote:
> Interesting.
> It doesn't look like it would be very extensible into multidimensional
> arrays though.
>
> Perhaps something like an 'Initialize attribute [on the type, not the
> variables thereof] which would take an Access to Function returning
> that type. It would have to be called only in the case of K :
> Array_Type because K : Array_Type:= (Others => <>) is providing an
> initialization of the default value to all the elements [which is
> unlikely to match the initialization's value].
>
> However, it is the internals of the function which are interesting if
> this route were taken.  The indexings need to be discrete types,
> however they need not be numeric or even all the same type. This
> results in the following being valid:
>   Type A_HighSchool_Letterjacket_Type is Array (Size, Color,
> Character) of Byte; -- A jacket-maker's inventory for letter-jackets.
>
> So we can't have an "array" representing the indicies for use in the
> initialization-function.
> (ex: ---Invalid
>   For Index_1 in Index(1)'Range loop
>     For Index_2 in Index(2)'Range loop
>       For Index_3 in Index(3)'Range loop
>         -- do stuff for calculating the value stored;
>       end loop;
>     end loop;
>   end loop;
> )

Good point.  I think it is ok for multidimensional arrays given the
right interpretation of a "for expression" though.

In fact, it should probably be called a "for aggregate".  It looked
like Adam was suggesting that it would just be another case of
array_aggregate (4.3.3) in the syntax.  So a nested "for aggregate"
would, presumably, work as a subaggregate allowing multidimensional
arrays to handled.

Another way to think about this is that

  (for I in T => F(I))

would be equivalent to and interchangeable with the named aggregate

  (X1 => F(X1), X2 => F(X2), ...)

where X1, X2, ... are the elements of subtype T.  With that view, it
seems a fairly simple extension to the language from a technical
perspective.

Phil

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Shark8]

On Oct 24, 4:48 pm, Phil Clayton <phil.clay...@lineone.net> wrote:
> Another way to think about this is that
>
>   (for I in T => F(I))
>
> would be equivalent to and interchangeable with the named aggregate
>
>   (X1 => F(X1), X2 => F(X2), ...)
>
> where X1, X2, ... are the elements of subtype T.  With that view, it
> seems a fairly simple extension to the language from a technical
> perspective.
>
> Phil

True enough; however just because something is easy (or *CAN* be done)
doesn't make it the right thing.
The C/C++ allowance of assignments within the conditional-test is a
good example of something that *CAN* be done that shouldn't be.
The syntax of the proposed (for ... ) construct simply look _wrong_ to
me, like a human-knee bending backward. {I think the same about the
new conditional expressions too, they simply go against the grain of
the rest of the language IMO.}

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Phil Clayton]

On Oct 25, 3:23 am, Shark8 <onewingedsh...@gmail.com> wrote:
> On Oct 24, 4:48 pm, Phil Clayton <phil.clay...@lineone.net> wrote:
> > With that view, it
> > seems a fairly simple extension to the language from a technical
> > perspective.
>
> True enough; however just because something is easy (or *CAN* be done)
> doesn't make it the right thing.
> The C/C++ allowance of assignments within the conditional-test is a
> good example of something that *CAN* be done that shouldn't be.

Sure, and no doubt it isn't quite as easy as it seems.


> The syntax of the proposed (for ... ) construct simply look _wrong_ to
> me, like a human-knee bending backward. {I think the same about the
> new conditional expressions too, they simply go against the grain of
> the rest of the language IMO.}

Mmm.. nice image!  For me, I am only slightly twitchy about the syntax
due to an irrational fear of drowning in parentheses.  What sort of
syntax would look natural to you?

Phil

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Shark8]

On Oct 29, 5:26 pm, Phil Clayton <phil.clay...@lineone.net> wrote:
> On Oct 25, 3:23 am, Shark8 <onewingedsh...@gmail.com> wrote:
>
> > The syntax of the proposed (for ... ) construct simply look _wrong_ to
> > me, like a human-knee bending backward. {I think the same about the
> > new conditional expressions too, they simply go against the grain of
> > the rest of the language IMO.}
>
> Mmm.. nice image!  For me, I am only slightly twitchy about the syntax
> due to an irrational fear of drowning in parentheses.  What sort of
> syntax would look natural to you?
>
> Phil

Ah, if you think that'll trigger "drowning in parentheses"-fear then
you should probably stay away from LISP.

As for a better syntax, I'm not sure; but then again I'm not sure that
an "x:= y if b else z"-style of expression is actually needed given
that we have declare-blocks.

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Georg Bauhaus]

On 10/31/10 7:47 PM, Shark8 wrote:

> As for a better syntax, I'm not sure; but then again I'm not sure that
> an "x:= y if b else z"-style of expression is actually needed given
> that we have declare-blocks.

Conditional expressions are used in aspect specifications.
Specifically in preconditions, postconditions, and type invariants.
The look natural, there.   AI 183 and AI 145.

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Phil Clayton]

On Oct 31, 6:47 pm, Shark8 <onewingedsh...@gmail.com> wrote:
> Ah, if you think that'll trigger "drowning in parentheses"-fear then
> you should probably stay away from LISP.

I do.  On the subject of LISP, I saw a great talk recently on Clojure
(think LISP on JVM) containing what is now one of my all time
favourite slides:
http://blog.fogus.me/2010/10/25/fertile-ground-the-roots-of-clojure/
Go to slide 21 (of 75).


> As for a better syntax, I'm not sure; but then again I'm not sure that
> an "x:= y if b else z"-style of expression is actually needed given
> that we have declare-blocks.

Are loop statements actually needed given the presence of conditional
statements and goto statements? :)

Phil

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Shark8]

On Oct 31, 6:45 pm, Phil Clayton <phil.clay...@lineone.net> wrote:
> On Oct 31, 6:47 pm, Shark8 <onewingedsh...@gmail.com> wrote:
>
> > Ah, if you think that'll trigger "drowning in parentheses"-fear then
> > you should probably stay away from LISP.
>
> I do.  On the subject of LISP, I saw a great talk recently on Clojure
> (think LISP on JVM) containing what is now one of my all time
> favourite slides:http://blog.fogus.me/2010/10/25/fertile-ground-the-roots-of-clojure/
> Go to slide 21 (of 75).

Heh; slightly amusing.

> > As for a better syntax, I'm not sure; but then again I'm not sure that
> > an "x:= y if b else z"-style of expression is actually needed given
> > that we have declare-blocks.
>
> Are loop statements actually needed given the presence of conditional
> statements and goto statements? :)

Well, since we started talking about LISP, strictly-speaking no, you
don't need loops.
While LISP is a bit different and parenthesis-heavy, it is certainly a
high-level language;
that you need to use a different style of thinking than you're used to
is slightly irrelevant.

C & C++ have loops but some VERY good arguments can be made that they
are *NOT* high-level languages;
that there are a significant portion of C programmers who recognize C
as "basically assembler with
some syntax-sugar" reinforces such an assertion. {That same group is
quite likely to have the idea
that C is better for systems-programming because it is law-level.}

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Brian Drummond]

On Sun, 24 Oct 2010 19:23:11 -0700 (PDT), Shark8 <onewingedshark@gmail.com>
wrote:

>On Oct 24, 4:48�pm, Phil Clayton <phil.clay...@lineone.net> wrote:
>> ... �With that view, it
>> seems a fairly simple extension to the language from a technical
>> perspective.
>>
>> Phil
>
>True enough; however just because something is easy (or *CAN* be done)
>doesn't make it the right thing.
>The C/C++ allowance of assignments within the conditional-test is a
>good example of something that *CAN* be done that shouldn't be.
>The syntax of the proposed (for ... ) construct simply look _wrong_ to
>me, like a human-knee bending backward.

While I wholeheartedly agree with the above ...

> {I think the same about the
>new conditional expressions too, they simply go against the grain of
>the rest of the language IMO.}

... having been raised on Algol-W I am delighted to see them come back.

Is it their unfamiliarity that disturbs you? 

They don't appear to have the same possibility for disaster as your C example,
and have been around in some form in VHDL for decades. 
(In the combinatorial/parallel part of the language. VHDL2008 reintroduces them
to the sequential part, inside processes)

- Brian

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Shark8]

> ... having been raised on Algol-W I am delighted to see them come back.
>
> Is it their unfamiliarity that disturbs you?

No, not so much.
I don't see how they are [strictly-speaking] necessary, given that we
have declare-blocks (which can be arbitrarily-nested).
Granted, they would make it a lot less verbose in many cases. {BTW, if
we're going to allow if/then statements inside expressions &
assignments/initializations then what's keeping us from using case-
statements too?}

>
> They don't appear to have the same possibility for disaster as your C example,
> and have been around in some form in VHDL for decades.

That's quite true. However, I've learned to be careful around C/C++;
they are full of little inconsistencies that the compiler will happily
consume, only to surprise you twenty minutes before the assignment is
due [for students] or eight months after you've deployed your software
[for businesses].

> (In the combinatorial/parallel part of the language. VHDL2008 reintroduces them
> to the sequential part, inside processes)

Interesting; what is the VHDL syntax for them, if I might ask?

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[(see below)]

On 31/10/2010 20:00, in article
d779c161-3199-45ca-87ae-d0501c74e219@26g2000yqv.googlegroups.com, "Shark8"
<onewingedshark@gmail.com> wrote:

>> ... having been raised on Algol-W I am delighted to see them come back.
>> 
>> Is it their unfamiliarity that disturbs you?
> 
> No, not so much.
> I don't see how they are [strictly-speaking] necessary, given that we
> have declare-blocks (which can be arbitrarily-nested).

"Necessary" is not a valid criterion for anything more human-oriented than a
Turing machine. Remember that Ada views programming, above all, as a human
activity.

> Granted, they would make it a lot less verbose in many cases. {BTW, if
> we're going to allow if/then statements inside expressions &
> assignments/initializations then what's keeping us from using case-
> statements too?}

Absolutely nothing.
Algol W and Ada 2012 (I'm delighted to see) have both.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Shark8]

> "Necessary" is not a valid criterion for anything more human-oriented than a
> Turing machine. Remember that Ada views programming, above all, as a human
> activity.

Hm, I disagree there. 'Necessary' is an extraordinarily valid
criterion for precise-languages, and even precision within languages.
One could argue that the lower-case letters are not necessary, and as
far as the possession of an alphabet goes they are not; English,
however, places some constraints on when to capitalize something --
the following two sentences are exactly the same except for a single
instance of capitalization:
I helped my uncle Jack off a horse.
I helped my uncle jack off a horse.

These two sentences have differing meanings because of English and,
therefore, we can see that insofar as English is concerned Upper-case
and Lower-case letters are not unnecessary.

This relates, because we were discussing the design of languages
(specifically Ada). If we were to throw in every idea that people had
w/o regard to 'necessary' we would quickly have a mess of a language
the result of which would make C++ look like Ada, comparatively. (That
is to say, all hope of consistency would be lost.)

In my opinion, I think that something like Delphi's properties on
objects would be useful; though they are strictly-speaking not
necessary (though they certainly could simplify 'interface' objects by
unifying 'getters' and 'setters'). That is something presented to the
outside world as a field of an object which may be readable and or
writable and may 'rename' a private-field or method of that object.
{You could then then have a 'field' that validates incoming data when
it is set; like disallowing someone from setting their computer's
Calendar to 31 Feb.}

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[(see below)]

On 31/10/2010 20:35, in article
3450508b-9f26-4f26-8cd1-70149ca113dc@b17g2000yqa.googlegroups.com, "Shark8"
<onewingedshark@gmail.com> wrote:

>> "Necessary" is not a valid criterion for anything more human-oriented than a
>> Turing machine. Remember that Ada views programming, above all, as a human
>> activity.
> 
> Hm, I disagree there. 'Necessary' is an extraordinarily valid
> criterion for precise-languages, and even precision within languages.
... 
> This relates, because we were discussing the design of languages
> (specifically Ada). If we were to throw in every idea that people had
> w/o regard to 'necessary' we would quickly have a mess of a language
> the result of which would make C++ look like Ada, comparatively. (That
> is to say, all hope of consistency would be lost.)

But this is a non sequitur. Saying that necessity is not a valid {I should
better have said "adequate"} criterion is is no way equivalent to saying
that that anything goes.  We are united in thinking that Ada should never
look like C++. I'm confident that there is no chance of that happening.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Shark8]

On Oct 31, 4:47 pm, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
> We are united in thinking that Ada should never look like C++.
> I'm confident that there is no chance of that happening.
>
> --
> Bill Findlay
> <surname><forename> chez blueyonder.co.uk

Indeed. Which is why I tend to scrutinize the features 'imported' from
c/C++ derived languages; the Java-style Interface, for example.
Is it useful, yes; just like the specifications in generics can be
used to solve a whole class of problems so can interfaces deliver a
guarantee that some object contains some function. {I've already
stated that they would have made Interfaces a lot more user-friendly
with the notion of properties; delegation, where some member of the
object implements the interface or some portion of it, would have been
nice too.}

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[(see below)]

On 01/11/2010 01:07, in article
214a69e5-c640-444c-8417-65a1102e20de@s4g2000yql.googlegroups.com, "Shark8"
<onewingedshark@gmail.com> wrote:

> On Oct 31, 4:47�pm, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
>> We are united in thinking that Ada should never look like C++.
>> I'm confident that there is no chance of that happening.
... 
> Indeed. Which is why I tend to scrutinize the features 'imported' from
> c/C++ derived languages; the Java-style Interface, for example.
> Is it useful, yes; just like the specifications in generics can be
> used to solve a whole class of problems so can interfaces deliver a
> guarantee that some object contains some function. {I've already
> stated that they would have made Interfaces a lot more user-friendly
> with the notion of properties; delegation, where some member of the
> object implements the interface or some portion of it, would have been
> nice too.}

The OOP aspect of Ada that makes me grumpy is the brain-deadening awfulness
of the gyrations needed for declaring constructors.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Brian Drummond]

On Sun, 31 Oct 2010 12:00:20 -0700 (PDT), Shark8 <onewingedshark@gmail.com>
wrote:

>> ... having been raised on Algol-W I am delighted to see them come back.
>>
>> Is it their unfamiliarity that disturbs you?
>
>No, not so much.
>I don't see how they are [strictly-speaking] necessary, given that we
>have declare-blocks (which can be arbitrarily-nested).
>Granted, they would make it a lot less verbose in many cases. {BTW, if
>we're going to allow if/then statements inside expressions &
>assignments/initializations then what's keeping us from using case-
>statements too?}

Nothing, as long as we can escape from expecting that all languages should look
like C...

>> They don't appear to have the same possibility for disaster as your C example,
>> and have been around in some form in VHDL for decades.
>
>That's quite true. However, I've learned to be careful around C/C++;
>they are full of little inconsistencies that the compiler will happily
>consume, 

Absolutely ... aaah, perhaps you have C's :? syntax in mind...
That makes me uncomfortable too, and it took me a long time to figure out why.

It's psychological; given the additional circumstances that booleans are
integers in C, I am strongly conditioned to expect the choices to be in
ascending order ( i.e. 0, 1, ... yet they are in descending order). 

Given that, I have always regarded C's ?: conditional operator as a poor
relation to if-expressions.
(I can still never read it correctly without stopping and thinking.)

Algol-W allows if- and case-expressions; as you suggest, there is no reason to
allow one and prohibit the other.

(approximate Ada syntax - untested!)

days := case month is
            feb => if leap(year) then 29 else 28;
            apr, jun, sept, nov =>30;
            others => 31;

>
>> (In the combinatorial/parallel part of the language. VHDL2008 reintroduces them
>> to the sequential part, inside processes)
>
>Interesting; what is the VHDL syntax for them, if I might ask?

A 2-way multiplexer can be written as

S <= A when SEL_A else B;

(A, B, SEL_A, S are signals, SEL_A is of type Boolean)
For this example I am using capitals for labels, lower case for keywords, but
VHDL is case-insensitive like Ada.

A 4-way multiplexer can be written as 

with SEL select
	S <= 	A when 0,
		B when 1,
		C when 2,
		D when 3,
		'Z' when others;

In this example, SEL is an integer signal. S and A..D are signals of a type
(std_logic) which allows a value 'Z' which means tristate or high impedance.
This means that S is undriven in the "others" case, and may be driven by some
other entity (not shown). Otherwise the example could have ended at 
"		D when others; " or even 
"		D when 3;" 
for which SEL should be an appropriately ranged integer type!

Signals in VHDL are (slightly) similar to Occam channels, or rendezvous between
Ada tasks, which are likewise similar to VHDL processes.

Thus the 2-way mux above is shorthand for

process (A,B,SEL_A);
begin
    if SEL_A then
      S <= A;
   else
      S <= B;
   end if;
end process;

This process wakes up on any event on any signal in its sensitivity list
(A,B,SEL_A, entries in Ada terms) and executes its sequential code until either
completion or a "wait" statement.

 In this case, the sequential code is merely a conditional statement and one of
two possible signal assignments. However it could use almost any sequential code
construct familiar from Ada. 

<= here denotes signal assignment, which can wake up other processes sensitive
to S. Processes can also have variables with the familiar := assignment; these
are only visible within the process, while signals connect between processes.

VHDL2008 allows the "when" and "select" forms in expressions within the
sequential code in processes. Why "when" and "select" when it uses "if" and
"case" to denote the equivalent statements, is a mystery to me...

- Brian       

Re: initialize an array (1-D) at elaboration using an expression based on the index?

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:d779c161-3199-45ca-87ae-d0501c74e219@26g2000yqv.googlegroups.com...
>> ... having been raised on Algol-W I am delighted to see them come back.
>>
>> Is it their unfamiliarity that disturbs you?
>
> No, not so much.
> I don't see how they are [strictly-speaking] necessary, given that we
> have declare-blocks (which can be arbitrarily-nested).
> Granted, they would make it a lot less verbose in many cases. {BTW, if
> we're going to allow if/then statements inside expressions &
> assignments/initializations then what's keeping us from using case-
> statements too?}

(Yes, Ada2012 has case expressions; coverage checking is important and not 
be be sacrificed just because you are writing an expression.)

You can't write a declare block in a declarative part, inside of a pragma, 
or (for Ada 2012) inside of an aspect specification or expression function. 
The first is a significant problem in Ada 95; you have to write:

                  Max_Value : constant Natural := Boolean'Pos(<some 
expr>)*TRUE_VALUE+
                                                                    Boolean'Pos(not 
<some expr>)*FALSE_VALUE;

In order to get a static conditional expression. To claim that the above is 
at all understandable or readable is BS, plus it duplicates the expression.

                  Max_Value : constant Natural := (if <some expr> then 
TRUE_VALUE else FALSE_VALUE);

is worlds better. And it gets even more fun if you have multiple cases...

                             Randy.