> Т.е. для примера не было бы в C# «if» «else», чтобы можно было бы сделать?

Для примера, в C# есть и if, и else. А чего там такого нет, для чего непременно нужны новые конструкции в языке?

> Для примера, в C# есть и if, и else. А чего там такого нет, для чего непременно нужны новые конструкции в языке?

Паттерн-матчинг входных параметров методов. Т.е. чтобы можно было накладывать условие на параметр метода не только по типу, но и по значению на уровне опр. метода, а не в его теле.

> Паттерн-матчинг входных параметров методов. Т.е. чтобы можно было накладывать условие на параметр метода не только по типу, но и по значению на уровне опр. метода, а не в его теле.

Вылезай из криокамеры. Давно уже есть http://msdn.microsoft.com/en-us/devlabs/dd491992

И никаких там конструкций в языке для этого не нужно, как оказалось.

Еще примеры будут? Надеюсь, не захочешь в язык регэкспы тащить, как в говножабаскрипте?

Вылезай из криокамеры. Давно уже есть http://msdn.microsoft.com/en-us/devlabs/dd491992

С каких это пор контракты стали сопоставлением с образцом?

Вобрать в себя лучшее и довести до отлаженного инструмента
в этом плане практически пионер

PL/1? :)

Разумно, да. Я присматривался к Nemerle года три назад, потом он впал в кому.

> Была бы моя воля, я бы под страхом смертной казни запрещал бы использовать что либо кроме Java1.2, вне какой либо простейшей IDE (можно древний NetBeans). Причем, за написание самодельных build-скриптов - расстрел на месте. Вот тогда было бы все чисто и красиво.

Тонко.

> С каких это пор контракты стали сопоставлением с образцом?

А с каких это пор сопоставление с образцом нужно, чтобы «можно было накладывать условие на параметр метода не только по типу, но и по значению»?

И никаких там конструкций в языке для этого не нужно, как оказалось.

ок, жду удобоваримого аналога след кода на F#:

let myfun ((a,_)::(_,c)::(_,b)::tail) =
  a+b-c

в интерпритаторе:

> let lst = [ 1,2 ; 2,3; 3,4; 5,6];;

val lst : (int * int) list = [(1, 2); (2, 3); (3, 4); (5, 6)]

> myfun lst;;
val it : int = 2

А с каких это пор сопоставление с образцом нужно, чтобы «можно было накладывать условие на параметр метода не только по типу, но и по значению»?

В исходном вопросе было «Паттерн-матчинг входных параметров методов». Так что там с реализацией сопоставления с образцом без макросов?

А с каких это пор сопоставление с образцом нужно, чтобы «можно было накладывать условие на параметр метода не только по типу, но и по значению»?

Это один из способов, причём удобный. Добавление к моему пред. примеру:

let myfun ((a,_)::(2,c)::(10,b)::tail) =
  a+b-c

> myfun lst;;
Microsoft.FSharp.Core.MatchFailureException: The match cases were incomplete
   at FSI_0018.myfun(FSharpList`1 _arg5)
   at <StartupCode$FSI_0019>.$FSI_0019.main@()
Stopped due to error

А, вот вы все о чем. Гадость какая! Фу, бросьте эту каку быстрее!

Так что там с реализацией сопоставления с образцом без макросов?

Так что там с макросами в FSharp?

> Так что там с макросами в FSharp?

Ты передёргиваешь, ибо речь шла о том, что нельзя сделать на C# без использования макросов(в F# паттерн матчинг зашит в компилятор, но если бы там были макросы, то паттерн матчинг можно было бы запилить ими). Это раз.

Два, макросов в F# нету(это минус, т.к. иногда с ними было бы проще), но есть цитирование кода (возвращение AST кода и возможность обработки этого AST + вычисления этого AST(в библиотеке PowerPack)).

>> 3)макросы, в самом языке нету «if», «else», эти синтаксические конструкции введены с помощью макросов.

Сделайте меня развидеть это

Самый правильный комментарий.

И да, в русском языке нет слова «нету».

А, вот вы все о чем. Гадость какая! Фу, бросьте эту каку быстрее!

Аргументировано.

>Не глядя выберу 100тыс строк, но без DSL.
Понимаешь, наплодив в проекте 100 функций и 500 классов в 100500 строк кода, ты по факту УЖЕ юзаешь невыразимо кастрированный DSL, хоть и всеми силами не хочешь признать это.

Короче, а теперь распишем неиллюзорные минусы Nemerle:
- Документации по этим самым макросам по факту НЕТ. Простейшие вещи как делать - из набора статей (КЫВТ) и материалов оф. сайта более-менее понятно, но , скажем, программно сгенерировать некий достаточно нетривиальный тип данных, например - заеб-тесь! Придется, ввиду отсутчвия док, идти по проторенной дорожке - лезть в кишки исходников компилятора и разбираться досконально , как оно там работает.
- Все еще куча ICE
- Самая вменяемая интеграция - только под Студию, и то - с глюками. Под другие IDE - максимум, раскраска кода и м.б. какое-то автодополнение.

К плюсу можно отнести
- ОЧЕНЬ НИЗКАЯ КРИВАЯ вхождения в ЯП для C# разрабов - все, кроме макросов, изучается и запоминается за 4-5 часов. Как дело отстоит с другими прогерами - мне неизвестно :)


Использовать как C# с плюшками можно уже и прямо сейчас.

> ты по факту УЖЕ юзаешь невыразимо кастрированный DSL, хоть и всеми силами не хочешь признать это.

Ну юзаю - и что? До тех пор, пока все в рамках одного языка, пусть хоть горшком называется.

Немерле в этом плане практически пионер (наряду с «D») - предлагает передовые методологии в едином языке.

Наркоман, штоле?

Последний ICE словил в сентябре, пишу на Nemerle в среднем около 3 часов в неделю, у вас не устаревшая информация? btw где то с тех пор и интеграция меньше падает.

Первое утверждение верно наполовину) лесть в сорсы компилятора и стандартных макробиблиотек можно, но не для того, чтобы понять как это работает, а за примерами, так как они доступная база исходных кодов макросов, по которым их можно изучать.

> Меньше всего мейнстриму нужны языки с возможностью вводить новые конструкции.

В теории я тоже как бы согласен :) Но взгляните на это с практической стороны: вы видели хоть одного прогера, который пришёл в проект и сразу начал ваять продакшн код? Я - нет. Всё равно приходится разбираться с общей архитектурой, выяснять какие функции и где нужны... но ведь эти функции - тот же самый DSL! (только не в общеизвестной макробиблиотеке, а в либе узкого коллектива) Т.е. через месяц «въезжания» ты вполне можешь осилить хоть функции, хоть DSL (который намного более успешно решает задачи _этого_ проекта).
Тем более, что макры - вещь серьёзная и долго обдумывается, прежде чем ввести в общее пользование. Так что код типа IncThisByTwo(x) вы не увидите. :)

> > Вобрать в себя лучшее и довести до отлаженного инструмента > в этом плане практически пионер

PL/1? :)

Пиэль вбирал в себя ртом и жопой, отчего подавился :) Немерле же вводит в стандартную библиотеку только то, что заведомо будет широко использоваться. Да и _возможность_ писать макросы не влекёт _обязательное_написание_ этих макросов - пишите на стандартных! (тем более, что их уже навалом)

> Наркоман, штоле?

Нет, ЛОРовский эксперт. :) «А ты какого цвета, товарищ с фоном лета?»

> Чем оно лучше scala? Или Clojure?

<петросянмоде> лучше чем скала. и лучше чем clojure )) </петросянмоде>

Nemerle vs F#

http://versusit.ru/viewtopic.php?pid=67441#p67441

> Чем оно лучше scala?

В скале нет метапрограммирования ака макросов. AFAIK это единственное преимущество Nemerle, но очень толстое. А то, что нету JVM, это печаль, да. Но в планах у них имеется.

немерле не нужен!

Но ведь макросы есть в clojure.

В скале метапрограммирование на подобающем ему месте: в плагинах компилятора.

Написать даже самый простенький плагин компилятора скалы - на порядки сложнее, чем простенький макрос немерла. Надо знать, как компилятор устроен, знать его фазы, внутренние структуры и точки расширения; и внедряться, писать преобразователь кода, всё практически вручную. А простой макрос на Nemerle не намного сложнее простого макроса на C++, только надёжней на порядок. Так что не надо мне про плагины компилятора. В концептуальном смысле это альтернатива, да, но альтернатива очень хреновая.

> http://versusit.ru/viewtopic.php?pid=67441#p67441

пардон, это к чему вообще?

Вот именно, что это сложно. А значит, будет использоваться когда действительно необходимо, а не когда в левой пятке зачешется. А для удовлетворения зуда в левой пятке достаточно изменчивости скальего синтаксиса. См. parser combinators из стандартной библиотеки или тот же databinder dispatch.

> Чем оно лучше scala?

Главная отличительная особенность - макросы. Причем как возможность их писать самому, так и не хилая библиотека макросов идущая в поставке. Например, в поставке идет макрос PegGrammar (http://rsdn.ru/article/?1071) генерирующий офигительно быстрые парсеры на основе PEG-грамматики. Другой пример, ComputationExpressions которые к F# прибиты гвоздями (встроены в компилятор) в Nemerle реализованы в виде библиотеки макросов.

Кроме того сам язык ближе к C#, что дает возможность стартовать разработку буквально в течении дня-двух, а уже по ходу пьесы изучать продвинутые особенности языка.

Или Clojure?

1. Nemerle высокопроизводительный (не медленее C#), компилируемый язык с выводом типов. Это значит что писать на нем можно как Лиспе без типизации (не указывая типы), но при этом получат код который будет быстрее чем на самом крутом компиляторе Лиспа с явным указанием типов (что еще и не станадратно). 2. У Nemerle есть синтаксис (в Лиспаах, в том числе в Ложур, нужно писать код в S-выражениях, т.е. в виде AST). И этот синтаксис очень близок к C/C++/C#. 3. Макросы Nemerle в отличии от макросов лиспов могут работать с типизированным AST, это дает возможность делать разные хитрые решения и оптимизации не доступные в лиспах. Например, упомянутый выше PegGrammar сравнивает правила грамматики с описанием методов-обработчиков и выдает внятные сообщения о несовпадении сигнатуры (с рекомендациями по устранению проблем). 4. В Nemerle поддерживаются Алгебраические Типы Данных и сопоставление с образцом (паттерн-матчинг), что для многих применений является супер-фичей.

И все это, подчеркиваю, в языке с С-подобным синтаксисом который любой C#-пщик может начать использовать за пару дней.

Для русскоговорящих есть еще одно преимущество. Разработка языка и компилятора ведется русскоязычным комьюнити которые всегда охотно помогает изучать язык и устранять проблемы (если они возникают).

> Вот именно, что это сложно. А значит, будет использоваться когда действительно необходимо, а не когда в левой пятке зачешется.

Не. Это просто не будет использоваться в 99% случаев. Собственно все развитие ЯП провоцируется именно тем, что на одном ЯП что-то сделать сложно, вот и изобретают другой.

А так все языки программирования общего назначения равны по мощности с точки зрения машины Тьюринга (на любом можно написать программу написанную на другом). Да и метапрограммирование всегда можно сделать иззвне. В конце концов - сгенерил текст и скормил его компилятору.

Если бы это был аргумент, то развитие ЯП не пошло бы дальше Фортрана.

На самом же деле все зависит именно от скорости и удобства реализации. Если мы можем писать расширения в 10 раз проще и быстрее - это значит, что нужные расширения появятся. Просто появятся! А не сгинут так и не перешагнув порог «интересной концепции».

> Главная отличительная особенность - макросы.

Со времен сишного препроцессора изводили эту заразу, изводили, а толку. Их гонишь в дверь, они в окно назад лезут. Только Java без препроцессора сделали, как мелкософт в сишарп его обратно сунули, хорошо хоть порезали как следует. Только лиспы уродские похоронили, полезли из всех щелей немерлы и прочая нечисть. Когда-нибудь это кончится?!?

Для русскоговорящих есть еще одно преимущество.

Спасибо, 1С у нас уже есть, и хватит пожалуй.

> Со времен сишного препроцессора изводили эту заразу, изводили, а толку.

Вообще-то Lisp где появились макросы о которых идет речь сильно старше С-ей. То что ты с ним не знаком не делает тебе честь.

Разница между макросами C (т.е. препроцессором Си) и макросами Nemerle/Lisp примерно такая же как разница между руссифицированными языком вроде 1С и статьям о языке написанных на русском языке, то есть запредельная.

В Nemerle макрос - это плагин к компилятору/IDE. На них делается все, от операторов вроде for/foreach/if, до средств многозадачности и генераторов парсеров.

Только лиспы уродские похоронили...

Лиспы тебя переживут и не заметят, что ты существовал. Им уже 50 лет. И скорой кончины явно не предвидится. Наоборот создаются новые диалекты (Clojure и ClojureCLR, например).

Nemerle же это попытка сделать язык с макросами и (одновременно) с человеческим синтаксисом доступным обычным смертным.

Спасибо, 1С у нас уже есть, и хватит пожалуй.

Ну, да. С такими познаниями, 1С самое то. Успехов в его освоении! ;)

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

Отучаемся говорить за всех

Ясно. Спасибо за развёрнутый ответ. Язык действительно интересный.

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

Отучаемся говорить за всех

Обрати внимание на конец фразы на которую ты отвечал «в общее пользование». «Общее пользование» - это стандартная библиотека, та что идет в поставке компилятора. С ней все так и есть. В нее включаются только очевидно полезные вещи не имеющие минусов. Все остальное долго обсуждается, и зачастую, долго дорабатывается, прежде чем попасть в стандартную библиотеку. Ценз даже выше чем у обычных библиотечных функций.

гы!

до сих пор, вопреки традициям, никто не сказал «макросы не нужны»

тогда я скажу: макросы не нужны, нужна способность компилятора делать partial evaluation и возможность программисту указать, *как* ее делать

> до сих пор, вопреки традициям, никто не сказал «макросы не нужны»

Але, дядя, ты ваще читать умеешь, или где?

тогда я скажу: макросы не нужны,

Облом, ты не первый, не второй и даже не третий.

нужна способность компилятора делать partial evaluation

А уж это то тем более не нужно. Компилятор должен быть тупым, как дрова. Чтоб каждая конструкция исходного языка разворачивалась в простую, понятную и предсказуемую последовательность кодов VM.

> Вообще-то Lisp где появились макросы о которых идет речь сильно старше С-ей. То что ты с ним не знаком не делает тебе честь.

Лисп всегда был полудохлым, и никому особо жить не мешал (кроме идиотов, которые с emacs мучались). А вот с появлением препроцессора в Си началить масштабные и глобальные проблемы.

В Nemerle макрос - это плагин к компилятору/IDE.

И на куа оно такое надо?

На них делается все, от операторов вроде for/foreach/if, до средств многозадачности и генераторов парсеров.

Ой-ой, и как же без плагынов раньше for-ы с if-ами делали?

Им уже 50 лет.

50 лет медленного разложения? Ну так Владимир Ильич и подольше разлагается. Толку то от него при этом?

с человеческим синтаксисом доступным обычным смертным.

Человеческий синтаксис только в Дельфи. А немерла - вся та же сишноскобочная параша.

С такими познаниями, 1С самое то. Успехов в его освоении! ;)

1С - говно, как и все другие созданные русскими языки программирования. Немерлу русские делают, значит быть уму говном точно таким же, как 1С.

Немерлевские троли с rsdn'а и сюда залезли. Пздец, товарищи.

Интересный язык с вполне вменяемым синтаксисом (камень в огород ML и его детишек вроде F#) и широкими возможностями. Единственный его минус для меня - платформа .NET. Ну не перевариваю я эту хрень!

Эх, портировали бы его на нативный код, вот было б здорово!

> Немерлевские троли с rsdn'а и сюда залезли. Пздец, товарищи.

Ну и что тут плохого? Стараются ребята, создают языку репутацию. При таком фееричном community ни один вменяемый человек на язык два раза и смотреть не станет. Так что они правильно все делают, четко и конкретно дают всем понять, что язык этот только для отморозков, а остальным нет нужды беспокоиться.

> Единственный его минус для меня - платформа .NET.

А Семён Горбунков опять против? :) Для Win32 платформы есть туча Сей, Сипипей и даже D! Туда же нехило развитый Delphi.
А для тех, кто устал от всего этого цирка «моделей памяти», недобиблиотек и убогих IDE, есть .NET - целый «компьютер в компьютере» с немыслимым количеством классов и на порядок улучшенной стабильностью. Можно простить капризы школоты (и те - чисто попугайски повторяют сетования «дедушек» на нестабильный Win 95), но взрослый, опытный разработчик уже как-то должен понимать, как тупо наезжать на .НЕТ - это вообще считай «эдем программирования». Изучайте пока не поздно, придёт время - мамка больше не даст «на кино», придётся зарабатывать самому. А .НЕТ - это всё «по-взрослому», вполне хорошая ниша для профи.

вон сейчас что у людей на злобе дня http://www.linux.org.ru/forum/development/6293496 а вы мертвый .net пинаете

будущее либо iOS либо Android

В Nemerle 2 планируется создать сменяемые бэкэнды: http://code.google.com/p/nemerle-2/wiki/BackEnds http://www.rsdn.ru/forum/philosophy/4280043.1.aspx

В том числе можно сделать и нэйтивынй бэкнэд. Он планируется и все рассчитывается на то, чтобы его создание было возможно.

Но им надо кому-то заниматься. Можешь сколотить команду и реализовать бэкэнд на базе LLVM или gcc. Поработать надо будет не мало, так как надо будет реализовать GC и его поддержку (карты стеков и т.п.). Но работа вполне подъемная.

Как это ни грустно, я ноль в разработке компиляторов. Так что остается только ждать...

А Семён Горбунков опять против? :) Для Win32 платформы есть туча Сей, Сипипей и даже D! Туда же нехило развитый Delphi.

В том и беда, что для win32. Для винды меня .Net полностью устраивает. А вот в linux мне совсем не хочется пользоваться mono, потому что это огромный тормозной довесок к системе, к тому же с урезанным функционалом. Не все возможности .Net там реализованы пока что.

Хотя может я ошибаюсь? Давненько его не использую на своей машине и может уже что-то изменилось.