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

I>Проверка размерностей в Фортране?

Нет. Но это не мешает большинство прог для численных задач писать именно на нем.

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

E>К тому же обсуждавшийся фрагмент кода на C++ со скалярными параметрами шаблонов ни относился ни к низкому уровню, ни к RealTime.

Я не вижу принципиальных проблем в том, чтобы реализовать эту функциональность на макросах Nemerle (ради пресловутого compile-time) — это сделать будет непросто, но и решение на шаблонах непростое. Естественно, это будут не скалярные параметры generic-ов (так делать просто нельзя), а нечто иное.

Я сам думал (ещё до того, как начались все эти обсуждения про физические величины) заимплементать этот код на Nemerle (понравился мне вариант на C++, чего уж там) чисто ради спортивного интереса, но времени нету...

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

O>Я не вижу принципиальных проблем в том, чтобы реализовать эту функциональность на макросах Nemerle (ради пресловутого compile-time) — это сделать будет непросто, но и решение на шаблонах непростое. Естественно, это будут не скалярные параметры generic-ов (так делать просто нельзя), а нечто иное.

Об этом и Vermicious Knid

Автор: Vermicious Knid
Дата: 27.03.06

говорил.
В общем-то я с вами согласен, смущает меня только то, что в C++ в одном выражении можно будет сочетать operator*() (и другие) для разных типов данных. Например, Physic<A,B,C> еще и на скаляр умножить можно будет -- в самом выражении с использованием операторов это никак не будет явно подчеркиваться. В Nemerle для таких ситуаций, вероятно, еще что-то додумывать придется.

Но поинт здесь был в другом. Хоть на C++ решение и не тривиальное на первый взгляд, но самое сложное в нем -- это додуматься до него. Сама же реализация отнюдь не сложная. Бывают гораздо более сложные навороты (например, проверка чисел на простоту в compile-time). И, возвращаясь к первоначальному замечанию VladD2 о скалярных параметрах шаблонах, вполне себе востребованный и жизнеспособный код.

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

E>Одинакого хорошо -- это, очень вероятно, на одинаково сером уровне.

парадигмы — это не задачи. Это разные подходы к решению одной конкретной задачи.

E>Ты конечно, можешь мне возразить, что там речи не было ни о низком уровне, ни о RTS. Но смысла это не изменит. К тому же обсуждавшийся фрагмент кода на C++ со скалярными параметрами шаблонов ни относился ни к низкому уровню, ни к RealTime.

единственная проблема с этим кодом — это требования к быстродействию. Если его отбросить, то задача решается на Немерле без малейших проблем. Но там и вообще с быстродействием пока не очень хорошо. Версия 0.9, всё-таки, да еще pure managed code. Ты это хотел услышать?

E>Так вот, мало кто скажет. Потому, что когда нужно решать реальные задачи, все разговоры о красиво/не красиво, отрывать/пришивать что-нибудь и пр. остаются в курилке. Поскольку нужно либо написать работающую программу и получить за это деньги, либо провалить проект. И выясняется, что на C++ коряво написать можно, и работать будет. А вот альтернативу найти -- еще попробуй.

Программа, которая вся целиком состоит из задачи контроля размерностей?

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

Д>единственная проблема с этим кодом — это требования к быстродействию. Если его отбросить, то задача решается на Немерле без малейших проблем. Но там и вообще с быстродействием пока не очень хорошо. Версия 0.9, всё-таки, да еще pure managed code. Ты это хотел услышать?

Нет. Давай отбросим требования к скорости. Реши ее на Nemerle.

Здравствуйте, 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) и чтобы другие языки не обоснованно не критиковались (особенно, если нет понимания необходимости конкретной фичи языка).

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

O>Насколько я понимаю, оператор * можно сделать макросом и тогда получится оставить "прозрачный" синтаксис.

Так вот не придется ли тебе в макросе проверять типы выражений и в зависимости от типа левого/правого операнда производить генерацию разного кода?

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

E>В общем-то я с вами согласен, смущает меня только то, что в C++ в одном выражении можно будет сочетать operator*() (и другие) для разных типов данных. Например, Physic<A,B,C> еще и на скаляр умножить можно будет -- в самом выражении с использованием операторов это никак не будет явно подчеркиваться. В Nemerle для таких ситуаций, вероятно, еще что-то додумывать придется.

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

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

E>Так вот не придется ли тебе в макросе проверять типы выражений и в зависимости от типа левого/правого операнда производить генерацию разного кода?

Я тут перемудрил: Re[24]: Дополнение

Автор: Oyster
Дата: 27.03.06

.

И даже если и прийдётся — код для генерации кода будет написан один раз

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

А так?
O>

O>using System.Console;
O>using Oyster;

O>// Выведет 720, посчитает в compile-time
O>WriteLine(Macro.Fact(0));

O>// Выведет 720, но посчитает в рантайме
O>def x = 6;
O>WriteLine(Macro.Fact(x))
O>

?

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

E>А так?

...

E>)

Не придирайся Забыл написать, что писал на скорую руку Главное ж принцип...

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

И согласись с главным — выглядит естественней, чем

fact<6>::value

или что-то такое. А что самое главное — можно использовать макрос как с константами, так и с переменными — внутри само разберётся.

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

E>>)

O>Не придирайся Забыл написать, что писал на скорую руку Главное ж принцип...

Я не придираюсь, просто показываю, что самые жестокие ошибки чаще всего делаются не столько из-за особенностей языка, сколько из-за человеческого фактора.

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

E>Я не придираюсь, просто показываю, что самые жестокие ошибки чаще всего делаются не столько из-за особенностей языка, сколько из-за человеческого фактора.

В таком случае сообщу, что я написал намеренно упрощённый код. Эту ошибку я сделал сознательно для упрощения примера. Вот как

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

O>

O>fact<6>::value
O>

Это дело привычки, на самом-то деле. Люди вон к Lisp-овой нотации привыкают

O>или что-то такое. А что самое главное — можно использовать макрос как с константами, так и с переменными — внутри само разберётся.

+1
А вот это да. Полностью согласен.

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

O>В таком случае сообщу, что я написал намеренно упрощённый код. Эту ошибку я сделал сознательно для упрощения примера. Вот как


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

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

E>Вот так всегда. На C++ работающий код есть и не в одном экземпляре. Хотя кто-то еще думает, что скаляры в шаблонах не нужны. Поэтому C++ код можно материть и кричать C++ must die (утрируя). Привести пример реально существующей альтернативы имеющий такие же возможности (в данном случае по быстродействию) -- умозрительные задачи.

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

Д>>Если тебя это так сильно интересует, попробуй сам изучить таки язык, который ты критикуешь.

E>А ты сам его изучил? А то фраза "Для меня же хватает того факта, что макросы Немерле достаточно мощны, чтобы эмулировать шаблоны С++ один-в-один . Значит, задача так или иначе решается" оставляет двойственные впечатления.

Знание общих принципов избавляет от необходимости помнить множество деталей (С) Конфуций, если не ошибаюсь.
Того, что я знаю, достаточно, чтобы делать предположения. Но — обоснованные предположения. Если ты считаешь, что в данном случае задача не решается — ты хотя бы объясни для начала, почему?

E>И еще, в данной ветке я не критиковал Nemerle. Ни разу.
E>Я вполне лояльно отношусь к нему. Но хочу, чтобы рассказы о Nemerle были более адекватные, чем "Nemerle рулит!" или "В Nemerle все продумано и уши не торчат", или "поверьте мои словам".

Так почему бы не выяснить самому, и не рассказать другим?