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

Z>>>Макрос выполняется в компайл тайме, он может анализировать компилируемый код и изменять его, например сгенерировать нужные методы для вызова хранимки.

VD>Да, черт побери, есть подвид задач которые решаются и тем и тем, но вот макросы не тождественны шаблонам и тем более дженерикам. С помощью макросов можно сделать все что можно сделать с помощью шаблонов и джененриков. Более того, то что хорошо делается шаблонами и дженериками не стоит делать марами. Но многое что можно сделать макрами сделать шаблонами и дженериками невозможно. В частности выделенное в цитате Ziaw сделать дженериками или шаблонами невозможно. Кроме того в них нельзя анализировать внешние источники данных.

Ну хорошие шаблоны очень близки по возможностям к макросам. Например D'шные вполне позволяют "анализировать компилируемый код" http://www.digitalmars.com/d/2.0/traits.html http://www.digitalmars.com/d/2.0/phobos/std_traits.html

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

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

Я о другом. Скажем, linq2Sql, использующий "внешний" генератор кода, не менее удобен в использовании, чем аналогичное решение с макросами. Здесь же, мне показалось, не о крутости макросов идет речь, а об удобстве веб-фреймворка.

H>Ну так нужны примеры Я не помню чтобы ктото пытался комбинировать несколько могучих макросов, которые выполняют немалую работу и генерируют/модифицируют много кода.

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

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

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

ВВ>С т.з. удобства разработки претензий к макросам нет. Мне не так редко приходится генерировать код с помощью XSLT и какой-то матери, чтобы это стало очевидным. Кстати, получение метаданных — достаточно типичная задача. В Т4 это кстати работает, т.е. метаданные внутри самого шаблона получить можно, но не всегда удобно. В рукопашном варианте в целом аналогично. Самым простым решением проблемы с метаданными — это вынесение этих самых метаданных (скажем, интерфейсов, по которым генерируются бизнес-сущности или whatever) в отдельную сборку.

Одним словом это называется — гемморой. Вот ты и начал сам отвечать на свой вопрос.

ВВ>Но это одна сторона медали. Другая — это DSLTools, BuildProviders в студии и пр.

Их ты пробовал использовать? В прочем DSLTools это из другой оперы. Это скорее средство создания интерактивных диаграмм. Штука несомненно иногда очень полезная. Только вот средства изучения, преобразования и генерации кода там точно такие же — T4.

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

Очень советую поработать над логическим выводом, так как такие ошибки не допустимы, на мой взгляд.
Из сказанного никак не вытекает последнего утверждения.

ВВ>А визуальные DSL-и для многих даже удобнее макросов. А если мне *как пользователю* не видно разницы...

Визуальные DSL может и хороши но у них есть два недостатка.
1. Они далеко не для всего применимы. Точнее будет сказать применимы они весьма редко.
2. Их очень не просто создавать. Фактически DSLTools предоставляет средство только для рисования диаграм. А весь код по анализу кода и генерации оного придется написать самому. Отсюда и такое малое количество тех самых DSL-ей произведенных с его помощью.

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

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


Z>Неужели в рантайме? Или препроцессор? Если так — то это каменный век.

Не все препроцессоры аналоги сишного, например camlp4 тот же XML/html запросто встраивает в код:

let html_of_tweet t =
   <:html<
      <div class="tweet">
        <div class="author">$html_of_author t.author$</div>
        <div class="date">$Date.html_of_date t.date$</div>
        <div class="contents">$t.contents$</div>
      </div>
   >>

http://www.openmirage.org/blog/introduction-to-htcaml
http://ocsigen.org/eliom/manual/1.3.0/1#p1baseprinciples

Ну и тут http://ocsigen.org/ как раз веб фреймворк на статическом (даже слишком статическом) функциональном языке,
но без макросов, но с препроцессорным (не обязательным) расширением синтаксиса.

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

Z>Так вот статика может дать потенциально не менее декларативный код и меньшее количество движений для внесения изменений. Просто потому, что компилятор проконтролирует больше и нам придется писать и править каждом изменении меньше тестов. Просто потому, что читать код станет проще, т.к. навигация и ограничения на типы в статике помогают читать код. Просто потому, что рефакторинг нам будет даваться меньшей кровью и мы будем делать его когда положено, а не когда уже дальше терпеть нельзя.

Про меньшее количество движений — это совсем неочевидно. Как компилятор может контролировать то, что известно только в рантайме? Если, скажем, у меня задача читать ХМЛ, который приходит из внешнего источника — то это динамика. И если ты макросом сгенеришь красивый и как бы статически типизированный код для чтения этого ХМЛ-я — то это все равно будет динамика. Просто выглядящая как статика. И если вместо ХМЛ-я придет фигня, то все свалится в рантайме.

Речь, наверное, не про "движения", а про меньшее количество тестов. Но тут мне тоже непонятно, насколько конкретно этих тестов будет меньше и как это вообще повлияет на разработку. Зато, например, мне понятно, что с тем же РОРом у меня уже есть готовый и работающий РЕПЛ. А вас пока только в планах. И я понимаю, что РЕПЛ-то как раз весьма заметно повлияет на мою эффективность.

ВВ>>Но сейчас все-таки не 90-е. Клиенты "хочут" аякса и веб-два-ноль. А это значит, что у нас будет куча ДжаваСкрипта. И что толку от того, что в одном маленьком месте мы добавили статики, а во всех остальных у нас как была, так и осталась динамика — причем динамика отборнейшейго, так сказать, "качества".
Z>Это что за задача с маленьким сервером и огромным клиентом?

Это не задача, это один из вариантов решения.

Z>Это потому, что у тебя есть код и там и там, естественно ты его можешь и там и там править. У меня код только там, разъезжаться в таком случае просто нечему.

Только "там" — это где? На сервере? Как у тебя так получается? Как можно писать приложения с богатым клиентским слоем, вроде того Гмейла, и не формировать HTML на джаваскрипте?
Да дело даже не в этом, пусть ДжаваСкрипт HTML вообще никак не генерит. Он что, с ним и не работает? Контрол задизеблить надо — сабмит форму или ее часть на сервер?

ВВ>>Поэтому если сравнивать статический ДАЛ — к примеру, на Linq2Sql — и динамический (ну собственно, рукописный код со всяческими reader.GetValue) — то я бы совсем не сказал, что первый вариант надежнее. К обоим надо прибивать юнит-тесты и гонять их чуть ли не на каждом комите.
Z>Давай пример юнит теста и сценария в котором этот юнит тест нам будет полезен. Я не представляю о чем ты говоришь.

А что непонятно-то Простые изолированные тесты, которые в первую очередь проверяют консистентность модели. Ну или корректность работы процедур, если они имеются. Скажем, один тест проверяет все процедуры для работы с конкретной сущностью — вставил, прочитал, сверил результаты, удалил.

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


H>>Ну так нужны примеры Я не помню чтобы ктото пытался комбинировать несколько могучих макросов, которые выполняют немалую работу и генерируют/модифицируют много кода.

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

Где это в моих словах? Я лишь сказал что комбинирование некомбинируемого однозначно провальная затея. А теперь примеры некомбинируемых макросов в студию. А также вменяемые юзкейзы их комбинации.

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

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

Тебе неудобно пользоваться кодом, которые сгенерирован через студийные билд-провайдеры? С т.з. юзабилити это чем от макросов отличается?

ВВ>>А визуальные DSL-и для многих даже удобнее макросов. А если мне *как пользователю* не видно разницы...
VD>Визуальные DSL может и хороши но у них есть два недостатка.
VD>1. Они далеко не для всего применимы. Точнее будет сказать применимы они весьма редко.
VD>2. Их очень не просто создавать. Фактически DSLTools предоставляет средство только для рисования диаграм. А весь код по анализу кода и генерации оного придется написать самому. Отсюда и такое малое количество тех самых DSL-ей произведенных с его помощью.

И одно важное достоинство — они широко используются и, так сказать, насаждаются вендором платформы. Люди к ним привыкли. И таки-да, многим удобнее модель набросать в дизайнере, чем делать это макросом.

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

Еще раз — речь не идет о том, лучше или хуже макросы. Речь об удобстве итогового продукта. Енд-юзеру по фиг — макросы там или внешний ДСЛ. Важен результат.

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


DG>как минимум сейчас есть следующие ограничения:
DG>во-первых, возможности шаблонов останавливаются на уровне классов.
DG> на уровне полей/свойств/методов шаблоны уже не работают, не говоря уже про тела методов

Ну D'шные не останавливаются, шаблон там не привязан к классу или функции и может описывать
произвольный кусок кода http://www.digitalmars.com/d/2.0/template.html ну и плюс миксины
http://www.digitalmars.com/d/2.0/template-mixin.html

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

В том же D доступен полноценный compile-time на довольно широком подмножестве языка http://www.digitalmars.com/d/2.0/function.html#interpretation

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

Z>Так вот статика может дать потенциально не менее декларативный код и меньшее количество движений для внесения изменений. Просто потому, что компилятор проконтролирует больше и нам придется писать и править каждом изменении меньше тестов. Просто потому, что читать код станет проще, т.к. навигация и ограничения на типы в статике помогают читать код. Просто потому, что рефакторинг нам будет даваться меньшей кровью и мы будем делать его когда положено, а не когда уже дальше терпеть нельзя.

Ну смотри, что упрощает жизнь в статике, как ты пишешь:
— Навигация по коду, рефакториг и проч.
Ну во-первых, особого рефакторинга я в том же Немерле не вижу Вот у C# есть, Решарпер называется.
Нормальная поддержка ИДЕ — на самом деле для языка с навороченным выводом типов это *сложнейшая* задача. В вашем случае она несколько упрощается, т.к. вы имеете прямой доступ к самому компилятору и даже контролируете развитие языка. Вплоть до того — тут Влад где-то говорил в стиле — такой-то фичи делать не будем, ибо она замедлит интеграцию. Это уже смещает акценты.
Если брать с чистого листа, то создание ИДЕ для динамически-типизированного языка и "языка вроде Немерле" — по сложности где-то близкие задачи. И там, и там будет хардкорный вывод типов Насколько сложна будет ИДЕ с рефакторингом зависит опять же от того, что за динамический язык у нас. Вот для языка вроде Pure задача вполне посильная и сравнивая по сложности с Немерлевской ИДЕ.

— Ограничения на типы
В динамике они тоже могут быть, не вижу противоречия. Только проверяться будут тестами, а не компилятором.

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

Вот какой стимул у РОР-иста переходить на nrails? Разве что ради скорости. Ну так РОР медленный потому что он тупо медленный, а не потому что динамика. V8 вон быстрее раз в сорок.

А для ASP.NET MVC программиста преимущества очевидны. Ну так им и не надо доказывать, что динамика лучше статики.

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

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

H>А теперь примеры некомбинируемых макросов в студию. А также вменяемые юзкейзы их комбинации.

макрос распараллеливания кода может конфликтовать с linq2sql.

т.к. и тот и другой — хочет select/where заменить на свою конструкцию.

но этот конфликт решается просто: что макрос распараллеливания должен работать всегда после linq2sql, в других задачах — такой явной зависимости может не быть.

зы
причем дьявол в мелочах.
например, распараллеливание + linq2sql может дохнуть в итоге на том, что база технически или по лицензии поддерживает лишь ограниченное кол-во соединений.
соответственно макрос параллеливания может потребоваться учить, чтобы он по разному обрабатывал код с linq и без linq

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

ВВ>Хотя бы потому что с точки зрения любого фреймворка важно не то, как это фреймворк *пишется*, а то, как он используется.

А тебе действительно не важно то насколько легко фрэймворк пишется и насколько он гладко скрывает все сложности разработки прикладной задачи?

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

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

L>Наоборот! С помощью метапрограммирования такое писать очень сложно. Проще заранее разработать ограниченную систему типов. Писать же на макросах анализ такой сложной и низкоуровневой системы типов, как в .NET, на поиск таких высокоуровненых вещей как чистая функция — гораздо сложнее, чем внести это в язык.

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

L>А! Речь про eDSL? Если взять другие языки, то окажется, что с этим там всё в порядке — ruby, например. Или, чтобы было схоже с Nemerle — Scala. Язык не имеет макросов, но писать на нём DSL-и приятно.

Жаль что на фреймворке который показывал здесь Курилка об этом забыли.

L>Если всё таки важен синтаксис, то во-первых — почему? Наверное, захочу примеров — мы как-то с VladD2 обсуждали разницу описания грамматики в Parsec и EBNF. Вместо p* пишем many p, вместо a | b, пишем a <|> b. Конечно, можно переопределить *, | для того, чтобы синтаксис был схож, но даже если нет — отличия только в синтаксисе — насколько это важно? Гораздо важнее в eDSL ведь семантика, как мне кажется.

L>Во-вторых — препроцессоры тоже разные бывают. С удобными разборщиками типа haskell-src-exts или с помощью camlp4 можно очень удобно работать.

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

Z>>Это утверждение говорит только об убогости AOP как внешних средств. Как только оно станет на расстоянии вытянутого пальца, ему найдутся вполне повседневные применения не нарушающие дизайн.

L>А вот примеры очень хочется. Для меня писать pointcut, который матчит по имени (!) то ещё убожество. Абстракция тут явно протекает.

Да тут простор фантазии, Допустим все методы ISession.Commit(), или все методы помеченные атрибутом TransactionScope(); Или все методы, внутри которых есть вызов любого метода ISession. Ни один PostSharp не даст таких возможностей. Да что методы, pointcut оборачивающий все секции lock {} для того же логгирования или профилирования.

Z>>Я оговорился, не IoC в общем смысле, а DI как механизм для него. Достигается например применением AOP ко всем конструкторам в коде.

L>Т.е.? Зачем такие сложности? Что мы от этого выигрываем?

От DI? Или от избавления явного обращения к контейнеру?

Z>>Любой универсальный язык недостаточно выразителен в каждой специфической области.
L>Не так. "Любой универсальный язык недостаточно выразителен в какой-то специфической области" и применение макросов показывает в какой именно.

Любой универсальный язык недостаточно выразителен в некотором множестве специфичиеских областей

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

ВВ>Сколько раз уже нарывались на то, что кто-нибудь залезет в модель того же Linq2Sql, чего-нибудь там добавит, поправит — и все, рассинхрон. *Без тестов* тоже фиг найдешь ошибку.

В иделогии РоР база руками обычно не меняется. Для того там есть миграции. Раньше приверженцы разных Руби утверждали, что такую крутую штуку как миграции и можно залудить благодаря динамике. Но Ziaw воспроизвел миграции не хуже чем на Руби, но при этом в статически-типизированном окружении.

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

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

ВВ>Это ты уже не в ту степь пошел. Статику вс. Динамику я здесь обсуждать не буду, наговорились уже на эту тему. Речь — исключительно о ДАЛ-е. А динамический ДАЛ прекрасно себя чувствуется и в насквозь статическом языке.

Он сам создаст проблемы в следствии той самой рассинхронизации. Раз уж язык у нас статически-типизированный, то ДАЛ должен проверить версию мета-данных БД и выдать сообщение об ошибке если она отлична от той на которую рассчитан ДАЛ. Или ДАЛ должен уметь преобразовать метаданные БД к версии с которой он способен работать. Именно так поступают рельсы. Так что их динамичность никак не используется в этом аспекте.

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

ВВ>>Ну запостил тему в форум "Флейм" и еще удивляешься, что тебя разводят на флейм. В первый раз что ли здесь

Z>Можно сказать, что да Вероятно и в последний, конструктивный диалог тут только с тобой получился.


Э... не говори гоп. С Воронковым обычно все разговоры кончаются флэймами. Он в этом плане спортсмен. Не столь важна тема, сколь хорошая компания .

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

ВВ>Можно сказать, что динамика рулит в вебе, потому что в вебе как раз менее всего проявляются недостатки динамики. А плюсы остаются такими же, как и в остальных случаях.
У динамики НЕТ плюсов.

ВВ>Но сейчас все-таки не 90-е. Клиенты "хочут" аякса и веб-два-ноль. А это значит, что у нас будет куча ДжаваСкрипта. И что толку от того, что в одном маленьком месте мы добавили статики, а во всех остальных у нас как была, так и осталась динамика — причем динамика отборнейшейго, так сказать, "качества".
http://www.impredicative.com/ur/

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

L>Недорого. Для чего я вижу полезно использование макросов — так это всяческая кодогенерация. Это явно говорит о том, что язык недостаточно выразителен в этой области. Т.к. из меньшего (несколько строк макроса) получаем большее (кучу кода на этом языке). Однако для этой цели можно пользоваться и другими средствами — внешние кодогенераторы, препроцессоры и т.д.

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

Хаскелю уже где-то лет двадцать, да? Но вот язык которому без году неделя делает его в области тех же парсеров как котенка, хотя казалось бы это та область на которой Хаскель пиарят последние лет 10.

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

Ваша хваленая ленивость сразу же выбрасывается за борт когда речь заходит о скорости выполнения.

Ваша хваленая гибкость так же почему-то не достаточна того чтобы оформить код именно так как хочется. Сравни, например, грамматики записанные на Хаскеле и грамматики записанные с использованием макроса PegGrammar. Ну, ведь очевидно же, что хаскелю явно не хватает выразительности.

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

L>>По остальным пунктам, как я понимаю, замечаний нет?

H>Конечно есть, но уже сколько раз говорилось о них что лень повторять.

Да бесполезно повторять. Хаскель — это религия. Она даже на совершенно очевидные вещи будут смотреть и говорить что не видят разницы.

Вообще, все эти соры совершенно бесполезны именно по той причине, что это реализованные споры.
Освоить обсуждаемые технологии не так просто. На это нужно много времени и сил. А без их освоения получается не боле чем абстрактная философия. Сравнение теплого с мягким.

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

ВВ>Ну во-первых, особого рефакторинга я в том же Немерле не вижу Вот у C# есть, Решарпер называется.
Плохо смотришь.
Переименование переменных и методов уже работает.

ВВ>Нормальная поддержка ИДЕ — на самом деле для языка с навороченным выводом типов это *сложнейшая* задача.
Не сложнее чем для C#

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

ВВ>Вплоть до того — тут Влад где-то говорил в стиле — такой-то фичи делать не будем, ибо она замедлит интеграцию. Это уже смещает акценты.
Угу... мелкософт тоже рубит фичи в C# по причине "трудно поддержать в IDE".

ВВ>Если брать с чистого листа, то создание ИДЕ для динамически-типизированного языка и "языка вроде Немерле" — по сложности где-то близкие задачи.
Ой насмешил. В недавнем флейме я "IDE" питона десятком строк запутал.
IDE немерла же проблем не имеет и с весьма большими проектами.

ВВ>И там, и там будет хардкорный вывод типов
Вывод типов для динамики в общем случае не работает.

ВВ>- Ограничения на типы
ВВ>В динамике они тоже могут быть, не вижу противоречия. Только проверяться будут тестами, а не компилятором.
Ну и нахрена нам тогда динамика?

ВВ>Вот какой стимул у РОР-иста переходить на nrails? Разве что ради скорости. Ну так РОР медленный потому что он тупо медленный, а не потому что динамика.
Он медленный ибо динамика.

ВВ>V8 вон быстрее раз в сорок.
И он по сравнению со статикой тоже тормоз и памяти жрет немеряно.

ВВ>А священная война в стиле "статика + вывод типов + макросы" во всем круче динамики ни к чему не приведет. Потому что на самом деле не круче. Они разные и для разного.
Вот только ни кто ни разу так и не озвучил ни одного преимущества динамики.

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

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

ВВ>А для конкретной случае веба — ну реально по фиг динамика там или статика. Слишком много переменных, известных только в рантайме, чтобы это что-то решало.
Назови хоть одну.
И вообще http://www.impredicative.com/ur/