Здравствуйте, VladD2, Вы писали:
VD>Насколько разумное будет сообщение об ошибках?
На мой взгляд не очень разумное, но для такого макроса вполне сойдет.
48:9:48:12: each overload has an error during call:
48:9:48:12: overload #1, method System.Double.op_Addition(left : System.Double, right : System.Double) : System.Double
48:9:48:12: in argument #2, needed a System.Double, got string: System.String is not a subtype of System.Double [simple require]
48:9:48:12: overload #2, method System.String.op_Addition(left : string, right : string) : string
48:9:48:12: in argument #1 (left), needed a string, got System.Double: System.Double is not a subtype of System.String [simple require]
VD>Хотя конечно в самом макросе можно сделать проверку на то чтобы типы совпадали и предоставляли нужные операторы.
Зачастую так и делается. Практически во всех "внутренних" макросах источниками сообщений об ошибкой является в первую очередь макрос. Но во многих случаях компилятор и сам неплохо справляется.
VD>А вообще, такие макросы похоже что хочешь заменят. Возможно языки следующего поколения будут вообще минималистичны, а все что нужно будет макросами. Уж больно мощьная технологиях.
Здравствуйте, Vermicious Knid, Вы писали:
VK>Простейший пример: VK>
VK>def x = if (false) 0;
VK>
VK>Что будет в x? Какой у него будет тип?
x = if false
0
end
x >> nil
x.class >> NilClass
VK>1. автоматическое выведение типов
Да, есть такое дело, согласен. Но мне кажется, что это автоматическое выведение типов будет доступно только в очень ограниченных контекстах. Внутри функций, например. При выходе за пределы метода описания типов лучше все-таки делать полными.
VK>2. макросы
VK>Или в качестве примера посложнее. У нас есть класс Dog с методами Bark и Woof. И есть например класс DogBrain.
VK>Вообще сложность и полезность операций поддерживаемых Nemerle во время компиляции в отличие от того же C++ определяется лишь фантазией и знанием языка. Скажем макрос продемонстрированный чуть выше относится к разряду относительно простых и выглядит так:
<...простенький макрос на 50 строк поскипан ...>
Вот, кстати, о макросах. Хочу воспользоваться твоим знанием языка Nemerle и спросить: как эти макросы отлаживать? Есть ли какой-то механизм unit-тестинга?
И вообще, если есть какой-то опыт создания макросов Nemerle, то интересно было бы послушать о впечатлениях.
VK>3. многочисленные элементы ФЯ, включая алгебраические типы, паттерн-мэтчинг, лямбду, list comprehensions, кортежи
По-твоему, все эти механизмы снижают вероятность ошибок в программах?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VK>>Ты лучше скажи как ты эту простейшую вешь собираешься применять на практике? Первое, что я в свое время попытался сделать, как давний фанат шаблонов C++ это именно то, что ты сейчас написал и естественно это не работало.
FR>Я дал нормально компилируемый и рабочий пример. В C++ это работает и широко применяется
Вот я и спросил тебя, как ты собираешься это применять? У макросов один недостаток — они лучше подходят чтобы решить реальную задачу, а не просто написать красивый код. У шаблонов C++ этого недостатка нет, но есть множество других.
Если ты хочешь получить аналог expression templates, то это на Nemerle это достаточно легко осуществить(правда там это реже нужно, так как есть лямбда). Если тебе нужны полиморфные функции — копай дженерики. Просто они не очень хорошо подходят для этого конкретного случая, поэтому решение с ними я не приводил.
FR> Вот я и думал почему-бы и Немерле не быть такому, лучше конечно не с C++ синтаксисом а ближе к другому примеру который на питоне, оказыватеся размечтался
Кстати Nemerle поддерживает альтернативный, питонообразный синтаксис.
FR>Да я уже понял, те же проблемы что и в Ocaml с их + и .+
Нет, другие. В Ocaml нет перегрузки, в Nemerle она есть. Оператор + можно перегружать свободно, в любом классе.
FR>А какой недостаток макросов мешает их использовать для таких вещей?
Макросы больше подходят для серьезных преобразований и генерации кода. Например они компилируются в отдельную сборку и подключаются к компилятору. И будет лучше если макрос будет проводить часть проверок на ошибки самостоятельно. Все таки они непосредственно встраиваются в язык. В общем-то макросы ортогональны шаблонам, хотя задачи у них иногда пересекаются.
Здравствуйте, VladD2, Вы писали:
VD>Скачай сегоюня на работе.
VD>Продемонстрируй не однозначно понимаемую, по-твоему, ситуацию. Я хоть на нее погляжу. А то пока, что я тут проблем в упро не вижу.
@cprov_in_directions = @cprov.in_directions.inject( [] ) do
|r, direction|
d = OpenStruct.new( :name => direction.number )
d.smscs = direction.smsc_agents.inject( {} ) do
|smsc_hash, agent|
smsc_hash[ agent.smsc ] ||= []
smsc_hash[ agent.smsc ] << agent
smsc_hash
end
r << d
r
end
Выделеная строка изначально была последней во вложенном блоке кода. Она возвращала Array вместо Hash. А вложенный блок должен был возвращать именно Hash. Поэтому нужно было написать еще одну строку, которая и давала результат.
Понятно, что это в Ruby с динамической типизацией возможно сменить в inject-е тип объекта с Hash на Array и не заметить этого. Но, если бы был inject([]), то тогда вообще несоответствия типов не обнаружилось бы.
VD>Хм. А если ты для объявленной ранее переменной такую же фигню сморозить, то разбираться тебе не прийдется? Так же пойдешь искать источник проблемы.
Нет, не пойду, компилятор мне точное место укажет.
VD>В общем, очередной пример высасаной из пальца проблемы. При этом ты программирушь на С++ где проблему можно получать буквально на ровном месте. Чуть чуть ошибся при написании шаблона и получи три километра туалетной бумаги вместо сообщения об ошибке.
Мне интересно, как поведет себя Nemerle, если я допущу ошибку в реализации макроса.
VD>Думаю, что основная проблема этого языка заключается в людях. Есть три группы людей которые его будут воспринимать с трудом: VD>1. Закостянелые импиративщики... VD>2. Противники всего от МС... VD>3. Просто люди сильно подсевшие на другой язык...
4. Люди, не доверяющие массированной рекламе и думающие, что серебрянной пули не существует.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Vermicious Knid, Вы писали:
VK>Вот я и спросил тебя, как ты собираешься это применять? У макросов один недостаток — они лучше подходят чтобы решить реальную задачу, а не просто написать красивый код. У шаблонов C++ этого недостатка нет, но есть множество других.
Я не собираюсь, я это постоянно применяю и в C++ (там половина STL это использует) и в питоне(там вообще затруднительно не применять).
Вот и подумал что в Немерле тоже легко это сделать.
VK>Если ты хочешь получить аналог expression templates, то это на Nemerle это достаточно легко осуществить(правда там это реже нужно, так как есть лямбда). Если тебе нужны полиморфные функции — копай дженерики. Просто они не очень хорошо подходят для этого конкретного случая, поэтому решение с ними я не приводил.
Дженерики не надо у них ни та ниша, и они слишком ограничены.
FR>> Вот я и думал почему-бы и Немерле не быть такому, лучше конечно не с C++ синтаксисом а ближе к другому примеру который на питоне, оказыватеся размечтался
VK>Кстати Nemerle поддерживает альтернативный, питонообразный синтаксис.
Ты про def или есть еще что?
FR>>Да я уже понял, те же проблемы что и в Ocaml с их + и .+
VK>Нет, другие. В Ocaml нет перегрузки, в Nemerle она есть. Оператор + можно перегружать свободно, в любом классе.
угу, только фиксация типа такая же.
FR>>А какой недостаток макросов мешает их использовать для таких вещей?
VK>Макросы больше подходят для серьезных преобразований и генерации кода. Например они компилируются в отдельную сборку и подключаются к компилятору. И будет лучше если макрос будет проводить часть проверок на ошибки самостоятельно. Все таки они непосредственно встраиваются в язык. В общем-то макросы ортогональны шаблонам, хотя задачи у них иногда пересекаются.
То есть в макросах все вручную? Та же утиная типизация что и в питоне или руби?
Здравствуйте, VladD2, Вы писали:
VD>Кстати, а как у Хаскелевского подхода с модульносью и компонентностью?
Честно говоря, не копенгаген. Есть интеграция с COM и C: http://www.haskell.org/hdirect/
Здравствуйте, Vermicious Knid, Вы писали:
VK>На мой взгляд не очень разумное, но для такого макроса вполне сойдет. VK>
VK>48:9:48:12: each overload has an error during call:
VK>48:9:48:12: overload #1, method System.Double.op_Addition(left : System.Double, right : System.Double) : System.Double
VK>48:9:48:12: in argument #2, needed a System.Double, got string: System.String is not a subtype of System.Double [simple require]
VK>48:9:48:12: overload #2, method System.String.op_Addition(left : string, right : string) : string
VK>48:9:48:12: in argument #1 (left), needed a string, got System.Double: System.Double is not a subtype of System.String [simple require]
VK>
Да, любой кто не новечок в дотнте поймет ето без проблем.
VK>Зачастую так и делается. Практически во всех "внутренних" макросах источниками сообщений об ошибкой является в первую очередь макрос. Но во многих случаях компилятор и сам неплохо справляется.
Хорошо бы чтобы он справлялся как можно больше. А так же хорошо, чобы макросы можно было делать и без отдельной компиляции. А то конечно возможно решить проблему есть, но уж больно выглядит это похожим на применение тяжоловй артилерии для стрельбы по воробьям.
Ведь по сути нет ничего чтобы помешало бы делать гокальные текстуально полиморфные функции. Макросы же прокатывают на ура?!
А помочь здесь могло бы введение чего то вроде концептов для С++. Я конечно понимаю сложности дизайна языка который кроме всего прочего должен первокласно поддерживать и компонентность. Но хочется всегда всего и сразу. И по возможности без швов.
VD>>А вообще, такие макросы похоже что хочешь заменят. Возможно языки следующего поколения будут вообще минималистичны, а все что нужно будет макросами. Уж больно мощьная технологиях.
VK>Уверен так и будет. Рано или поздно.
Согласен. Но вот MS явно боится применять столь мошьные вещи. Больно они напуганы тем, что шаблоны плюсов не могут понять 90% средних программистов. Боятся угробить новые языки. А остальные гиганты еще более консервативны. Итого на гора море исследований и капял результата.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Я дал нормально компилируемый и рабочий пример. В C++ это работает и широко применяется,
Работает — Да. Широко применятся? Вот это вряд ли. Если реально поглядеть, то мест в которых это надо раз два и обчелся. Я вот во всю программирую на C# где "это" тоже нельзя напрямую заполучить, но как-то особо не напрягаюсь по этому поводу. Зачем обобщенно складывать что-то? Рельно семантика сложения общая только у числовых данных. Те же строки имеют семантику конкатинации. Так что, то что твой add работает со строками скорее плохо нежели хорошо. Ну, а числа можно и не обобщенно сложить. За много лет я ни разу не испытал необходимости обобщить сложения. Вот сортировка — другое дело. Но для нее как раз дженерики влет работают.
FR> Вот я и думал почему-бы и Немерле не быть такому, лучше конечно не с C++ синтаксисом а ближе к другому примеру который на питоне, оказыватеся размечтался
У питона своих проблем хватемт. Если уж говорить об аналогихя, то лучше поговорить о тех самых клонах ML-я. Но там похоже именно вот такой обобщенный вывод привел к тому, что невозможно делать перегруженные методы. Хотя с другой стороны ведь на макросах в немереле все похожит. Значит можно?!
FR>Да я уже понял, те же проблемы что и в Ocaml с их + и .+
Да, похоже проблемы растут от туда же. Я тут в блоках Нэмерла читал, что ребята отаказались от поддержки ковариантности для массивов (которая есть в C#). Думаю тоже выводу типов мешает.
FR>А какой недостаток макросов мешает их использовать для таких вещей?
Дык жто же марос! Макрос в Нэмерле — это изменение синтаксиса языка, а значит неявное изменение компилятора. Самое смешное, что в этом макросе можно еще и синтаксис "+" перегрузить. И тогда можно будет вызвать его так, что никто и не догадается о подмене. Представляешь каких неожиданностей можно добиться таким образом?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Vermicious Knid, Вы писали:
VK>Макросы больше подходят для серьезных преобразований и генерации кода. Например они компилируются в отдельную сборку и подключаются к компилятору. И будет лучше если макрос будет проводить часть проверок на ошибки самостоятельно. Все таки они непосредственно встраиваются в язык. В общем-то макросы ортогональны шаблонам, хотя задачи у них иногда пересекаются.
Я бы варазился так. Макросы ремерла это мощьное и гибкое средсво метапрограммирования с помощью которого можно эмулировать и обобщенное программирование. А шаблоны С++ это мощьное и гибкое средство обобщенного программирования с помощью которого можно эмулировать метапрограммирование.
Вопрос только в издержках. Макросы нэмерла явно слишком сложно компилировать и они могут привести к уда более сложным решениям чем специализироанные средства обобщенного порграммирования.
Шаблоны же С++ имеют кучу своих проблем (вроде не внятных сообщений об ошибках), отсутсвия полноценной типизации до момента компиляции и т.п. А так же являются очень плохим средством метапрограммиирования (ну, не для этого они создавались).
Учитывая ниличие дженериков, функций как первокласных значений и лябд лично я без осмнения предпочту подход Нэмерла. Темболее, что меня устраивали даже дженерики в C# где метапраограммирование можно было устроить только путем отдельной генарции кода.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Я не собираюсь, я это постоянно применяю и в C++ (там половина STL это использует) и в питоне(там вообще затруднительно не применять). FR>Вот и подумал что в Немерле тоже легко это сделать.
Vermicious Knid дело говорит. Ты обясни где ты "это" хочень применить конкретно. И мы тебе покажем, как можно тоже самое сделать другими средствами.
Я так и думал, что ты скажешь про STL. Но вот в чем парадокс. Я не чуствую нужны в STL даже в C# с его дженериками. А уж любой функциональщик тебе скажет, что STL — это плохая породиях на ФЯ.
Мы давим на рельный код потому что скорее всего тебе нужно будет не полиморфный вариант процедуры сложения. А передакть конкретный вариант такой процедуры в полиформфную функцию в качестве параметра.
Так вот для этого существуют лямбды, интерфейсы и функции как значения в купе с делегатами. Ты же привел пример обобщения примитивной опирации. На что Vermicious Knid тебе резонно заметил, что такая фигня нужна приемущественно в тестах и примерах. А в реальной жизни она встречается очень редко.
FR>Дженерики не надо у них ни та ниша, и они слишком ограничены.
У них как раз та самая ниша. Это чистое обобщенное программирование не конфликтующие с такими нужными вещами как:
1. Модульность.
2. Компонентность.
3. Однозначность конструкций языка.
Да, ты не можешь напрямую использовать в них оператор "+" или любой другой. Но ты без проблем можешь создать обобщенную функцию получающую в качесвте параметра другую функцию выполняющую нужное действие. Учитывая, что функции можно объявлять по месту, ты не много потеряшь от такого решения. Ну, а если типы реализуют нужный интерфейс, то ты можешь просо добавить констрэйн к параметру типа и получить решение не отличимое от С++.
Все же выпендрежы доступные на С++ это в соновном метапрограммирование. А оно у Нэмерла на порядок круче. Тебе просто не потребуются эти убогие средства. В твоем распоряжении исенное расширение компилятора.
FR>Ты про def или есть еще что?
Нет. Он про то, что в Нэмерле можно переключиться на задание структуры кода отступами. По мне так это полнейшее извращение. Но наверно при работе в консоли это разумно.
Кстати, забавно, что эта возможность вроде как тоже сделана на базе макросов. Так что можешь оценить их мощь!
FR>То есть в макросах все вручную? Та же утиная типизация что и в питоне или руби?
Нет. В макросы передаются конструкции языка такими какими их видит компилятор. В них история очень похожая на препроцессор ОКала или макросы Лиспа. Разница только в том, что в них таки достуипна информация о типах и ты можешь залезть в разные стадии компиляции.
Другими словами макросы Нэмерла — это расширение компилятора со всеми вытекающими последствиями. Невероятная гибкость, но и возрастающая сложность, а так же опасность сделать лишнего или получить двоольно странный результат.
Одано в отличии от утиных историй, макросы чисто компайл-атймная сущность. И однажды написанные и отлаженные они становятся частью языка обеспечивая всю мощь которую может обеспечить компилятор со статической типизацией и статическим выводм типов. В общем, мое мнение, что это будущее языков программирование которе было придумано много лет назад в Лиспе, но и вследсвии чудности (от слова "чудак", а не "чудо") самого Лиспа и отсуствия свлязи с компилятором не оцененное широкими массами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>И уж если говорить о макросах, то стоит сказать, что они действительно выглядят достойно! Кратко и понятно. Это тебе не на шаблонах изворачиваться. Собственно по тому в тематическом письме и присутсвует ехидное замечание про С++.
ГМ, я чего-то не понимаю, Вроде не так давно был целый флейм о вреде макросов в С++ и Ваша позиция была стойкой — макросы это зло. С чего бы это такие перемены ?
Здравствуйте, srggal, Вы писали: S>Чем эти макросы лучше друних, которые на С++?
Серж, это другие макросы, эт не просто тупая подстановка текста, это, скорее, расширение компилятора.
Вот цитата из доков по Nemerle:
You can think about macros as of a system of compile-time transformations and automatic generation of code with regard to some rules.
Здравствуйте, VladGalkin, Вы писали:
VG>Здравствуйте, srggal, Вы писали: S>>Чем эти макросы лучше друних, которые на С++? VG>Серж, это другие макросы, эт не просто тупая подстановка текста, это, скорее, расширение компилятора. VG>Вот цитата из доков по Nemerle: VG>
VG>You can think about macros as of a system of compile-time transformations and automatic generation of code with regard to some rules.
ГМ, читал, много дкмал...
А может эти макросы — это и есьти сермяжная правда ?
То, о чём твердят большевики с завидной переодиностью в лице (eao197 С++ + Ruby )?
Так сказать шампунь 2в одном, вместо прикручивания внешних тулзов для кодогенерации имеем встроенную возможность.
Кстати, я таки прав, но весьма отчасти
The idea of making simple inline operations on the code comes from preprocessor macros, which many languages (especially C, C++) have contained since early times of compiler design. We are following them in the direction of much more powerful, and at the same time more secure (type-safe) solutions like Haskell Template Meta-programming.
Здравствуйте, srggal, Вы писали:
S>А может эти макросы — это и есьти сермяжная правда ?
Все в истории развивается по спирали. Подобные вещи уже были.
Сейчас вот у некоторых есть уверенность что уж в этот раз все будет хорошо.
Поживем, увидим. На самом деле, если Nemerle позволит легко ввести в язык конструкции, которые позволят поддерживать возможности SObjectizer
, то я возьмусь за портирование SObjectizer под .NET на Nemerle. Однако, для этого нужны не только красивые глаза самого Nemerle, но и его благосклонное приятие сообществом разработчиков (а здесь все может быть не так радужно).
S>То, о чём твердят большевики с завидной переодиностью в лице (eao197 С++ + Ruby )? S>Так сказать шампунь 2в одном, вместо прикручивания внешних тулзов для кодогенерации имеем встроенную возможность.
У внешних тулзов есть два очень больших, имхо, преимущества:
-- легкость освоения скриптовых языков (Perl, Python, Ruby), большое количество существующей документации и готовых программистов;
-- возможность автономной отладки. Написать unit-тесты, которые проверяют корректность кодогенератора на Ruby не сложно. Насколько просто это будет делать в макросах Nemerle -- вопрос открытый.
По крайней мене об отладке и тестировании макросов Nemerle здесь разговор пока не заходил. А для меня привлекательность Nemerle как раз в макросах и состоит.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Я дал нормально компилируемый и рабочий пример. В C++ это работает и широко применяется,
VD>Работает — Да. Широко применятся? Вот это вряд ли. Если реально поглядеть, то мест в которых это надо раз два и обчелся. Я вот во всю программирую на C# где "это" тоже нельзя напрямую заполучить, но как-то особо не напрягаюсь по этому поводу. Зачем обобщенно складывать что-то? Рельно семантика сложения общая только у числовых данных. Те же строки имеют семантику конкатинации. Так что, то что твой add работает со строками скорее плохо нежели хорошо. Ну, а числа можно и не обобщенно сложить. За много лет я ни разу не испытал необходимости обобщить сложения. Вот сортировка — другое дело. Но для нее как раз дженерики влет работают.
Не надо зацикливатся на сложении, это просто пример, главное идея.
Вообще интерсно получилось первый же пример который я ввел сам а не скопировал, оказался на немерле не реализуем без макросов
FR>> Вот я и думал почему-бы и Немерле не быть такому, лучше конечно не с C++ синтаксисом а ближе к другому примеру который на питоне, оказыватеся размечтался
VD>У питона своих проблем хватемт. Если уж говорить об аналогихя, то лучше поговорить о тех самых клонах ML-я. Но там похоже именно вот такой обобщенный вывод привел к тому, что невозможно делать перегруженные методы. Хотя с другой стороны ведь на макросах в немереле все похожит. Значит можно?!
ладно будем смотреть, но уже видно что для меня немерле не является "языком мечты"
FR>>Да я уже понял, те же проблемы что и в Ocaml с их + и .+
VD>Да, похоже проблемы растут от туда же. Я тут в блоках Нэмерла читал, что ребята отаказались от поддержки ковариантности для массивов (которая есть в C#). Думаю тоже выводу типов мешает.
FR>>А какой недостаток макросов мешает их использовать для таких вещей?
VD>Дык жто же марос! Макрос в Нэмерле — это изменение синтаксиса языка, а значит неявное изменение компилятора. Самое смешное, что в этом макросе можно еще и синтаксис "+" перегрузить. И тогда можно будет вызвать его так, что никто и не догадается о подмене. Представляешь каких неожиданностей можно добиться таким образом?
Представляю
Так что про безграблевость ты поторопился
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Я не собираюсь, я это постоянно применяю и в C++ (там половина STL это использует) и в питоне(там вообще затруднительно не применять). FR>>Вот и подумал что в Немерле тоже легко это сделать.
VD>Vermicious Knid дело говорит. Ты обясни где ты "это" хочень применить конкретно. И мы тебе покажем, как можно тоже самое сделать другими средствами.
Ну конечно, час. Я пытаюсь понять что может язык, чего нет. Мне пока не нужно решать конкретную задачу на Немерле, я только знакомлюсь с ним.
VD>Я так и думал, что ты скажешь про STL. Но вот в чем парадокс. Я не чуствую нужны в STL даже в C# с его дженериками. А уж любой функциональщик тебе скажет, что STL — это плохая породиях на ФЯ.
Я тоже когда пишу на питоне не чуствую потребности в STL, странно да?
VD>Мы давим на рельный код потому что скорее всего тебе нужно будет не полиморфный вариант процедуры сложения. А передакть конкретный вариант такой процедуры в полиформфную функцию в качестве параметра.
VD>Так вот для этого существуют лямбды, интерфейсы и функции как значения в купе с делегатами. Ты же привел пример обобщения примитивной опирации. На что Vermicious Knid тебе резонно заметил, что такая фигня нужна приемущественно в тестах и примерах. А в реальной жизни она встречается очень редко.
Понимаешь у всех реальная жизнь разная, спроси об этом в форуме C++.
И не надо меня учить как писать на C++ используя опыт C#.
FR>>Дженерики не надо у них ни та ниша, и они слишком ограничены.
VD>У них как раз та самая ниша. Это чистое обобщенное программирование не конфликтующие с такими нужными вещами как: VD>1. Модульность. VD>2. Компонентность. VD>3. Однозначность конструкций языка.
и куча ограничений в придачу.
VD>Да, ты не можешь напрямую использовать в них оператор "+" или любой другой. Но ты без проблем можешь создать обобщенную функцию получающую в качесвте параметра другую функцию выполняющую нужное действие. Учитывая, что функции можно объявлять по месту, ты не много потеряшь от такого решения. Ну, а если типы реализуют нужный интерфейс, то ты можешь просо добавить констрэйн к параметру типа и получить решение не отличимое от С++.
Угу могу и вручную все написать, мне вон один дельфист доказывал что шаблоны вообще не нужны, все можно скопипастить.
Ладно в немерле нет того что я хотел, будем смотреть как обходится без этого.
FR>>Ты про def или есть еще что?
VD>Нет. Он про то, что в Нэмерле можно переключиться на задание структуры кода отступами. По мне так это полнейшее извращение. Но наверно при работе в консоли это разумно.
так уже интересно
VD>Кстати, забавно, что эта возможность вроде как тоже сделана на базе макросов. Так что можешь оценить их мощь!
мечта суперхардкорных C++'ишников перегруженный оператор пробел?
FR>>То есть в макросах все вручную? Та же утиная типизация что и в питоне или руби?
VD>Нет. В макросы передаются конструкции языка такими какими их видит компилятор. В них история очень похожая на препроцессор ОКала или макросы Лиспа. Разница только в том, что в них таки достуипна информация о типах и ты можешь залезть в разные стадии компиляции.
VD>Другими словами макросы Нэмерла — это расширение компилятора со всеми вытекающими последствиями. Невероятная гибкость, но и возрастающая сложность, а так же опасность сделать лишнего или получить двоольно странный результат.
VD>Одано в отличии от утиных историй, макросы чисто компайл-атймная сущность. И однажды написанные и отлаженные они становятся частью языка обеспечивая всю мощь которую может обеспечить компилятор со статической типизацией и статическим выводм типов. В общем, мое мнение, что это будущее языков программирование которе было придумано много лет назад в Лиспе, но и вследсвии чудности (от слова "чудак", а не "чудо") самого Лиспа и отсуствия свлязи с компилятором не оцененное широкими массами.
я думаю такая мощь просто приведет к расползанию языка как было с фортом и лиспом.
Здравствуйте, srggal, Вы писали:
S>Но, в целом, по данному вопросу я разделяю радость Vlad2D — С# — уже мёртвый язык
По поводу смерти какого-либо языка я вообще не испытываю радости. Т.к. за этим стоит работа по переносу продуктов, написанных на этом языке, на другие платформы. Мы вынуждены повторять функциональность вместо того, чтобы развивать ее.
S> — доведут ли Nemerle до ума ?
Меня интересует другое. Когда Nemerle дойдет до состояния, после которого на нем можно будет писать код коммерческих продуктов? Не получится ли так, что написав для версии 0.9.2 пару сотен килобайт макросов, я обнаружу, что половина из них требует переделки в версии 0.10.3.
S> — как воспримет M$ появление этого языка ?
Другой вопрос: будет ли Nemerle одинаковым под .NET от MS и Mono? Кроссплатформенность для меня важна.
Без ответов на эти вопросы разговоры о Nemerle -- это академические рассуждения.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Уж больно мощьная технологиях.
Рано или поздно. 
...>
.
