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

C>Немерль — это расширение C#, так же как С++ — это расширение С.
C>Вот мне и интересно узнать как реализован interop.
О как! Немерле это не расширение C#. Откуда ты это вобще взял? Немерле это еще один язык для .NET. И интероп между немерле, C#, F#, VB.NET и тп идет через .NET.

WolfHound wrote:
> C>Немерль — это расширение C#, так же как С++ — это расширение С.
> C>Вот мне и интересно узнать как реализован interop.
> О как! Немерле это не расширение C#. Откуда ты это вобще взял? Немерле
> это еще один язык для .NET. И интероп между немерле, C#, F#, VB.NET и тп
> идет через .NET.
Прекрасно, заменим на политкорректное: "А как Немерь интероперирует с
остальными языками .NET?"

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

C>Прекрасно, заменим на политкорректное:
Это не политкорректность, а элементарное знание предметной обласити.

C>"А как Немерь интероперирует с остальными языками .NET?"
Точно также как C++/CLI и C#. В чем проблема то? Проблем с интеропом между языками .NET нет вобще.
Ессно вещи которые не поддержывает .NET на прямую интеропнуть нельзя. Те например нельзя шаблон из C++/CLI использовать в C#. Но результат работы этого шаблоны вполне.
Точно также как нельзя использовать шаблоны из С++ в С. Но если спрятать шаблоны за С интерфейсом то результатом этого шаблона можно воспользоваться.
С немерле и его макросами таже петрушка. Сами макросы можно использовать только в программах на намерле. А вот сборку которая получилась можно использовать из любого языка .NET.

WolfHound wrote:
> C>Прекрасно, заменим на политкорректное:
> Это не политкорректность, а элементарное знание предметной обласити.
Вы еще скажите, что остальные языки .NET кардинально отличаются от C#...

> C>"А как Немерь интероперирует с остальными языками .NET?"
> Точно также как C++/CLI и C#. В чем проблема то? Проблем с интеропом
> между языками .NET нет вобще.
Угу. Передайте граф объектов из IronPython в Ruby.NET, к некоторым
объектам в графе добавьте по несколько новых методов, затем распечатайте
этот граф из Nemerle.

И как там с интероперабельностью?

> Точно также как нельзя использовать шаблоны из С++ в С. Но если спрятать
> шаблоны за С интерфейсом то результатом этого шаблона можно воспользоваться.
> С немерле и его макросами таже петрушка. Сами макросы можно использовать
> только в программах на намерле. А вот сборку которая получилась можно
> использовать из любого языка .NET.
В результате работы получаются сборка. Информация о размерностях величин
хранится в каких-то атрибутах — было бы неплохо уметь с ними работать
через какой-то внешний интерфейс. Чего-то типа Foreign Nemerle Interface.

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

C>Вы еще скажите, что остальные языки .NET кардинально отличаются от C#...

Следует переформулировать: у всех .NET-языков есть т.н. CLS (Common Language Subset) — некая общая часть, которую они все должны поддерживать. Так что можно вообще сказать, что все языки .NET не отличаются друг от друга.

C>Угу. Передайте граф объектов из IronPython в Ruby.NET, к некоторым
C>объектам в графе добавьте по несколько новых методов, затем распечатайте
C>этот граф из Nemerle.

C>И как там с интероперабельностью?

А теперь сделайте то же самое с C++ и Си: передайте граф объектов из C++ в Си, к некоторым объектам добавьте по несколько новых методов, затем распечатайте этот граф из Objective-C.

Естественно, что language-specific фичи вроде макросов или рантайм-геренации методов как в Ruby так и остаются language-specific — выходят за рамки CLS. С этим никто и не спорит.

C>В результате работы получаются сборка. Информация о размерностях величин
C>хранится в каких-то атрибутах — было бы неплохо уметь с ними работать
C>через какой-то внешний интерфейс. Чего-то типа Foreign Nemerle Interface.

Зачем? Макросы Nemerle — это макросы Nemerle и никого другого. Кроме того, если к классу применяются макросы-атрибуты, то Nemerle на классе оставит специальный атрибут MacroAttribute, из которого можно будет извлечь некоторую инфу о макросе (имя, часть параметров, возможно) впоследствии (с помощью reflection, например).

Кроме того, никто нам не мешает в таком макросе самим делать всё, что угодно, чтобы предоставить какую-то дополнительную информацию коду на том же C#.

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

C>Угу. Передайте граф объектов из IronPython в Ruby.NET, к некоторым объектам в графе добавьте по несколько новых методов, затем распечатайте этот граф из Nemerle.
Только после того как ты воспользуешься макросами Nemerle в C#, шаболоном из C++/CLI в VB.NET и шаблоном С++ в С.

C>В результате работы получаются сборка. Информация о размерностях величин хранится в каких-то атрибутах — было бы неплохо уметь с ними работать через какой-то внешний интерфейс. Чего-то типа Foreign Nemerle Interface.
В результате работы получается сборка с таким классом

public class СуперСчитатель
{
    public Результат Посчитать(Параметры параметры)
    {
        ...
    }
}

Этот класс можно использовать из любого языка .NET
И никаких атрибутов и никакой Foreign Nemerle Interface не нужен.

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

VD>Проблема тут в другом. Метапрограммирование на макросах сильно ограничено по возможнсотям, очень неудобно в отладке, страшно в восприятии. Одинм словом, криво.

Конкретно в этом месте речь шла не о метапрограммировании на шаблонах, а о compile-time вычислениях на шаблонах. Имхо, это все же разные вещи. А применительно к compile-time вычислениям я не вижу принципиальной разницы между записями:

fact<6>::value

и

Macro.Fact(6)

смысл одного и другого для человека, разбирающегося в C++ и Nemerle понятен.

Что же касается моего мнения по поводу сложных compile-time вычислений в C++, то ты его можешь прочитать здесь

Автор: eao197
Дата: 25.10.05

(там же, кстати, используется ссылка на статью, в которой используется compile-time вычисление вещественных чисел на шаблонах).

Disclaimer: насколько я помню, об удобстве вычисления факториала заговорил Oyster

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

VD>Почему вычисление во время компиляции должно отличаться от того же самого в рантайме?

Ну, например, потому, что в коде инициировать compile-time вычисления ты все равно будешь явно. Ты же пишешь CompileTimeFactorial. Если же вспомнить пример Oyster-а, где не видно по записи, какое именно вычисление будет использоваться, то его реализация так же разбита на две разные части.

Если же ты о том, что для реализации compile-time вычислений приходиться писать свой код вместо библиотечного, то у меня на этот счет совсем другое мнение -- я думаю, что кодогенерация здесь может быть выгоднее. Зачем при каждой компиляции повторно перевычислять то, что можно вычислить один раз, сохранить в файле и все.

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

VD>Например, посчитай во время компиляции сколько будет 1.234 + 123.23232.
VD>Например, сделай просешую вещь. Сгенерируй код функции который при ее вызове выведет время и дату компиляции.

#include <iostream>

const char *
compilation_time()
    {
        return __DATE__ " " __TIME__;
    }

int
main()
    {
        const float f = 1.234 + 123.23232;

        std::cout << compilation_time() << std::endl;
        std::cout << "compilation computation: " << f << std::endl;
    }

Анекдот в тему:

Экзаменатор и студент.
Э: Вы будете отвечать на один сложный вопрос или на три простых?
С: На один сложный.
Э: Хорошо. Сколько байт в мегабайте?
С: Много!
Э: Сколько "много"?
С: Это уже второй вопрос!

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

C>Немерль — это расширение C#, так же как С++ — это расширение С.
C>Вот мне и интересно узнать как реализован interop.

Немерле — это гибрид C#-а, ML-я, и макросов Схемы. Расширением C# он не является.

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

C>Прекрасно, заменим на политкорректное: "А как Немерь интероперирует с
C>остальными языками .NET?"

Отлично. Немерле являеся CLI-провайдером и потребителем. Так что на нем ожно писать библиотеки для других языков и из него можно использовать чужие библиотеки.

Кстати, макросы можно писать даже на C#. Ведь макрос — это просто класс реализующий некоторый интерфейс. Проблема только в том, что без псевдоцитирования и сопоставления с образцом это будет делать крайне неудобно.

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

C>WolfHound wrote:
>> C>Прекрасно, заменим на политкорректное:
>> Это не политкорректность, а элементарное знание предметной обласити.
C>Вы еще скажите, что остальные языки .NET кардинально отличаются от C#...

Еще как скажу. Сравни, например, F# (Caml), Лисп или Питон. Неужели они копии C#-а?

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

O>Следует переформулировать: у всех .NET-языков есть т.н. CLS (Common Language Subset) — некая общая часть, которую они все должны поддерживать. Так что можно вообще сказать, что все языки .NET не отличаются друг от друга.

Все несколько сложнее. Есть понятие CLS consumer (потребитель) и CLS producer. Языки которые могут только потреблять типы из других языков должны реализовывать требования CLS-потребителя. А языки которые хотят сами экспотрировать типы для других языков должны реализовывать требования CLS-провайдера.

Потеницально язык может жить на дотнете и не реализовывать целиком обе спецификации. Но по жизни большинство языков реализуют требования CLS-потребителя. Немерле реализует требования обоих спецификаций CLS consumer и CLS producer.

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

E>Ну, например, потому, что в коде инициировать compile-time вычисления ты все равно будешь явно. Ты же пишешь CompileTimeFactorial. Если же вспомнить пример Oyster-а, где не видно по записи, какое именно вычисление будет использоваться, то его реализация так же разбита на две разные части.

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

Кстати, можно написать макрос, который будет пытаться вычислить результат любой функции на этапе компиляции или, если не получится, вставлять её вызов Естественно, такой макрос можно будет использовать только для детерминированных функций (разумное требование для любых compile-time вычислений).

E>Если же ты о том, что для реализации compile-time вычислений приходиться писать свой код вместо библиотечного, то у меня на этот счет совсем другое мнение -- я думаю, что кодогенерация здесь может быть выгоднее. Зачем при каждой компиляции повторно перевычислять то, что можно вычислить один раз, сохранить в файле и все.

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

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

E>Disclaimer: насколько я помню, об удобстве вычисления факториала заговорил Oyster

Факториал — это шелуха, как ты сам понимаешь. То, почему на Nemerle может быть удобнее делать compile-time вычисления, уже звучало неоднократно...

Видимо, надо было привести пример compile-time оптимизации, которую на C++ просто невозможно осуществить. Такой, например, как Влад приводил: Re[25]: Вопрос к Vlad2: Nemerle & R#

Автор: VladD2
Дата: 28.03.06

. Тогда бы, наверное, было понятнее...

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

VK>Не только скомпилируется, но еще и константу выдаст в качестве результата, т.к. в Nemerle есть constant folding.

Кстати, вопрос к гуру — а можно ли в макросе определить новый макрос?

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

O> Полностью согласен с тобой — давай экономить время на этапе компиляции! Миллисекунды на дороге не валяются!! Про удобство использования такой схемы скромно умолчу...

Про отладку compile-time вычислений, которую можно делать только отладочными печатями, доступными только при запуске компилятора, я тоже не буду распространяться...

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

E>Про отладку compile-time вычислений, которую можно делать только отладочными печатями, доступными только при запуске компилятора, я тоже не буду распространяться...

E>)

В таком случае использовать compile-time computations на шаблонах C++ с целыми как параметрами тоже нехорошо (по тем же причинам)? В общем, мы пришли к тому, что всё есть зло, только CodeSmith рулит

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

O>В таком случае использовать compile-time computations на шаблонах C++ с целыми как параметрами тоже нехорошо (по тем же причинам)?

Да, применительно C++ я считаю что в большинстве случаев так оно и есть (бо к C++ кодогенерация прикручивается без проблем). За исключением самых простых случаев и когда для выжимания скорости прибегают к технике expression templates.

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

E>Да, применительно C++ я считаю что в большинстве случаев так оно и есть (бо к C++ кодогенерация прикручивается без проблем). За исключением самых простых случаев и когда для выжимания скорости прибегают к технике expression templates.

Возможно, ты и прав. Тчк.