Здравствуйте, lomeo, Вы писали:

L>Это не понял. Пример?

Кодогенерация при деплойменте.

Здравствуйте, Cyberax, Вы писали:

IT>>Кто такой, почему не знаю?
C>

C>Assigning the values of the Customer class shown to the left to the same instance one million times takes about a minute on my laptop using pure refleciton. Using bytecode enhanced reflection it takes a mere ~175 milliseconds to do the same thing. So maybe reflection isn't that slow after all?

Блин, тоже мне. В bltoolkit такая хрень называется TypeAccessor и существует уже сто лет. Но, если ты внимательно читал, то косяк в ASP.NET не позволяет задействовать этот механизм. Для обращения к полям / свойствам объекта ASP.NET тупо вызывает TypeDescriptor.GetProperties. В свою очередь этот метод либо создаёт PropertyDescriptors используя рефлекшин, либо, если объект реализует интерфейс ICustomTypeDescriptor, то запрашивает коллекцию PropertyDescriptor через него. Т.е. чтобы не попасть на рефлекшин объект должен реализовывать ICustomTypeDescriptor. К примеру, для WinForms баиндинга это не обязательно. Там PropertyDescriptors запрашиваются через ITypedList и IBindingList, что позволяет полностью контролировать процесс.

IT>>По моим тестам, генерируемые аксессоры всего лишь в 3-4 раза быстрее рефлекшина, чего достаточно, чтобы кастомер на глаз замечал задержку.
C>Тормозилло... У нас чистым reflection'ом байндятся таблицы в тысячи элементов в Swing'овом GUI. Ничего не тормозит, все довольны.

Я знаю как решаются такие проблемы в джаве. Покупается 4-х процессорный ящик, в него втыкается 16 гигов памяти и всё начинает просто летать.

IT>>Допустим, так получилось, что я переименовал одно поле. Как отреагирует твой ынхибернейт:
C>В IDEA запрос будет подчеркнут красной линией, как содержащий ошибку. Инспекция на билд-сервере TeamCity начнет писать разработчикам грозные письма. И т.п.

Но компиляция всё же пройдёт?

C>>>Ну не знаю, Hibernate держит свой кэш на любом провайдере.
IT>>Видишь ли в чём дело. Машина не должна думать, машина должна ездить. Я не люблю когда машина додумывает за меня куда мне нужно ехать.
C>Так ведь едет же

Едет, но хреново. На самом деле, при наличии макросов большинство выкрутасов хибернейта и биэлтулкита нафиг не нужны. Тот же маппинг как понятие появился исключительно благодаря лени разработчиков и нежеланию постоянно писать кучу тупого кода. Макросами эта задача решается влёт. Особенно зная контекст выполнения. Можно, кстати, попытаться вообще обойтись без создания объектов. Если отложить запрос до момента рендеринга, то мапить можно DataReader непосредственно в response стрим.

C>Эта текстуальность замечательно проверяется современными IDE и не создает проблем в 99% случаев.

Если компиляция проходит, то этого достаточно. Всё что мне нужно сделать — поменять имя поля в БД, чтобы получить потом весь секс в рантайме. А если ты выпускаешь этот код за пределы DAL, то это возврат на 10 лет назад.

Здравствуйте, Klapaucius, Вы писали:

K>Казалось бы, если индустрия так хорошо все это опробировала, то можно ведь привести ссылки на исследования. Тот же Gaperton любит приводить исследования, в которых с точностью до процента высчитывается превосходство Erlang над C++ по всем возможным показателям.

Это, мягко говоря, преувеличение. А называя вещи своими именами — ложь и подтасовка.

K>Абстрагируемся от того, насколько они точны — в данном случае важно, что они есть. И если бы были соответствующие исследования по данной проблеме, он бы их нашел — я в нем не сомневаюсь.

Я никогда не ищу того, что мне не интересно, уважаемый Клапауций — просто ради того, чтобы дать вам ссылку. Знаю я, как обходятся с хорошими ссылками в РСДН-овских флеймах. Я даю те ссылки, которые я знаю, потому что я их читал, и они мне показались интересными. Тема макросов мне не интересна совершенно, и тратить время на поиск исследований (т.е. фактически провести самому первичное исследование темы), только ради того, чтобы "прогрессивная общественность" морщила нос — я не хочу (все равно читать не будете, упретесь и начнете изворачиваться и терминами жонглировать — вы собственно уже начали в этой подветке). Извините — эта мотивация слабовата для меня.

K>Но нет. Он рассказывает про какие-то макроассемблеры, которые не только не родственники, но и не однофамильцы.

Балшыт. Макроассемблеры — не то что родственники — они имеют прямейшее отношение к современным макросистемам. Ваши тезисы, что мол это совершенно разные вещи, потому что мол там AST нет — в лучшем случае странно, в худшем — смешно. Это тоже самое, что утверждать, что самолеты с поршневыми двигателями — это никакие не самолеты вовсе, потому что у них видите ли нет сопла. Можно подумать, они не летают вовсе.

Вот, взять макроассемблеры. Какое к черту AST в ассемблере?! Какие типы вы нашли в ассемблере? Вы знаете, как транслятор ассемблера устроен? Думаете, там AST анализируется и типы выводятся? Там простые табличные проверки и разбор лексем. Нет там никаких типов и AST, поэтому их нет и в макросистеме.

K> Все дело в том, что таким исследованиям неоткуда взяться. Самый дальний родственник нынешнего Template Haskell и Nemerle — это, наверное, MetaML — а по нему и статей старее 1998-го года нет. Мне, как физику, совершенно непонятно, как могут плоды исследования 1998-го года быть опробированы в 1970-м.

Вам как физику может быть вообще многое непонятно, так же как например мне, получившему образование computer science & applied math не понятны вопросы биологии и химии. То, что вам что-то непонятно — не может являться ни аргументом, ни серьезным вызовом computer science.

- Жгут и убивают СС — а мы солдаты, мы воюем.
— А что, изобрели какой-нибудь новый способ воевать — без убийств и бомбежек?
(17 мгновений весны, диалог Штирлица и пьяного генерала в поезде)

Что, в современных исследованиях по макросам придумали что-то такое, что макросы перестали быть макросами, да? Макросы у нас теперь не задают новые ситаксические конструкции, и не генерируют код, как они делали в далеких 70-х, да? Они что-то такое невообразимое делают, что разумом постичь невозможно? Суть макросов всегда была в макрозамене, и для пользователя неважно по большому счету, как она сделана. То, что при помощи паттерн-матчинга сокращается код пробежки по деревьям — НИКАК не меняет пользовательские свойства макросов. То же самое касается остальных ваших аргументов.

"Исследованиям неоткуда взяться". Каким исследованиям? Исследованиям свойств Nemerle? Можно подумать, в немерле в первый раз макросы изобрели.
Вот, тут в соседней ветке Mikl Kurkov ссылку на целую книгу дал, ага.

Ну вот лежит книга Брауна "Макропроцессоры и мобильность ПО".
Подробно рассматриваются разные типы макропроцессоров и способы их применения. Связанные с этим преимущества и сложности.
Цитата:

Не так давно возникла тенденция создавать языки с большой степенью встроенной расширяемости, и они были названы "расширяемыми языками". Встроенная расширяемость может быть реализована, по крайней мере частично, за счет макросов, но такие макросы должны составлять единое целое с компилятором базового языка.
1974 год.

http://rsdn.ru/forum/message/2607040.1.aspx

Автор: Mikl Kurkov
Дата: 01.08.07

Здравствуйте, Klapaucius, Вы писали:

G>>

G>>ось представляла собой колоссальное количество макросов.

K>Это пять. Все равно как если бы Испания сегодня попыталась привлечь астронома Фрэнка Дрэйка к отвественности за Номбре де Диос. "Верни наше серебро, подлый пират!"

Это десять. Я привел эту цитату в подтверждение того, что макросы применялись в мэйнстриме в 70-х. У вас по существу вопроса есть что сказать? Фрэнк Дрейк и его серебро мне малоинтересно.

Здравствуйте, Cyberax, Вы писали:

M>>Опыт отладки макросов может дать, например, такая среда разработки как Eclipse. Только там плагины к IDE отлаживаются, а не макросы, но суть процесса та-же самая. Не пробовали к Eclipse плагины писать?
C>Пробовал. Не понравилось.

Единственный альтернативный вариант, который мне приходит в голову — это иметь специальный императивный язык для трансформации AST кода, и отлаживать программы написанные на этом языке. Макросы a-la Nemerle тут не подойдут, поскольку он предоставляет декларативный язык (псевдо-цитирование). В декларативном языке точку останова не поставить. А императивный язык трансформации будет сложен для чтения и понимания для нетривиальных трансформаций. Фактически, он будет мало отличаться от generic-perpose императивных языков, а конструирование вручную AST дерева — это очень тяжело.

Я пробовал писать плагины к Эклипсе, и мне их отладка понравилась. Видимо, тут речь идёт просто об опыте и знании инструмента. Безусловно, отлаживать компилятор — намного сложнее, чем выучить язык. Но если вы этот компилятор уже выучили вдоль и поперёк — то его отладка ничем не отличается от отладки обычного кода. Впрочем, это справедливо для любого большого проекта — пока его не выучишь, хрен поймёшь что происходит. В этом отношении IDE сильно рулит, так как по ходу отладки можно заодно и выучить проект.

Здравствуйте, AndrewVK, Вы писали:

IT>>В-четвётых. Аналогичная проблема возникает при ручном конструировании запросов, что необходимо для реализации всевозможных фильтров. Линк здесь уже никак не поможет и придётся заниматься самой обычной императивщиной.

AVK>Здесь можно поподробнее?

С Женей поговори, он тебе лучше расскажет.

Когда нам требуется построить запрос динамически, то синтаксис линка идёт в сад. Например, у нас есть несколько полей для задания фильтра. Если поле пустое, то мы по нему не фильтруем, если в нём есть какое-то значение, то мы его включаем в фильтр.

Здравствуйте, IT, Вы писали:

IT>Когда нам требуется построить запрос динамически, то синтаксис линка идёт в сад. Например, у нас есть несколько полей для задания фильтра. Если поле пустое, то мы по нему не фильтруем, если в нём есть какое-то значение, то мы его включаем в фильтр.
MS переизобретает Hibernate

        DetachedCriteria dc = DetachedCriteria.forClass(Student.class)
            .add( Property.forName("studentNumber").eq( new Long(232) ) )
            .setProjection( Property.forName("name") );

Единственного чего не хватает — ссылок на свойства, тогда вообще без строковых констант все можно было бы делать.

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, FR, Вы писали:

K>>>Basic — статически типизированный язык.
FR>>Лисп, смалталк, питон и руби тоже.

K>Звучит феерично и психоделично, конечно. Жаль, что это просто недоразумение.

Молодец чувствуется нордический характер
Если это так то и мой список состоит из статически типизированных языков.

Здравствуйте, Gaperton, Вы писали:

G>Ага. Такой же, как я — папа римский.

G>LET F = 1
G>LET D = 1.0
G>PRINT F+D
G>LET F = "string"

G>Классику надо знать, даже если это такое дерьмо как бейсик.

Странно, что это вообще где-то будет работать. QBasic напишет несоотвествие типа. А более "классические" бэйсики, во-первых, требуют записи строковых переменных с постфиксом "$" (аналогично, для int'ов — !, для double'ов — %, и т.д.), а во-вторых, номеров строк. F+D — совершенно верное выражение, т.к. по умолчанию переменные имеют тип single, а значит переменные совместимы. Впрочем, можно складывать и целые с дробными, при этом делается неявное приведение. Но неявное приведение — ещё не признак динамики.

Конечно, существовало сотни разновидностей бэйсика, так что какой-нибудь из них мог быть динамическим, я точно не знаю. Но большинство реализаций были статически типизированым.

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, IT, Вы писали:

G>>>Индустрия имела макросы в далеких 70-х. И отказалась от них вместе с ассемблерами и языками-монстрами вроде PL/1 — с появлением простых и понятных языков высокого уровня.
IT>>Я не уверен в том, что макросы имела именно индустрия. Отдельные исследовательские проекты возможно. Но насчёт всей индустрии я бы не стал утверждать. Вообще, востребованность инструмента напрямую зависит от сложности вхождения в него. Если сложность вхождения в те макросы была запредельной, то результат вполне закономерный.

K>На самом деле макросов, как преобразований над AST, индустрия не имела никогда. Индустрия имела текстуальные препроцессоры a la препроцессор C и макроассемблеры. Все это к современным макросистемам вроде Nemerle или Template Haskell имеет такое же отношение как и макросы Word-а, т.е. сходство только в названии.

Есть еще кое-что общее у текстовых препроцессоров и преобразований над AST, кроме названия. Сходство, которое вы, коллега, умудрились каким-то непостижимым мне образом в своем рассуждании пропустить, состоит в том, что и то и другое делает ровно одно и тоже — выполняет некоторую трансформацию кода, расширяя синтаксис и семантику базового языка. Делается это преобразованием над AST, вылавливанием и заменой регекспов, или как-то по другому — совершенно не важно ни для кого, кроме как разработчика макросов. А я не проблемы разработчика макросов обсуждаю — они меня мало волнуют, я обсуждаю проблемы пользователя макросов. Это второй тонкий и не очевидный момент, который, видимо, надо подробно растолковать.

K>Короче говоря, Gaperton валит с больной головы если и не на здоровую, то, по крайней мере, на неизвестно какую.
Да ладно, скажите просто и честно: "я не понимаю, что и о чем пишет Гапретон, проблемы, которые он поднимает мне не понятны и не близки". Так вы, по крайней мере, избежали бы перехода на личности, плюс — точно передали бы суть дела.

K>Учитывая, что новые макросистемы — изделия начала — середины двухтысячных годов, легко видеть, что в индустрии их еще никто не имел возможности испробовать, так что все грабли в этой области еще ожидают своих первооткрывателей.

Отчего же. Учитывая, что новые макросистемы делают в конечном счете то же самое, что и старые, совсем не трудно представить, какие грабли ждут энергичных "первооткрывателей" технологий 70-х годов, закрывающих глаза на здравый смысл и на опыт индустрии.

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, FR, Вы писали:

K>>>Не обязательно. Макросами, которые написали другие он точно пользовался.
FR>>Мне правильно кажется что в немерле вообще очень затруднительно не пользоватся макросами?

K>Слово "затруднительно" не имеет объективного значения. Я думаю, что на Nemerle можно писать, не пользуясь макросами. Но зачем?

Угу зачем ведь тяжело не использовать даже if for и т. п. уж лучше на лиспе.

Здравствуйте, Gaperton, Вы писали:

K>>Basic — статически типизированный язык.
G>Ага. Такой же, как я — папа римский.

Йозеф? Старина! Тебя не признать. Какие погоды стоят в Риме?

G>LET F = 1
G>LET D = 1.0
G>PRINT F+D
G>LET F = "string"

Это по-каковски написано?
В самом первом BASIC так написать было нельзя. Это был язык с двумя типами данных: числами с плавающей точкой и строками. Типы не указывались при объявлении — но идентификатор типа должно было нести имя переменной. Т.е код

LET F = "string"

не валидный. Надо писать так:

LET E$ = "string"

Да и присвоить строку переменной с плавающей точкой в нем было нельзя.
Потом появились целые числа с постфиксом %. Т.е. никакого динамического полиморфизма в Basic небыло — просто были такие багофичи как неявное определение переменной при первом использовании и тип данных по умолчанию. При полностью статической типизации, разумеется. В те допотопные времена такие багофичи были вообще нормой, тут Basic не одинок что-то вроде того того было и в Fortran.
Все эти языки, что характерно, эволюционировали в сторону явного определения типов. Вобщем, во всяких Turbo и Quick Basic-ах можно было отказаться от постфиксов в пользу явной декларации типа при объявлении переменной.
Что было потом? Потом появился Visual Basic — в котором таки да, этот код может быть валидным в зависимости от того, как объявлялись переменные и объявлялись ли они. Просто потому, что тип по умолчанию в нем не Single а Variant. Наличие же вариантного типа и неявные преобразования строк в числа не делают динамическим ни один язык. Мало ли где есть вариантный тип?
Типизация для классов в VB тоже как в статических языках, номинативная, никаких duck typing и прототипов.
Впрочем, VB все рано нельзя назвать языком общего назначения. Все таки это язык для склеивания COM-серверов, и в варианте VBA для автоматизации. Т.е. скрипт.
Ну а VB.NET хотя и имеет кое-какие фичи для позднего связывания — все равно не более и не менее динамический, чем любой другой язык, компилирующийся в MSIL.

G>Классику надо знать, даже если это такое дерьмо как бейсик.
Неужели? В таком случае учите матчать. Я все понимаю, эрудиция это всегда поверхностное знание, но нужно учитывать опасность столкнуться с эрудитом у которого знание в данной конкретной области несколько менее поверхностное.

G>Макросистема не обязана уметь получать информацию о типах. Дело в том, что ее вообще может не быть, этой информации, так же как и типов. К примеру, макросистема в любом чисто динамическом языке без аннотаций типов этой информации получить не может в принципе. Взять хотя бы тикль. А в ряде приложений, где возможно применение макросистем, типов вообще в природе не существует как понятия — например при обработке текстов или в случае макроассемблера, или языка FORTH.

Понятно, что никто не требует возможности получить типы в для таких языков. Я, собственно, так и написал. И указал это естественной причиной того, что макросистемы именно в таких языках и появились. Но для языка, для которого доступна статическая информация о типах — требовать доступа к информации о типах в макросистеме естественно. Именно поэтому первые макросистемы для статических языков и появились так поздно — при разворачивании макросов основные сложности с типизацией.

Здравствуйте, IT, Вы писали:

IT>Когда нам требуется построить запрос динамически, то синтаксис линка идёт в сад.

Вог-первых не идет, я, кажется, кому то уже демонстрировал. Во-вторых декларативный синтаксис линка далеко не самая важная его часть. И использование функциональной формы записи совсем не означает "обычной императивщины".

IT> Например, у нас есть несколько полей для задания фильтра. Если поле пустое, то мы по нему не фильтруем, если в нём есть какое-то значение, то мы его включаем в фильтр.

if (fooParam != null)
query.Where(x => x.Foo == fooParam);

Но можно и промежуточный провайдер написать, который будет автоматом сворачивать ET, а потом передавать его Linq2SQL. Тогда можно будет просто декларативно писать полный запрос, а он потом свернется до необходимого.

Здравствуйте, konsoletyper, Вы писали:

K>Здравствуйте, Gaperton, Вы писали:

G>>Ага. Такой же, как я — папа римский.

G>>LET F = 1
G>>LET D = 1.0
G>>PRINT F+D
G>>LET F = "string"

G>>Классику надо знать, даже если это такое дерьмо как бейсик.

K>Странно, что это вообще где-то будет работать. QBasic напишет несоотвествие типа. А более "классические" бэйсики, во-первых, требуют записи строковых переменных с постфиксом "$" (аналогично, для int'ов — !, для double'ов — %, и т.д.), а во-вторых, номеров строк. F+D — совершенно верное выражение, т.к. по умолчанию переменные имеют тип single, а значит переменные совместимы. Впрочем, можно складывать и целые с дробными, при этом делается неявное приведение. Но неявное приведение — ещё не признак динамики.

Надо же, прищучили. Действительно, во всех диалектах надо для строк писать $F. Эх, стареем . Однако, для чисел это не так. Префиксы не обязательны, более того, многие диалекты не поддерживали префиксы ! и % вовсе — например, спектрумовский бейсик.

Второе — никакого контроля типов при "компиляции" бейсики не делают — не было в них компиляции, они по большей части выполняют проверку типа в динамике. А это и есть динамическая типизация, позднее связывание, и т.д. При динамической типизации у тебя на выполнении выскочит несоответствие типа, и это нормально. Типизация то сильная, хоть и динамическая.

K>Конечно, существовало сотни разновидностей бэйсика, так что какой-нибудь из них мог быть динамическим, я точно не знаю. Но большинство реализаций были статически типизированым.

Большинство были как раз динамическими — а именно — все интерпретируемые бейсики проверяли типы в динамике.

Здравствуйте, GlebZ, Вы писали:

IT>>- устранение pass-through слоёв.
GZ>Я испуган...

Не боись, прорвёмся.

GZ>Не согласен. То что ты здесь написал — это есть "встроенный макрос". Мне вообще непонятно зафигом его ввели.

Это не ко мне. Это к Хэйлсбергу и Боксу.

GZ>Говорить о том, что визуальность по сравнению с функциональной записью кардинально увеличилось — не приходится.

Ну почему же? Идея очень правильная. Как ты думаешь, зачем народ во всяких хибернейтах занимается всякими query languages? Для того, чтобы получить не просто язык запросов, а типизированный язык запросов, полностью контролируемый компилятором. Мечта! А ты говоришь не приходится.

IT>>Во-первых, из-за кривой реализации баиндинга в ASP.NET, при работе с навороченными веб-контролами типа GridView, объект должен реализовывать интерфейс ICustomTypeDescriptor. В противном случае мы нарываемся на рефлекшин со всеми вытекающими последствиями. Будут ли анонимные типы реализовывать ICustomTypeDescriptor? У меня есть на этот счёт определённые сомнения.
GZ>На фоне генерации грида и работы с бд — выигрыш будет очень незначительным.

Точно? Проверял или сам догадался?

IT>>Во-вторых, несмотря на то, что вся информация о запросе у нас доступна в компайл-тайм, мы получим генерацию SQL в райн-тайм, опять же со всеми вытекающими последствиями.
GZ>Это нормально. Провайдер может быть подменен.

А может быть не подменён. Но жертву мы уже принесли. Да и работа с разными провайдерами может быть выполнена по разному. Например, макрос может сгенерировать SQL для разных провайдеров, в рантайм останется только проверить кто там у нас сейчас текущий провайдер.

IT>>В результате, хотя всё и выглядит зашибись, мы уже получили неустранимые проблемы. Точнее первую можно легко устранить, но за счёт отказа от анонимных типов и возврата к одноразовым типам. Второе даже не знаю, разве что написать Linq2Me и огранизовать кешироание запросов самостоятельно.
GZ>Кэширование запросов или результатов?

Запросов.

IT>>Учитывая, что разница между версиями у нас 2005 — 2008, то как говорится обещанного три года ждут.
GZ>Это особенности провайдера LINQ2SQL. К макросам отношение имеет мало.

Какая разница. Имея свои макросы я такую проблему решу быстро и эффективно.

GZ>Линк ленив. Забудь о встроенном макросе — пиши в функциональном виде. Собрать запрос — вещь тривиальная.

Спасибо, дорогой. Чтобы мы делали без твоих советов? Вообще у нас тут спор о том какая декларативность лучше, такая или сякая. Ты же приходишь и говоришь — пишите императивно и будет вас счастье

GZ>Ага. Посему и удивился твоему утверждению про pass-through.

Ты можешь мне привести неубиваемые преимущества pass-through кода?

GZ>Итак. Насколько я понял, из всего вышеперечисленного 4,5,6 пунктов, ты хочешь заменить слои на АОП с помощью макросов.

АОП тут вообще не причём.

Здравствуйте, Cyberax, Вы писали:

C>Единственного чего не хватает — ссылок на свойства, тогда вообще без строковых констант все можно было бы делать.

Это мы уже обсуждали. Нужно ввести в язык конструкцию nameof и всем будет счастье. Кстати, добавить макрос nameof в Немереле как... ну ты понял

Здравствуйте, Константин Л., Вы писали:

IT>>Для написания более сложных вещей желательно иметь полное представление.
КЛ>Для изучения которого нужно потратить полгода.

Откуда такие точные разведданные?

IT>>- обезъянкам будет трудно;
КЛ>само собой, ведь другие обезьянки такого нахреначат...

Именно. Те, кто нас с тобой считают обезъянками именно так и думают.

Здравствуйте, Cyberax, Вы писали:

C>Я пробовал Nemerle'евые макросы отлаживать — нет, спасибо.

Что не так? Я без проблем отлаживаю даже сам компилятор.

Здравствуйте, VladD2, Вы писали:

VD>Если правильно понимаю действие этой штуки, то конечно это интересное решение, вот только боюсь, что не пригодное в реальной жизни. Одним из важнейших аспектов работы этого алгоритма является скорость. Она не просто важна, она жизнанно важна. И тут есть две проблемы. Во-первых универсальные алгоритмы сами по себе не быстры. В том числе и универсальный map скорее всего будет не быстр (ну, да это мои домыслы). А во-вторых, для ускорения работы приходится исключать некоторые ветки из просмотра. Ну, то есть заранее известно, что в таких-то подветках искать бессмысленно, а подветки огромные. Плюс еще некоторые ветки имеют цеклические ссылки, так что нужно как-то исключать зацикливание алгоритма обхода. Лично я даже не представяю как в Хаскеле сделать циклический граф (предпологаю, что без ленивости не обойдется).

Разумеется, gmap проходит по всем узлам, поэтому он медленный. Для ускорения можно и исключить ветки из просмотра (правда, чисто это будет, насколько я знаю, только для определённых случаев — для этого варианта не делаем, а для этого делаем), можно решить и циклы. У тебя разве по другому?

VD>Конечно это все общие рассуждения, но на практике весь из себя распрекрасный Хаскель имет очень убогую интеграцию с VS, а вот язык с макросами очень даже полноценную. Конечно можно всегда сказать, что мол программисты делающие интеграцию с VS для Хаскеля слабоваты, но это тоже вряд ли можно считать плюсом для Хаскеля.

Э-э-э... А зачем Хаскелю интеграция с VS?

BZ>>по теме: ответ да. другое дело, что абсолютно выразительных языков не бывает, в хаселе тоже без макросов не всегда обойдёшься. так что вопрос не в наличии их в языке (запас карман не тянет), а в том, когда их приходится применять.

VD>Согласен. Конечно наличие чудо gmap — это несоменно полезно. Вот только ты прав и в том, что на все случи жизни не напасешся. И тот же gmap отлично можно было бы реализовать на макросах.

Зачем, если он реализуется средствами языка?

VD>Правильно ли я понимаю, что gmap (и другие g*) — это встроенная фукнция языка? Если нет, то очень интересно поглядеть на ее реализацию (и получить пояснения к ней). Если, да, то это еще один случаяй добротного хардкодинга. Но не более того. В любой язык моно захардкодить что угодно. Вот только есть два "но". 1. Все захардкодить нельзя. 2. Захардкоденые решения в большинстве случаев старадат от различных проблем (скорость низка, гикость недостаточная и т.п.).

Не встроенная, не захардкоденная, просто использует несколько расширений (точнее — два: cast и rank-2 полиморфизм) Хаскеля. Реализация и объяснение приводится в том самом scrap your boilerplate, на который указывал Булат. Кстати, он говорил о самой простой её форме — gmapT :: (forall b. b -> b) -> a -> a

Реализуется она просто (ниже примитивная реализация):

У нас есть класс описывающий одноуровневую трансформацию. Любую, поэтому тип имеет rank-2 полиморфизм.

class Typeable a => Data a where
    gmapT :: (forall b. Data b => b -> b) -> a -> a

Теперь мы можем элементарно описать (пока руками) свой тип как экземпляр типа Data:

instance Data [a] where
    gmapT f [] = []
    gmapT f (x:xs) = f x : f xs

Это всё ещё одноуровневый проход. Добавить рекурсивный несложно:

everywhere :: Data a => (forall b. Data b => b -> b) -> a -> a
everywhere f x = f (gmapT (everywhere f) x)

Заметь, что теперь мы не можем вставить свою функцию с точным типом как параметр everywhere — она ожидает более полиморфный тип. Для этого используется комбинатор mkT

mkT :: (Typeable a, Typeable b) (b -> b) -> a -> a
mkT f = case cast f of
    Just g -> g
    Nothing -> id

Здесь используется одно из расширений Хаскеля — функция cast :: a -> Maybe b, на самом деле она может быть реализована средствами языка, но это будет, разумеется медленнее, чем встроенная.

Теперь мы можем делать так, как показал Булат:

everywhere (mkT (\Salary x -> Salary (x*1.1)))

gmap в его примере это что то вроде gmap f = everywhere (mkT f)

Теперь добавим ещё одно расширение Haskell — derivable type classes, кажется они называются, и мы сможем генерить экземпляры Data для конкретных типов тупым указанием в этих типах deriving Data.

Т.е.

data X = X (Maybe Int) deriving (Typeable, Data, Show)

> everywhere (mkT (\x -> x + 1 :: Int)) (X (Just 1))
X (Just 2)

VD>В общем, gmap — это ХОРОШО! Но лучше если он создан в виде макроса. Чтобы можно было бы создать на его основе специализированную версию. Да и вообще, чтобы на языке можно было создавать подобные вещию.

Не понимаю, чем лучше, если он создан в виде макроса. Тут вроде речь о том, что если язык достаточно мощный и имеет средства, заменяющие макросы (например те же derivable type classes), то зачем нужны макросы (для решения этих задач, разумеется)?

VD>Возмем тот же gmap. gmap и есть та самая магия. Почему магия? А его нельзя объяснитьв термирах основного языка (если я правильно понял). Скажем в Ява/дотнете его аналог можно создать на базе рефлексии.

Тут в чём прикол. В Хаскеле рефлексия сделана интересно. Ты сам определяешь для каких типов она есть, а для каких нет. Рефлексия конкретного типа -- это просто экземпляр класса Typeable, в котором ты наопределял (или Хаскель сам вывел) нужные тебе комбинаторы.

VD>Работать будет на ура, но медленно, а значит не всегда приемлемо.

Медленно рефлексия работает из-за рефлексивного вызова функции? Так в SYB этого нет. Ты погляди -- это же тупой визитор.

VD>Возможно в каких-то языках его аналог можно будет создат не базе компайлтайм-рефлексии. Но без подобных средств создать gmap мне не представляется возможным.

Проверяем — наш ли тип — нет, спускаемся к его полям, да — выполняем функцию.
Проход всё равно будет по всем узлам (пока мы руками не ограничим, разумеется) — но в этом смысл gmap.

VD>А многие нуждаются в создании подобных магических фунций. И не телько. Кому-то просто хочется сделать синтаксис именно таким как он видит. А кто-то хочет интегрировать в свои программы некий фрэймворк. В общем, бесспорно, что если имеется отлично подходящие средства встроенные в язык, то лучше выбирать их, а не заниматься самодеятельностью и клепать макросы. Но макросы иметь тоже нужно. Иначе рано или поздно прийдется идти на компромисы и довольствоваться огрызками с барского стола.

С этим спорить не буду.

BZ>>то же самое относится и к немерле или хаскелю — случаи, когда приходится применять макросы, высвечивают недостатки языка.

VD>Согласен.

О! Тема топика, кстати.

VD>Ты проповедушь совершенно неверную, на мой взгляд, идею — в язык нужно впихнуть все что попало. Я за компактный язык с возможностью гибкого его расширения.

Эх! Если бы это всегда было возможно. Как на макросах в Хаскеле тот же cast сделаешь (быстрый)? Никак, базовых средств недостаточно.

VD>DSL-и — это отдельная область. И для их строителсьтва макросы вседа будут идеальным решением.

Ну слишком категорично. Вот на руби обходятся без макросов (мы же про DSEL?)

VD>А вот извороты вроде Хаскелевских всегда будут сопровождаться коментариями вроде (ну, вот все замечательно только А кривовато, а Б медленновато, а С зависит от компилятора и направления ветра). Реализация разны магических фунций вроде gmap опять же отличное поле для макросов. В итоге мы получим и там, и там фунцию gmap, которую внешне нельзя будет отличить. Но в одном случае ее смогут создать только создатели компилятора, а в друго любой смертный. Думаю не надо объяснять почему путь макросов лучше?

gmap может создать любой смертный. Средствами по мне более простыми нежели макросы.

VD>Я не очень понял что значит "управляющие стурктуры". Посему не могу об этом рассуждать. С точки зрения манипуляции функциями Хаскель мало чем отличается от Немерле.

Да и вообще все языки Тьюринг-полные

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Gaperton, Вы писали:

G>>Также, для прямого оптимизированного перехода между двумя нелинейними пространствами (что надо делать по показаниям) — никто не мешает определить специализированный метод.

AVK>Если преобразования описываются матрицей (а если я не совсем позабыл соотв. раздел прикладной математики, то матрицей можно описать очень широкий класс аналоговых функций), то что мешает не преобразования делать в несколько шагов, а просто перемножить матрицы преобразований? При этом сами матрицы можно представлять на этапе перемножения со сколь угодно высокой точностью, это не скажется на производительности самих преобразований.

Гут. Ты все почти разрюхал. Именно так и надо делать для преобразований половины его цветовых пространств — у него там половина цветовых пространств переводятся друг в друга матричным преобразованием. Судя по всему — именно здесь он вместо простого перемножения матриц макросами разворачивает формулы , по кратчайшему пути через граф определенных ручками преобразований. Жуть.

Вторая половина приводится к гражданским пространствам типа RGB нелинейно, т.е. в терминах матричного линейного преобразования не описывается. Что тоже не проблема — при нашем с тобой подходе любое преобразование делается в два хода — из нелинейного в линейное, потом обратно в нелинейное. Это устраняет необходимость в макроанализе страшного графа допустимых переходов между пространствами. Что-то намудрил WH на ровном месте, мне кажется.