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

DM>(другая причина — что компилятор написан на С++).

Что же это они за 10 лет его ни на Ди ни на немерле даже не переписали-то?

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

EP>Дело в том, что в C++ любой sub-range представляется парой итераторов — и при использовании алгоритмов не появляются новые типы итераторов на ровном месте.
EP>А тут если вызвать банальный findSplit — то уже всё, уже приплыли.

Ну, на сколько я понял, новые типы -- это плата за ленивость. В целом в бусте сделали некий разумный компромисс. Хочешь энергично, но всё статически -- юзай итераторы или их пары, хочешь лениво -- юзай линивые конструкции, а в Ди, как я опять же, понял, вынуждают всё писать типа лениво и тем самым удобнее для функциональщины выходит. Но если мне по какому-то поддиапазону надо елозить много раз, то тут ленивость может выйти боком. Ну и вообще ненужная ленивость пости всегда выходит боком, IMHO...

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

DM>А VMT относится к RTTI? Тогда да.
Я имел в виду, что не статика. Ну, типа нельзя подставить всё инлайн, например...

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

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

А кстати как будет выглядеть такой статический итератор, который выдает строчки из файла с таким вот динамическим условием выхода? Скажем, если первая строка "{", то выдает строчки до "}", а если нет — то просто первые 13 строк, если они там есть. И мы хотим этот итератор использовать в стандартных filter и map.

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

E>Что же это они за 10 лет его ни на Ди ни на немерле даже не переписали-то?

Не знаю, все собираются, сам удивляюсь. Говорят, сейчас какой-то конвертер пишут, чтобы компилятор в D сконвертить по частям.

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

DM>А кстати как будет выглядеть такой статический итератор, который выдает строчки из файла с таким вот динамическим условием выхода? Скажем, если первая строка "{", то выдает строчки до "}", а если нет — то просто первые 13 строк, если они там есть. И мы хотим этот итератор использовать в стандартных filter и map.

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

Но для таких целей никто не мешает, кстати, наделать анологичных ленивых обёрток над итераторами...

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

E>а в итераторах можно обойтись статикой для любого поддипазона последовательности всегда и гарантированно...

И да, как на итераторах будет выглядеть хотя бы xs.take(100).until('\n') без пробега по лишним символам?

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

E>>Что же это они за 10 лет его ни на Ди ни на немерле даже не переписали-то?

DM>Не знаю, все собираются, сам удивляюсь. Говорят, сейчас какой-то конвертер пишут, чтобы компилятор в D сконвертить по частям.

IMHO, это лучший аргумент за то, что пока что не надо спешить переносить свои проекты на ди...

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

EP>>Дело в том, что в C++ любой sub-range представляется парой итераторов — и при использовании алгоритмов не появляются новые типы итераторов на ровном месте.
EP>>А тут если вызвать банальный findSplit — то уже всё, уже приплыли.
E>Ну, на сколько я понял, новые типы -- это плата за ленивость.

А ленивость там от безысходности. Вот есть std::find — возвращает итератор, мы можем легко получить хоть первую половину, хоть вторую.
А в D, когда мы дошагаем до нужного элемента, у нас на руках будут два range:
1. original: [first, last)
2. truncated: [find(first, last, x), last)
Причём это атомы — из них никак не получить [first, find(first, last, x)), вот поэтому и считают, на каком расстоянии находится find(first, last, x) от first, и первая часть там получается вида [first, n), новым "ленивым" типом, причём с ForwardRange категорией (пофиг что исходный range мог быть Bidirectional).

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

Что точно выходит боком так это "ленивая" ленивость — когда все ленивые конструкции являются SinglePass, хотя могли бы иметь категорию повыше. Например как тут

Автор: Ночной Смотрящий
Дата: 22.09.13

— демонстрируются прелести yield, после копии создания нового массива из SinglePass IEnumerable

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

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

А как с ними будут работать стандартные алгоритмы? Или их тоже придется переписать?

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

DM>И да, как на итераторах будет выглядеть хотя бы xs.take(100).until('\n') без пробега по лишним символам?

В смысле? Если ты хочешь линивых вычислений, затолканных в тип итератора, то ничего не мешает так и сделать, тем более, что оно уже всё написано по пять раз, правда тут будет одно хитрое отличие. Мона будет в конце сказать что-то вроде .base() и получить неленивый исходный итератор...
А можно просто циулом прокрутить, если надо энергично...

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

DM>А как с ними будут работать стандартные алгоритмы? Или их тоже придется переписать?

Зачем? Это будут тоже итераторы же

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

DM>>И да, как на итераторах будет выглядеть хотя бы xs.take(100).until('\n') без пробега по лишним символам?

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

Пример кода можно? Конкретно для данного случая.

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

DM>>А кстати как будет выглядеть такой статический итератор, который выдает строчки из файла с таким вот динамическим условием выхода? Скажем, если первая строка "{", то выдает строчки до "}", а если нет — то просто первые 13 строк, если они там есть. И мы хотим этот итератор использовать в стандартных filter и map.

E>Но для таких целей никто не мешает, кстати, наделать анологичных ленивых обёрток над итераторами...

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

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

DM>>>И да, как на итераторах будет выглядеть хотя бы xs.take(100).until('\n') без пробега по лишним символам?

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

DM>Пример кода можно? Конкретно для данного случая.

Ну, тут

Автор: jazzer
Дата: 29.10.13

же приводили...

Если очень хочется, можешь вообще написать так, что будет просто один в один:
Скажем на плюсах будет как-то так:

auto i_begin = lazy::untill(lazy::take( xs_begin, 100 ), '\n' );
auto i_end = i.end( xz_end );
// тут что-то на стандартных алгоритмах на ленивых итераторах
auto res = xxx( i_begin, i_end );
// потом можешь вернуться к исходному итератору, до которого удалось доползти, скажем так:
return lazy::base( res );

Ы?

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

DM>Т.е. городить свои типы на каждый чих? Ну так-то я и в D могу статику гарантировать, это не интересно. Что-то слабовата выходит ваша стандартная библиотека. Наверное, "плохая композиционность" и плохой дизайн.

при чём тут "наша" или "ваша" стандартная библиотека? Речь же о диапазнах и итераторах, а не о стандартной библиотеке?

STL сам по себе ленивых вычислений не гарантирует, но есть более другие библиотеки...
С другйо стороны, подход прятать ленивость в порождаемые по требованию типы, как бы порождает типы на каждый чих просто по замыслу как бы.

Я так понял, что диапазоны, как они сделаны в Ди, как бы вынуждают нас использовать ленивость, без вариантов, а итераторы, как это сделано сейчас, например, в stl+boost позволяют нам в каждом конкретном месте выбрать лениво считать или энергично...

Кстати, как у Ди с мемоизацией? То есть если я замучу линивый поддиапазон, и потом буду ему save говорить и итерировать сто раз, он сто раз повторит вычисления, или как-то хитрее сделает?

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

E>Ну, например, если в последовательности ГДЕ_ТО есть конец строки, то вернуть до него, а если нет, то первые 100 и т. д...

E>Или ты хочешь сказать, что обычно всегда всё можно как-то хитро лениво закодировать так, что никогда не надо ветвиться?

Вообще говоря можно в большинстве случаев, т.к. все эти алгоритмы работы с диапазонами в D параметризуются функциями. И until в том числе. Просто я в этом примере использовал дефолтное значение ("a==b"), поэтому этого нюанса не было видно. Кстати, формально говоря в этом примере можно было и не использовать take вообще, а затащить всю нужную тебе логику в until, передав соответствующую сложную функцию. Но это было бы заметно менее красиво. )))

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

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

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

Нет, оно не так устроено. Хорошо взлетают новые языки, ориентированные на какую-то новую нишу. И взлёт происходит в основном за счёт развития самой ниши (при этом в неё приходят люди, которые по любому будут обучаться работать по другому), а не за счёт перераспределения доли между языками.

Если же взять D, то он очевидно нацелен не на новую нишу, а как прямая замена C/C++ в его родных нишах. Ну может быть предлагая небольшое расширение в чужие ниши, за счёт сильного инструмента построения быстрых DSL. Т.е. по сути здесь предполагается, что программисты будут оставаться на своей текущей работе и тратить время на обучение D только ради увеличения удобства. А это у нас крайне консервативный процесс. Достаточно взглянуть на то, что на дико страшном Фортране до сих пор пишут, хотя современный C++ делает его по всем параметрам...

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

_>Если же взять D, то он очевидно нацелен не на новую нишу, а как прямая замена C/C++ в его родных нишах. Ну может быть предлагая небольшое расширение в чужие ниши, за счёт сильного инструмента построения быстрых DSL. Т.е. по сути здесь предполагается, что программисты будут оставаться на своей текущей работе и тратить время на обучение D только ради увеличения удобства. А это у нас крайне консервативный процесс. Достаточно взглянуть на то, что на дико страшном Фортране до сих пор пишут, хотя современный C++ делает его по всем параметрам...

Да даже перевести проект с С++03 на С++11 — та еще история, а тут — целый новый язык

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

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

E>А встраивать один язык в другой вообще путь к запутыванию кода, IMHO, то есть маломасштабируемый и тупиковый.

Сильно зависит. Тот же парсер я с большим удовольствием, скоростью и удобством напишу на Spirit прямо внутри программы (и где он будет естественно с ней взаимодействовать, используя из контекста типы, переменные и прочая), чем буду дергать стороннюю тулзу и размазывать код по ее конфигурационным файлам.

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