Здравствуйте, alex_public, Вы писали:

_>На итераторах можно элементарно написать код, который одновременно и ленивый и с ветвлением? )
Конечно можно, как и на интервалах, но тогда будет динамика где-то...
Но её в любой момент можно энергично "прокачать" и снова вернуться к статике, если надо. А вот в интервалах, как они сделаны в Ди так не получится, насколько я понял...

Вот смотри, простая задача. У меня есть итератор букв в тексте, я сначала разбиваю текст на слова, потомнекоторые слова, вроде слова "плащ-палатка", например, клею обратно, и хочу в конце увидеть однородный итератор слов. Как сделать на ди-образных интервалах?

Здравствуйте, jazzer, Вы писали:

J>Но ты же где-то будешь явно указывать, что вот сейчас у нас пошел Си, а сейчас — Паскаль, правильно?
Ха, так можно прямо сейчас на плюсах сделать. Речь, как я понял, именно о бесшовной интеграции...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, jazzer, Вы писали:

J>>Но ты же где-то будешь явно указывать, что вот сейчас у нас пошел Си, а сейчас — Паскаль, правильно?
E>Ха, так можно прямо сейчас на плюсах сделать. Речь, как я понял, именно о бесшовной интеграции...

Ну так а что ты понимаешь под бесшовной интеграцией?
имхо, это как раз интеграция в стиле

//C#
int dbl(int x){ return x+x; }

c_code[
  int triple(int x){ return dbl(x); } // use dbl
]

// back to C#
var r = triple(5); // use triple
assert(r == 10);

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Erop, Вы писали:

DM>>Годится. А теперь давай с ветвлением логики завершения в рантайме (аналог твоего вопроса выше), и чтобы "а в итераторах можно обойтись статикой для любого поддипазона последовательности всегда и гарантированно...".

E>"динамика" в этом подходе -- плата за ленивость же. Если ленивость не нужна, то просто энергично ВЫЧИСЛЯЕШЬ нужные позиции итераторов, как угодно и возвращаешь нужную пару...

DM>>И получаешь два прохода (при поиске конца и при использовании) вместо одного. Вместо "всегда и гарантировано" получили "в некоторых случаях". Ладно, понятно.

E>А что мешает получить нужные позиции в исходном итераторе за один проход ленивого?..

Твои же слова выше мешают — сам предложил энергично искать. Если сначала ищем, а потом используем (во время использования идет проход по итератору), получается два прохода по данным.

Здравствуйте, Erop, Вы писали:

DM>>В смысле? Есть у нас, скажем, xs.map!someComputation.filter!someCondition. Как тут итераторы помогают с мемоизацией, где их тут энергично вычислять?

E>Ну, например, если нам надо в конце концов получить какой-то поддиапазон какого-то итератора, то можно его энергично вычислить и перейти к диапазону заданному не черз хитрые, обеспечивающие ленивость типы, а через тупую и простую пару итераторов.

Так нет же, в большинстве случаев (как в предложенном примере) на выходе не будет поддиапазона входа, а будут совсем другие данные. Кстати, в некоторых случаях к исходному диапазону можно получить доступ через свойство .source у рэнджа.

E>Если всё так же, как и в плюсах, то воможность перейти от ленивого интервала к энергичному ценна, если же есть надежда на то, что, например, оптимизатор, обеспечит мемоизацию, то, это не так критично было бы...

Не, оптимизатор не настолько умен. Для таких высокоуровневых вещей нужен хаскель, в грязных языках без referential transparency компилятор никогда не будет достаточно смелым и умным для подобных оптимизаций.

E>Вот смотри, пусть у нас есть итератор/интервал букв в тексте, и мы хотим превратить его в итератор слов, в каждом из которых есть итератор букв.
E>В случае с итераторами всё решается прямо, типа мапом получаем итератор границ слов, потом последовательные границы берём, из каждой добываем оригинальный итератор букв и получаем диапазоны, соответствующие словам.

В D все то же самое. Получим рэндж рэнджей.
Единственное, что так просто не выйдет, — объединить "плащ" и "палатка" в одно слово с дефисом между ними, ибо когда есть два рэнджа, информация о том, что они к одной строке относятся определенным образом, уже потеряна. Но если такая задача действительно возникнет, то просто вместо диапазонов для слов можно использовать пары индексов или пары позиция-длина. Считай, те же итераторы, только типа int.

Здравствуйте, Erop, Вы писали:

I>>Подразумевается, что на D одни дураки пишут ?
E>Ну про С++ же подразумевается?..

Покажи ссылку где такое подразумевается.

E>Вот, например, работа с кодом, как со строкой меня в этом языке пугает, скажем...

Так это лично твои проблемы

Здравствуйте, Erop, Вы писали:

E>Конечно можно, как и на интервалах, но тогда будет динамика где-то...
E>Но её в любой момент можно энергично "прокачать" и снова вернуться к статике, если надо. А вот в интервалах, как они сделаны в Ди так не получится, насколько я понял...

E>Вот смотри, простая задача. У меня есть итератор букв в тексте, я сначала разбиваю текст на слова, потомнекоторые слова, вроде слова "плащ-палатка", например, клею обратно, и хочу в конце увидеть однородный итератор слов. Как сделать на ди-образных интервалах?

Вообще не понял ни задачу, ни подразумеваемую ею проблему. Но может такой код

auto d=[-2, -1, 0, 1, 2, 3, 4];
auto r=splitter(d, 0);//ленивый диапазон кусков
auto r1=r.array;//энергичный диапазон кусков
reverse(d);//правим изначальные данные
writeln(typeid(r), ": ", r);//выводит: std.algorithm.splitter!(int[], int).splitter.Result: [[4, 3, 2, 1], [-1, -2]]
writeln(typeid(r1), ": ", r1);//выводит: int[][]: [[4, 3], [1, 0, -1, -2]]

пояснит ситуацию с этим вопросом в D? )

Здравствуйте, D. Mon, Вы писали:

DM>Твои же слова выше мешают — сам предложил энергично искать. Если сначала ищем, а потом используем (во время использования идет проход по итератору), получается два прохода по данным.

В смысле? Если есть алгоритм, где надо МНОГО раз по интервалу бегать, то сначала ищем, потом используем.
Если так уж критично сделать -1, то можно сделать итератор с мемоизацией, но я не верю, что он может быть нужен.

Что будем делать с интервалами?..

Здравствуйте, D. Mon, Вы писали:

DM>Единственное, что так просто не выйдет, — объединить "плащ" и "палатка" в одно слово с дефисом между ними, ибо когда есть два рэнджа, информация о том, что они к одной строке относятся определенным образом, уже потеряна. Но если такая задача действительно возникнет, то просто вместо диапазонов для слов можно использовать пары индексов или пары позиция-длина. Считай, те же итераторы, только типа int.

1) Это проканает только при произвольном доступе, а в случае интераторов достаточно односвязного списка...

Здравствуйте, Ikemefula, Вы писали:

I>Так это лично твои проблемы

не-не-не, у меня нет в продакшине кода на Ди, соответственно и проблем нет...
Но вот Владу в такой ситуации что-то не нравится

Здравствуйте, Erop, Вы писали:

I>>Так это лично твои проблемы

E>не-не-не, у меня нет в продакшине кода на Ди, соответственно и проблем нет...
E>Но вот Владу в такой ситуации что-то не нравится

В с++ ты, понятное дело, не используешь ничего из того, чем можно прострелить ногу ? То есть, ни указателей, ни исключений, ни шаблонов, ни виртуальных методов, ни конструкторов, ни деструкторов, ни операторов, ни смартпоинтеров... И вот по этой единственной причине твой проект "выстрелил" ? А то бы выстрелил ты себе в спину и всё, капут

Здравствуйте, Erop, Вы писали:

E>В смысле? Если есть алгоритм, где надо МНОГО раз по интервалу бегать, то сначала ищем, потом используем.
E>Если так уж критично сделать -1, то можно сделать итератор с мемоизацией, но я не верю, что он может быть нужен.

E>Что будем делать с интервалами?..

Да не надо нам много раз бегать туда-сюда. Что за мания у вас такая по данным елозить? Я уже выше говорил: большая часть реальной работы с контейнерами и потоками сводится к iterate/filter/map/reduce/find, все они работают за один проход, и их комбинации тоже. И дивные интервалы/диапазоны/рэнджи позволяют работать так, чтобы почти всегда по данным был ровно один проход. Сейчас память очень медленная по сравнению с вычислениями, и число пробежек по данным влияет на скорость намного сильнее, чем лишний инкремент счетчика, о котором беспокоился выше Евгений. Так вот, решение с энергичными итераторами ведет к неэффективности — многократному проходу по данным. А попытка перейти на ленивые итераторы есть ничто иное как переход на рэнджи.

Здравствуйте, D. Mon, Вы писали:

DM>Сейчас память очень медленная по сравнению с вычислениями и число пробежек по данным влияет на скорость намного сильнее,

Ну так примеры выше и показывают, что в D проходов по памяти будет больше, за счёт заниженных категорий. Когда у тебя Bidirectional внезапно становится Forward — тебе придётся снова топать до нужной позиции, или делать лишний раз .array (как раз был в примерах со строкой)

DM>чем лишний инкремент счетчика, о котором беспокоился выше Евгений.

В первую очередь лишний инкремент счётчика это демонстрация неудобства/неправильности концепции. Правильные абстракции зачастую не заставляют делать лишние действия.
Во-вторых — итераторы и range'и шагают далеко не всегда по памяти. Вот даже выше была iota. И в подобных случаях лишний инкремент может быть очень даже заметен
В-третьих — иногда данные могут быть компактными и многократно переиспользоваться, и помещаться целиком в L1.

DM>А попытка перейти на ленивые итераторы есть ничто иное как переход на рэнджи.

Ленивые итераторы есть, например в Boost, и там нет никаких iterator-less range'ей как в D
Если же ты говоришь про iteratorful range'и — так тут и никто не против их использования — они всегда позволяют достать итераторы при необходимости

Здравствуйте, D. Mon, Вы писали:

DM>Да не надо нам много раз бегать туда-сюда. Что за мания у вас такая по данным елозить?


Ну, например, у меня есть список букв, я выдвигаю гипотезы о точках в которых есть границы слов, после чего в каждую границу кладу список итераторов на возможные концы слова начинающегося в этом начале. Получается ациклический граф. Теперь я могу генерить там пути от начала в конец, каждый такой путь -- это гипотеза о том, как строка сегментируется на слова. У меня может быть модель слова, вернее набор моделей, ну там слово из словаря, идентификатор, дата, число, денежная сумма и т. д.
И я каждый такой путь могу оценить, подобрав к каждому слову из пути наилучшую модель и просуммировав качество сопоставления моделей со своими словами. Мало того, у меня могут быть ещё и какие-то модели, оценивающие сочетаемость слов, целые предложения, ещё что-нибудь уровня всего текста/предложения.

Моя цель -- найти лучшую сегментацию текста на слова.

Как написать такой алгоритм на итераторах списка, я понимаю, а вот как на дишных интервалах -- не очень...
Конечно, если ты пишешь некую *стандартную бизнес логику" и тебя устраивают те самые стандартные три-четыре блатные аккорда алгоритма, то всё зашибись, тока шарп с линком наперевес всё равно ещё лучше...
Но мир алгоритмов значительно более другой, вообще-то... Ширее так сказать и сложнее...

Здравствуйте, Erop, Вы писали:

E>Ну, например, у меня есть список букв,

Не, не верю. Ты действительно решаешь такую задачу, храня строки в *двухсвязном списке букв*? Если по ним нужно много бегать туда-сюда, то никакой итератор не сделает это быстрее, чем записать их в массив (вот и random access, все ваши проблемы с bidirectional улетучились) и работать с ним.

Здравствуйте, D. Mon, Вы писали:

DM>Не, не верю.
Почему? "буквы"-то могут быть довольно сложными структурами данных. Например результатами распознавания куска ПРОЧИТАННОГО ВСЛУХ текста, или версиями обратного криптования исходника, или ещё чем-то хитрым.


Пока обсуждение итераторы vs регионы сводится к тому, что ПРОСТЫЕ алгоритмы можно легко закодировать и на том и на том, но даже для простых нужны читы в библиотеке...

Вот тебе пример алгоритма посложнее...

Здравствуйте, Erop, Вы писали:

DM>>Не, не верю.
E>Почему? "буквы"-то могут быть довольно сложными структурами данных.

Ну и положи в массив на них указатели.
Я к тому, что основные сложности с рэнджами возникают на довольно экзотическом случае — когда есть bidirectional, но нет random access. Это экзотика совершенно необязательная.

E>Вот тебе пример алгоритма посложнее...

В алгоритмах посложнее итераторы все равно малополезны, там структуры данных и перемещение по ним редко сводится к хождению пешком туда-сюда (линейно) по одному элементу. То же дерево возьми, по нему итераторами будешь ходить?

Здравствуйте, D. Mon, Вы писали:

DM>Ну и положи в массив на них указатели.
Ну вот и выходит, что итераторы дают больше возможностей, чем дишные интервалы, так как итераторам ничего не надо дополнительного, а интервалам нужен массив указателей...
Отдельным вопросом может быть то, нужно ли это. Ну то есть, ты тцт всё время намекаешь, что мощь итераторов избыточна, и типа скорее идёт во вред, чем в пользу. Мне, например, это не очевидно. Тем более, чот если мы говорим не о конкретных библиотеках, а о паттернах и приёмах, то итератор списка, ака указатель на ноду списка намного лучше, проще и понятнее, чем интервал списка...

То есть я бы сказал так, что если для массивов итераторы -- несколько противоестественны, то для всяких списочных структур вполне адекватны. А дишные интервалы, выходит, естественны только для вещей вроде потоков ввода, а для массивов им всё равно надо явно знать, что это массив и всё время в исходный массив лазить, или делать массивы ссылок на элементы исходного...
То есть получается, что абстракция ещё более кривая, чем итераторы...


DM>Я к тому, что основные сложности с рэнджами возникают на довольно экзотическом случае — когда есть bidirectional, но нет random access. Это экзотика совершенно необязательная.

Э-э-э, двусвязанный список/ прошитое дерево / рассованный по сегментам массив / массив пар {элемент, число повторов} / большинство графов -- это всё, по твоему экзотика?

DM>В алгоритмах посложнее итераторы все равно малополезны, там структуры данных и перемещение по ним редко сводится к хождению пешком туда-сюда (линейно) по одному элементу. То же дерево возьми, по нему итераторами будешь ходить?

Э-э-э, месье с std::map знаком?..

Вообще-то, если у меня есть какая-то состоящая из как-то свзяанных между собой, содержащих данные узлов и нам надо перебрать все узлы, то у нас есть всего два варианта.

1) Написать код, который умеет выдавать нам узлы один за другим
2) Написать код, который вызовет наш колбэк на каждом узле

(1) можно завернуть и в итераторы и в интервалы. В интервалы, как мы выше видели, выйдет хуже...

Здравствуйте, Erop, Вы писали:

DM>>Я к тому, что основные сложности с рэнджами возникают на довольно экзотическом случае — когда есть bidirectional, но нет random access. Это экзотика совершенно необязательная.

E>Э-э-э, двусвязанный список/ прошитое дерево / рассованный по сегментам массив / массив пар {элемент, число повторов} / большинство графов -- это всё, по твоему экзотика?

Это обычно требует более специфического обращения, чем то, что дают итераторы.

DM>>В алгоритмах посложнее итераторы все равно малополезны, там структуры данных и перемещение по ним редко сводится к хождению пешком туда-сюда (линейно) по одному элементу. То же дерево возьми, по нему итераторами будешь ходить?

E>Э-э-э, месье с std::map знаком?..

А что хорошего делают там итераторы? Указатель на конкретный элемент и пробежаться по всей коллекции — это не то, что я называю хождением по дереву, это и рэнджи все умеют. Я имел в виду более осмысленное перемещение по дереву, когда нет четко предопределенного понятия prev/next. Т.е. не вперед-назад, а вверх-влево-вправо хотя бы, ну и другие нелинейные обходы по другим структурам.

E>Вообще-то, если у меня есть какая-то состоящая из как-то свзяанных между собой, содержащих данные узлов и нам надо перебрать все узлы, то у нас есть всего два варианта.

На операции "перебрать все узлы" разница между итераторами и рэнджами незаметна. А более сложные операции требуют и более сложного обращения, итераторов там недостаточно все равно.

Здравствуйте, D. Mon, Вы писали:

DM>А что хорошего делают там итераторы?
Возможность перебрать все элементы или какое-то их подмножество, часто в определённом порядке.
Например, итератор красно-чёрного дерева, который обычно сидит в std:map::iterator позволяет передать как поддиапазон любое поддерево...

DM>На операции "перебрать все узлы" разница между итераторами и рэнджами незаметна. А более сложные операции требуют и более сложного обращения, итераторов там недостаточно все равно.

Это от операций зависит...
Но я верно понял, что ты пришёл к убеждению, что интервалы вообще ненужное УГ, а итераторы, почти такое же УГ, просто чуть лучше и мягче?