So on one hand you use the specific term "iterator" for a concept that's slightly different than the general idea of looping through a datastructure, but then "coiteration" is a step too far? Where do you draw the line, at the limits of the C++ standard library?
> Whatever is going on underneath doesn't matter
Performance matters and is often based on what is going on underneath.
So on one hand you use the specific term "iterator" for a concept that's slightly different than the general idea of looping through a data structure
True, but an iterator is a specific value that can be incremented for the next value. It helps loop through a data structure when that data structure can't be indexed by sequential values.
but then "coiteration" is a step too far? Where do you draw the line, at the limits of the C++ standard library?
An iterator helps loop through a data structure. Coiteration is iteration, there isn't a separate concept here.
Performance matters and is often based on what is going on underneath.
You need to understand the context here, this is about the interface.
Basically there is no need to use a different language or hallucinate words to act like they invented something. The entire paper could just be a C++ class and someone using their data structure wouldn't have to give up the C++ eco system. As it stand, no one is going to use an entirely different language to use one data structure.
> Coiteration is iteration, there isn't a separate concept here.
It is a subset that the paper seems to focus on, so using precise language is useful in this case. Just like a study about humans will use the word "human" instead of "mammal".
> no one is going to use an entirely different language to use one data structure.
It seems to me that the goal is more about approaches for specific compiler optimizations/code generation, not to replace C++.
Iteration though is already used when looping through something is non trivial. It isn't necessary for an array or vector because those have random and sequential integer indices.
Iterators are made for situations like this where it is more complex under the hood. What no one can say is why this can't be covered by giving the user an iterator. You say next, it gives you the next item, pair etc.
It seems to me that the goal is more about approaches for specific compiler optimizations/code generation
Based on what? The title is "A Language for Structured Coiteration" and most of the paper is about the internal of the data structure.
not to replace C++.
No one said that, I asked why this couldn't be done in C++ as a class. Then you wouldn't even have to use a different language.
> > the goal is more about [...] optimizations/code generation
> based on what?
From the abstract:
Specializing for structure yields significant speedups. But automatically generating efficient code for structured data is challenging, especially when arrays with different structure interact. We show how to abstract over array structures so that the compiler can generate code to coiterate over any combination of them.
i.e. yes could write your own iterator to efficiently co-iterate over any given pair of structured arrays, and this is a way to express the structure to a compiler so you won't have to figure out the right optimizations yourself every time you want to try out a new way of structuring your data.
Note that this is a research article. The target audience is other researchers in the field, who it would seem would already be familiar with this term. That target audience apparently doesn't include you, which is something that happens fairly often on hacker news and seems like something not to get upset about. It doesn't include me either, but after I actually read the text of the first page of the article it was quite clear from context what co-iteration means. Given the level of effort you've put in so far in this thread my guess is you don't really care what it means, but in case you do: it is about iterating through more than one array simultaneously, generally to do some computation that needs related elements of the multiple arrays at any given step. The example they give is a dot product, where you want to multiply the elements at corresponding locations in two arrays (and then add those products up). They then present clever ways to tell their compiler about different ways of representing sparse arrays so that efficient algorithms for this kind of coiteration can be generated automatically, rather than having to be handwritten for every pair of representations.
So on one hand you use the specific term "iterator" for a concept that's slightly different than the general idea of looping through a datastructure, but then "coiteration" is a step too far? Where do you draw the line, at the limits of the C++ standard library?
> Whatever is going on underneath doesn't matter
Performance matters and is often based on what is going on underneath.