Здравствуйте, Oyster, Вы писали:
AVK>>Я уже говорил — для кодогенерации в деплойменте. Еще для настройки O/R Mapper, для автоматического формирования GUI, для привнесения автоматики в ряд стандартных алгоритмов и т.д. Много где, всего и не упомнишь.
O>Ну я понял, в общем. Для того дизайна, что имеется сейчас, Nemerle пролетает.
Да все нормально. Он после генерации исходников на ХСЛТ тоже их компилирует. Ну, будет компилировать Нэмерл, а не C#. Какая разница?
А реализовать чтение модели из ХМЛ — это не проблема.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
O>>Ну я понял, в общем. Для того дизайна, что имеется сейчас, Nemerle пролетает.
VD>Да все нормально. Он после генерации исходников на ХСЛТ тоже их компилирует. Ну, будет компилировать Нэмерл, а не C#. Какая разница?
VD>А реализовать чтение модели из ХМЛ — это не проблема.
Но надо ли... Т.е. тут от Nemerle будет небольшая подмога имхо.
Re[42]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>То есть нужно создать обертку над методом Nemerle.Compiler.PrettyPrint.PrintExpr()? VD>ОК, попробую.
Кстати, да. Я сначала подумал, что Nemerle.Macros.ImplicitCTX() это макрос и должен вызываться по месту, но потом вспомнил, что сам-то он изначально юзается в другом макросе (pretty_print_expr), так что проблем с выделением в отдельную функцию вроде быть не должно.
Здравствуйте, Oyster, Вы писали:
O>Было бы неплохо имхо. По крайней мере, повеселее чем Reflection.Emit и всякие там CodeDom.
В общем, то мне и сейчас никто не мешат нагенерировать код и скомпилировать его в рантайме. Но тут смысл в том, что для его генерации можно будет пользоваться не низкоуровневыми интерфейсами вроде эмита, и не ужасной текстовой конкатинацией, а теми же механизмами которые исползуются в компайлтайм-кодогенерации сейчас.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
VD>>А реализовать чтение модели из ХМЛ — это не проблема.
O>Но надо ли... Т.е. тут от Nemerle будет небольшая подмога имхо.
Ты ты погляди на этот ужас что присуствует в ХСЛТ? Если объем увеличится, то это будет хаос.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Снова о Nemerle или профанация не пройдет :)
Похоже этот проект мертв. Исходники датируются 2004 годом и содержат старый синтаксис дженериков (с <> вместо []). К тому же это похоже LALR-парсер созданный по стандартной схеме (не как макрос), что представляет мало интереса.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
O>>Но надо ли... Т.е. тут от Nemerle будет небольшая подмога имхо.
VD>Ты ты погляди на этот ужас что присуствует в ХСЛТ? Если объем увеличится, то это будет хаос.
Знаешь, я думаю, что впихнуть использование Nemerle в уже существующий дизайцн будет тяжко... Вот в случае разработки подобного вновь уже можно будет учитывать факт присутствия Nemerle на арене
Re[23]: Снова о Nemerle или профанация не пройдет :)
Ты правильно сделал, что поставил смайлик напротив SDK\...\Samples\clisp, надеюсь это от того, что ты все-таки заглянул туда и посмотрел на то, что там лежит.
Насчет остального — списочек маловат, у меня в несколько раз поболе будет, но картина от этого не меняется. Есть стандарт, скажем, на Схему. Есть несколько замечательных реализаций на С/С++ (гнутая в т.ч.), есть даже одна неплохая реализация для Java (остальные для Java опять же — слишком неполно реализовали стандарт, по-сути тянут на чьи-то несерьезные эксперименты). Так вот, для дотнета НЕТ НИ ОДНОГО проекта, который бы реализовал стандарт R5SR (текущий стандарт Схемы).
Переходим к Лиспу... (Хотя, Схема мне импонирует больше).
В мире Лиспа есть CommonLisp. И куча его совместимых реализаций, т.е. не тулько гнутая. Это означает, что программы на Лиспе можно распространять хотя бы в исходниках. Для дотнета НЕТ ПОДОБНОЙ РЕАЛИЗАЦИИ.
Особенность CommonLisp-а в том, что для того, чтобы его реализовать, ядро Лисп-системы должно имплементировать совсем небольшой список возможностей, все остальные либы и стандартные процедуры Лиспа затем уже пишуться на самом Лиспе, начиная от этих самых тривиальных процедур ядра. Понимаешь теперь, о чем речь? Все эти реализации не предоставляют достаточный список даже базовых возможностей. О диалекте речь не идет, ибо диалекты Лиспа в основном отличаются набором "стандартных" процедур. Т.е., взяв некое самодостаточное ядро Лиспа, на нем можно накатать кучу диалектов.
Но это не вся проблема. Проблема в непонимании того, как системы типа Лиспа должны использовать VM.Net для получения приемлимой эффективности. Я видел только один (!!!) проект, в котором разработчики подошли к этому вопросу грамотно (компилятор Схемы пишут). Проект очень неплох, но еще очень сырой. К тому же, у них основной упор — это использование Майкрософтного оптимизирующего бакенда компилятора ("феникс" вроде) для построения оптимизирующего компилятора Схемы. интерпретатор в их системе даже и не планируется. А для меня этот пункт — самый важный.
Вот такое положение дел пока. Я уверен, что через пару лет кое-что может измениться, но пока именно так.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[41]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
O>Знаешь, я думаю, что впихнуть использование Nemerle в уже существующий дизайцн будет тяжко... Вот в случае разработки подобного вновь уже можно будет учитывать факт присутствия Nemerle на арене
Не сомненно. Но АВК поднимал вопрос отндь не с целью избавиться от ХСЛТ. Это был аргумент в пенесометрическом споре.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>За штуку баксов (на спор) я готов написать реализацию хэш-таблицы на T-SQL. Если не страшно можешь поставить свою штуку против моей?
Готов посудействовать за 25%. Ну что бы всё было честно
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VladD2, Вы писали:
VD>>Если серьезно, Нэмереловцы работают над рантайм-кодогенерацией.
IT>Зачем её делать? Она уже сделана майкрософтом.
МС сделали базис. Нэмереловцы делают надстройку.
VD>>Но лично мне за глаза хватило бы компайл-тайм решений.
IT>Тем более, что у run-time кодогенерации нет практически ни одного более менее серьёзного преимущества перед compile-time. Всё это от безисходности.
Есть:
1. Можно учитывать особенности данных информация о которых появляется только в рантайме.
2. Можно перегененировать код в зависимост от изменяющейся ситуации.
Обе этих возможности выходят за пределы современной реальности но через много лет они тоже будут востребованны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>МС сделали базис. Нэмереловцы делают надстройку.
Они это делают в рамках разработки компилятора?
VD>Обе этих возможности выходят за пределы современной реальности но через много лет они тоже будут востребованны.
Ну ты блин сказанул Сейчас для многих и compile-time генерация выходит за пределы современной реальности
А если без смеха, то хотелось бы услышать хотя бы гепотетически реальный пример, не высосанный из пальца.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, vdimas, Вы писали:
V>Не Лиспу, а мне, то бишь девелоперу. Машина Лиспа представляет из себя практически идеальный механизм построения эффективных интерпретаторов.
В каком смыле эффективных? В смысле скорости работы? Сомневаюсь, если в конечном итоге код интерпретатора не будет компилироваться в тот же MSIL.
V>Мне нужно именно последнее, плюс возможность использовать этот интерпретатор в дотнете (не обязательно с Лиспа, почитай ниже мой ответ eao197).
Я почитал, но, ИМХО, это неудачное использование Lisp. Я думаю, что лучше было бы генерировать Lisp-машиной исходный текст интерпретатора, который потом скармливать тому же C# и деплоить сборку с готовым к употреблению интепретатором. Даже лучше будет, если учесть, что таким образом ты избавляешься, как минимум, от необходимости писать собственный отладчик Lisp-а, заниматься вопросами интеграции самой Lisp-машины с .Net и решать проблемы с незащищённостью Lisp-кода.
Что до концепции ограниченного окружения, так никто же не запрещает ограничить в целевом языке набор разрешённых имён сборок/объектов/методов и т.п.
Притом обрати внимание, если ты озабочен защитой интерпретатора и среды исполнения от несанкционированого воздействия/чтения и т.п., то всё равно придёшь к необходимости генерировать объектный код в том или ином виде. Результат можно выдать в виде асссемблера или квазиассемблера. Prolog и Lisp одно время модно было компилировать в C, поскольку этих компиляторов везде предостаточно. А чем будет генерироваться такой код, совершенно неважно. Это может сделать и написаный тобой .Net-Лисп, и, скажем, Common Lisp, поскольку тут главная проблема — переложить Лисповские выверты вроде самомодификации программы (ещё точнее — игрища с eval/apply) на семантику целевой машины. Кстати, AFAIK, компиляторы Lisp так и поступают — при подозрении на самомодификацию программы просто пихают вместе с объектным кодом исходники на Лиспе или сам компилятор. Какой-то из ранних Lisp-ов некоторые программы вообще не мог компилировать.
Да и вообще, лучше сначала с самим языком "для бухгалтеров" определиться, бо здесь можно наступить на грабли с большими, тяжелыми и остро заточенными ручками. Такие аспекты, как синтаксис, грамматика и семантика языка по-любому придётся прорабатывать — и в случае DSL, интепретирумого Lisp-ом, и в случае, описанном мной.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[35]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали: VD>Ненужны для реализации хэш-таблиц никакие внешние модули. T-SQL — это полноценный императивный язык. Единственная его проблема — это ограничение на рекурсию в процедурах. Но это не является фатальной проблемой. На многих языках (если не ошибаюсь даже на Фортране) тоже первое время нельзя было делать рекурсию. Но писать программы это не мешало.
Извини, Влад, но все-таки — не вполне. В нем нет поддержки никаких динамических структур: нет ни массивов, ни указателей. Это означает невозможность реализовать контейнер. Поэтому ни о каких хеш-таблицах, деревьях, или списках речь на нем идти не может. И это не зависит от того, сколько и кому заплатить. Так что это "полуимперативный" язык: управляющие конструкции для записи алгоритмов в него ввели (ветвления и циклы), а структурные данные — нет.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Если нам не помогут, то мы тоже никого не пощадим.
1.1.4 stable rev. 510
