Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Офф-топ: Кстати, обычно под словом "птичий" понимают не язык с гибким синтаксисом, а язык с кучей "птичек" и прочих значков в противовес словам. Значение таких значков невозможно понять, а можно только запомнить. Яркий представитель таких языков — перл.
Совершенно верно.
Re[35]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
WH>>Тогда и проблемы не будет. O>Да. Чего-то подобного надо, наверное. Если тут подводных камней нету, конечно...
Не вижу.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Снова о Nemerle или профанация не пройдет :)
VD>Причем ошибиться нигде нельзя! Если ты впишешь неверное имя переменной в текст, то тебя остановит компилятор! А в C# ты рискушь получить ошибку во время выполнения (неверный форма или еще что).
Ну, положим, от ошибки неверного формата (кстати, имеет ли это место быть в случае ToString()) этот макрос не спасет. Он всего лишь делает запись короче и не позволяет ошибиться с циферками в скобочках. Всё. После его прохода у компилятора оказывается примерно вот что:.
// До
def a = 5;
$"var a has value $a, blah-blah-blah";
// После
def a = 5;
def tmp = StringBuilder("var a has value ");
tmp.Append(a.ToString());
tmp.Append(", blah-blah-blah");
tmp.ToString();
--
Re[18]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Ну, положим, от ошибки неверного формата (кстати, имеет ли это место быть в случае ToString()) этот макрос не спасет.
Зато спасут макросы из Nemerle.IO: printf, sprintf и fprintf. Естественно эти макросы лишены недостатков своих сишных аналогов. А еще к своему удивлению я только что обнаружил scanf и иже с ним.
Вообще не знаю как для production кода, но для тестовых приложений эти макросы незаменимы.
Re[24]: Снова о Nemerle или профанация не пройдет :)
.
E>Причем интересно как с парсингом XML-я (может быть даже в compile-time), так и создание специализированного DSL на макросах специально для этой задачи.
В общем, я решил попробовать написать такой макрос. Сильно не пинать — первый опыт, можно сказать.
Макрос генерит класс в compile-time в соответствии с постановкой задачи. Конструктор вот только пока что не создаётся (уже домой бежать надо — завтра, надеюсь...). Используется макрос вот так:
Здравствуйте, IT, Вы писали:
WP>> Программист обязан знать все парадигмы и по одному или лучше по два языка из каждой парадигмы. Иначе не программист он, а кодер. Лабух.
IT>Знать всё невозможно.
Вы меня пугаете. Какое такое всё? Это за пару семестров вдалбливается тривиально. А если человек уже отучился, мозги натренировал, то за пару месяцев.
IT> К сожалению. На это просто не хватит времени.
Время надо было раньше тратить. Когда оно было.
IT> Хотя нет, всё же знать очень много можно, если только тем и заниматься, что постоянно изучать всё новое. Но тогда не останется времени на работу. Если же только и делать что работать, то не будешь ничего знать. Как обычно руль посередине
Как уже тут обсуждалось, работающий студент — пропавший для общества студент. Отработанный материал. Социальный труп...
WP>> Легко: ADT, pattern matching, list comprehensions, annotations (уже есть в примитивном виде — контракты, но грядёт скоро вообще полная щастя), Pi calculus (в свете XBox360 и Cell — мегаактуально, так что скоро всем индусам придётся эту математику изучать), ну и всенародно любимые DSL-и, конечно же. Они и так внедрены, но пока народ не знает, как это называется, и формальными методами не владеет. Скоро завладеют.
IT>Многое из этого уже есть и давно широко используется, кое что появляется (в том же Nemerle) и будет скоро широко использоваться. Но всё это мелочи (кроме пожалуй DSL), техники, на технологии и парадигмы никак не тянут. Мир они не перевернут и даже особенного шороха не наделают.
Перевернут. Всё это вместе убьёт индусов. Кодирование станет настолько простым и автоматизируемым делом, что недоучки из программирования вылетят, улицы подметать пойдут или бигмаками торговать. И это будет радость великая!
Re[17]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Sinclair, Вы писали:
S>После этого я понял, что придумать язык типа С++ еще тяжелее, чем реализовать.
+1
А реализовать его практически невозможно.
Можно посмотреть на это с точки зрения проблемы представления знаний. Стандарт насчитывает порядка 700 страниц на английском языке. Воды, понятное дело, в стандарте нет. Даже у экспертов C++ случаются разночтения по поводу некоторых сложных моментов. При этом весь этот объем знаний должен быть отражен в компиляторе, на языке, значительно менее выразительном по сравнению с английским — на C.
Неудивительно, что по хорошему соответствующий стандарту компилятор в природе существует только один (Comeau), да и ему веры нет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>Кстати, думаю, что твое начальство было бы только радо если бы и другие смогли бы если не править, то хотя бы проще понимать что делает код трансформации. Это и тебе жизнь упростило бы. Ведь вместо туманных описаний что не так, ты бы зачастую получал бы информацию о том, в каком месте макроса проблемы.
Ни фига бы не упростило. Если ты единственный чувак на проекте, который может что-то поправить, то твоя ценность как специалиста сильно увеличивается
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[25]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
O>В общем, я решил попробовать написать такой макрос.
Интересно получилось.
Только вот о вкусах, конечно, можно спорить, но мне этот код красивым не показался. В особенности <[ и ]> -- путаюсь к чему что относится. Вспоминаются слова классика
Еще одна мысль по поводу compile-time генерации vs precompile-time. В случае precompile-time можно нагенерировать обычный класс с комментариями. Он может быть обработан инструментом типа javadoc и программисту будет предоставлена документация о том, что в TestClass кроме prop1 и prop2 будут еще геттеры-сеттеры. А вот такой DSL как документировать?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
O>В общем, я решил попробовать написать такой макрос. Сильно не пинать — первый опыт, можно сказать.
Очень неплохо для первого опыта. Хотя и не без ляпов конечно. Сразу становится понятно, что Nemerle достаточно простой в освоении язык.
O>Конструктор вот только пока что не создаётся (уже домой бежать надо — завтра, надеюсь...).
С конструктором вообще и параметрами функций там все не так просто. В общем я добавил создание конструктора и упростил/улучшил некоторые моменты. Вот пример того, как это все работает:
using Oyster;
using Nemerle.IO;
metaclass zuper
{
test : int;
anotherProperty : string;
}
def z = zuper(1, "crazy test");
printf("%d %s\n", z.Test, z.AnotherProperty);
Вот улучшенный код(комментировать было лень, да и код в общем недалеко ушел):
Здравствуйте, VladD2, Вы писали:
VD>Так что тебе нужно заменить твой ХМЛ на нечто более выразительное. Ты и сам это пыташся сделать делая визуальные средства редактирования ХМЛ-ей для своих ДСЛ-ей.
Ей-богу это уже религия какая-то. Честно говоря, не вижу особой разницы между:
<EntityName Attribute1="" Attribute2="" />
и
EntityName
{
Attribute1="";
Attribute2="";
}
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>3. ХСЛТ не полноценный ЯП и если что-то нужно посчитать и т.п., то прийдется делат вставке на другом ЯП, что усложняет процесс.
А XSLT + XPath?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Снова о Nemerle или профанация не пройдет :)
E>Только вот о вкусах, конечно, можно спорить, но мне этот код красивым не показался. В особенности <[ и ]> -- путаюсь к чему что относится.
Ну во-первых нет "правильной" подсветки синтаксиса. А во-вторых мне многое в том коде показалось не совсем "красивым", просто потому что человек писал такое впервые. Посмотри лучше мой вариант его кода. А чтобы окончательно не путаться — почитай лучше документацию. Вообще Nemerle как язык это лучше, чем Nemerle как компилятор и библиотека. И первое, и второе на мой взгляд оставляют желать лучшего. И это не в последнюю очередь сказывается на коде. К сожалению я не застал первый компилятор C++, CFront(я в начале восьмидесятых только родился ), но думаю что он был тоже не самого хорошего качества. Если бы он предоставлял коду доступ к своим внутренностям, то я думаю повеситься можно было бы, т.к. ничего приличного написать бы не удалось.
E>
E>То что технически грамотно должно быть как минимум красиво.
Самого "классика"(c-smile) я уважаю, а вот эти его слова не очень. Тогда можно и шаблоны C++ считать технически неграмотными(да и любого неподготовленного к такому зрелищу человека от них просто выворачивает). Да и красота вещь весьма относительная, ни у кого нет единого взгляда на этот вопрос. Вот "классик" считает Форт эталоном красивости и технической грамотности, а по мне так это доисторический мусор и ужасно некрасивый.
Правда на Форте я не писал. Но пробовал писать на его "последователях" — Postscript и Joy, особенно на Postscript. Оба эти языка более высокоуровневые чем Форт, но программирование на них это весьма специфическое занятие, чем-то похожее на программирование на ассемблере. Я вообще ради развлечения люблю попрограммировать на самых разных языках, но за деньги я бы не стал касаться ни одного из вышеперечисленных языков, собственное время дороже.
А вообще "классику" следовало бы поближе познакомиться с Lisp, а еще лучше Rebol, он имхо покрасивее будет. Но все это не имеет никакого отношения к Nemerle. И вот почему.
В Nemerle все усилия приложены к тому, чтобы скомпилировался только такой макрос, который хотя бы генерирует синтаксически и семантически правильный код. Отсюда куча необходимых преобразований кода, явные указания типа для фрагментов AST итд. Все для того, чтобы компилятору не пришлось затрачивать дополнительное время на парсинг и валидацию кода во время исполнения макроса, ведь они могут исполняются по ходу компиляции тысячи, а то и десятки тысяч раз. Конечно можно было "красиво" и по простому — макрос работает как текстуальный. Только вот никаких приличных сообщений об ошибке он вывести не сможет, вывести типы выражений не сможет, в половине случаев будет выдавать абсолютно некорректный код(и выяснить это можно будет только на этапе компиляции самой программы, а не макроса) и все это дело при таком количество встроенных макросов как в Nemerle будет жутко тормозить.
Я больше скажу — не такая уж проблема полностью текстуально генерировать код в Nemerle, а затем парсить его(благо компилятор под боком, может и твиков в его код не придется делать) Тогда код который привел Oyster сократиться раза в два, а его надежность в три.
E>Еще одна мысль по поводу compile-time генерации vs precompile-time. В случае precompile-time можно нагенерировать обычный класс с комментариями. Он может быть обработан инструментом типа javadoc и программисту будет предоставлена документация о том, что в TestClass кроме prop1 и prop2 будут еще геттеры-сеттеры. А вот такой DSL как документировать?
Хороший вопрос. В Nemerle встроенная поддержка xml документации как и в C#. Я думаю простейшую информацию о сгенерированном типе он в xml скорее всего выводит. С xml комментариями наверное будет проблема, т.к. разработчики об этом даже не думали. Но я внимательно посмотрел исходники компилятора и с ходу придумал как это можно добавить. Так что технически это не проблема.
Re[26]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, eao197, Вы писали:
E>Интересно получилось.
E>Только вот о вкусах, конечно, можно спорить, но мне этот код красивым не показался. В особенности <[ и ]> -- путаюсь к чему что относится. Вспоминаются слова классика
E>То что технически грамотно должно быть как минимум красиво.
E>
Ты прав — о вкусах не спорят. Ну а к <[ и ]> можно привыкнуть — не сильно страшнее скобочек в шаблонах C++. Потом, ты же привык к тому, что надо писать "> > >", а не ">>>", например. Зато оцени, как красиво и элегантно описывается кусок AST — фактически ты пишешь код на Nemerle, только внутри этих самых скобочек. А возможности какие — такое шаблонам и не снилось!
Кстати, этот корявый код (надеюсь, со временем будет получаться лучше) я налабал чуть больше, чем за час. При этом надо учитывать, что:
Это был мой второй макрос на Nemerle. Первый считал факториал в compile-time, и писал я его тоже около часа
У меня нет никакого опыта функционального программирования — разве что читал на RSDN — поэтому паттерн-матчинг, вывод типов, туплы и списки я юзал чисто интуитивно и прыгая по граблям.
Большую часть времени заняло чтение онлайн-документации и сборок рефлектором, а не написание собственно кода.
Это говорит о том, что порог вхождения действительно низок. Что может способствовать популяризации языка.
Вообще у меня впечатления от кодинга остались самые что ни на есть положительные — чувствуется мощь, элегантность и простота чуть ли не в каждой строчке (может и переборщил чуток, но мощь точно). Даже страшно себе представить, как бы выглядел такой код на Reflection.Emit. Точнее, даже представлять не хочется
E>Еще одна мысль по поводу compile-time генерации vs precompile-time. В случае precompile-time можно нагенерировать обычный класс с комментариями. Он может быть обработан инструментом типа javadoc и программисту будет предоставлена документация о том, что в TestClass кроме prop1 и prop2 будут еще геттеры-сеттеры. А вот такой DSL как документировать?
Да ты просто задокументируй сам макрос — делов то. Всё равно дока будет автоматом сгенерирована и полезной информации в ней будет мало. Мне, кстати, генерация в compile-time гораздо больше нравится — нет никакой возни с поддержкой кода, сгенерированного в precompile-time (класть/не класть в VSS/CVS/SVN, как следить за тем, чтобы никто ничего не модифицировал и т.д.).
Ну а вообще меня в этой связи интересует другой интересный вопрос — а можно ли как-то из куска AST получить код на Nemerle? Типа "распечатать" AST. По идее, даже если стандартная библиотека такой фичи не содержит, это получится дописать самому. Тогда можно в макросе не делать класс, а строить AST класса и выводить его в файл или что-то вроде того. И автокомментарии можно добавить (тут бы не помешало, если бы AST содержал ноды комментариев ).
Re[18]: Снова о Nemerle или профанация не пройдет :)
СТ>Ну, положим, от ошибки неверного формата (кстати, имеет ли это место быть в случае ToString()) этот макрос не спасет. Он всего лишь делает запись короче и не позволяет ошибиться с циферками в скобочках. Всё. После его прохода у компилятора оказывается примерно вот что:.
Как же не спасет, если формата просто нет?! Ты подставляешь имена переменных которые контролируются в во время компиляции. Я кстати, совершенно случайно ошибся когда писал код и мой пример уже неверный!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, little_alex, Вы писали:
_>Если не секрет, что там смешного
Таварщи программируют на Блабле и стало быть оценивают другие языки с его уровнея. Это не позволяет им оценить приемущества более мощьного языка (с) орла что успешно продал Яху. Вот мы и дожили когда Блаблом стал Лисп, и лисп-программисты стали блабл-программистами смеющимися над тем, что не в силах понять.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Снова о Nemerle или профанация не пройдет :)