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

E>Скажем на плюсах будет как-то так: [c]
E>auto i_begin = lazy::untill(lazy::take( xs_begin, 100 ), '\n' );
E> Ы?

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

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

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

Ну вот Евгений выше очень радел именно за стандартную библиотеку. Говорил, что это часть языка, и ее проблемы становятся проблемами всего языка. Вон сколько сообщений написал про одну единственную функцию поиска..

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

Если просто save, то скорее всего повторит. Ежели там сложные вычисления, то вместо .save пишешь .array и получаешь все мемоизованное.

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

E>Если очень хочется, можешь вообще написать так, что будет просто один в один:
E>Скажем на плюсах будет как-то так: [c]
E>auto i_begin = lazy::untill(lazy::take( xs_begin, 100 ), '\n' );
E>auto i_end = i.end( xz_end );
E>// тут что-то на стандартных алгоритмах на ленивых итераторах
E>auto res = xxx( i_begin, i_end );

Не, погоди. По идее, результаты until и take начало-то одно имеют, а влияют именно на конец итерирования. Стандартный алгоритм будет же итератор с переданным end сравнивать, с чем именно он будет сравнивать и как? Или логика окончания заложена в операцию сравнения для такого итератора? Тогда это уже range, и никакой end ему не нужен по-хорошему..

E>// потом можешь вернуться к исходному итератору, до которого удалось доползти, скажем так:
E>return lazy::base( res );

Если у нас в xxx был filter или map, это не имеет никакого смысла.

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

EP>Библиотечный findSplit возвращает три range, два из которых результат takeExactly, а третий оригинального типа.
EP>Допустим тебе в функцию передали BidirectionalRange, внутри ты сделал этот findSplit, и тебе нужно вернуть либо первый range либо последний. Как будешь делать?

Ну да, есть такое. Только ты забыл уточнить пару нюансов:

1. Описанное тобой поведение относится только к не RandomAccess диапазонам, так что удобные встроенные типы (массивы, строки) опять же сюда не попадают. А проблемы есть только у всяких SList, DList и т.п.

2. Указанная проблема является следствием ленивости, но её можно в любой момент устранить сделав .array (например).

EP>А вот на итераторах это элементарно разруливается

На итераторах можно элементарно написать код, который одновременно и ленивый и с ветвлением? )

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

E>IMHO, если мы таки за рассчёты-рассчёты, то ничего лучше фортрана либо матлаба (в зависимости от того, что за рассчёты) не придумали. Это я тебе как вычматик говорю...

E>И библиотеки там ЛУЧШИЕ, хотя совсем перегрузками операторов не балуются при этом...

E>Тут IMHO, С++ будет очень сильно оверкилл. И Ди, насколько я понимаю, тоже...

Вообще то в роли числодробилки C++ однозначно лучший язык. Если сравнивать с Фортраном, то он предлагает намного более высокоуровневые абстракции и при этом даже чуть быстрее в умелых руках. Однако как мы видим во многих местах до сих пор используют Фортран — тут есть и тот самый консерватизм (как при переходе с C++ на D в других местах) и небольшая доля прагматизма, если мы говорим об учёных, а не программистах (C++ очень сложный, по сравнению с Фортраном).

Если говорить про D в роли числодробилки, то он предлагает ещё более удобные абстракции, менее сложен в обучение (там не обязательно разбираться во всех фичах, чтобы писать приличный код), но при этом немного медленнее и C++ и Фортрана. Так что тут весьма спорный вопрос о его применимости.

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

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

Ну, во-первых, то же самое можно же сделать и с итераторами.
Во-вторых, ничто не мешает написать тогда и цикл, вообще-то...

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

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

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

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

Если тебе удобнее говорить на языке "ниш", то можно попробовать обсудить что за ниша даст старт Ди?..

_>Достаточно взглянуть на то, что на дико страшном Фортране до сих пор пишут, хотя современный C++ делает его по всем параметрам...

В том-то и фигня, что не делает...

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

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

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

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

E>>Скажем на плюсах будет как-то так: [c]
E>>auto i_begin = lazy::untill(lazy::take( xs_begin, 100 ), '\n' );
E>> Ы?

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

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

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

DM>Ну вот Евгений выше очень радел именно за стандартную библиотеку. Говорил, что это часть языка, и ее проблемы становятся проблемами всего языка. Вон сколько сообщений написал про одну единственную функцию поиска..

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

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

DM>Если просто save, то скорее всего повторит. Ежели там сложные вычисления, то вместо .save пишешь .array и получаешь все мемоизованное.

Э-э-э, тогда уж лучше итераторы энергично вычислить, чем копию массива делать, не?

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

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

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

E>Но, всё-таки, ты при этом синтаксис плюсов-то не поменяешь...

Т.е. против встроенных ДСЛ типа Спирита ты ничего не имеешь и не агитируешь их выносить наружу, правильно?

E>А вот прикинь, что будет какой-то Фреймворк, который меняет синтаксис входного языка компилятора для того, что бы круто-круто описывать GUI декларативно, и будет другой, который мат-формулы позволит шпарить, например. И в какой-то момент тебе понадобится скрестить в одном исходнике оба...

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

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

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

DM>Тогда это уже range, и никакой end ему не нужен по-хорошему..

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

DM>Если у нас в xxx был filter или map, это не имеет никакого смысла.

Ну тут надо выбрать -- ленивость или статика...

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

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

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

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

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

DM>>Если просто save, то скорее всего повторит. Ежели там сложные вычисления, то вместо .save пишешь .array и получаешь все мемоизованное.

E>Э-э-э, тогда уж лучше итераторы энергично вычислить, чем копию массива делать, не?

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

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

E>>при чём тут "наша" или "ваша" стандартная библиотека? Речь же о диапазнах и итераторах, а не о стандартной библиотеке?
DM>Ну вот Евгений выше очень радел именно за стандартную библиотеку. Говорил, что это часть языка, и ее проблемы становятся проблемами всего языка.

То о чём ты говоришь реализуется на итераторах — и until и takeExactly, и даже ленивое ветвление по {/}.
В топике шла речь про принципиальную ограниченность Range — нормальный find для bidirectional нельзя сделать, вообще никак

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

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

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

В этом смысле и С++ с мемоизацией в рантайме всё плохо, надо как-то обесепечиить самому.
Я Ди не особо глубоко смотрел, так что просто не знаю, вдруг там есть какая-то поддержка мемоизации, в языке или в библиотеке или в сочетани того и другого...
Если всё так же, как и в плюсах, то воможность перейти от ленивого интервала к энергичному ценна, если же есть надежда на то, что, например, оптимизатор, обеспечит мемоизацию, то, это не так критично было бы...

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

А как это будет на Ди-образных интервалах?..

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

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

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

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

J>Т.е. против встроенных ДСЛ типа Спирита ты ничего не имеешь и не агитируешь их выносить наружу, правильно?
Я против фич и методов, которые дают всего лишь синтаксический сахар, но не гарантируют при этом непротиворечивости себя в большой программе...

E>>А вот прикинь, что будет какой-то Фреймворк, который меняет синтаксис входного языка компилятора для того, что бы круто-круто описывать GUI декларативно, и будет другой, который мат-формулы позволит шпарить, например. И в какой-то момент тебе понадобится скрестить в одном исходнике оба...

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

Ну, ты хочешь сказать, что можно для языка построенного таким образом, что можно произвольно патчить его парсер прямо из кода, можно выработать какие-то методы программирования, такие, что они гарантируют отсутсвие противоречий в синтаксисе входного языка? -- Ну, скорее всего можно. Но, если мы не навяжем эту стратегию ВСЕМ разработчикам всех фреймворков для всех целей, то рискуем нарваться на то, что сочетать два фреймворка в одной программе нам будет очень трудно...

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

но, насколько я понял Влада с его концепцией языков 21-го века, он призывает проектировать язык так, что мы можем написать такой хедер или модуль или что-то ещё, что позволит писать часть кода на Си, например, или на паскале.
Потом кто-то напишет библу, которая вносит нам во входной язык Си, а кто-то такую, кто вносит паскаль. В паскале текст в {} -- это комментарий, а в Cи -- блок кода. А что получится в нашем входном языке, когда мы попробуем подключить обе библиотеки? Как там будет рулится, текст в скобках -- это бок или комментарий?

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

_>Вообще то в роли числодробилки C++ однозначно лучший язык. Если сравнивать с Фортраном, то он предлагает намного более высокоуровневые абстракции и при этом даже чуть быстрее в умелых руках. Однако как мы видим во многих местах до сих пор используют Фортран — тут есть и тот самый консерватизм (как при переходе с C++ на D в других местах) и небольшая доля прагматизма, если мы говорим об учёных, а не программистах (C++ очень сложный, по сравнению с Фортраном).


Это главная проблема С++, как числодробилки. Что бы решить сложную вычматематическую задачу нужен не спец в С++, а спец в вычматах. А таким спецм фортран ПОНЯТНЕЕ и УДОБНЕЕ.
В числодробилках хитрые абстракции нужны редко, а вот боевая итерация по каким-то матрицам + возможность компилятора это всё векторизовать на любой платформе более или менее самостоятельно нужна практически всегда.
поэтому-то в руках вычматематика фортран и лучше. Конечно, если ты посадишь кодить числодробилку не математика, а спеца по плюсам там или Ди, он накодит лучше, но не то. Потому что он спец не в том.

_>Если говорить про D в роли числодробилки, то он предлагает ещё более удобные абстракции, менее сложен в обучение (там не обязательно разбираться во всех фичах, чтобы писать приличный код), но при этом немного медленнее и C++ и Фортрана. Так что тут весьма спорный вопрос о его применимости.

IMHO он просто не нужен. Нет никакой выгоды. А накладные расходы больше.

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

E>но, насколько я понял Влада с его концепцией языков 21-го века, он призывает проектировать язык так, что мы можем написать такой хедер или модуль или что-то ещё, что позволит писать часть кода на Си, например, или на паскале.
E>Потом кто-то напишет библу, которая вносит нам во входной язык Си, а кто-то такую, кто вносит паскаль. В паскале текст в {} -- это комментарий, а в Cи -- блок кода. А что получится в нашем входном языке, когда мы попробуем подключить обе библиотеки? Как там будет рулится, текст в скобках -- это бок или комментарий?

Но ты же где-то будешь явно указывать, что вот сейчас у нас пошел Си, а сейчас — Паскаль, правильно?
Т.е. одна макра будет с синтаксисом c_code[int main(){}], а другая — с синтаксисом paskal_code[procedure Main {comment} begin ... end]
Ну и пусть себе живут рядом в одном коде

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