Multiple iterators for a type

Multiple iterators for a type

[Lucretia]

Hi,

I want to have a type which is an array of 8 bit values, I want the default iterator to be the normal array loop.

But then I want to add more iterators which return different types but constructed from the array, i.e. a 32-bit value and a sub-array.

1. Can this be done on the base type or do I need to create new types from the base type?

2. if 1. can be done, do these iterators all need to be one package or can I put them in child packages?

Thanks,
Luke.

Re: Multiple iterators for a type

[Jacob Sparre Andersen]

Lucretia <laguest9000@googlemail.com> writes:

> I want to have a type which is an array of 8 bit values, I want the
> default iterator to be the normal array loop.
>
> But then I want to add more iterators which return different types but
> constructed from the array, i.e. a 32-bit value and a sub-array.
>
> 1. Can this be done on the base type or do I need to create new types
>    from the base type?

It can be done on the base type.

> 2. if 1. can be done, do these iterators all need to be one package or
>    can I put them in child packages?

They can be in child packages.  Or even locally defined in the
subprogram where you use them.

Greetings,

Jacob
-- 
"War does not determine who is right - only who is left."
                                         -- Bertrand Russell

Re: Multiple iterators for a type

[Randy Brukardt]

Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message 
news:87o9h3qzv3.fsf@jacob-sparre.dk...
> Lucretia <laguest9000@googlemail.com> writes:
>
>> I want to have a type which is an array of 8 bit values, I want the
>> default iterator to be the normal array loop.
>>
>> But then I want to add more iterators which return different types but
>> constructed from the array, i.e. a 32-bit value and a sub-array.
>>
>> 1. Can this be done on the base type or do I need to create new types
>>    from the base type?
>
> It can be done on the base type.

There can only be one "of" iterator, and it's built-in for array types. To 
replace the "of" iterator you need different private types (which means of 
course that they can't directly be used as arrays, either, although you can 
emulate that). Why you'd want to go through that escapes me.

You can explicitly use alternate iterators using the "in" syntax. After all, 
any iterator object can be iterated (duh!), and you can create as many 
different ones of those as you want/need.

The "of" iterator is just a convinience, and I think the language would have 
been just fine without it. Ignore its existence and you'll be just fine and 
can have all of the iterators you ever could need.

                                                         Randy.

Re: Multiple iterators for a type

[Stephen Leake]

On Friday, May 25, 2018 at 11:49:48 AM UTC-5, Lucretia wrote:
> Hi,
> 
> I want to have a type which is an array of 8 bit values, I want the default iterator to be the normal array loop.
> 
> But then I want to add more iterators which return different types but constructed from the array, i.e. a 32-bit value and a sub-array.
> 
> 1. Can this be done on the base type or do I need to create new types from the base type?
> 
> 2. if 1. can be done, do these iterators all need to be one package or can I put them in child packages?
> 
> Thanks,
> Luke.

An "iterator" can be anything you want it to be. As Randy pointed out, there can be only one that gets special treatment from the compiler, but you did not mention that as a requirement.

Re: Multiple iterators for a type

[Luke A. Guest]

Stephen Leake <> wrote:

> An "iterator" can be anything you want it to be. As Randy pointed out,
> there can be only one that gets special treatment from the compiler, but
> you did not mention that as a requirement.
> 

I’m attempting to implement a Unicode string using UTF-8, so I want the
basic iterator over octets, then the next will iterate over the octets and
generate code points, then another will be graphème clusters.

Re: Multiple iterators for a type

[Jere]

On Friday, May 25, 2018 at 11:57:47 PM UTC-4, Luke A. Guest wrote:
> Stephen Leake <> wrote:
> 
> > An "iterator" can be anything you want it to be. As Randy pointed out,
> > there can be only one that gets special treatment from the compiler, but
> > you did not mention that as a requirement.
> > 
> 
> I’m attempting to implement a Unicode string using UTF-8, so I want the
> basic iterator over octets, then the next will iterate over the octets and
> generate code points, then another will be graphème clusters.

When I did multiple iterators I ended up making a package for it, which I 
later adapted just for fun to provide iteration of types in generics.  
The steps I ended up doing were:

1.  Create my Cursor type and Has Element
2.  Create a set of functions returning reference types, but use a package
    to do it so I could pass them into another generic
3.  Instantiate Iterator_Interfaces for my cursor
4.  Implement my iterator
5.  Pass it into a package that created an iterable wrapper

Technically if you just want "in" iteration, you stop at #4, but I like
the "of" version so that is why I made a package for step 5.

In the end I was able to get something like:
for E of Iterable(Container_Object) loop
   E.Do_Things;
end loop;

where Iterable is a function from my generic package that returns
an iterable version of Container object.  It was handy for generics
and having multiple iterators, though it comes at a performance
cost since it uses a layer on top of the container.

Package for making reference types:
https://github.com/jeremiahbreeden/bullfrog/blob/master/src/bullfrog-access_types-references.ads

Package for making "of" iterable wrappers:
https://github.com/jeremiahbreeden/bullfrog/blob/master/src/bullfrog-containers-iterable_wrappers.ads

Package with some predefined wrappers of the standard containers
to my iterable wrappers:
https://github.com/jeremiahbreeden/bullfrog/blob/master/src/bullfrog-containers-predefined_iterable_wrappers.ads

Some testing of the predefined wrappers that I made:
https://github.com/jeremiahbreeden/bullfrog/blob/master/src/tests/test_generic_iteration.adb

Re: Multiple iterators for a type

[Dmitry A. Kazakov]

On 2018-05-26 05:57, Luke A. Guest wrote:
> Stephen Leake <> wrote:
> 
>> An "iterator" can be anything you want it to be. As Randy pointed out,
>> there can be only one that gets special treatment from the compiler, but
>> you did not mention that as a requirement.
>>
> 
> I’m attempting to implement a Unicode string using UTF-8, so I want the
> basic iterator over octets, then the next will iterate over the octets and
> generate code points, then another will be graphème clusters.

Why do you bother? I mean, there is no solution for having a 
user-defined array type in Ada. Iterator is only a small part of it. 
Even if the iterator kludge worked somehow, the rest would not.

Multiple inheritance is not complete either, so having two array 
interfaces for one object will be extremely difficult and uncomfortable. 
You will end up with a mess of helper generic packages to emulate full 
inheritance. [I went that way, there is nothing good there.]

In short, there is nothing useful Ada 20xx could bring to the problem of 
dealing with encoded strings.

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

Re: Multiple iterators for a type

[Dan'l Miller]

On Saturday, May 26, 2018 at 1:59:59 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-05-26 05:57, Luke A. Guest wrote:
> > Stephen Leake <> wrote:
> > 
> >> An "iterator" can be anything you want it to be. As Randy pointed out,
> >> there can be only one that gets special treatment from the compiler, but
> >> you did not mention that as a requirement.
> >>
> > 
> > I’m attempting to implement a Unicode string using UTF-8, so I want the
> > basic iterator over octets, then the next will iterate over the octets and
> > generate code points, then another will be graphème clusters.
> 
> Why do you bother? I mean, there is no solution for having a 
> user-defined array type in Ada. Iterator is only a small part of it. 
> Even if the iterator kludge worked somehow, the rest would not.

Conversely, why do you bother writing this reply, raining on his parade?  Luke never said that he wants to change Ada's array itself.  He said that he wants a type implemented via an array that just happens to have 2 or more other types (i.e., iterators) usable with it.

> Multiple inheritance is not complete either, so having two array 
> interfaces for one object will be extremely difficult and uncomfortable. 
> You will end up with a mess of helper generic packages to emulate full 
> inheritance. [I went that way, there is nothing good there.]

Luke never said that he wants an •array• with  two personalities bolted deeply within the •array• itself.  He said that he want 2 or more iterators traversing the one array.  He implied that 1 or more of them would have:

1) a function to return a UCS4/UTF-32 normalized form, when traversing a UTF-8 sequence of base character plus one or more combining graphemes.

2) a function to return a subarray of denormalized UTF-8 base character plus one or more combining characters, when traversing a fully- or partially-normalized character in the main array.

> In short, there is nothing useful Ada 20xx could bring to the problem of 
> dealing with encoded strings.

We will see if your prediction of the outcome of this thread proves to be true.  If at least one multiple-iterator solution arrises for traversing one single-personalty** array, then your theorem would be proven false by counterexample.

** The single personality of that main array that Luke implies is:  the main array can have any valid UTF-8 characters in it, including any variant of fully-normalized, partially-normalized, and fully-denormalized characters regarding the combining-form graphemes (e.g., for diacritics when focusing on the Latin language-family alphabets).

Re: Multiple iterators for a type

[Lucretia]

On Saturday, 26 May 2018 07:59:59 UTC+1, Dmitry A. Kazakov  wrote:
> On 2018-05-26 05:57, Luke A. Guest wrote:
> > Stephen Leake <> wrote:
> > 
> >> An "iterator" can be anything you want it to be. As Randy pointed out,
> >> there can be only one that gets special treatment from the compiler, but
> >> you did not mention that as a requirement.
> >>
> > 
> > I’m attempting to implement a Unicode string using UTF-8, so I want the
> > basic iterator over octets, then the next will iterate over the octets and
> > generate code points, then another will be graphème clusters.
> 
> Why do you bother? I mean, there is no solution for having a 
> user-defined array type in Ada. Iterator is only a small part of it. 
> Even if the iterator kludge worked somehow, the rest would not.
> 
> Multiple inheritance is not complete either, so having two array 
> interfaces for one object will be extremely difficult and uncomfortable. 
> You will end up with a mess of helper generic packages to emulate full 
> inheritance. [I went that way, there is nothing good there.]
> 
> In short, there is nothing useful Ada 20xx could bring to the problem of 
> dealing with encoded strings.

Sorry, didn't understand a word of this wrt to my post.

We can't have user defined array types in Ada? WTF? What wouldn't work?

How is MI involved here?

What has Ada 20xx got to do with anything?

Totally lost.

Re: Multiple iterators for a type

[Dmitry A. Kazakov]

On 2018-05-26 15:03, Lucretia wrote:
> On Saturday, 26 May 2018 07:59:59 UTC+1, Dmitry A. Kazakov  wrote:
>> On 2018-05-26 05:57, Luke A. Guest wrote:
>>> Stephen Leake <> wrote:
>>>
>>>> An "iterator" can be anything you want it to be. As Randy pointed out,
>>>> there can be only one that gets special treatment from the compiler, but
>>>> you did not mention that as a requirement.
>>>>
>>>
>>> I’m attempting to implement a Unicode string using UTF-8, so I want the
>>> basic iterator over octets, then the next will iterate over the octets and
>>> generate code points, then another will be graphème clusters.
>>
>> Why do you bother? I mean, there is no solution for having a
>> user-defined array type in Ada. Iterator is only a small part of it.
>> Even if the iterator kludge worked somehow, the rest would not.
>>
>> Multiple inheritance is not complete either, so having two array
>> interfaces for one object will be extremely difficult and uncomfortable.
>> You will end up with a mess of helper generic packages to emulate full
>> inheritance. [I went that way, there is nothing good there.]
>>
>> In short, there is nothing useful Ada 20xx could bring to the problem of
>> dealing with encoded strings.
> 
> Sorry, didn't understand a word of this wrt to my post.
> 
> We can't have user defined array types in Ada? WTF?

There are only built-in arrays in Ada. You cannot have an array ADT 
providing your array object representation and/or implementation of 
array operations.

> What wouldn't work?

Implementation of encoded string with two array views of it, as an array 
of encoding units and an array of characters/glyphs/code points etc.

> How is MI involved here?

An encoded string implements two array interfaces. Add here 
fixed/bounded/unbounded axis and you will have a lot of things to 
inherit from and export to. You would certainly want to be able to mix 
all possible combinations of these.

> What has Ada 20xx got to do with anything?

You can stick to Ada 95. Iterators and interfaces do not help much with 
encoded strings.

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

Re: Multiple iterators for a type

[Dan'l Miller]

On Saturday, May 26, 2018 at 8:52:18 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-05-26 15:03, Lucretia wrote:
> > On Saturday, 26 May 2018 07:59:59 UTC+1, Dmitry A. Kazakov  wrote:
> >> On 2018-05-26 05:57, Luke A. Guest wrote:
> >>> Stephen Leake <> wrote:
> >>>
> >>>> An "iterator" can be anything you want it to be. As Randy pointed out,
> >>>> there can be only one that gets special treatment from the compiler, but
> >>>> you did not mention that as a requirement.
> >>>>
> >>>
> >>> I’m attempting to implement a Unicode string using UTF-8, so I want the
> >>> basic iterator over octets, then the next will iterate over the octets and
> >>> generate code points, then another will be graphème clusters.
> >>
> >> Why do you bother? I mean, there is no solution for having a
> >> user-defined array type in Ada. Iterator is only a small part of it.
> >> Even if the iterator kludge worked somehow, the rest would not.
> >>
> >> Multiple inheritance is not complete either, so having two array
> >> interfaces for one object will be extremely difficult and uncomfortable.
> >> You will end up with a mess of helper generic packages to emulate full
> >> inheritance. [I went that way, there is nothing good there.]
> >>
> >> In short, there is nothing useful Ada 20xx could bring to the problem of
> >> dealing with encoded strings.
> > 
> > Sorry, didn't understand a word of this wrt to my post.
> > 
> > We can't have user defined array types in Ada? WTF?
> 
> There are only built-in arrays in Ada. You cannot have an array ADT 
> providing your array object representation and/or implementation of 
> array operations.
> 
> > What wouldn't work?
> 
> Implementation of encoded string with two array views of it, as an array 
> of encoding units and an array of characters/glyphs/code points etc.
> 
> > How is MI involved here?
> 
> An encoded string implements two array interfaces.

Other than from Dmitry, where did “encoded string” come from in this thread?  Dmitry, where are you getting this (bizarre) definition of “encoded string”?  From some non-Ada programming language?  And apparently not a mainstream one, at that.

[I ask because a quick Bing/Google search turns up only the canonical definition of encoded string:  a 2nd string converted to a special encoding (e.g., Base64 in MIME) as the (separate) •output• (encoded-)string of a (encoding-)transformation that took a (separate) (unencoded-)input string that lacked the special encoding.  I couldn't easily find any programming language or library that uses “encoded string” as its internal-culture jargon that has your apparently-novel definition of 2 concurrent/super-imposed array-esque personalities on the same string-instance.]

Re: Multiple iterators for a type

[G.B.]

On 26.05.18 05:57, Luke A. Guest wrote:
> Stephen Leake <> wrote:
> 
>> An "iterator" can be anything you want it to be. As Randy pointed out,
>> there can be only one that gets special treatment from the compiler, but
>> you did not mention that as a requirement.
>>
> 
> I’m attempting to implement a Unicode string using UTF-8, so I want the
> basic iterator over octets, then the next will iterate over the octets and
> generate code points, then another will be graphème clusters.

Would layering work where each layer uses
   Has_Element
   Next

This should then work with streams, too, that is,
with open ended arrays read from some source.