This proposal doesn't seem like a fair comparison:
It presents a new form of the 'for of' syntax that provides the key and the
value in the loop, and contrasts it with using a generic to manage the loop.
The more accurate contrast would be with a 'for in' loop - especially the Ada
2012 kind, which can provide access to the iterator (or Cursor) in the loop.
The existing syntax that someone might use to contrast that with is:
for Cursor in My_Obj.Iterate loop
Do_Something_With (Container_Pkg.Key (Cursor), Container_Pkg.Value
(Cursor));
end loop;
(You could also write Do_Something to take a Cursor, depending on its
relationship to the container type)
Note: Here, the Iterate procedure returns an Interator from
Ada.Iterator_Interfaces, and the Cursor type has a Key and Value function.
Not all Cursor types have both, since a key isn't relevant for all iterate-able
structures; Doubly linked lists don't have a meaningful key, and Vectors have a
"To_Index" function instead of a Key function.
A structure comparable two a multi-dimensional array could have multiple keys;
but that's not much different from a key with multiple elements.
I'm not saying it's a bad idea - it would give the 'best of both worlds' of a
"for in" and a "for of" loop in one.
- "For in" gives the cursor (which typically has accessors for key and value),
"For of" just gives the value without the key.)
I prefer "for of" loops for any case where I don't actually need the key (or
index). If I need the key (or index), I use "for in"
Tucker's suggested new syntax would make it easier to get the key and value
inside the loop (eliminating the step of having to extract them from the
Cursor),
but the existing cost of doing so is pretty small because of what was added in
Ada 2012, and doesn't typically require a generic.
Joshua Fletcher
613-721-4405
-----Original Message-----
From: Tucker Taft @ adacore <[email protected]>
Sent: Tuesday, December 3, 2019 6:19 PM
To: Ada-Comment List <[email protected]>
Subject: [Ada-Comment] Possible generalization of Procedural Iterator
While putting together some slides about the "procedural iterator"
(https://smex-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=http%3a%2f%2fwww.ada%2dauth.org%2fstandards%2f2xaarm%2fhtml%2fAA%2d5%2d5%2d3.html&umid=0ba83771-1871-4370-99cd-3ddf9200b2b6&auth=eb73852e237f4c399a45f8ab019f4a6dae168ea9-19b9591f9899b75811cd3682211a7403b49e9b92)
I realized that there is a very similar case which comes up very often, at
least in my code, which might also benefit from the procedural iterator
syntactic sugar. In particular, I have many, many instances of generic
(iterating) procedures that have exactly one generic formal parameter, which is
a formal procedure. For example:
generic
with procedure Action (Key : Key_Type; Value : Value_Type);
procedure Iterate_Some_Structure (Obj : Structure_Type);
A typical usage is as follows:
declare
procedure Process_One (Key : Key_Type; Value : Value_Type) is
begin
Do_Something_With (Key, Value);
end Process_One;
procedure Process_All is new Iterate_Some_Structure (Process_One);
begin
Process_All (My_Obj);
end;
This is quite similar to the situation of calling an iterating procedure that
has a single access-to-procedure parameter, plus zero or more other parameters.
So perhaps the same syntactic sugar should apply. That is:
for (Key, Value) of Iterate_Some_Structure (My_Obj) loop
Do_Something_With (Key, Value);
end loop;
I would claim that the "sugared" version is much easier to read and understand
than the gobbledygook above it. And at least from my experience, I have many
places where I could use this second sort of procedural iterator. One
interesting aspect of this second sugaring is that the parameters are already
separated into the formal procedure and the other parameters, so there is no
need for a "<>" placeholder.
Comments?
-Tuck
________________________________________________________
You have received this message because you subscribed to the Ada-Comment
mailing list. To leave the Ada-Comment list, send an email with 'leave
Ada-Comment' in the body to [email protected]. For help on the other
commands available, send 'help Ada-Comment' to the same address.
Problems? Send mail to [email protected]. This list is operated by the Ada
Resource Association, Inc., PO Box 8685, New York NY 10116-8685.
“This message and/or attachments may include information subject to GD
Corporate Policies 07-103 and 07-105 and is intended to be accessed only by
authorized recipients. Use, storage and transmission are governed by General
Dynamics and its policies. Contractual restrictions apply to third parties.
Recipients should refer to the policies or contract to determine proper
handling. Unauthorized review, use, disclosure or distribution is prohibited.
If you are not an intended recipient, please contact the sender and destroy all
copies of the original message.”
