Здравствуйте, eao197, Вы писали:
E>К тому же обсуждавшийся фрагмент кода на C++ со скалярными параметрами шаблонов ни относился ни к низкому уровню, ни к RealTime.
Я не вижу принципиальных проблем в том, чтобы реализовать эту функциональность на макросах Nemerle (ради пресловутого compile-time) — это сделать будет непросто, но и решение на шаблонах непростое. Естественно, это будут не скалярные параметры generic-ов (так делать просто нельзя), а нечто иное.
Я сам думал (ещё до того, как начались все эти обсуждения про физические величины) заимплементать этот код на Nemerle (понравился мне вариант на C++, чего уж там) чисто ради спортивного интереса, но времени нету...
Здравствуйте, Oyster, Вы писали:
O>Я не вижу принципиальных проблем в том, чтобы реализовать эту функциональность на макросах Nemerle (ради пресловутого compile-time) — это сделать будет непросто, но и решение на шаблонах непростое. Естественно, это будут не скалярные параметры generic-ов (так делать просто нельзя), а нечто иное.
говорил.
В общем-то я с вами согласен, смущает меня только то, что в C++ в одном выражении можно будет сочетать operator*() (и другие) для разных типов данных. Например, Physic<A,B,C> еще и на скаляр умножить можно будет -- в самом выражении с использованием операторов это никак не будет явно подчеркиваться. В Nemerle для таких ситуаций, вероятно, еще что-то додумывать придется.
Но поинт здесь был в другом. Хоть на C++ решение и не тривиальное на первый взгляд, но самое сложное в нем -- это додуматься до него. Сама же реализация отнюдь не сложная. Бывают гораздо более сложные навороты (например, проверка чисел на простоту в compile-time). И, возвращаясь к первоначальному замечанию VladD2 о скалярных параметрах шаблонах, вполне себе востребованный и жизнеспособный код.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Одинакого хорошо -- это, очень вероятно, на одинаково сером уровне.
парадигмы — это не задачи. Это разные подходы к решению одной конкретной задачи.
E>Ты конечно, можешь мне возразить, что там речи не было ни о низком уровне, ни о RTS. Но смысла это не изменит. К тому же обсуждавшийся фрагмент кода на C++ со скалярными параметрами шаблонов ни относился ни к низкому уровню, ни к RealTime.
единственная проблема с этим кодом — это требования к быстродействию. Если его отбросить, то задача решается на Немерле без малейших проблем. Но там и вообще с быстродействием пока не очень хорошо. Версия 0.9, всё-таки, да еще pure managed code. Ты это хотел услышать?
E>Так вот, мало кто скажет. Потому, что когда нужно решать реальные задачи, все разговоры о красиво/не красиво, отрывать/пришивать что-нибудь и пр. остаются в курилке. Поскольку нужно либо написать работающую программу и получить за это деньги, либо провалить проект. И выясняется, что на C++ коряво написать можно, и работать будет. А вот альтернативу найти -- еще попробуй.
Программа, которая вся целиком состоит из задачи контроля размерностей?
Здравствуйте, Дарней, Вы писали:
Д>единственная проблема с этим кодом — это требования к быстродействию. Если его отбросить, то задача решается на Немерле без малейших проблем. Но там и вообще с быстродействием пока не очень хорошо. Версия 0.9, всё-таки, да еще pure managed code. Ты это хотел услышать?
Нет. Давай отбросим требования к скорости. Реши ее на Nemerle.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, SilverCloud, Вы писали:
SC>А вот здесь поспорю. Пока не подходит. Это ограничение текущей реализации платформы, причём явно временное. Ни сам язык, ни спецификация .NET таких ограничений, вроде, не содержит.
а я не буду спорить Я говорил именно про текущую реализацию. Что там да как будет потом — это можно только догадываться.
Здравствуйте, eao197, Вы писали:
E>Нет. Давай отбросим требования к скорости. Реши ее на Nemerle.
У меня нет времени заниматься решением умозрительных задач. Если тебя это так сильно интересует, попробуй сам изучить таки язык, который ты критикуешь. А потом рассказать всем, какие принципиальные препятствия, не дающие решить эту задачу, там есть.
Для меня же хватает того факта, что макросы Немерле достаточно мощны, чтобы эмулировать шаблоны С++ один-в-один . Значит, задача так или иначе решается.
Здравствуйте, eao197, Вы писали:
E>В общем-то я с вами согласен, смущает меня только то, что в C++ в одном выражении можно будет сочетать operator*() (и другие) для разных типов данных. Например, Physic<A,B,C> еще и на скаляр умножить можно будет -- в самом выражении с использованием операторов это никак не будет явно подчеркиваться. В Nemerle для таких ситуаций, вероятно, еще что-то додумывать придется.
Насколько я понимаю, оператор * можно сделать макросом и тогда получится оставить "прозрачный" синтаксис.
E>Но поинт здесь был в другом. Хоть на C++ решение и не тривиальное на первый взгляд, но самое сложное в нем -- это додуматься до него. Сама же реализация отнюдь не сложная. Бывают гораздо более сложные навороты (например, проверка чисел на простоту в compile-time). И, возвращаясь к первоначальному замечанию VladD2 о скалярных параметрах шаблонах, вполне себе востребованный и жизнеспособный код.
На самом деле, макросы Nemerle позволяют делать compile-time вычисления проще, потому что — сам понимаешь — в них можно выполнять любой код.
Сейчас дам ма-аленький такой пример. Будем считать факториал в compile-time:
namespace Oyster
{
public module Math
{
// Просто метод, который просто считает факториал в рантаймеstatic public Fact(x : int) : int
{
| 1 => 1
| _ => x * Fact(x - 1)
}
}
}
namespace Oyster.Macro
{
// Макрос
macro Fact(expr)
{
match (expr) {
| <[ $(x : int) ]> => <[ $(Oyster.Math.Fact(x) : int) ]>
| _ => <[ Oyster.Math.Fact($expr) ]>
}
}
}
Макрос Fact или вернёт константу (если передана константа) или вставит вызов Math.Fact (в противном случае). При этом вызов макроса ничем не отличается от вызова функции и оба варианта из примера ниже отработают:
using System.Console;
using Oyster;
// Выведет 720, посчитает в compile-time
WriteLine(Macro.Fact(6));
// Выведет 720, но посчитает в рантайме
def x = 6;
WriteLine(Macro.Fact(x))
Здравствуйте, Дарней, Вы писали:
E>>Нет. Давай отбросим требования к скорости. Реши ее на Nemerle.
Д>У меня нет времени заниматься решением умозрительных задач.
Вот так всегда. На C++ работающий код есть и не в одном экземпляре. Хотя кто-то еще думает, что скаляры в шаблонах не нужны. Поэтому C++ код можно материть и кричать C++ must die (утрируя). Привести пример реально существующей альтернативы имеющий такие же возможности (в данном случае по быстродействию) -- умозрительные задачи.
Д>Если тебя это так сильно интересует, попробуй сам изучить таки язык, который ты критикуешь.
А ты сам его изучил? А то фраза "Для меня же хватает того факта, что макросы Немерле достаточно мощны, чтобы эмулировать шаблоны С++ один-в-один . Значит, задача так или иначе решается" оставляет двойственные впечатления.
И еще, в данной ветке я не критиковал Nemerle. Ни разу.
Я вполне лояльно отношусь к нему. Но хочу, чтобы рассказы о Nemerle были более адекватные, чем "Nemerle рулит!" или "В Nemerle все продумано и уши не торчат", или "поверьте мои словам". А посему хочется, чтобы Nemerle корректно сравнивался с другими языками (моя придирка к OCaml) и чтобы другие языки не обоснованно не критиковались (особенно, если нет понимания необходимости конкретной фичи языка).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>В общем-то я с вами согласен, смущает меня только то, что в C++ в одном выражении можно будет сочетать operator*() (и другие) для разных типов данных. Например, Physic<A,B,C> еще и на скаляр умножить можно будет -- в самом выражении с использованием операторов это никак не будет явно подчеркиваться. В Nemerle для таких ситуаций, вероятно, еще что-то додумывать придется.
Насчёт этого — можно будет оставить прозрачный синтаксис и без * как макрос, потому что, в конце концов, никто нам не мешает сконструировать новый тип для конкретной физической величины в compile-time в Nemerle с таким вот оператором (собственно, это и происходит в C++ — с помощью шаблонов создаётся куча конкретных типов при компиляции).
Здравствуйте, eao197, Вы писали:
E>Так вот не придется ли тебе в макросе проверять типы выражений и в зависимости от типа левого/правого операнда производить генерацию разного кода?
Здравствуйте, Oyster, Вы писали:
E>>)
O>Не придирайся Забыл написать, что писал на скорую руку Главное ж принцип...
Я не придираюсь, просто показываю, что самые жестокие ошибки чаще всего делаются не столько из-за особенностей языка, сколько из-за человеческого фактора.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Я не придираюсь, просто показываю, что самые жестокие ошибки чаще всего делаются не столько из-за особенностей языка, сколько из-за человеческого фактора.
В таком случае сообщу, что я написал намеренно упрощённый код. Эту ошибку я сделал сознательно для упрощения примера. Вот как
Это дело привычки, на самом-то деле. Люди вон к Lisp-овой нотации привыкают
O>или что-то такое. А что самое главное — можно использовать макрос как с константами, так и с переменными — внутри само разберётся.
+1
А вот это да. Полностью согласен.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Oyster, Вы писали:
O>В таком случае сообщу, что я написал намеренно упрощённый код. Эту ошибку я сделал сознательно для упрощения примера. Вот как
Ты часом к науке не имел отношения? А то я наблюдал, как при передачи статей в журнал некоторые научные деятели намеренно в сложных формулах мелкие ошибки делали (например, кое-где плюсик на минус поменяют). Чтобы никто просто так результатами трудов не воспользовался
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Вот так всегда. На C++ работающий код есть и не в одном экземпляре. Хотя кто-то еще думает, что скаляры в шаблонах не нужны. Поэтому C++ код можно материть и кричать C++ must die (утрируя). Привести пример реально существующей альтернативы имеющий такие же возможности (в данном случае по быстродействию) -- умозрительные задачи.
Для меня сама эта задача — умозрительная, а не детали ее реализации. Потому что я никогда с ней не сталкивался, не сталкиваюсь сейчас и вряд ли когда-нибудь столкнусь в обозримом будущем.
Я вообще не вижу ни малейшего смысла доказывать общее утверждение, доказывая частные случаи. Потому что таким образом всё равно невозможно что-то доказать. Давай будем конструктивнее?
Д>>Если тебя это так сильно интересует, попробуй сам изучить таки язык, который ты критикуешь.
E>А ты сам его изучил? А то фраза "Для меня же хватает того факта, что макросы Немерле достаточно мощны, чтобы эмулировать шаблоны С++ один-в-один . Значит, задача так или иначе решается" оставляет двойственные впечатления.
Знание общих принципов избавляет от необходимости помнить множество деталей (С) Конфуций, если не ошибаюсь.
Того, что я знаю, достаточно, чтобы делать предположения. Но — обоснованные предположения. Если ты считаешь, что в данном случае задача не решается — ты хотя бы объясни для начала, почему?
E>И еще, в данной ветке я не критиковал Nemerle. Ни разу. E>Я вполне лояльно отношусь к нему. Но хочу, чтобы рассказы о Nemerle были более адекватные, чем "Nemerle рулит!" или "В Nemerle все продумано и уши не торчат", или "поверьте мои словам".
Так почему бы не выяснить самому, и не рассказать другим?