Iterators in Ada2012

Iterators in Ada2012

[comp.lang.php]

I have an instantiation of the package Ada.Containers.Ordered_Maps
(Integer, Float). Is there a neat way of iterating over the values
similar to the construction:
for x of a_Set loop ... end loop.

Re: Iterators in Ada2012

[Georg Bauhaus]

On 08.11.11 11:05, comp.lang.php wrote:
> I have an instantiation of the package Ada.Containers.Ordered_Maps
> (Integer, Float). Is there a neat way of iterating over the values
> similar to the construction:
> for x of a_Set loop ... end loop.

Fear of nesting a procedure? :-)

I had thought that the new syntax of AI 139 would be for all
containers.

Strangely, the fashion seems to be moving elsewhere:
list comprehensions, Map + Reduce (US Patent #7,650,331), Scala,
... all functional, hence little sympathy for for-loops.
Sequence comprehensions are now recommended when
writing Python, so I had thought there is all the more
to say in favor of a simple automatic

  Container.Iterate (Process => Meaningful_Name'Access).

But OTOH, Guido van Rossum suggested to simply write a
for-loop in place of a traditional reduce procedure.
With Ada, the two can be combined...

Re: Iterators in Ada2012

[Dmitry A. Kazakov]

On Tue, 08 Nov 2011 14:13:03 +0100, Georg Bauhaus wrote:

> On 08.11.11 11:05, comp.lang.php wrote:
>> I have an instantiation of the package Ada.Containers.Ordered_Maps
>> (Integer, Float). Is there a neat way of iterating over the values
>> similar to the construction:
>> for x of a_Set loop ... end loop.
> 
> Fear of nesting a procedure? :-)
> 
> I had thought that the new syntax of AI 139 would be for all
> containers.
> 
> Strangely, the fashion seems to be moving elsewhere:

Lady Gaga or lady Lovelace? (:-))

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

Re: Iterators in Ada2012

[R. Tyler Croy]

On Tue, 08 Nov 2011 14:13:03 +0100, Georg Bauhaus wrote:

> On 08.11.11 11:05, comp.lang.php wrote:
>> I have an instantiation of the package Ada.Containers.Ordered_Maps
>> (Integer, Float). Is there a neat way of iterating over the values
>> similar to the construction:
>> for x of a_Set loop ... end loop.
> 
> Fear of nesting a procedure? :-)
> 
> I had thought that the new syntax of AI 139 would be for all containers.
> 
> Strangely, the fashion seems to be moving elsewhere:
> list comprehensions, Map + Reduce (US Patent #7,650,331), Scala,
> ... all functional, hence little sympathy for for-loops. Sequence
> comprehensions are now recommended when writing Python, so I had thought
> there is all the more to say in favor of a simple automatic
> 
>   Container.Iterate (Process => Meaningful_Name'Access).

The reasons things like list comprehensions and generator expressions are 
recommended in Python is because they're faster in the CPython 
implementation of the language since they get to native C "faster" (with 
less interpretation and bytecode).

Additionally, generator expressiones: `(x for x in iterable)` are lazily 
evaluated so you don't have to actually have your working set in memory 
all at once.

An Ada "built-in" equivalent of a generator expression I actually don't 
know of, I suppose you could hide that behind your Container.Iterate 
procedure?



Cheers

-- 
- R. Tyler Croy
--------------------------------------
    Code: http://github.com/rtyler

Re: Iterators in Ada2012

[Simon Wright]

"R. Tyler Croy" <tyler@linux.com> writes:

> The reasons things like list comprehensions and generator expressions
> are recommended in Python is because they're faster in the CPython
> implementation of the language since they get to native C "faster"
> (with less interpretation and bytecode).

I had no idea that list comprehensions were faster (I have no idea
whether Mac OS X's native Python is a CPython implementation!), I used
them because they are so expressive!

Re: Iterators in Ada2012

[R. Tyler Croy]

On Wed, 09 Nov 2011 09:02:38 +0000, Simon Wright wrote:

> "R. Tyler Croy" <tyler@linux.com> writes:
> 
>> The reasons things like list comprehensions and generator expressions
>> are recommended in Python is because they're faster in the CPython
>> implementation of the language since they get to native C "faster"
>> (with less interpretation and bytecode).
> 
> I had no idea that list comprehensions were faster (I have no idea
> whether Mac OS X's native Python is a CPython implementation!), I used
> them because they are so expressive!

(I'm aware this is off-topic for comp.lang.ada :))

Pretty much any time you're using Python, you're using the CPython 
implementation. The other options (Jython (java), IronPython (C#), PyPy 
(Python self-hosting)) are less used because they lag behind CPython or 
they have other issues.

That said, yes, list comprehensions are certainly expressive! Having spend 
some time in Ruby lately, I'm not sure which I like more, the list 
comprehension pattern or Ruby's block-based syntax, e.g:

    some_collection.each do |item|
        item.do_thing
    end

vs.

  [item.do_thing() for item in some_collection]

While semantically they're the same thing, there's more one can do in the 
block the Ruby option provides compared to the comprehension approach.



Different strokes for different folks :)



-- 
- R. Tyler Croy
--------------------------------------
    Code: http://github.com/rtyler

Re: Iterators in Ada2012

[Georg Bauhaus]

On 11/9/11 11:58 PM, R. Tyler Croy wrote:

> Pretty much any time you're using Python, you're using the CPython
> implementation.

Google's App Engine is a huge Pythonic computer installation, and it
runs only those Python programs that do *not* use anything requiring
CPython. :-)  App Engine has just now started the experimental phase of
Python 2.7 (version 2.5 still being the standard). There is no
trace of 3.x on the App Engine's blogizon.

Why was it that we absolutely must have all new Ada 2012 compilers early
next year? ;-)

Re: Iterators in Ada2012

[Georg Bauhaus]

On 11/9/11 5:12 AM, R. Tyler Croy wrote:

> Additionally, generator expressiones: `(x for x in iterable)` are lazily
> evaluated so you don't have to actually have your working set in memory
> all at once.

Maybe it is worth mentioning---though in this case savings come from the
other end where collections exist---that Iterate may not have to
inspect every element. Exceptions such as StopIteration in the following
example, can make the process stop early, as needed:

with Ada.Containers.Ordered_Maps;
with Ada.Text_IO;

procedure Iter is

    type Location is digits 8;

    type Coords is record
       Sun : Location;
       Snow : Location;
    end record;

    type Place is (Nowhere, Springfield, Shangri_La, Meryton, Zamunda);

    package Maps is new Ada.Containers.Ordered_Maps
      (Key_Type => Place,
       Element_Type => Coords);

    StopIteration : exception;
    Whereabouts : Maps.Map;
    First_Above_Equator : Place;


    procedure Is_Above (Key : Place; Element : Coords) is
       --  When place `Key` is above the equator, stores it in
       --  `First_Above_Equator` and raises `StopIteration`
    begin
       if Element.Snow > 0.0 then
          First_Above_Equator := Key;
          raise StopIteration;
       end if;
    end Is_Above;


    procedure Stops_Early (Position : Maps.Cursor) is
       --  inspects key/element via `Is_Above`
    begin
       Maps.Query_Element (Position, Is_Above'Access);
    end Stops_Early;

begin
    First_Above_Equator := Nowhere;
    Whereabouts.Insert (Meryton, Coords'(Sun => 0.0, Snow => 51.0));
    -- ...
    Whereabouts.Iterate (Stops_Early'Access);
exception
    when StopIteration =>
       Ada.Text_IO.Put_Line (Place'Image (First_Above_Equator));
end Iter;


> An Ada "built-in" equivalent of a generator expression I actually don't
> know of,

Me neither; though Ada.Numerics.*Random are examples of how
to model producing elements on demand.  I imagine one can do similar
things with task objects in order to emulate a Python style yield.
The result, then, is a generating mechanism that does not require
a working set in memory. I guess one could make the mechanism
more generically useful.

task body Generator is
    Current : Value_Type;
begin
    loop
       Current := Produce_Next;
       accept Next (Result : out Value_Type) do
          Result := Current;
       end Next;
    end loop;
end Generator;

And wrap it in an Ada.Container like package.

Re: Iterators in Ada2012

[Yannick Duchêne (Hibou57)]

Le Wed, 09 Nov 2011 11:55:52 +0100, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:
> Me neither; though Ada.Numerics.*Random are examples of how
> to model producing elements on demand.  I imagine one can do similar
> things with task objects in order to emulate a Python style yield.
> The result, then, is a generating mechanism that does not require
> a working set in memory. I guess one could make the mechanism
> more generically useful.
>
> task body Generator is
>     Current : Value_Type;
> begin
>     loop
>        Current := Produce_Next;
>        accept Next (Result : out Value_Type) do
>           Result := Current;
>        end Next;
>     end loop;
> end Generator;

The good time for a question: Are coroutines planned for Ada 2020 ?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: [Epigrams on Programming — Alan J. — P. Yale University]

Re: Iterators in Ada2012

[Randy Brukardt]

"comp.lang.php" <kst@ecs.soton.ac.uk> wrote in message 
news:66dbca36-0248-458a-aff4-1176d6ce098b@m10g2000vbc.googlegroups.com...
>I have an instantiation of the package Ada.Containers.Ordered_Maps
> (Integer, Float). Is there a neat way of iterating over the values
> similar to the construction:
> for x of a_Set loop ... end loop.

Exactly that should work (but only in Ada 2012, and only in a reasonably 
complete implementation). Don't know if GNAT has all of the needed features 
(my understanding was that a few were still missing, but that's a few months 
old now).

                        Randy.