Prev: Ann: Generic Image Decoder v.01
Next: ANN: Tables 1.10
From: Dmitry A. Kazakov on 5 Jul 2010 09:12 On Sun, 4 Jul 2010 18:27:04 -0700 (PDT), Phil Clayton wrote: > In my view, condition expressions are a step in the right direction... > but I'm the sort of person who wants to write an array aggregate like > > (for I in 1 .. 5 => (for J in 1 .. 7 => (if I = J then 1.0 else > 0.0))) (for I in 1..5 => (for J in 1..7 => Float (Boolean'Pos (I = J)))) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Phil Clayton on 5 Jul 2010 10:24 On Jul 5, 11:26 am, Georg Bauhaus <rm.dash-bauh...(a)futureapps.de> wrote: > On 05.07.10 03:27, Phil Clayton wrote: > > > On Jun 30, 4:21 am, Britt Snodgrass <britt.snodgr...(a)gmail.com> wrote: > > For formal verification tools, conditional expressions could be > > useful. For example, there are two paths through > > > if C then > > Y := A; > > else > > Y := B; > > end if; > > > but only one path through > > > Y := (if C then A else B); > > Any advantage over a function---which in SPARK case will > be a pure function, IIRC? > > Y := Find_Y (Depends => C); Not much advantage over a function, only that you don't have the overheads of introducing the new function and ensuring its specification has sufficient information. I wasn't really considering the possibility of introducing new functions as a general alternative. For example, I would rather see certain conditional expressions inline and not tucked away inside functions, for readability. (Correct, SPARK does not allow functions to have side effects.) > > In my view, condition expressions are a step in the right direction... > > but I'm the sort of person who wants to write an array aggregate like > > > (for I in 1 .. 5 => (for J in 1 .. 7 => (if I = J then 1.0 else > > 0.0))) > > What kind of name would you pick for the thing? I suppose I'd call it a 'tabulation'.. Phil
From: Phil Clayton on 5 Jul 2010 18:47 On Jul 5, 2:12 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Sun, 4 Jul 2010 18:27:04 -0700 (PDT), Phil Clayton wrote: > > In my view, condition expressions are a step in the right direction... > > but I'm the sort of person who wants to write an array aggregate like > > > (for I in 1 .. 5 => (for J in 1 .. 7 => (if I = J then 1.0 else > > 0.0))) > > (for I in 1..5 => (for J in 1..7 => Float (Boolean'Pos (I = J)))) Yep, I should have seen that one coming straight back... and taken steps to avoid it :) Phil
From: Dmitry A. Kazakov on 6 Jul 2010 03:36 On Mon, 5 Jul 2010 15:47:41 -0700 (PDT), Phil Clayton wrote: > On Jul 5, 2:12�pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> On Sun, 4 Jul 2010 18:27:04 -0700 (PDT), Phil Clayton wrote: >>> In my view, condition expressions are a step in the right direction... >>> but I'm the sort of person who wants to write an array aggregate like >> >>> � (for I in 1 .. 5 => (for J in 1 .. 7 => (if I = J then 1.0 else >>> 0.0))) >> >> � (for I in 1..5 => (for J in 1..7 => Float (Boolean'Pos (I = J)))) > > Yep, I should have seen that one coming straight back... and taken > steps to avoid it :) BTW, is your construct 1) a macro expansion (as I remember PL/1 preprocessor also had %for statement alike) and how far are you ready to go allowing "for" macros? Loops unrolling? Or else 2) it is an attempt to name the components of an array element index. In the latter case (I, J : others => <an expression involving I,J>) (I : 1..5 => <an expression involving I>) (Odd : 1 | 3 | 5 | 7 => <an expression involving Odd>, others => 0.0) etc looks to me more consistent with existing Ada, e.g. when Error : others => in exception handlers. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Georg Bauhaus on 6 Jul 2010 05:13
On 06.07.10 09:36, Dmitry A. Kazakov wrote: > BTW, is your construct 1) a macro expansion (as I remember PL/1 > preprocessor also had %for statement alike) and how far are you ready to go > allowing "for" macros? Loops unrolling? Or else 2) it is an attempt to name > the components of an array element index. In the latter case > > (I, J : others => <an expression involving I,J>) > (I : 1..5 => <an expression involving I>) > (Odd : 1 | 3 | 5 | 7 => <an expression involving Odd>, others => 0.0) > etc > > looks to me more consistent with existing Ada, e.g. when Error : others => > in exception handlers. I think that AI 05 177 might be on topic. http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0177-1.txt |