Так как предыдущая тема, по мнению модераторов слишком разрослась, продолжим здесь.
Вышло новое обновление http://www.digitalmars.com/d/2.0/changelog.html#new2_029 очень много изменений в основном в библиотеках. Больше всего радует станадартный range который давно бы пора ввести и в C++ STL.
Вообще range довольно мощная штука и по выразительности и по возможностям уже близко к питоновским итераторам — генераторам и местами больше похоже на Хаскель чем на с++
// a[0] = 1, a[1] = 1, and compute a[n+1] = a[n-1] + a[n]auto fib = recurrence!("a[n-1] + a[n-2]")(1, 1);
// print the first 10 Fibonacci numbers
foreach (e; take(10, fib)) { writeln(e); }
// print the first 10 factorials
foreach (e; take(10, recurrence!("a[n-1] * n")(1))) { writeln(e); }
Во всяком случае STL'ным итераторам и алгоритмам такое комбинирование в стиле
функциональщины (уже почти все аналоги основных ФВП есть) и не снится.
Здравствуйте, FR, Вы писали:
FR>Во всяком случае STL'ным итераторам и алгоритмам такое комбинирование в стиле FR>функциональщины (уже почти все аналоги основных ФВП есть) и не снится.
Да ладно, STL-ю уже скоро двадцать лет исполнится (если мне не изменяет склероз, Степанов начал работать над его идеями еще в конце 80-х, но для Ada). Не было бы никаких range, если бы не было пятнадцати лет широчайшего использования STL-ных итераторов.
FR>
FR>// print the first 10 factorials
FR>foreach (e; take(10, recurrence!("a[n-1] * n")(1))) { writeln(e); }
FR>
Имхо, всю красоту идеи убивает то, что даже в супер-пупер-продвинутом D 2.0 тела лябда-функций приходится записывать в виде строк. Гораздо симпатичнее и логичнее выглядела бы запись:
// print the first 10 factorials
foreach (e; take(10, recurrence!(a[n-1] * n)(1))) { writeln(e); }
Но для этого, вероятно, нужно будет D 3.0 ждать, с синтаксическими макросами.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Да ладно, STL-ю уже скоро двадцать лет исполнится (если мне не изменяет склероз, Степанов начал работать над его идеями еще в конце 80-х, но для Ada). Не было бы никаких range, если бы не было пятнадцати лет широчайшего использования STL-ных итераторов.
Степанов конечно молодец, но все-равно почетный велосепедист, если даже не смотреть на лисп и функциональщину, то тот же CLU http://en.wikipedia.org/wiki/CLU_programming_language со своими итераторами, которые гораздо ближе D'шным range был уже в 74.
E>Имхо, всю красоту идеи убивает то, что даже в супер-пупер-продвинутом D 2.0 тела лябда-функций приходится записывать в виде строк. Гораздо симпатичнее и логичнее выглядела бы запись: E>
E>// print the first 10 factorials
E>foreach (e; take(10, recurrence!(a[n-1] * n)(1))) { writeln(e); }
E>
Угу.
E>Но для этого, вероятно, нужно будет D 3.0 ждать, с синтаксическими макросами.
А вот это уже совсем интересно: Migrate-to-shared. Начиная с версии 2.030 глобальные и статические переменные по умолчанию будут размещаться как TLS переменные (т.е. с использованием thread local storage). Если нужно объявить "общепринятую" разделяемую глобальную переменную, то должен использоваться модификатор shared:
shared int flag;
Т.о. в языке D сделан еще один шаг к тому, чтобы сделать язык максимально multi-thread/multi-core friendly.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Имхо, всю красоту идеи убивает то, что даже в супер-пупер-продвинутом D 2.0 тела лябда-функций приходится записывать в виде строк. Гораздо симпатичнее и логичнее выглядела бы запись: E>
E>// print the first 10 factorials
E>foreach (e; take(10, recurrence!(a[n-1] * n)(1))) { writeln(e); }
E>
Кстати в шаблонах стали выводится типы для аргументов лямбд, то есть вместо
Здравствуйте, eao197, Вы писали:
E>Т.о. в языке D сделан еще один шаг к тому, чтобы сделать язык максимально multi-thread/multi-core friendly.
Не знаю как на юнихе, а на винде, статически обьявленные TLS-переменные не работают в .DLL-ях.
Интересно, как Уолтер и компания думают с этим бороться?
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, eao197, Вы писали:
E>Да ладно, STL-ю уже скоро двадцать лет исполнится (если мне не изменяет склероз, Степанов начал работать над его идеями еще в конце 80-х, но для Ada). Не было бы никаких range, если бы не было пятнадцати лет широчайшего использования STL-ных итераторов.
Здравствуйте, FR, Вы писали:
FR>Так как предыдущая тема, по мнению модераторов слишком разрослась, продолжим здесь. FR>Вышло новое обновление http://www.digitalmars.com/d/2.0/changelog.html#new2_029 очень много изменений в основном в библиотеках. Больше всего радует станадартный range который давно бы пора ввести и в C++ STL.
По большому счету, в вопросе слежения за D, есть только один интересны момент — когда им можно будет пользоваться в коммерческой разработке. Пока же это все дело дальше "поделия для саморазвития" не пошло. А жаль.
Здравствуйте, z00n, Вы писали:
E>>Да ладно, STL-ю уже скоро двадцать лет исполнится (если мне не изменяет склероз, Степанов начал работать над его идеями еще в конце 80-х, но для Ada). Не было бы никаких range, если бы не было пятнадцати лет широчайшего использования STL-ных итераторов.
Z>Вообщето первый пробраз STL Степанов написал для Scheme(!) в 86-ом: Z>http://www.stepanovpapers.com/schemenotes/notes.pdf Z>http://www.stepanovpapers.com/schemenotes/
Имхо, не корректно сравнивать подходы к обобщенному программированию в динамических и статически-типизированных языках. Так что то, что было сделано для Scheme и, затем, для Ada -- все-таки две очень большие разницы.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>>Т.о. в языке D сделан еще один шаг к тому, чтобы сделать язык максимально multi-thread/multi-core friendly. DEA>Не знаю как на юнихе, а на винде, статически обьявленные TLS-переменные не работают в .DLL-ях.
Это как? И вообще причём тут DLL и TLS? Можно пояснить?
Здравствуйте, Tom, Вы писали:
E>>>Т.о. в языке D сделан еще один шаг к тому, чтобы сделать язык максимально multi-thread/multi-core friendly. DEA>>Не знаю как на юнихе, а на винде, статически обьявленные TLS-переменные не работают в .DLL-ях.
Tom>Это как?
А вот так. По умолчанию все не-автоматические переменные превращаются... превращаются переменные... в thread-local.
А чтобы глобальная переменная стала действительно глобальной, ей надо будет сказать "shared".
Tom>И вообще причём тут DLL и TLS?
Вот при этом (курим "Rules and Limitations for TLS" в MSDN):
If a DLL declares any nonlocal data or object as __declspec( thread ), it can cause a protection fault if dynamically loaded. After the DLL is loaded with LoadLibrary, it causes system failure whenever the code references the nonlocal __declspec( thread ) data. Because the global variable space for a thread is allocated at run time, the size of this space is based on a calculation of the requirements of the application plus the requirements of all the DLLs that are statically linked. When you use LoadLibrary, there is no way to extend this space to allow for the thread local variables declared with __declspec( thread ). Use the TLS APIs, such as TlsAlloc, in your DLL to allocate TLS if the DLL might be loaded with LoadLibrary.
...как следствие, динамически подгружаемые DLL-и на D писать станет ну оооочень трудно.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, Tom, Вы писали:
E>>>>Т.о. в языке D сделан еще один шаг к тому, чтобы сделать язык максимально multi-thread/multi-core friendly. DEA>>>Не знаю как на юнихе, а на винде, статически обьявленные TLS-переменные не работают в .DLL-ях.
Tom>>Это как? DEA>А вот так. По умолчанию все не-автоматические переменные превращаются... превращаются переменные... в thread-local. DEA>А чтобы глобальная переменная стала действительно глобальной, ей надо будет сказать "shared".
Tom>>И вообще причём тут DLL и TLS? DEA>Вот при этом (курим "Rules and Limitations for TLS" в MSDN): DEA>
DEA>If a DLL declares any nonlocal data or object as __declspec( thread ), it can cause a protection fault if dynamically loaded. After the DLL is loaded with LoadLibrary, it causes system failure whenever the code references the nonlocal __declspec( thread ) data. Because the global variable space for a thread is allocated at run time, the size of this space is based on a calculation of the requirements of the application plus the requirements of all the DLLs that are statically linked. When you use LoadLibrary, there is no way to extend this space to allow for the thread local variables declared with __declspec( thread ). Use the TLS APIs, such as TlsAlloc, in your DLL to allocate TLS if the DLL might be loaded with LoadLibrary.
DEA>...как следствие, динамически подгружаемые DLL-и на D писать станет ну оооочень трудно.
В своё время два дня на это убил
__declspec( thread ) действительно не работает в дллках, загруженных через LoadLibrary (впрочем, в Висте уже работает). Зато обычный АПИ прекрасно справляется (ТлсАллок и пр).
Здравствуйте, eao197, Вы писали:
Z>>Вообщето первый пробраз STL Степанов написал для Scheme(!) в 86-ом: Z>>http://www.stepanovpapers.com/schemenotes/notes.pdf Z>>http://www.stepanovpapers.com/schemenotes/
E>Имхо, не корректно сравнивать подходы к обобщенному программированию в динамических и статически-типизированных языках. Так что то, что было сделано для Scheme и, затем, для Ada -- все-таки две очень большие разницы.
Почитал бы сначала о чем работа. Хотя бы ее название прочел бы — "Notes on Higher Order Programming in Scheme".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>>Вообщето первый пробраз STL Степанов написал для Scheme(!) в 86-ом: Z>>>http://www.stepanovpapers.com/schemenotes/notes.pdf Z>>>http://www.stepanovpapers.com/schemenotes/
E>>Имхо, не корректно сравнивать подходы к обобщенному программированию в динамических и статически-типизированных языках. Так что то, что было сделано для Scheme и, затем, для Ada -- все-таки две очень большие разницы.
VD>Почитал бы сначала о чем работа. Хотя бы ее название прочел бы — "Notes on Higher Order Programming in Scheme".
Да где уж мне понять о чем работа. И как один итератор в работе о Scheme вдруг превратился в пару итераторов в работе об Ada. И как отсуствие описания контейнеров в работе о Scheme вдруг стало описанием целой серии родственных контейнеров в Ada. И как структуры-итераторы из Ada вдруг стали объектами-итераторами из C++. И почему "Higher Order Programming" вдруг стало главной идеей C++ STL, без учета тучи обобщенных STL-евских контейнеров (и операций над ними на основе пары итераторов, а не одного итератора из работы о Scheme).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
FR>Во всяком случае STL'ным итераторам и алгоритмам такое комбинирование в стиле FR>функциональщины (уже почти все аналоги основных ФВП есть) и не снится.
Boost.RangeEx
и что бы не писать кучу скобочек:
filter1(transformer(filter2(any_adaptor(range))));
имеется оператор '|'
range | any_adaptor
| filter2
| transformer
| filter1;
Удобно.
На последней BoostСon Александреску выступал на эту тему тута. Плюсовики понимают, что концепция итераторов морально устарела и ни что не мешает, где нибудь сбоку, создать Range-based design.
Здравствуйте, eao197, Вы писали:
E>Да где уж мне понять о чем работа. И как один итератор в работе о Scheme вдруг превратился в пару итераторов в работе об Ada. И как отсуствие описания контейнеров в работе о Scheme вдруг стало описанием целой серии родственных контейнеров в Ada. И как структуры-итераторы из Ada вдруг стали объектами-итераторами из C++. И почему "Higher Order Programming" вдруг стало главной идеей C++ STL, без учета тучи обобщенных STL-евских контейнеров (и операций над ними на основе пары итераторов, а не одного итератора из работы о Scheme).
Как сказал бы Степанов:
I know what I want to say. I can say it in C++, I can say it in Ada, I can say it in Scheme. I adapt myself to the language, but the essence of what I am trying to say is language independent. So far, C++ is the best language I've discovered to say what I want to say.
Z>I know what I want to say. I can say it in C++, I can say it in Ada, I can say it in Scheme. I adapt myself to the language, but the essence of what I am trying to say is language independent. So far, C++ is the best language I've discovered to say what I want to say.
Продолжая в том же духе, можно сказать, что раз Степанов свои работы писал на английском, то истоки его работ нужно искать в то время, когда он занимался изучением английского языка.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, z00n, Вы писали:
Z>>
Z>>I know what I want to say. I can say it in C++, I can say it in Ada, I can say it in Scheme. I adapt myself to the language, but the essence of what I am trying to say is language independent. So far, C++ is the best language I've discovered to say what I want to say.
E>Продолжая в том же духе, можно сказать, что раз Степанов свои работы писал на английском, то истоки его работ нужно искать в то время, когда он занимался изучением английского языка.
Нет, нельзя. Цитата из ответа на вопрос: "What about Generic Programming?" Вы легко найдете контекст.
Здравствуйте, z00n, Вы писали:
E>>Продолжая в том же духе, можно сказать, что раз Степанов свои работы писал на английском, то истоки его работ нужно искать в то время, когда он занимался изучением английского языка.
Z>Нет, нельзя.
В идеях STL для Ada и C++ ключевую роль играют пары итераторов (параметризуемых типом элемента последовательности). Покажите таковую в работе о Scheme.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Да где уж мне понять о чем работа.
+1
E>И как один итератор в работе о Scheme вдруг превратился в пару итераторов в работе об Ada.
"Два" — это в смысле begin и end.
E>И как отсуствие описания контейнеров в работе о Scheme вдруг стало описанием целой серии родственных контейнеров в Ada.
Производим поиск по "ADT" и убеждаемся в обратном.
E>И как структуры-итераторы из Ada вдруг стали объектами-итераторами из C++.
Вот удивительно! А это не зависит от способа представления АТД в языке?
E> И почему "Higher Order Programming" вдруг стало главной идеей C++ STL, без учета тучи обобщенных STL-евских контейнеров (и операций над ними на основе пары итераторов, а не одного итератора из работы о Scheme).
Дык особенности и родили STL, а не что-то другое. А уникальной библиотека как раз стала из-за того, что это была первая известная библиотека эксплуатирующая тот самый "Higher Order Programming".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>> И почему "Higher Order Programming" вдруг стало главной идеей C++ STL, без учета тучи обобщенных STL-евских контейнеров (и операций над ними на основе пары итераторов, а не одного итератора из работы о Scheme).
VD>Дык особенности и родили STL, а не что-то другое.
А теперь поднимаемся в вершину ветки и видим, что речь шла именно об итераторах (которые парами) и их замены на более многообещающие Ranges. А пары итераторов как раз и возникли из-за особенностей обобщенного программирования в Ada и C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>В идеях STL для Ada и C++ ключевую роль играют пары итераторов (параметризуемых типом элемента последовательности). Покажите таковую в работе о Scheme.
Давайте лучше вы покажете, где Степанов сказал что "В идеях STL для Ada и C++ ключевую роль играют пары итераторов (параметризуемых типом элемента последовательности)". Идеи, кстати, самим Степановым датируются 70-ыми годами.
Здравствуйте, z00n, Вы писали:
E>>В идеях STL для Ada и C++ ключевую роль играют пары итераторов (параметризуемых типом элемента последовательности). Покажите таковую в работе о Scheme.
Z>Давайте лучше вы покажете, где Степанов сказал что "В идеях STL для Ada и C++ ключевую роль играют пары итераторов (параметризуемых типом элемента последовательности)".
Ну <censored>, какой интересный расклад получается. Вначале FR заговорил о Ranges, которые Александреску ввел в D вместо C++ных итераторов. И я сказал об STL именно с точки зрения итераторов -- мол, не было бы опыта их использования в C++, возможно в D не было бы сейчас Ranges. И что идеи итераторов в C++ пришли прямиком из Ada. Тут подключаются эрудиты и утверждают, что идеи эти пришли еще из Scheme. Но показать их в Scheme отказываются.
Что до ключевой идеи, то это не Степанов сказал, а я. Да, по-моему, контейнеры и итераторы -- это краеугольные камни C++ного STL (времен стандарта 98-го года). Причем итераторы, наверное, даже краеугольнее, т.к. именно из-за них в C++ных контейнерах есть методы begin()/end(), а не методы each/inject/map.
Если вас эта точка зрения не устраивает, то разговор можно закончить, списав все на мою воинствующую безграмотность.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, z00n, Вы писали:
E>>>В идеях STL для Ada и C++ ключевую роль играют пары итераторов (параметризуемых типом элемента последовательности). Покажите таковую в работе о Scheme.
Z>>Давайте лучше вы покажете, где Степанов сказал что "В идеях STL для Ada и C++ ключевую роль играют пары итераторов (параметризуемых типом элемента последовательности)".
E>Ну ёптыть, какой интересный расклад получается. Вначале FR заговорил о Ranges, которые Александреску ввел в D вместо C++ных итераторов. И я сказал об STL именно с точки зрения итераторов -- мол, не было бы опыта их использования в C++, возможно в D не было бы сейчас Ranges. И что идеи итераторов в C++ пришли прямиком из Ada. Тут подключаются эрудиты и утверждают, что идеи эти пришли еще из Scheme. Но показать их в Scheme отказываются.
Напоминаю: Вы> STL-ю уже скоро двадцать лет исполнится (если мне не изменяет склероз, Степанов начал работать над его идеями еще в конце 80-х, но для Ada) Я> Вообщето первый пробраз STL Степанов написал для Scheme(!) в 86-ом.
И Степанов говорит, и вообще так принято считать, что идеей STL является отделение алгоритмов от контейнеров.
Здравствуйте, z00n, Вы писали:
Z>Напоминаю: Вы>> STL-ю уже скоро двадцать лет исполнится (если мне не изменяет склероз, Степанов начал работать над его идеями еще в конце 80-х, но для Ada) Я>> Вообщето первый пробраз STL Степанов написал для Scheme(!) в 86-ом. Z>И Степанов говорит, и вообще так принято считать, что идеей STL является отделение алгоритмов от контейнеров.
Ну да, итератор, который у Степанова получился в Ada и C++ -- это не идея, это так, мелкая деталь реализации.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А теперь поднимаемся в вершину ветки и видим, что речь шла именно об итераторах (которые парами) и их замены на более многообещающие Ranges. А пары итераторов как раз и возникли из-за особенностей обобщенного программирования в Ada и C++.
STL и работа Степанова — это не итераторы и не про итераторы. Итераторы там — это абстракция списка в том виде в котором она может быть обобщена в С++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>А теперь поднимаемся в вершину ветки и видим, что речь шла именно об итераторах (которые парами) и их замены на более многообещающие Ranges. А пары итераторов как раз и возникли из-за особенностей обобщенного программирования в Ada и C++.
VD>STL и работа Степанова — это не итераторы и не про итераторы.
Зато у нас с FR разговор был об STL-ных итераторах и Ranges из D, как более совершенной альтернативы итераторам. И в C++ итераторы были введены Степановым на основании его работы над Ada-реализацией.
VD>Итераторы там — это абстракция списка в том виде в котором она может быть обобщена в С++.
Абстракцией какого списка служит, например, istream_iterator?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, z00n, Вы писали:
Z>>И Степанов говорит, и вообще так принято считать, что идеей STL является отделение алгоритмов от контейнеров.
E>Вообще-то, это не столько идея, сколько цель.
Это, разумеется, ваше мнение — подкрепить его, например, цитатой из Степанова вы не можете.
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, z00n, Вы писали:
Z>>>И Степанов говорит, и вообще так принято считать, что идеей STL является отделение алгоритмов от контейнеров.
E>>Вообще-то, это не столько идея, сколько цель. Z>Это, разумеется, ваше мнение — подкрепить его, например, цитатой из Степанова вы не можете.
Ммм, а что на твой взляд было его целью? И чем идея у тебя от цели отличается?
Или чисто спор о терминах?
VladD2 wrote:
> Именно так. В динамических ФЯ к которым относится Схема они просто не > очень нужны. Там все базируется на списках.
Утверждение сомнительное. Итераторы в первую очередь ограничивают
обрабатываемую подпоследовательность. Как список это может сделать ?
Я не знаю, как в схеме, а в common lisp аналоги итераторов есть,
там все последовательности отображены на множество целых неотрицательных
чисел, и два необязательных индекса начала и конца обрабатываемого
диапазона входят в число параметров всех функций обработки последовательностей.
Это — прямой аналог итераторов, хотя сделано всё без дешёвых понтов,
железобетонно и удобно.
Я подозреваю, что в схеме просто нет ничего, кроме списков, из
последовательностей. Т.е. обобщённых последовательностей нет вообще.
Здравствуйте, MasterZiv, Вы писали:
MZ>VladD2 wrote:
>> Именно так. В динамических ФЯ к которым относится Схема они просто не >> очень нужны. Там все базируется на списках.
MZ>Утверждение сомнительное. Итераторы в первую очередь ограничивают MZ>обрабатываемую подпоследовательность. Как список это может сделать ?
Последовательность и список — это одно и тоже. Все что нужно уметь с ними делать для унифицированной обработки — это получить голову и хвост. Остальные операции реализуются на них. CAR CDR как раз и есть встроенные возможности любого диалекта лиспа решающие данный вопрос.
MZ>Я не знаю, как в схеме, а в common lisp аналоги итераторов есть, MZ>там все последовательности отображены на множество целых неотрицательных MZ>чисел, и два необязательных индекса начала и конца обрабатываемого MZ>диапазона входят в число параметров всех функций обработки последовательностей.
Ну, и как это применить к списку у которого попросту нет индексированного доступа?
MZ>Это — прямой аналог итераторов, хотя сделано всё без дешёвых понтов, MZ>железобетонно и удобно.
Как раз итераторы С++ не предполагают наличия индексного доступа (кроме одного поддтипа, который трудно назвать итератором).
MZ>Я подозреваю, что в схеме просто нет ничего, кроме списков, из MZ>последовательностей. Т.е. обобщённых последовательностей нет вообще.
У тебя весьма извращенное понимание обобщенности. "Обобщенный означает переход от частного к общему. Индексированный доступ — это частность, а вот понятие списка — упорядоченное множество — это более общее понятие.
Теперь почему для динамических языков введение четкого интерфейса не имеет особого смысла...
В динамических языках обычно все функции автоматически становятся обобщенными. Достаточно описать функции доступа используемые в алгоритме, как алгоритм автоматически становится обобщенным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Как я понял это пока не входит в boost ?
A>и что бы не писать кучу скобочек: A>filter1(transformer(filter2(any_adaptor(range))));
A>имеется оператор '|' A>range | any_adaptor A> | filter2 A> | transformer A> | filter1; A>Удобно.
Ну в D еще удобней
Хотя конечно тоже лучше итераторов.
A>На последней BoostСon Александреску выступал на эту тему тута. Плюсовики понимают, что концепция итераторов морально устарела и ни что не мешает, где нибудь сбоку, создать Range-based design.
Это читал.
Осталось еще один шаг сделать, до генераторов с yield
Здравствуйте, VladD2, Вы писали:
VD>В динамических языках обычно все функции автоматически становятся обобщенными. Достаточно описать функции доступа используемые в алгоритме, как алгоритм автоматически становится обобщенным.
Здравствуйте, eao197, Вы писали:
E>Зато у нас с FR разговор был об STL-ных итераторах и Ranges из D, как более совершенной альтернативы итераторам. И в C++ итераторы были введены Степановым на основании его работы над Ada-реализацией.
Зря наверно про функциональщину я писал
Я уже давал ссылку на более близкую чем функциональщина (при этом мало уступающую в выразительности) родню итератором и ranges это итераторы из CLU http://en.wikipedia.org/wiki/CLU_programming_language похоже Степанов о них все-таки не знал, тогда сразу могло получится гораздо лучше.
Здравствуйте, z00n, Вы писали:
Z>>>И Степанов говорит, и вообще так принято считать, что идеей STL является отделение алгоритмов от контейнеров.
E>>Вообще-то, это не столько идея, сколько цель. Z>Это, разумеется, ваше мнение
Разумеется мое.
Отделение алгоритмов от контейнеров -- это одна из идей обобщенных алгоритмов:
The most important technical idea is that of generic algorithms, which are a means of
providing functionality in a way that abstracts away from details of representation and basic
operations.
А STL -- это библиотека, целью которой является воплощение замыслов разработчиков в реальный код.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
FR>>Во всяком случае STL'ным итераторам и алгоритмам такое комбинирование в стиле FR>>функциональщины (уже почти все аналоги основных ФВП есть) и не снится.
E>Да ладно, STL-ю уже скоро двадцать лет исполнится (если мне не изменяет склероз, Степанов начал работать над его идеями еще в конце 80-х, но для Ada). Не было бы никаких range, если бы не было пятнадцати лет широчайшего использования STL-ных итераторов.
Я был не прав. В реализации Степанова для Ada итераторы были совсем другие -- там не было пар итераторов. Пары итераторов возникли уже в C++. Из работ на Ada в C++ пришли, разве что, слои абстракции.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, eao197, Вы писали:
E>>В идеях STL для Ada и C++ ключевую роль играют пары итераторов (параметризуемых типом элемента последовательности). Покажите таковую в работе о Scheme. Z>Давайте лучше вы покажете, где Степанов сказал что "В идеях STL для Ada и C++ ключевую роль играют пары итераторов (параметризуемых типом элемента последовательности)". Идеи, кстати, самим Степановым датируются 70-ыми годами.
In the generic programming approach we use generic indexing by a generic formal
type Coordinate. Coordinate is instantiated to type Natural for vectors; for linked
lists, however, cells themselves can serve as Coordinate values. A generic Find can thus
return a Coordinate value that can be used to reference the located element directly
The intended semantics for Coordinate is that there are functions
* Initial from Sequence to Coordinate;
* Next from Coordinate to Coordinate;
* Is End from Sequence x Coordinate to Boolean, and
* Ref from Sequence x Coordinate to a third type Element
We stress that the algorithms at this level are derived by abstraction from concrete, efficient
algorithms. As an example of algorithmic abstraction, consider the task of choosing
and implementing a sorting algorithm for linked list data structures. The merge sort algorithm
can be used and, if properly implemented, provides one of the most efficient sorting
algorithms for linked lists. Ordinarily one might program this algorithm directly in terms
of whatever pointer and record field access operations are provided in the programming
language. Instead, however, one can abstract away a concrete representation and express
the algorithm in terms of the smallest possible number of generic operations. In this case,
we essentially need just three operations: Next and Set_Next for accessing the next cell in a
list, and Is-End for detecting the end of a list. For a particular representation of linked lists,
one then obtains the corresponding version of a merge sorting algorithm by instantiating
the generic access operations to be subprograms that access that representation.
Thus in Ada one programs generic algorithms in a generic package whose parameters
are a small number of types and access operations-e. g.,
generic
type Cell is private;
with function Next (S : Cell) return Cell ;
with procedure Set_Next (S1 , S2 : Cell) ;
with function Is_End(S : Cell) return Boolean;
with function Copy_Cell(Sl , S2 : Cell) return Cell ;
package Linked_List_Algorithms i s
The subprograms in the package are algorithms such as Merge and Sort that are efficient
when Next, Set_Next , etc., are instantiated with constant time operations.
Так что для меня очевидно, что итераторы -- это краеугольный камень в работах Степанова по обобщенному программированию, т.к. алгоритмы в них записываются именно через итераторы.
Другое дело, что в Ada не было еще пары итераторов. А в C++ уже была.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Я был не прав. В реализации Степанова для Ada итераторы были совсем другие -- там не было пар итераторов. Пары итераторов возникли уже в C++. Из работ на Ada в C++ пришли, разве что, слои абстракции.
Здравствуйте, eao197, Вы писали:
VD>>В динамических языках обычно все функции автоматически становятся обобщенными. Достаточно описать функции доступа используемые в алгоритме, как алгоритм автоматически становится обобщенным.
E>Тогда может ты объяснишь, с чем ты был не согласен вот здесь: http://www.rsdn.ru/forum/philosophy/3389403.1.aspx
Со всем. Сравнивать корректно. Плюс его работа не про общение, а про выделение алгоритмов, то что он назвал "хай ордер программирг". Совершенно фиолетово как это достигается. Важен сам подход. ФЯ исконно были сильны в этом вопросе. И динамический Лисп, и статический Хаскель одинаково предоставляют абстракцию лямбды и замыкания для вынесения частных частей во вне.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>shared int flag;
E>Т.о. в языке D сделан еще один шаг к тому, чтобы сделать язык максимально multi-thread/multi-core friendly.
нет. это наоборот приведёт к тому, что использовать потоки станет невозможно. представь, что есть у тебя поток, который обрабатывает скажем connection с пользователем. и в этом потоке что-то удобно сделать в бэкграунде, запустив для этого отдельный поток. ап! и облом
Здравствуйте, z00n, Вы писали:
Z>Как сказал бы Степанов: Z>
Z>I know what I want to say. I can say it in C++, I can say it in Ada, I can say it in Scheme. I adapt myself to the language, but the essence of what I am trying to say is language independent. So far, C++ is the best language I've discovered to say what I want to say.
то, что он хочет сказать, language-independent, но почему-то не видно работ о generic-программировании в схеме, руби и других динамических языках. не знаешь почему?
Здравствуйте, BulatZiganshin, Вы писали:
E>>shared int flag;
E>>Т.о. в языке D сделан еще один шаг к тому, чтобы сделать язык максимально multi-thread/multi-core friendly.
BZ>нет. это наоборот приведёт к тому, что использовать потоки станет невозможно. представь, что есть у тебя поток, который обрабатывает скажем connection с пользователем. и в этом потоке что-то удобно сделать в бэкграунде, запустив для этого отдельный поток. ап! и облом
Почему? Я не понял твоего примера.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, BulatZiganshin, Вы писали:
E>>>shared int flag;
E>>>Т.о. в языке D сделан еще один шаг к тому, чтобы сделать язык максимально multi-thread/multi-core friendly.
BZ>>нет. это наоборот приведёт к тому, что использовать потоки станет невозможно. представь, что есть у тебя поток, который обрабатывает скажем connection с пользователем. и в этом потоке что-то удобно сделать в бэкграунде, запустив для этого отдельный поток. ап! и облом
E>Почему? Я не понял твоего примера.
да потому что другой тред, который ты создашь, не получит доступ к переменным твоего треда. а в них вся информация о пользователе. в результате треды из средства упрощения логики и повышения производительности программы прверащаются в минное поле почище null
Здравствуйте, BulatZiganshin, Вы писали:
BZ>да потому что другой тред, который ты создашь, не получит доступ к переменным твоего треда. а в них вся информация о пользователе. в результате треды из средства упрощения логики и повышения производительности программы прверащаются в минное поле почище null
А по-моему как раз наоборот. Вместо минного поля ты будешь вынужден при старте треда передать ему всю информацию явно (избежав таким образом всех гонок). И ты трижды подумаешь, прежде чем пометить некую переменную как shared.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>да потому что другой тред, который ты создашь, не получит доступ к переменным твоего треда. а в них вся информация о пользователе. в результате треды из средства упрощения логики и повышения производительности программы прверащаются в минное поле почище null
Sinclair рядом уже ответил. Я же добавлю, что в D2 легко разделить мутабельные данные между потоками -- для этого достаточно пометить глобальную переменную как shared. А иммутабельные данные (invariant-объекты), вроде бы разделяются между нитями вообще без проблем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
BZ>>да потому что другой тред, который ты создашь, не получит доступ к переменным твоего треда. а в них вся информация о пользователе. в результате треды из средства упрощения логики и повышения производительности программы прверащаются в минное поле почище null S>А по-моему как раз наоборот. Вместо минного поля ты будешь вынужден при старте треда передать ему всю информацию явно (избежав таким образом всех гонок).
и что здесь меняется от того, что переменные по умолчанию стали tls? от обычных глобалов хоть какая-то польза есть, tls-переменные же сейчас — минне поле. и то, что этот атрибут применяется по автомату, открывает блестящие перспективы для ошибок
S> И ты трижды подумаешь, прежде чем пометить некую переменную как shared.
Здравствуйте, eao197, Вы писали:
E>Sinclair рядом уже ответил. Я же добавлю, что в D2 легко разделить мутабельные данные между потоками -- для этого достаточно пометить глобальную переменную как shared.
я умею читать, спасибо. проблема в том, что эту пометку нетрудно забыть
Здравствуйте, BulatZiganshin, Вы писали:
E>>Sinclair рядом уже ответил. Я же добавлю, что в D2 легко разделить мутабельные данные между потоками -- для этого достаточно пометить глобальную переменную как shared.
BZ>я умею читать, спасибо. проблема в том, что эту пометку нетрудно забыть
По-моему, если забыть эту отметку в том сценарии, о котором ты говорил для примера, то первый же тестовый запуск выловит null-ы в нитях.
Хотя, думаю, что в многом ты прав. И было бы логичнее, если бы глобальные переменные нужно было помечать атрибутом shared, а TLS-переменные каким-то другим атрибутом (типа threadlocal). Чтобы не было просто глобальных переменных. Это бы сразу избавило D-шных программистов от C/C++ного наследия.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>По-моему, если забыть эту отметку в том сценарии, о котором ты говорил для примера, то первый же тестовый запуск выловит null-ы в нитях.
а если нить создаётся, к примеру, только при высокой нагрузке? а если там int?
E>Хотя, думаю, что в многом ты прав.
tls — механизм очень удобный, но только при ограниченной модели программирования. исходная проблема состоит в том, что нам нужны отдельные копии global state для разных invocations какой-то операции, но эти копии должны быть привязаны к операции. привязка к процессу хороша только когда каждая операция живёт в своём процессе, т.е. это работает только в модели "многопоточность разрещена только на верхнем уровне". при активном использовании многопточности для реализации самих алгоритмов это всё вылетает в трубу
E>И было бы логичнее, если бы глобальные переменные нужно было помечать атрибутом shared, а TLS-переменные каким-то другим атрибутом (типа threadlocal). Чтобы не было просто глобальных переменных. Это бы сразу избавило D-шных программистов от C/C++ного наследия.
Здравствуйте, BulatZiganshin, Вы писали:
E>>По-моему, если забыть эту отметку в том сценарии, о котором ты говорил для примера, то первый же тестовый запуск выловит null-ы в нитях.
BZ>а если нить создаётся, к примеру, только при высокой нагрузке? а если там int?
Так ведь этот сценарий так же нужно протестировать, или нет?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
BZ>>а если нить создаётся, к примеру, только при высокой нагрузке? а если там int?
E>Так ведь этот сценарий так же нужно протестировать, или нет?
рассказать тебе почему применяются языки со стат. типизацией?
Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>а если нить создаётся, к примеру, только при высокой нагрузке? а если там int?
E>>Так ведь этот сценарий так же нужно протестировать, или нет?
BZ>рассказать тебе почему применяются языки со стат. типизацией?
Нет, агитация мне не нужна. Но тесты беспристрасно показывают, что реально делает программа в конктерных условиях. Тогда как статическая типизация всего лишь декларирует желания программиста о том, что программа хочет делать. Желания и хотения, как показывает практика, сильно отличаются от объективной реальности.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 0xDEADBEEF, Вы писали:
E>>Т.о. в языке D сделан еще один шаг к тому, чтобы сделать язык максимально multi-thread/multi-core friendly. DEA>Не знаю как на юнихе, а на винде, статически обьявленные TLS-переменные не работают в .DLL-ях.
Здравствуйте, eao197, Вы писали:
BZ>>>>а если нить создаётся, к примеру, только при высокой нагрузке? а если там int?
E>>>Так ведь этот сценарий так же нужно протестировать, или нет?
BZ>>рассказать тебе почему применяются языки со стат. типизацией?
E>Нет, агитация мне не нужна.
В последнее время участилось появление новых версий D, надеюсь это признак приближающегося релиза.
В последней версии http://www.digitalmars.com/d/2.0/changelog.html#new2_035 появился интересный ключик у компилятора -X выдает что-то сильно похожее на AST в JSON формате, там пока все еще криво и формат не устаканился, но если довести до ума будет очень близко к рефлексии из управляемых языков.
Здравствуйте, FR, Вы писали:
FR>В последнее время участилось появление новых версий D, надеюсь это признак приближающегося релиза.
FR>В последней версии http://www.digitalmars.com/d/2.0/changelog.html#new2_035 появился интересный ключик у компилятора -X выдает что-то сильно похожее на AST в JSON формате, там пока все еще криво и формат не устаканился, но если довести до ума будет очень близко к рефлексии из управляемых языков.
интересно будут ли авторы D делать такие же лицензионные ограничения на использование этой инфо как это сделали авторы gcc. Разумеется это не толкнет использовать D в проектах — просто будет интересный вариант для экспериментов в генерации кода.
Здравствуйте, SleepyDrago, Вы писали:
SD>интересно будут ли авторы D делать такие же лицензионные ограничения на использование этой инфо как это сделали авторы gcc. Разумеется это не толкнет использовать D в проектах — просто будет интересный вариант для экспериментов в генерации кода.
А что с gcc?
Я не вижу причин для автора D в чем-то ограничивать, вот недавно он и стандартную библиотеку перевел на бустовскую лицензию.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, SleepyDrago, Вы писали:
SD>>интересно будут ли авторы D делать такие же лицензионные ограничения на использование этой инфо как это сделали авторы gcc. Разумеется это не толкнет использовать D в проектах — просто будет интересный вариант для экспериментов в генерации кода.
FR>А что с gcc? FR>Я не вижу причин для автора D в чем-то ограничивать, вот недавно он и стандартную библиотеку перевел на бустовскую лицензию.
ну вот более менее ясный линк http://lwn.net/Articles/324028/ на тему "что с gcc".
если нет времени смотреть — то они борются с построением коммерческих плагинов.
Самое интересное по моему http://www.digitalmars.com/d/2.0/operatoroverloading.html#Dispatch. Дает возможность диспетчеризации вызовов, если какой то метод не определен в структуре или классе, но при этом определен шаблонный метод opDispatch с соответствующей сигнатурой, то он и вызывается. Раньше была перегрузка оператора точки opDot (во многом аналог operator-> из C++) сейчас из документации это исчезло, opDispatch в общем полностью перекрывает его функциональность.
FR>>В общем с мая никаких глобальных или ломающих изменений не видно, пора уже хотя бы в бету перейти.
FR>Похоже я поторопился в новой версии http://www.digitalmars.com/d/2.0/changelog.html#new2_037 появились новые фичи.
FR>Самое интересное по моему http://www.digitalmars.com/d/2.0/operatoroverloading.html#Dispatch. Дает возможность диспетчеризации вызовов, если какой то метод не определен в структуре или классе, но при этом определен шаблонный метод opDispatch с соответствующей сигнатурой, то он и вызывается. Раньше была перегрузка оператора точки opDot (во многом аналог operator-> из C++) сейчас из документации это исчезло, opDispatch в общем полностью перекрывает его функциональность.
opDot перекрылся уже alias this (перенаправление вызовов неопределённых методов другому объекту. Иными словами, наследование методом делегирования, как в snit). opDispatch — новая фича.
opDispatch — шаблонный метод. Если он объявлен в классе или структуре, то, при вызове отсутствующего в классе метода, имя функции и все аргументы (в соответствии с сигнатурой. Либо tuple'ом, либо фиксированными аргументами) будут переданы в opDispatch. Незаменимая штука в некоторых случаях. Например, с помощью этой штуки можно реализовать класс, который будет все вызываемые у него методы... преобразовывать в удалённые Xml-Rpc вызовы.
Здравствуйте, naryl, Вы писали:
N>opDot перекрылся уже alias this (перенаправление вызовов неопределённых методов другому объекту. Иными словами, наследование методом делегирования, как в snit). opDispatch — новая фича.
Угу в D уже многовато способов сделать одно и тоже
N>opDispatch — шаблонный метод. Если он объявлен в классе или структуре, то, при вызове отсутствующего в классе метода, имя функции и все аргументы (в соответствии с сигнатурой. Либо tuple'ом, либо фиксированными аргументами) будут переданы в opDispatch. Незаменимая штука в некоторых случаях. Например, с помощью этой штуки можно реализовать класс, который будет все вызываемые у него методы... преобразовывать в удалённые Xml-Rpc вызовы.
Там много применений можно придумать, в динамических языках (питон, руби) давно такой механизм существует. Вот только пора бы уже и остановится с добавлением фич.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, naryl, Вы писали:
N>>opDot перекрылся уже alias this (перенаправление вызовов неопределённых методов другому объекту. Иными словами, наследование методом делегирования, как в snit). opDispatch — новая фича.
FR>Угу в D уже многовато способов сделать одно и тоже
opDot убрали. alias this и opDispatch — концептуально разные фичи и применяются в разных задачах.
N>>opDispatch — шаблонный метод. Если он объявлен в классе или структуре, то, при вызове отсутствующего в классе метода, имя функции и все аргументы (в соответствии с сигнатурой. Либо tuple'ом, либо фиксированными аргументами) будут переданы в opDispatch. Незаменимая штука в некоторых случаях. Например, с помощью этой штуки можно реализовать класс, который будет все вызываемые у него методы... преобразовывать в удалённые Xml-Rpc вызовы.
FR>Там много применений можно придумать, в динамических языках (питон, руби) давно такой механизм существует. Вот только пора бы уже и остановится с добавлением фич.
Если подумать, то пора, но, например, opDispatch как-раз для Xml-Rpc очень бы пригодился... Если бы начальство не сказало мне (единственному разработчику внутреннего проекта) "надо на C++".
Здравствуйте, naryl, Вы писали:
N>opDot убрали. alias this и opDispatch — концептуально разные фичи и применяются в разных задачах.
Обоими opDot можно заменить.
FR>>Там много применений можно придумать, в динамических языках (питон, руби) давно такой механизм существует. Вот только пора бы уже и остановится с добавлением фич.
N>Если подумать, то пора, но, например, opDispatch как-раз для Xml-Rpc очень бы пригодился... Если бы начальство не сказало мне (единственному разработчику внутреннего проекта) "надо на C++".