Jump to page: 1 24  
Page
Thread overview
C++ / Why Iterators Got It All Wrong
Aug 29, 2017
Robert M. Münch
Aug 29, 2017
bitwise
Aug 29, 2017
bitwise
Aug 29, 2017
jmh530
Aug 31, 2017
Robert M. Münch
Aug 31, 2017
drug
Sep 02, 2017
Robert M. Münch
Sep 02, 2017
Moritz Maxeiner
Sep 03, 2017
Robert M. Münch
Sep 03, 2017
Moritz Maxeiner
Sep 04, 2017
Robert M. Münch
Sep 04, 2017
Mark
Sep 01, 2017
Mark
Sep 02, 2017
Robert M. Münch
Sep 05, 2017
Mark
Sep 03, 2017
Ilya Yaroshenko
Sep 03, 2017
Moritz Maxeiner
Sep 03, 2017
Ilya Yaroshenko
Sep 03, 2017
Moritz Maxeiner
Sep 03, 2017
Ilya Yaroshenko
Sep 03, 2017
Moritz Maxeiner
Sep 04, 2017
Ilya
Sep 04, 2017
jmh530
Sep 06, 2017
jmh530
Sep 06, 2017
Enamex
Sep 06, 2017
jmh530
Sep 07, 2017
Ilya Yaroshenko
Sep 07, 2017
jmh530
Sep 07, 2017
jmh530
Sep 07, 2017
jmh530
Sep 07, 2017
jmh530
Sep 11, 2017
Ilya Yaroshenko
Sep 11, 2017
jmh530
August 29, 2017
Maybe of interest: https://www.think-cell.com/en/career/talks/iterators/#1

I haven't read everything, so not sure if it worth to take a look.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

August 29, 2017
On Tuesday, 29 August 2017 at 12:50:08 UTC, Robert M. Münch wrote:
> Maybe of interest: https://www.think-cell.com/en/career/talks/iterators/#1
>
> I haven't read everything, so not sure if it worth to take a look.

"superseded" is the wrong word, as ranges cannot do everything iterators can.
August 29, 2017
On 8/29/17 8:50 AM, Robert M. Münch wrote:
> Maybe of interest: https://www.think-cell.com/en/career/talks/iterators/#1
> 
> 
> I haven't read everything, so not sure if it worth to take a look.
> 
> 

Interesting. It reminds me a bit of cursors for dcollections. In there, a cursor is a 0 or 1 element range. The one element range points at an element, the 0 element range points at a border. You can use cursors to compose ranges.

https://github.com/schveiguy/dcollections

Not sure how useful it is to have them be separate types. It can be nice I suppose. But one thing I love about iterators/cursors is that something like find doesn't assume what data you are interested in.

In Phobos, find gives you a range where the first element is the one you searched for, and the last element is the end of the original range. But what if you wanted all the data *up to* the element instead? What if you just wanted to look at that specific element? So we need several functions that do this, and it's not always clear how to do it correctly, and it's difficult to compose one function from the other. With iterators, it's simple.

-Steve
August 29, 2017
On Tuesday, 29 August 2017 at 13:23:50 UTC, Steven Schveighoffer wrote:
>
> In Phobos, find gives you a range where the first element is the one you searched for, and the last element is the end of the original range. But what if you wanted all the data *up to* the element instead? What if you just wanted to look at that specific element? So we need several functions that do this, and it's not always clear how to do it correctly, and it's difficult to compose one function from the other. With iterators, it's simple.
>
> -Steve

I was about to whine about exactly this, but thought it would be off topic ;)

I see "trim_left" in the slides which I'm guessing refers to what D calls "find". IMO, "trim_left" is a much better name. "find" should not return elements you didn't ask for, it should return a range of length 1 or 0.

August 29, 2017
On Tuesday, 29 August 2017 at 13:23:50 UTC, Steven Schveighoffer wrote:
>
> Interesting. It reminds me a bit of cursors for dcollections. In there, a cursor is a 0 or 1 element range. The one element range points at an element, the 0 element range points at a border. You can use cursors to compose ranges.
>
> https://github.com/schveiguy/dcollections
>

I was thinking this exact same thing when I got to the Element part of it.

The mach library also makes use of cursors.
https://github.com/pineapplemachine/mach.d

I'm not entirely sure how if I grok how the Border thing they are talking about works.
August 29, 2017
On 8/29/17 9:34 AM, jmh530 wrote:
> On Tuesday, 29 August 2017 at 13:23:50 UTC, Steven Schveighoffer wrote:
>>
>> Interesting. It reminds me a bit of cursors for dcollections. In there, a cursor is a 0 or 1 element range. The one element range points at an element, the 0 element range points at a border. You can use cursors to compose ranges.
>>
>> https://github.com/schveiguy/dcollections
>>
> 
> I was thinking this exact same thing when I got to the Element part of it.
> 
> The mach library also makes use of cursors.
> https://github.com/pineapplemachine/mach.d
> 
> I'm not entirely sure how if I grok how the Border thing they are talking about works.

A border points between elements. It's like the end element in a standard STL container, it's not really pointing at an element, but one past the last element.

It can be handy when specifying ranges. I.e. exclusive or inclusive ranges.

My gut feeling is that the splitting of types between elements and borders is too much machinery, but I haven't seen it in practice to make a fair judgment.

-Steve
August 31, 2017
On 2017-08-29 13:23:50 +0000, Steven Schveighoffer said:

> ...
> In Phobos, find gives you a range where the first element is the one you searched for, and the last element is the end of the original range. But what if you wanted all the data *up to* the element instead? What if you just wanted to look at that specific element? So we need several functions that do this, and it's not always clear how to do it correctly, and it's difficult to compose one function from the other.

I'm a big fan of Rebol (yes, it's far from mainstream and a dead-end these days but it has a lot of very nice ideas) and it uses the idea of a series datatype. Fruther information here: http://www.rebol.com/docs/core23/rebolcore-6.html

There you do something like:

1. Return the first hit and the rest of the series

>> my-series: "abcdefg"
== "abcdefg"
>> find my-series "b"
== "bcdefg"


2. Return only the hit

>> first find my-series "b"
== #"b"


3. Return everything before the first hit

>> copy/part my-series find my-series "d"
== "abc"


If you ever got used to such a thinking, writing & using more non-functional approaches, really hurts.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

August 31, 2017
31.08.2017 09:50, Robert M. Münch пишет:
> On 2017-08-29 13:23:50 +0000, Steven Schveighoffer said:
>
>> ...
>> In Phobos, find gives you a range where the first element is the one
>> you searched for, and the last element is the end of the original
>> range. But what if you wanted all the data *up to* the element
>> instead? What if you just wanted to look at that specific element? So
>> we need several functions that do this, and it's not always clear how
>> to do it correctly, and it's difficult to compose one function from
>> the other.
>
> I'm a big fan of Rebol (yes, it's far from mainstream and a dead-end
> these days but it has a lot of very nice ideas) and it uses the idea of
> a series datatype. Fruther information here:
> http://www.rebol.com/docs/core23/rebolcore-6.html
>
> There you do something like:
>
> 1. Return the first hit and the rest of the series
>
>>> my-series: "abcdefg"
> == "abcdefg"
>>> find my-series "b"
> == "bcdefg"
>
>
> 2. Return only the hit
>
>>> first find my-series "b"
> == #"b"
>
>
> 3. Return everything before the first hit
>
>>> copy/part my-series find my-series "d"
> == "abc"
>
>
> If you ever got used to such a thinking, writing & using more
> non-functional approaches, really hurts.
>
Interesting. How is it comparable with iterators and ranges ideas?
September 01, 2017
On Tuesday, 29 August 2017 at 12:50:08 UTC, Robert M. Münch wrote:
> Maybe of interest: https://www.think-cell.com/en/career/talks/iterators/#1
>
> I haven't read everything, so not sure if it worth to take a look.

Iterators have many problems. Andrei's talk some years ago, titled "Iterators Must Go", points out many of them in a clear fashion. I think most of the problems stem from the fact that they are inherently a leaky abstraction. Iterators basically treat all data structures as a singly/doubly linked list or as arrays (if they allow random access). There is no natural or intuitive way of describing, say, a tree or an arbitrary graph as a list/array. Ranges and cursors try to solve some of the issues but they still have this fundamental problem.

When I think of a good iteration interface, the only thing that comes to mind is SQL queries (= relational algebra, more or less). You have a few basic operators (Select, From, etc.) for querying that are intuitive, simple and safe. Furthermore, they compose elegantly, allowing you to express fairly complicated queries using these few basic operators. It's a true abstraction - I don't know and I don't care if the operators are implemented underneath using iterators, ranges, cursors or whatever (of course, sometimes I do care, when performance is a priority...).

It may be unrealisic to expect such a nice abstraction of iteration for other data structures, not to mention a universal one which will work for all interesting data structures. Still, if and when I can dispense with iteration altogether, I'm happy to do so.
September 02, 2017
On 2017-08-31 07:13:55 +0000, drug said:

> Interesting. How is it comparable with iterators and ranges ideas?

Well, see: http://www.rebol.com/docs/core23/rebolcore-6.html#section-6

Just download the interpreter and play around with it to get a feeling.

Overall it's way more functional. Like getting the last element: copy back tail my-series

What I don't like is that indexing starts at 1, because this makes working with +/- offsets from a specific positon cumbersome.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

« First   ‹ Prev
1 2 3 4