Статья:
Nemerle

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

Авторы:
VladD2
Сергей Туленцев

Аннотация:
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка) и является неформальным введением в язык.

Может ли Nemerle работать в unsafe режиме?

>... Сергей Туленцев, Владислав Чистяков

C огромным удовольствием прочел статьтю.
Был бы очень рад, если в будущем Немерле из лабораторной разработки превратился бы в промышленный продукт...

Интересно, авторы статьи какое-то отношение к разработке Немерле имеют, кроме литерного?
Можно ли использовать Немерле в Visual Studio (intellisence, debugging)? На оф-м сайте видел упоминание о плагине, но насколько оно юзабильно?

С нетерпением жду продолжения на сайте.

siv>Интересно, авторы статьи какое-то отношение к разработке Немерле имеют, кроме литерного?
Sorry за опечатки. Имелось в виду литературного.

BTW, очень не хватает редактирования своего же постинга (разумеется, если никто еще не успел дать на него ответ)ю

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

A>Может ли Nemerle работать в unsafe режиме?

Нет. Но может использовать intrerop (PInvoke и COM-intrerop). С их помощью, к сожалению тоже можно легко привести программу к неработоспособнсоти.

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

siv>C огромным удовольствием прочел статьтю.

Спасибо за оценку. Собственно в читабельности заслуга не только авторов, но и многих посетителей этого сайта учавствовавших в вичитке. Среди них особо хочется отметить Vermicious Knid, Oyster и adontz.

siv>Был бы очень рад, если в будущем Немерле из лабораторной разработки превратился бы в промышленный продукт...
siv>Интересно, авторы статьи какое-то отношение к разработке Немерле имеют, кроме литерного?

Кое какое имеем. Не говоря уже о багрепортах (коих от RSDN-а чуть ли не болшинство) ведем работу над интеграцией Nemerle в VS 2005. К сожалению, в последнее время можно сказать "веду", в смысле в гордом одиночестве. От помощи не отказался бы.

Сейчас в основном занимаюсь подправкой компилятора чтобы он выдавал нужную информацию в нужном виде. Надеюс, что через месяц-другой кое что уже будет сносно работать. А там и рефакторинг с другими фичами прикрутим.
Вот форум проекта http://rsdn.ru/Forum/?group=prj.nemerle

siv>Можно ли использовать Немерле в Visual Studio (intellisence, debugging)? На оф-м сайте видел упоминание о плагине, но насколько оно юзабильно?

Сейчас можно использовать Упрощенную интеграцию

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

. Предоставляет возможность редактирования с подсветкой синтаксиса, компиляции, отладки (с грем пополам). Основана на хаке C#-проекта.

Через некоторое время (когда доделаем и когда дадут ключ для VSIP-пакета) будет полноценная интеграция где будет:
1. Улучшенная подсветка синтаксиса.
2. Автодополнение при вводе (cmplete word).
3. Хинты при редактировании и подведении мыши к идентификаторам.

Потом доделаем навигацию по коду и другие RAD-ости.

siv>С нетерпением жду продолжения на сайте.

Будет. Все будет. Почему-то мне кажется, что Nemerle — это проходная фишка.

Собственно если кто-то готов помочь, то не откладывайте это в долгий ящик.

А жаль. Какие еще языковые возможности c# 2.0 не поддерживает Nemerle?

A>>Может ли Nemerle работать в unsafe режиме?

VD>Нет. Но может использовать intrerop (PInvoke и COM-intrerop). С их помощью, к сожалению тоже можно легко привести программу к неработоспособнсоти.

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

A>А жаль.

По-моему это очень правильное решение. Лично я никогда по делу не использовал ансэйф в C#. А любой лишний кусок требует времени. Если кому-то понадобится анэйф, то МС++ и C# в полном распоряжении.

A>Какие еще языковые возможности c# 2.0 не поддерживает Nemerle?

Вроде бы никакие. Все отличия как раз и описаны в статье. Более того даже от еще не вышедшего C# 3.0 отличий почти нет. Нет только самого Linq-а и то к выходу C# 3.0 скорее всего уже будут написаны соовествующие макросы.

Хочу высказать свое субъективное мнение как программиста на C# по поводу статьи, языка и ...

По поводу статьи
1. Отличная статья, которая позволяет ощутить мощь нового языка.
2. В статье промелькнула фраза что C# 3.0 когда еще будет, а Nemerle можно попробовать уже сейчас. На самом деле они оба имеют одинаковый статус — бета,
которую можно попробовать.

Недостатки языка
1. Не полная реализация возможностей C# (Нет поддержки unsafe режима). По-этому мне кажется лучше его сравнивать с VB.NET (он тоже не поддерживает unsafe)
Т.е. Nemerle — это VB.NET с расширенными возможностями (они указаны в статье) и синтаксисом C# и Pascal (объявление переменных и результатов функций)
2. Многопроходный компилятор (Интересно скольки?). Но тут уже никуда не денешся. Это плата за расширенные возможности языка.

Плюсы
1. Язык максимально приближен по синтаксису к c#. По-этому бери и пиши. Причем можно писать по старинке (в стиле C#). И потихоньку переходить на
стиль Nemerle.
2. Остальные фичи описаны в статье.

По поводу проекта интеграции в VS.NET
1. Насколько я знаю такой-же проект как на rsdn.ru ведется на nemerle.org. Не логичней было бы их объеденить, а не распылять ресурсы разработчиков.
2. После обсуждений с VladD2 я пришел к выводу что на Nemerle лучше писать не интерфейсную часть, а интерфейс на традиционных языках (C# или VB).
По-этому рациональней сначала сделать всю функциональность редактора, codesnippets, code complete, refactoring и иже с ним.
А на следующем этапе — дизайнер форм и asp-страниц

Прошу не сильно бить за критику.

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

A>2. В статье промелькнула фраза что C# 3.0 когда еще будет, а Nemerle можно попробовать уже сейчас. На самом деле они оба имеют одинаковый статус — бета,
A>которую можно попробовать.

+1

A>Недостатки языка
A>1. Не полная реализация возможностей C# (Нет поддержки unsafe режима). По-этому мне кажется лучше его сравнивать с VB.NET (он тоже не поддерживает unsafe)

Весьма странная логика.

A>Т.е. Nemerle — это VB.NET с расширенными возможностями (они указаны в статье) и синтаксисом C# и Pascal (объявление переменных и результатов функций)

"VB.NET с синтаксисом C# и Pascal" это вообще перл.

На мой взгляд, разделение языков по принципу "поддерживает ансэйф" и "не поддерживает ансэйф" смысла не имеет. Языки же в первую очередь отличаются синтаксисом и семантикой и тут с VB ну совсем мало сходств.

A>2. Многопроходный компилятор (Интересно скольки?). Но тут уже никуда не денешся. Это плата за расширенные возможности языка.

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

На сегодня можно говорить только про многостадийные компиляторы. Вот только я не знаю ни одного современного языка программирования который бы был одностадийным.

Компилятор C# точно такой же многостадийный компилтор как и немерловый. В Немерле ровно на оду стадию больше. В нем есть стадия PrePars в которой токены помещаются в специальные группы. Нужен он для поддержки синтаксиса базирующегося на отступах и для возможности внедренеия в язык расширений (DSL-ей) на уровне токенов.

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

A>По поводу проекта интеграции в VS.NET
A>1. Насколько я знаю такой-же проект как на rsdn.ru ведется на nemerle.org. Не логичней было бы их объеденить, а не распылять ресурсы разработчиков.

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

A>2. После обсуждений с VladD2 я пришел к выводу что на Nemerle лучше писать не интерфейсную часть, а интерфейс на традиционных языках (C# или VB).

На самом деле это не так. Nemerle тут ничем не отличается от C# или VB. Но проблема в том, что для него просто пока нет нужной поддержки в IDE. Когда мы ее сделаем, то разницы не будет.

A>По-этому рациональней сначала сделать всю функциональность редактора, codesnippets, code complete, refactoring и иже с ним.

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

A>>Недостатки языка
A>>1. Не полная реализация возможностей C# (Нет поддержки unsafe режима). По-этому мне кажется лучше его сравнивать с VB.NET (он тоже не поддерживает unsafe)

VD>Весьма странная логика.

Неполная поддержка возможностей C# не дает возможности сказать.
"Забудьте про си-шарп. Переходите на Nemerle — и все будет в шоколаде. Тем более что синтаксис языков похож"
А можно сказать так.
"Пишите на Nemerle. А если чего не хватает (unsafe) — дописывайте на си-шарп"

A>>Т.е. Nemerle — это VB.NET с расширенными возможностями (они указаны в статье) и синтаксисом C# и Pascal (объявление переменных и результатов функций)

VD>"VB.NET с синтаксисом C# и Pascal" это вообще перл.

VD>На мой взгляд, разделение языков по принципу "поддерживает ансэйф" и "не поддерживает ансэйф" смысла не имеет. Языки же в первую очередь отличаются синтаксисом и семантикой и тут с VB ну совсем мало сходств.

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

A>>2. Многопроходный компилятор (Интересно скольки?). Но тут уже никуда не денешся. Это плата за расширенные возможности языка.

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

Да

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

A>Неполная поддержка возможностей C# не дает возможности сказать.
A>"Забудьте про си-шарп. Переходите на Nemerle — и все будет в шоколаде. Тем более что синтаксис языков похож"

Да, позволяет, позволяет. На оборот это даже приемущество, так как шаловливые ручки не будут постоянно тянуться к оверкильным-методам.

A>А можно сказать так.
A>"Пишите на Nemerle. А если чего не хватает (unsafe) — дописывайте на си-шарп"

Откровенно говоря если нужен ансэйф, то лучше просто написать мелкий модуль на C/C++. Но можно конечно и на Шарпе. Вот олько еще раз повторюсь, что лично мне за 5 лет не понадобилось написать ни одной строчки ансэйфа по делу. Только в пенисометрии какой-нибудь.

A>На самом деле с бейсиком очень много общего. Параметры по-умолчанию, ... В общем Вы в своей статье очень хорошо описали все заимствования из VB.

Параметры по умолчанию вообще-то взяты из Питона. В статье я упоминал VB так как он более знаком аудитории. Да и мест где можно скзать о взаимствовании из VB раз два и обчелся. Их несравнимо меньше чем взаимсвований из C# или ML. Так что твое утверждение вряд ли можно назвать верным. Просто на твое суждение воздействует среда в которой ты варился и довольно странное предположение, что ансэйф является весьма значимой частью языка.

На самом деле ансэйф не является критичным ни для скорости получаемого кода, ни для функционала получаемых приложений. Это средство для хаков. И лично я считаю, что чем меньше хаков и чем менее они опасны, тем лучше.

Я так настаиваю на unsafe потому что он мне был реално нужен, и сейчас кстати, тоже, не для пенисометрии, а для реальной работы (Взаимодействие с некоторыми функциями WinAPI).

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

A>>Неполная поддержка возможностей C# не дает возможности сказать.
A>>"Забудьте про си-шарп. Переходите на Nemerle — и все будет в шоколаде. Тем более что синтаксис языков похож"

VD>Да, позволяет, позволяет. На оборот это даже приемущество, так как шаловливые ручки не будут постоянно тянуться к оверкильным-методам.

A>>А можно сказать так.
A>>"Пишите на Nemerle. А если чего не хватает (unsafe) — дописывайте на си-шарп"

VD>Откровенно говоря если нужен ансэйф, то лучше просто написать мелкий модуль на C/C++. Но можно конечно и на Шарпе. Вот олько еще раз повторюсь, что лично мне за 5 лет не понадобилось написать ни одной строчки ансэйфа по делу. Только в пенисометрии какой-нибудь.

A>>На самом деле с бейсиком очень много общего. Параметры по-умолчанию, ... В общем Вы в своей статье очень хорошо описали все заимствования из VB.

VD>Параметры по умолчанию вообще-то взяты из Питона. В статье я упоминал VB так как он более знаком аудитории. Да и мест где можно скзать о взаимствовании из VB раз два и обчелся. Их несравнимо меньше чем взаимсвований из C# или ML. Так что твое утверждение вряд ли можно назвать верным. Просто на твое суждение воздействует среда в которой ты варился и довольно странное предположение, что ансэйф является весьма значимой частью языка.

Именно так. А на тебя разве среда в которой ты варился на воздействует?

VD>На самом деле ансэйф не является критичным ни для скорости получаемого кода, ни для функционала получаемых приложений. Это средство для хаков. И лично я считаю, что чем меньше хаков и чем менее они опасны, тем лучше.

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

A>Я так настаиваю на unsafe потому что он мне был реално нужен, и сейчас кстати, тоже, не для пенисометрии, а для реальной работы (Взаимодействие с некоторыми функциями WinAPI).

Маршалинга с P/Invoke не хватает? Приведи пример.

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

A>Я так настаиваю на unsafe потому что он мне был реално нужен, и сейчас кстати, тоже, не для пенисометрии, а для реальной работы (Взаимодействие с некоторыми функциями WinAPI).

Сдается мне, что WinAPI можно использовать без unsafe.

A>Именно так. А на тебя разве среда в которой ты варился на воздействует?

Я стараюсь вариться в разных средах.

Код вышлю позже...

В версии 6470 добавлена ковариантность/контрвариантность для делегатов и интерфейсов.

Описывается это дело с помощью "+" и "-" перед параметрами типов:

public interface IFun [-I, +O]
{
  Apply (x : I) : O;
}

Данная запись означает, что вместо I могут быть подставлены типы являющиеся базовыми типами для I, а вместо O типы являющиеся наследниками от O.
Таким образом если некий функция требует в качестве параметра интерфейс с конкретными параметрами типа, то ему все можно передать реализацию интерфейса с другими параметрами итпа которые удовлетворяют указанным критериям.

Возможность основана на поддержке рантайма. К сожалению, Моно пока данную возможность не поддерживает.

Пример исползования:
http://nemerle.org/svn/nemerle/trunk/ncc/testsuite/positive/co-contra-variance-native.n
Негативный тест:
http://nemerle.org/svn/nemerle/trunk/ncc/testsuite/negative/co-contravariant-native.n

Привожу пример, как и обещал. Если поможешь избавиться от unsafe — персональная моя большая благодарность

    private static WaveFormat GetFormat(IntPtr format)
    {
      unsafe
      {
        WinApi.WaveFormatEx* wfx = (WinApi.WaveFormatEx*)format.ToPointer();
        WaveFormat waveFormat = new WaveFormat();
        waveFormat.wFormatTag = wfx->wFormatTag;
        waveFormat.nChannels = wfx->nChannels;
        waveFormat.nSamplesPerSec = wfx->nSamplesPerSec;
        waveFormat.nAvgBytesPerSec = wfx->nAvgBytesPerSec;
        waveFormat.nBlockAlign = wfx->nBlockAlign;
        waveFormat.wBitsPerSample = wfx->wBitsPerSample;
        return waveFormat;
      }
    }

        public byte[] FormatBytes()
        {
            unsafe
            {
                int dataSize;
                WinApi.WaveFormatEx* wfx = (WinApi.WaveFormatEx*)_Format.ToPointer();
                if (WinApi.WAVE_FORMAT_PCM == wfx->wFormatTag)
                    dataSize = Marshal.SizeOf(typeof(WaveFormat));//WinApi.//PCMWAVEFORMAT
                else
                    dataSize = Marshal.SizeOf(typeof(WinApi.WaveFormatEx)) - 2 + wfx->cbSize;
                //base.Write(dataSize, base.Position, Marshal.SizeOf(dataSize));

                IntPtr wfxPtr = new IntPtr(wfx);//Ptr
                byte[] wfxArr = new byte[dataSize];
                Marshal.Copy(wfxPtr, wfxArr, 0, dataSize);
                return wfxArr;
            }
        }

O>Маршалинга с P/Invoke не хватает? Приведи пример.

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

A>>Т.е. Nemerle — это VB.NET с расширенными возможностями (они указаны в статье) и синтаксисом C# и Pascal (объявление переменных и результатов функций)

VD>"VB.NET с синтаксисом C# и Pascal" это вообще перл.

Э-э, причем здесь Perl?

Здравствуйте, <Аноним>, Вы писали:

А>Привожу пример, как и обещал. Если поможешь избавиться от unsafe — персональная моя большая благодарность

Marshal.PtrToStructure + [StructLayout(LayoutKind.Explicit)]
и [FieldOffset] в структуре.

Плюс во втором случае я вижу два варианта:

1. Использовать бОльшую по размеру из структур (но это может не всегда работать).
   
2. Зная, где именно находится wfx->wFormatTag, вытягивать его с помощью Marshal.ReadInt32() (и подобных методов). Если поле не в начале структуры, то можно указать offset.