Здравствуйте, VladD2, Вы писали:
VD>Авторы тяготеют к функциональщике. Функциональщика к неизменяемым объектам. Так что не судренно, что по умолчанию самая простая запись для неизменяемых свойств. Для них она проста и логична:
А если я хочу атрибут навесить на геттер? Упс?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Дарней, Вы писали:
IT>>Всё так. Осталось только это растолковать интеграции VSS с VS.
Д>можно один раз добавить эти файлы в VSS, затем удалить, но не делать purge
Согласен, это решение. Редкостной извращённости, но решение.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Документация не самое страшное. А вот если понадобится сгенерить SQL или какой нибудь WSDL, то тут уже придется задуматься. WH>>Дык эта... макросы могут делать что угодно... и к базе приконектиться и в фаил писать...
AVK>В момент компиляции? А нафига?
Чтобы докладать количество сгенерированных строк манагеру.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[33]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали: VD>Хм. И даже если я пишу утилиту командной строки для собственных целей?
Влад, твои утилиты командной строки никому не интересны. Кроме тебя же самого. Меня интересует разработка для заказчика, а не для меня. VD>И что мне помешает сделать такой макрос?
Я не знаю. Я пока вообще немерле не смотрел — у меня linq то проверить времени нету. VD>Ну, а зачем номер?
Чтобы в другом порядке можно было аргументы поставить. VD>И что значи в дотнете? Нэмерл тоже дотнет, но в нем я волен оперировать именами переменных из текущей области видимости.
VD>И чем, раскажи на милость, это отличается от: VD>
В итоге person (бизнес-данные) берется из одного места, а формат (презентация) — из другого. Например, из автоматически выбранной по текущей культуре сателлитной сборки. VD>Хотя конечно можно сделать макрос который и такое разрулит. Вот только надо ли?
Еще раз: придумай, как решить проблему локализации. Это было бы очень круто. А возможность слеплять строчки малоинтересна, т.к. она не дает ничего нового по сравнению с:
"Имя: "+name+"Фамилия: "+lastname;
Особенно заметно это станет, если ты попробуешь при помощи своего макроса вывести что-то без пробелов. Что-то мне подсказывает, что парсер споткнется на этом:
$"Имя:$nameФамилия:$lastname"
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Воронков Василий, Вы писали: ВВ>А что, на макросах нельзя хорошо написать библиотеку? ВВ>Да если даже и так — что в этом удивительного? Мало ты что ли видел важного/нужного АПИ, которое в то же время было плохо спроектировано?
Из заменяемого — мало. ВинАПИ имеет то "преимущество", что его невозможно выкинуть и заменить. В общем, мне кажется, что ты будешь выбирать ту библиотеку, которая хорошая. Плохая — нафиг не нужна по очевидным причинам, а хорошую вряд ли напишут люди, которые просто хотели другой формы записи. Тем более вряд ли в проект попадут прямо десятки таких уродцев. "Я вчера случайно в шестой раз перечитал вашу книгу и опять плевался".
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, IT, Вы писали:
IT>А если я хочу атрибут навесить на геттер? Упс?
Значит обяви свойство явно. Или создай свой метаатрибут который навесит что захочешь.
Надо правильно понимать метаатрибуты. Это возможность задать некоторые паттерны декларативно. Именно паттерны! Если у тебя свой паттерн, то или вазись вручную, или создай свой метаатрибут описывающий этот паттрн.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
IT>>А если я хочу атрибут навесить на геттер? Упс?
VD>Значит обяви свойство явно. Или создай свой метаатрибут который навесит что захочешь.
Боюсь, этим скорее всго и закончится.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
// Сначала получаю объявление класса без полей.
// Тут typedecl типа Nemerle.Compiler.Parsetree.ClassMember+TypeDeclaration
def typedecl = <[ decl: [Record] public class $(className.ToString() : usesite) {} ]>;
// Потом создаю новый typedecl, но в качестве списка чайлдовых ClassMember-ов
// указываю список полей, полученный на предыдущем шаге.
// Остальные свойства остаются такими же
def newTopdecl = TopDeclaration.Class(
typedecl.Location,
typedecl.name,
typedecl.modifiers,
typedecl.td.typarms,
(typedecl.td :> TopDeclaration.Class).t_extends,
code.Reverse()); // вот он - список полей
def newTypedecl = ClassMember.TypeDeclaration(
typedecl.Location,
typedecl.name,
typedecl.modifiers,
newTopdecl);
// И в конце передаю объявление класса уже с полями в Define()
def builder = ctx.Env.Define(newTypedecl);
builder.Compile();
А сделано всё это так "императивненько" потому, что другого, более красивого способа, я не нашёл. Ну а код активации с их форума ещё не пришёл почему-то
Re[26]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, AndrewVK, Вы писали:
AVK>Никоим образом не хочу преуменьшать важность и значимость подхода, который ты привел, но в реальном приложении, из которого взят пример, такой подход не годится. Во-первых там нужна метаинформация в рантайме, для чего xml подцепляется в скомпилированную сборку в виде ресурса. Причем рефлекшен по сгенеренному классу здесь не прокатит, потому что далеко не все, что содержится в метаинформации, используется при генерации исходников. Во-вторых, что еще печальнее, часть кодогенерации выполняется не на этапе компиляции, а на этапе деплоймента, и перенести ее на этап компиляции нельзя, потому что в этом случае используется специфика платформы, в которой производится процедура, на этапе компиляции неизвестная принципиально.
Да я всё понимаю. Я для себя рассматривал эту задачу как пример написания макроса. Опять же, я уже вроде говорил, но повторюсь — мы можем написать функцию, которая возвращает AST. Т.е. делать это из XML на этапе выполнения, но всё равно используя преимущества <[ ]>
Re[22]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, vdimas, Вы писали:
O>>Имхо один из ключевых недостатков Форта — необходимость постоянно держать стек в мозгу при кодировании (на Форте почти всегда приходится писать состояние стека после операции в комментах к операции, чтобы не запутаться).
V>Это одна из причин быстродействия Форта. Посмотри в отладчике ассемблерный код, либо С++ либо дотнетный, где производятся цепочки вызовов методов. Да там около половины кода — это тасовка значений м/у регистрами. Программы на Форте (хорошие программы) от этого избавленны, ибо в хороших программах на Форте практически нет лишних перетасовок данных. Твои слова должны располагаться в таком порядке и иметь такую стековую нотацию, чтобы для вызова следующих слов не нужно было тасовать данные... В общем, это своего рода Дао, типа процесса ручной разводки плат.
Да, тут я согласен. Производительность выше из-за того, что стек используется оптимальней. Но проблема, которую я написал выше, никуды не девается.
Re[32]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>Хм. "Этот" код не простой. Мы ведь не использовали TopDeclaration.Class(). Может так и прокатит. Сейчас попробую... VD>Попробовал. Твой код работат. Но он совсем дургой.
Он простой. Просто надо было докопаться до того, как всунуть список полей в объявление класса — всего и делов Это можно вынести во внешнюю функцию один раз и юзать всегда (если лучшего решения нет).
VD>Ты бы, кстати, объяснил его смысл. Почему ты пришел к такому решению?
Здравствуйте, VladD2, Вы писали:
VD>Хм. Динамически компилировать генерируемый код только для того, чтобы один раз его выполнить? А будет ли это быстрее интерпретации?
Классичесский Лисп — это и не компилятор и не интерпретатор в майнстримовом понимании. По мне — это скорее компилятор, но компилятор не в нативный или там байт-код, а в Pair(Cons)-списки данных. Тело процедуры — это цепочка Лисп-объектов, т.е. данные, и эти данные выполняются (в терминах Лиспа — вычисляются). Базовые примитивы Лисп-машины написаны обычно на некоем языке, близком к машинному (С/С++/С#), а весь остальной Лисп — это именно в таком виде скомпилированные процедуры, символы и атомы. Оптимизирующие компиляторы Схемы потому и могут генерировать оптимизированный код, что во время исполнения доступны тела процедур.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, WinniePoh, Вы писали:
WP>>> Возможно всё. Из Лиспа сделать Nemerle тривиально. Из Nemerle сделать Лисп тривиально.
VD>>Тривильно? Ну, так сделай. Если получится, я с удовольствием на нем по программирую. А делать Нэмерл из Лиспа лично я не хочу. Это огномный труд, а не тривильное занятие.
WP> Да ничего огромного. Семантика Немерля довольно примитивная, все алгоритмы — простые и хорошо известные.
Давайте лучше Лисп (а еще лучше — Схему) для дотнет напишем. А то все то, что есть на сегодняшний момент для дотнет немного сыро и криво. А задача эта на порядок проще того же Януса. Официальная спецификация Схемы есть, она очень небольшая (в сравнении со спецификациями других используемых мною языков)
Заготовки у меня кое-какие уже есть, и даже немного работают, определяются и работают процедуры. Дошел до special forms (это основа макросов, define-ов, и пр., сам синтаксис определения макро — это лишь макрос), но после Нового года не было вообще свободного времени.
Зачем это надо?
1. Для задач, где требуется не эмуляция, а реальный скриптинг. Т.е. например мы можем в одном домене дотнета прогонять запросы на вычисления сотен и тысяч разных процедур, модифицировать процедуры, загружать заново и так до бесконечности без побочного эффекта "засорения" домена. Ведь дотнет не поддерживает выгрузки программ. А вся среда Лиспа/Схемы — это данные.
2. Очень неплохая скорость вычислений. Да и скорость компиляции тоже потрясающая. На Лиспе даже можно будет заниматься прорисовкой графики контролов, вполне должно сносно работать. В интерпретируемом варианте на каждый шаг программы мы имеем потери ценой примерно в одно приведение типов + один виртуальный вызов + один if. Для вызова процедур + еще один. В общем, шустро.
3. Всякие ОС типа Сингулярити на подходе. В процессы этой ОС невозможно будет подгружать код, только данные. Лисп машина подходит идеально. по скорости должна будет с большим отрывом дрючить плагины, выполненные как отдельные SIP-ы. Для реализации всяких бухгалтерских и пр. бизнес-систем — незаменимое качество.
4. Механизм Лисп-машины можно использовать как бэк-энд для других скриптовых нужд. Например прямо сейчас заканчиваю парсер ОБЫЧНЫХ (не в Лисповой нотации) выражений для некоего веб-сайта. Эти выражения редактируются из браузера, затем компилятся в структуры Лисп-машины на стороне сервака, и затем запускаются для выполнения расчетов над приличными объемами данных (под гиг).
5. Очень прост сам способ расширения функциональности Лисп-машины. Публичные статические методы любого класса внешних сборок нетрудно добавить в среду, и они будуи использоваться наряду с "обычными" лисповыми. (Собственно, разработка и началась с поиска этих способов, именно так реализованы базовые примитивы)
Т.е. сама по себе Лисп-машина уже будет являться неплохой платформой для произвольного скриптового языка (опять же, например некий C# или VB.Net-подобный скриптовый язык для бухгалтерских программ)
Какие еще есть коссвенные преимущества:
6. Управляемость и надежность. Мне страшно давать в руки бухгалтера какой-нить JavaScript.Net, потому как он сможет написать программу, которая подключает внешние сборки, которые могут предоставлять абсолютно произвольные возможности навредить компьютеру, программной системе и нервам разработчиков. Напротив в Лисп/Схеме существует понятие "окружение". Этим окруженим можно управлять как угодно (имеется в виду не из Лиспа, а из хост-системы), формировать ограниченный список доступных процедур, например. Т.е. вообще для каждого прикладного объекта можно было бы подавать заточенное именно на "местные" нужды окружение, которое не позволит написать потенциально опасные куски в бухгалтерских программах.
Не знаю, насколько далеко зайдет этот Немерле, но уделать 10 000 индусов не откажусь!
(в принципе, может зайти далеко, в MS есть открытый проект оптимизирующего бэк-энда компиляторов для дотнета, насколько я понял Nemerle пока его не юзает, но теоретически ничего не мешает)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Снова о Nemerle или профанация не пройдет :)
Если нам не помогут, то мы тоже никого не пощадим.
1.1.4 stable rev. 510
