Когда требуется использование сохранённых процедур (например, из-за требований безопасности), то у нас вводится ещё один слой и на каждый запрос пишется SQL скрипт с процедурой. С макросами можно оставаться в тем же самым кодом как и без сохранённых процедур, только вместо SQL генерировать саму сохранённую процедуру во время компиляции. Т.е. издержки на написание СП можно полностью устранить.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, AndrewVK, Вы писали:
AVK>Вог-первых не идет, я, кажется, кому то уже демонстрировал. Во-вторых декларативный синтаксис линка далеко не самая важная его часть. И использование функциональной формы записи совсем не означает "обычной императивщины".
Ну давай это назовём "обычной императивщиной и функциональщиной". Какая разница?
AVK>Но можно и промежуточный провайдер написать, который будет автоматом сворачивать ET, а потом передавать его Linq2SQL. Тогда можно будет просто декларативно писать полный запрос, а он потом свернется до необходимого.
Здравствуйте, mkizub, Вы писали:
M>Это на каком основании такое утверждение?
Извини, погорячился. Понимай это фразу в контексте, мол, "хорошо, пусть макросы -- лучшее для... тогда ..."
Не об этом разговор.
M>Самым мощным средством является непосредственная трансформация AST. Это что-то вроде ассемблера для расширяемого языка/компилятора.
Чем макрос отличается? Он же тоже работает с AST, нет?
M>Есть другие способы задания правил трансформации, макросы — один из них, и не более того.
Это само собой.
M>Нет, нельзя, ибо генерируемый код и правила генерации являются чисто project-specific. M>Если же под "более мощным" понимать язык, в который пихают всякий специфический мусор — то PL/1 покажется стройным и простым
Так трудно спорить. Почвы нет. Не можешь привести примеры project-specific генерируемого кода, т.е. вот столько нагенерили, отличия у них вот такие то?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[35]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Klapaucius, Вы писали:
G>>Классику надо знать, даже если это такое дерьмо как бейсик. K>Неужели? В таком случае учите матчать. Я все понимаю, эрудиция это всегда поверхностное знание, но нужно учитывать опасность столкнуться с эрудитом у которого знание в данной конкретной области несколько менее поверхностное.
Это не "эрудиция", это плохая память, коллега . Все-таки, в 31 год тяжело вспомнить детали угребищного языка, на котором писал много, но в школе. Я с тех пор настолько много чему научился, что мне не стыдно забыть $ перед строковой переменной, а смешно .
Однако, что такое динамическая и статическая типизация я помню хорошо. Отличие между ними, мой хорошо эрудированный и плохо знающий матчасть коллега, состоит не в полиморфизме, а в том, в какой момент проверяются типы. До выполнения (статически) или во время выполнения (динамически). Все бейсики, как интерпретируемые языки, кроме некоторых исключений-компиляторов, проверяли типы в динамике... И это соврешенно не важно, что переменная $String не полиморфна. Это уже второй вопрос — ответ на который также прост — нет в бейсике составных данных и сложных структур данных — как в фортране, потому и от полиморфных переменных толку немного.
Re[43]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
M>>Самым мощным средством является непосредственная трансформация AST. Это что-то вроде ассемблера для расширяемого языка/компилятора.
L>Чем макрос отличается? Он же тоже работает с AST, нет?
Макрос — это "декларативное" описание изменений, а ещё AST можно трансформировать императивно, напрямую создавая и меняя узлы.
А ещё есть AOP, тоже декларативное описание изменений, но в другом виде.
M>>Нет, нельзя, ибо генерируемый код и правила генерации являются чисто project-specific. M>>Если же под "более мощным" понимать язык, в который пихают всякий специфический мусор — то PL/1 покажется стройным и простым
L>Так трудно спорить. Почвы нет. Не можешь привести примеры project-specific генерируемого кода, т.е. вот столько нагенерили, отличия у них вот такие то?
Здравствуйте, Gaperton, Вы писали:
G>Надо же, прищучили. Действительно, во всех диалектах надо для строк писать $F. Эх, стареем . Однако, для чисел это не так. Префиксы не обязательны, более того, многие диалекты не поддерживали префиксы ! и % вовсе — например, спектрумовский бейсик.
Многие диалекты не поддерживали постфиксы ! и % (и, кажется, там ещё что-то было) потому, что в них не было соотв. типов. Например, в спектрумовском бэйсике было всего два базовых типа — single и string. Не было даже целочисленных переменных.
G>Второе — никакого контроля типов при "компиляции" бейсики не делают — не было в них компиляции, они по большей части выполняют проверку типа в динамике. А это и есть динамическая типизация, позднее связывание, и т.д. При динамической типизации у тебя на выполнении выскочит несоответствие типа, и это нормально. Типизация то сильная, хоть и динамическая.
Таким же макаром я могу доказать, что и Хаскель — динамически типизированный. А всего-то и нужно, что написать интерпретатор, который не проверяет типы заранее, а добавляет метки типов ко всем объектам. Ах да, забыл, это даст нехороший побочный эффект! Все функции станут обладать свойством "type polymorphism"! Ну ничего, можно и этот недостаток залатать, если подумать как.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[44]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, mkizub, Вы писали:
M>Макрос — это "декларативное" описание изменений, а ещё AST можно трансформировать императивно, напрямую создавая и меняя узлы.
Вовсе необязательно. Макрос -- это то же код, какая разница декларативный он или императивный. Или я не о том?
M>Вот тут немного об этом написал M>http://www.rsdn.ru/Forum/message/2611455.aspx
Осталось дать ссылку не главный пункт сдачи металлолома и на исходную (вроде бы) статью по этой тематике. В ней за давностью лет (2003 год) вместо стандартного класса типов Data из модуля Data.Generics.Basics используется класс типов Term.
Re[45]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
M>>Макрос — это "декларативное" описание изменений, а ещё AST можно трансформировать императивно, напрямую создавая и меняя узлы.
L>Вовсе необязательно. Макрос -- это то же код, какая разница декларативный он или императивный. Или я не о том?
это же декларация (как данные для некоего кода, который с ними будет работать). А вот
macro for (init, cond, change, body)
{
Label lbl_cont = new Label();
Label lbl_check = new Label();
Label lbl_break = new Label();
return new Block(
init,
new Goto(lbl_check),
lbl_cont,
body,
change,
lbl_check,
new IfElse(
cond, // condition
new Goto(lbl_cont), // then
null // else
),
lbl_break
)
}
это императивщина, поскольку последовательность операций.
Процедурный подход безусловно мощнее, поскольку декларативный ограничен набором известных ему операций. Но он же и более тяжёлый в написании и понимании. Что-то более сложное на нём практически невозможно изобразить. Мне кажется, компилятор должен иметь оба этих интерфейса к преобразованию AST, точнее — декларативный можно изобразить как некий плагин к компилятору (если понимать под плагином некий пользовательский код, который делает трансформацию AST), тогда в компилятор можно вставить несколько разных систем описания трансформации (используя квотинг, или как это описывается в AOP, или это будет некий embedded DSL вроде logic engine в SymADE и так далее).
L>Э-э-э не понял. Это же мой пост
Впрочем, мне не особенно интересно участвовать во флейме по BASIC. Того что он начнется я вообще не ожидал. А вот еще один индустриальный динамический язык я все же забыл упомянуть. Erlang.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[32]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
K>>Казалось бы, если индустрия так хорошо все это опробировала, то можно ведь привести ссылки на исследования. Тот же Gaperton любит приводить исследования, в которых с точностью до процента высчитывается превосходство Erlang над C++ по всем возможным показателям. G>Это, мягко говоря, преувеличение. А называя вещи своими именами — ложь и подтасовка.
Это гипербола. Стилистическая фигура речи — в тексте с сатирическим уклоном вполне уместна. Но, если мои слова Вас обидели, я приношу свои извинения.
G>Я никогда не ищу того, что мне не интересно, уважаемый Клапауций — просто ради того, чтобы дать вам ссылку.
Весьма похвально.
G>Знаю я, как обходятся с хорошими ссылками в РСДН-овских флеймах. Я даю те ссылки, которые я знаю, потому что я их читал, и они мне показались интересными. Тема макросов мне не интересна совершенно,
Это заметно. Ваша активность в данной ветке и некоторых других ветках сходной тематики не оставляет никаких сомнений в этом.
G>и тратить время на поиск исследований (т.е. фактически провести самому первичное исследование темы), только ради того, чтобы "прогрессивная общественность" морщила нос — я не хочу
Это Ваше право. Неотчуждаемое.
G>(все равно читать не будете, упретесь и начнете изворачиваться и терминами жонглировать — вы собственно уже начали в этой подветке).
Это, мягко говоря, преувеличение. А называя вещи своими именами — ложь и подтасовка.
G>Извините — эта мотивация слабовата для меня.
Тем не менее, охотно извиняю.
K>>Но нет. Он рассказывает про какие-то макроассемблеры, которые не только не родственники, но и не однофамильцы.
G>Макроассемблеры — не то что родственники — они имеют прямейшее отношение к современным макросистемам. Ваши тезисы, что мол это совершенно разные вещи, потому что мол там AST нет — в лучшем случае странно, в худшем — смешно. Это тоже самое, что утверждать, что самолеты с поршневыми двигателями — это никакие не самолеты вовсе, потому что у них видите ли нет сопла. Можно подумать, они не летают вовсе.
Вообще-то свойства системы (а значит и ее сильные и слабые стороны) зависят не только от того, что система делает, но и от того, как она это делает. В некоторых случаях системы делающие одно и то же могут быть сходными и по принципу своего действия — это конвергенция — но так бывает далеко не всегда.
Чтобы небыло обвинений в притянутых за уши аналогиях использую Ваш же пример с самолетами. То, что и самолеты с ДВС и реактивные летают — еще не означает, что у них одинаковые преимущества и недостатки. Значительная часть их качеств, имеющих значение при эксплуатации как раз и определяется тем, реактивный у них двигатель или нет.
G>Вот, взять макроассемблеры. Какое к черту AST в ассемблере?! Какие типы вы нашли в ассемблере? Вы знаете, как транслятор ассемблера устроен? Думаете, там AST анализируется и типы выводятся? Там простые табличные проверки и разбор лексем. Нет там никаких типов и AST, поэтому их нет и в макросистеме.
Вот видите, Вы и сами понимаете, что макроассемблер и макросистема, оперирующая типизированным AST совершенно разные вещи.
K>> Все дело в том, что таким исследованиям неоткуда взяться. Самый дальний родственник нынешнего Template Haskell и Nemerle — это, наверное, MetaML — а по нему и статей старее 1998-го года нет. Мне, как физику, совершенно непонятно, как могут плоды исследования 1998-го года быть опробированы в 1970-м. G>Вам как физику может быть вообще многое непонятно, так же как например мне, получившему образование computer science & applied math не понятны вопросы биологии и химии. То, что вам что-то непонятно — не может являться ни аргументом, ни серьезным вызовом computer science.
Позвольте несогласиться с Вами. Возможность опробировать методику за треть столетия до появления первых научных работ, в которых она разрабатывается это серьезный вызов скорее физике, а не computer science.
G>
G>- Жгут и убивают СС — а мы солдаты, мы воюем.
G>- А что, изобрели какой-нибудь новый способ воевать — без убийств и бомбежек?
G>(17 мгновений весны, диалог Штирлица и пьяного генерала в поезде)
Цель бомбометания — уничтожение военных объектов. Это то, зачем бомбометание производится.
Побочный эффект — гибель мирного населения. Потери мирного населения определяются в основном методикой бомбометания и ТТХ боеприпасов.
Цель метапрограммирования — уменьшение объема кода.
Побочные эффекты разной степени катастрофичности также зависят в основном не от цели, а от технической реализации и дизайна.
G>Что, в современных исследованиях по макросам придумали что-то такое, что макросы перестали быть макросами, да? Макросы у нас теперь не задают новые ситаксические конструкции
Задавать новые синтаксические конструкции вовсе не обязательно.
G>и не генерируют код, как они делали в далеких 70-х, да?
Зло не в том, что код генерируется. Это как раз добро. Зло в том, какой код генерируется и как он генерируется. А зависит это от гигиеничности, метаязыка, доступности информации о типах, et cetera.
G>То, что при помощи паттерн-матчинга сокращается код пробежки по деревьям — НИКАК не меняет пользовательские свойства макросов.
Да, это меняет пользовательские свойства макросистемы для разарботчика макросов. И для того, кто будет поддерживать код этого макроса.
Для пользователя библиотеки макросов имеют значение, например, побочные эффекты применения макроса, которые опять таки зависят от реализации макросистемы.
G>"Исследованиям неоткуда взяться". Каким исследованиям? Исследованиям свойств Nemerle?
О том, что все опробировано говорил не я.
Я не рассчитываю на исследования применимости в индустрии Template Haskell и Nemerle. Если исследования по макросистемам для статически типизированных языков в индустрии и появятся, то я к тому времени уже буду, скорее всего, старикашкой с отвратительным характером, гипертонией и раком поджелудочной железы и эти данные для меня будут малоактуальны.
Вы лучше вот что скажите, я так понимаю, что Вам не нравится в основном изменения синтаксиса? Если так, то как Вы относитесь к тому, что в некоторых языках есть штатные средства вроде определения произвольных операторов (Prolog, Haskell, Scala...) и неявного создания замыканий как в Scala (по понятным причинам в Haskell можно и без этого обойтись)? Такие средства позволяют изменять синтаксис также как и макросы — но "гражданскими" средствами, никак особо не выделенными.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[28]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>Есть еще кое-что общее у текстовых препроцессоров и преобразований над AST, кроме названия. Сходство, которое вы, коллега, умудрились каким-то непостижимым мне образом в своем рассуждании пропустить, состоит в том, что и то и другое делает ровно одно и тоже — выполняет некоторую трансформацию кода, расширяя синтаксис и семантику базового языка. Делается это преобразованием над AST, вылавливанием и заменой регекспов, или как-то по другому — совершенно не важно ни для кого, кроме как разработчика макросов.
Я об этом написал в другом ответе. См. выше.
G>А я не проблемы разработчика макросов обсуждаю — они меня мало волнуют, я обсуждаю проблемы пользователя макросов. Это второй тонкий и не очевидный момент, который, видимо, надо подробно растолковать.
Растолкуйте.
G>Да ладно, скажите просто и честно: "я не понимаю, что и о чем пишет Гапретон, проблемы, которые он поднимает мне не понятны и не близки". Так вы, по крайней мере, избежали бы перехода на личности, плюс — точно передали бы суть дела.
Это вопрос дискуссионный.
G>Отчего же. Учитывая, что новые макросистемы делают в конечном счете то же самое, что и старые, совсем не трудно представить, какие грабли ждут энергичных "первооткрывателей" технологий 70-х годов, закрывающих глаза на здравый смысл и на опыт индустрии.
Ага. Электробритва и опасное лезвие делают совершенно одно и тоже. Разумеется, поэтому слабым местом опасного лезвия является обязательное требование доступа к источнику электрического тока, а электробритвой можно случайно зарезаться. Или наоборот?
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[39]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, FR, Вы писали:
FR>Угу зачем ведь тяжело не использовать даже if for и т. п. уж лучше на лиспе.
Одними car и cdr? Это не путь настоящих джедаев. Рекомендую попробовать программировать только с помощью S и K.
Минимальный Nemerle не так уж и жесток. Есть вся ситсема типов, PM, локальные функции и лямбды. Хвостовая рекурсия гарантированно разворачивается. Может каким-нибудь синтаксическим диабетикам это и понравилось бы.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[40]: Являются ли макросы свидетельством недостаточной выр
- А что это за шаги такие на лестнице? — спросил Коровьев, поигрывая
ложечкой в чашке с черным кофе.
— А это нас арестовывать идут, — ответил Азазелло и выпил стопочку
коньяку.
— А, ну-ну, — ответил на это Коровьев.
(с)Булгаков
GZ>>Говорить о том, что визуальность по сравнению с функциональной записью кардинально увеличилось — не приходится. IT>Ну почему же? Идея очень правильная. Как ты думаешь, зачем народ во всяких хибернейтах занимается всякими query languages? Для того, чтобы получить не просто язык запросов, а типизированный язык запросов, полностью контролируемый компилятором. Мечта! А ты говоришь не приходится.
Так и запись в функциональном виде точно так же контролируется компилятором. Мне не нравится проход компилятором, чтобы преобразовать
var a=from b in cust select c
в
var a=cust.Select(b => b.c);
вторая запись не менее визуальна чем первая. И в такой записи, запросы вполне можно собирать.
GZ>>На фоне генерации грида и работы с бд — выигрыш будет очень незначительным. IT>Точно? Проверял или сам догадался?
Нет. Догадался. В принципе точно такая же ситуация с сериализацией DataSet в FW1.1(многие обжигались). Действительно — тормоз страшный. Только если задача вызвана тем, что нужно поставлять датасеты для визуалки — все это фигня, так как действует другой принцип. Больше чем пользователю нужно увидеть и он сможет увидеть — данных не поставлять. По тому же принципу, и в вышеописанном тобою случае эта оптимизация избыточна.
IT>>>Во-вторых, несмотря на то, что вся информация о запросе у нас доступна в компайл-тайм, мы получим генерацию SQL в райн-тайм, опять же со всеми вытекающими последствиями. GZ>>Это нормально. Провайдер может быть подменен. IT>А может быть не подменён. Но жертву мы уже принесли. Да и работа с разными провайдерами может быть выполнена по разному. Например, макрос может сгенерировать SQL для разных провайдеров, в рантайм останется только проверить кто там у нас сейчас текущий провайдер.
Трансформация OQL-подобных запросов в SQL — не является ресурсоемкой задачей.
IT>>>В результате, хотя всё и выглядит зашибись, мы уже получили неустранимые проблемы. Точнее первую можно легко устранить, но за счёт отказа от анонимных типов и возврата к одноразовым типам. Второе даже не знаю, разве что написать Linq2Me и огранизовать кешироание запросов самостоятельно. GZ>>Кэширование запросов или результатов? IT>Запросов.
Опять. Трансформация OQL-подобных запросов в SQL — не является ресурсоемкой задачей.(если конечно в Microsoft не напортачили )
IT>>>Учитывая, что разница между версиями у нас 2005 — 2008, то как говорится обещанного три года ждут. GZ>>Это особенности провайдера LINQ2SQL. К макросам отношение имеет мало. IT>Какая разница. Имея свои макросы я такую проблему решу быстро и эффективно.
Если ты сможешь выйти за рамки LINQ2SQL — то безусловно.
GZ>>Линк ленив. Забудь о встроенном макросе — пиши в функциональном виде. Собрать запрос — вещь тривиальная. IT>Спасибо, дорогой. Чтобы мы делали без твоих советов? Вообще у нас тут спор о том какая декларативность лучше, такая или сякая. Ты же приходишь и говоришь — пишите императивно и будет вас счастье
А тут вопрос не декларатива/императива. Это всего лишь вопрос использования инструмента. А как ты его оформишь декларативно(с помощью макросов или без оных) или императивно — это твое личное дело.
GZ>>Ага. Посему и удивился твоему утверждению про pass-through. IT>Ты можешь мне привести неубиваемые преимущества pass-through кода?
ООП. LINQ2SQL — можно считать заменителем или хелпером для DAL. Бизнес-логику полностью на нем не сделаешь. И тут, лично мне известно где мне нужен полиморфизм, а где нет. Я вполне понимаю как структурировать код, чтобы легко и сопровождаемо можно было вносить изменения и добавлять особенности в поведение того или иного варианта использования. В случае макросов — у меня понимания нет. Есть только понимание — что всех проблем они не решат, и даже при их наличии нужно делать слой BLL. А значит что я остаюсь в той-же архитектуре, и их использование/неиспользование не играет определяещей роли. Вызов проверки секьюрити/кэширования можно и ручками везде проставить.
Re[37]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, Gaperton, Вы писали:
G>>Надо же, прищучили. Действительно, во всех диалектах надо для строк писать $F. Эх, стареем . Однако, для чисел это не так. Префиксы не обязательны, более того, многие диалекты не поддерживали префиксы ! и % вовсе — например, спектрумовский бейсик.
K>Многие диалекты не поддерживали постфиксы ! и % (и, кажется, там ещё что-то было) потому, что в них не было соотв. типов. Например, в спектрумовском бэйсике было всего два базовых типа — single и string. Не было даже целочисленных переменных.
Были там целочисленные значения у переменных, были. Плавающая запятая эмулировалась программно, и работала крайне медленно. Поэтому, интерпретатор различал целые числа и плавающие в динамике, несмотря на то, что этих постфиксов-префиксов (не помню уже) там не было. Так вел себя любой бейсик для слабых процов без аппаратной плавающей запятой, таких как Z80.
G>>Второе — никакого контроля типов при "компиляции" бейсики не делают — не было в них компиляции, они по большей части выполняют проверку типа в динамике. А это и есть динамическая типизация, позднее связывание, и т.д. При динамической типизации у тебя на выполнении выскочит несоответствие типа, и это нормально. Типизация то сильная, хоть и динамическая.
K>Таким же макаром я могу доказать, что и Хаскель — динамически типизированный. А всего-то и нужно, что написать интерпретатор, который не проверяет типы заранее, а добавляет метки типов ко всем объектам. Ах да, забыл, это даст нехороший побочный эффект! Все функции станут обладать свойством "type polymorphism"! Ну ничего, можно и этот недостаток залатать, если подумать как.
Таким макаром ты ничего доказать не можешь. В хаскеле есть декларации типов, а семантика стандарта предполагает статическую проверку. В бейсике ничего подобного нет. Там даже DIM — объявление массива не является декларацией — это конструктор массива, работающий в динамике — семантика такая.
Re[40]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Klapaucius, Вы писали:
G>>Большинство были как раз динамическими — а именно — все интерпретируемые бейсики проверяли типы в динамике.
K>Вот только все "индустриальные" Бэйсики, которые позиционировались как языки общего назначения были компиляторами.
Ага щаз. "Индустриальные" бейсики по началу все были интерпретаторами без исключения. Компиляторы из бейсиков стали делать уже сильно позже — и эти языки бейсиками можно уже с натяжкой было назвать — это уже сильно расширенные диалекты. И то, современные "индустриальные" бейсики днамические, например Visual Basic, не путать со скриптом VBScript и встраиваемым Visual Basic for applications.
Если нам не помогут, то мы тоже никого не пощадим.
. Все-таки, в 31 год тяжело вспомнить детали угребищного языка, на котором писал много, но в школе. Я с тех пор настолько много чему научился, что мне не стыдно забыть $ перед строковой переменной, а смешно 
