Re[18]: Являются ли макросы свидетельством недостаточной выр
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.07.07 16:19
Оценка: 1 (1) +4 :))) :))
Здравствуйте, VladD2, Вы писали:

VD>Пояснил бы суть решения...


Если ты знаешь C++ хотя бы наполовину настолько хорошо, как ты здесь заявлял, мои комментарии излишни.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 12.07.07 12:03
Оценка: +2 :))) :))) :)
Здравствуйте, jazzer, Вы писали:

L>>>Нет. PackedString прошлый век

L>>>Сейчас есть BinaryString.
K>>Это что-то ужасно секретное, да? Поиск в Google и на haskell.org ничего не дал.
J>Значит, Google и иже с ним — тоже прошлый век

Я всегда знал, что lomeo — человек далекого будущего.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'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[26]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 14:19
Оценка: 195 (5) +3
Здравствуйте, IT, Вы писали:

G>>Индустрия имела макросы в далеких 70-х. И отказалась от них вместе с ассемблерами и языками-монстрами вроде PL/1 — с появлением простых и понятных языков высокого уровня.

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

На самом деле макросов, как преобразований над AST, индустрия не имела никогда. Индустрия имела текстуальные препроцессоры a la препроцессор C и макроассемблеры. Все это к современным макросистемам вроде Nemerle или Template Haskell имеет такое же отношение как и макросы Word-а, т.е. сходство только в названии.
70-е годы это раннее детство Scheme, с ее гигиеническими макросами, ну а Scheme никогда в индустрии широко не использовалась.
Поскольку тогда таких средств композиции/декомпозиции кода как квазицитирование и паттерн-матчинг не существовало, LISP и Scheme платили за наличие в них макросов специфическими синтаксическими особенностями, из-за которых отношение к ним в индустрии было в лучшем случае холодным, а в худшем — резко отрицательным. (Естественно, лисперы скажут, что это, наоборот, очень сертезное преимущество. А LISP, по моему, вообще один из самых недооцененных языков. Вот и я его всегда недооценивал, недооцениваю сейчас и буду недооценивать и дальше, по всей видимости.) Со времен LISP макросистемы развивались в основном в сторону повышения безопасности (лиспер скажет — в сторону увиличения числа ограничений).
Посмотрел бы я, что сделали здесь с ветераном, заявившим что-то вроде "Видел я ваш сборщик мусора в шестьдесят-лохматом году в Simula — жуткий тормоз. То ли дело FORTRAN 77 там проблем с хипом вообще нет!" — а обсуждать недостатки макросистемы на примере PL/I это еще смешнее.
Короче говоря, Gaperton валит с больной головы если и не на здоровую, то, по крайней мере, на неизвестно какую. Учитывая, что новые макросистемы — изделия начала — середины двухтысячных годов, легко видеть, что в индустрии их еще никто не имел возможности испробовать, так что все грабли в этой области еще ожидают своих первооткрывателей.
... << 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[38]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.08.07 06:08
Оценка: 73 (3) +5
Здравствуйте, IT, Вы писали:
IT>Какие именно последствия? Ты можешь однозначно, не в терминах "базовый уровень", "изменение граммитики" и прочей лабуды ответить на этот вопрос? Боюсь что нет. И никто не может, потому что опыта такого пока ни у кого нет. Точнее у некоторых он есть, причем положительный, но их здесь всё равно слушать никто не будет.
Ну почему же. Я вот очень внимательно слушаю.
Пока что мое мнение таково: это, конечно же, rather big gun, но фишка именно в том, что если ты пошел валить слона, то лучше иметь big gun, чем обходиться без него.
Я видел страшные вещи, которые люди ухитряются творить безо всякой помощи макросов. Если сильно хочется, могу привести парочку вполне реалистичных ужастиков про свойства, события и прочие, ставшие вполне привычными нам вещи.

Я за то, чтобы оружие все-таки было. И я таки за то, чтобы это оружие было как можно более умным, так что если я нечаянно буду целиться в своего, оно б заблокировало ствол. Потому что мало ли что.
И вот немерлевые макросы пока что выглядят достаточно
а) сложными для использования, так что новичок скорее всего вообще не сможет это снарядить
б) умными, так что новичок не сможет использовать готовый макрос неправильно — компилятор надает ему по рукам (ср. с макросами С/С++)
в) мощными, так что можно решать офигительно сложные задачи офигительно изящно

Так что, имхо, пусть макросы немерле остаются в качестве last resort для случая, когда мы таки увидим очевидно хороший случай для их применения.

З.Ы. Я вот в свое время раз наверное десять прочитал главу про манипуляторы потоков ввода-вывода у Страуструпа, прежде чем понял, как это работает. Внутри у них достаточно сложное сочетание сразу нескольких механизмов языка. А в эизни народ с опытом в два дня пишет cout << "Hello" << endl; совершенно не стесняясь. А ведь перегрузка операторов есмь Страшное Зло, сравнимое с Убойной Силой Макросов. Особенно если мы сильно меняем семантику оригинального оператора. Ведь это же ужас, что такое, когда результат (cout << 1) не совпадает ни с (cout * 2), ни с (cout + cout)! Можно голову сломать, если таким кодом будет пестреть приложение!

З.З.Ы. Что характерно, я не знаю других случаев, в которых бы применяли templates и перегрузку операторов столь безбашенно и столь успешно. Так что в целом можно считать потоки тем самым счастливым исключением, ради которого вообще стоило разрешать перегрузку операторов << // >>. Такого же я ожидаю от Nemerle: будет выделено несколько удачных случаев применения макросов, которые станут стандартом де-факто; в типичном проекте будут применяться все эти стандартные макросы плюс парочка макросов "от местного архитектора", без которых, в общем-то, можно было и обойтись, остальной код будет достаточно консервативным.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Являются ли макросы - аналогия
От: Gaperton http://gaperton.livejournal.com
Дата: 30.07.07 15:46
Оценка: :))) :))) :))
Здравствуйте, BulatZiganshin, Вы писали:

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


Вот-вот. Язык и его правила — это как физические законы. А Макросы — это чорное колдовство, действующая в обход физических законов. А злых Колдунов и Ведьм раньше сжыгали на кострах, ибо нефиг. Я думаю, так.
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 22:58
Оценка: 88 (3) :))) :)
Здравствуйте, mkizub, Вы писали:

M>Я не говорю о сегодняшнем дне, я говорю о завтрашнем.

M>Вы говорите о Nemerle, который работает только в рамках фиксированного набора AST узлов (и расширения компилятора строятся на композиции узлов) — это день сегодняшний.
M>А я говорю о расширяемом AST, где узел дополнительно описывает свою семантику, которая и служит как компилятору, так и IDE и VM, для работы с данным типом узлов — это день завтрашний.

О. Вот мы и добрались до сути.

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

Ты же живешь мечтами. Твоего будущего просто не будет.

Что же касается текста, то очень многие продукты использовавшие ранее бинарные форматы (МС Офис, Опен Офис) стримительно движутся к текстовым форматам (на базе стандартного ХМЛ-я). Правда есть над чем задуматься?

Есть огромная разница между внтренним представлением компилятора/IDE и форматом хренения на диске. Нет никакой нужны хранить бинарную хрень если можно хранить читабельный текст. Формат для хранения придуман много лет назад. Это — текст. Никто не мешает представлять его как в виде фиксированного АСТ, так и в виде изменяемого (если оно оправдано). ВМ тут правда не причем. Так как это редставление и язык ВМ совсем разные вещи (мсил и байтод недопустимо, для обработки человеком, низкоуровневы).

Я еже, кажется, говорил, что твои идеи не новы. Джетбрэйновцы озвучивали похожую идею. Лично мне она кажется просто непратичной. Идея же программирования в АСТ и хранения бинарного формата была опробована еще в GUPTA SQL Windows в 1993-ем (есл не ошибаюсь) году. В итоде они пришли к тому что тоже позволили генерировать текст. Ничего эта идея им не дала.

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


Его расширяемости за глаза хватит на 10 поколений. Язык более расширяемый был придуман более 50 лет назад. Его имя Лисп. Он и сейчас жалеет всех живых (с). Гичше уже ничего не будет. Но такая гибкость просто ненужна людям. Она черезмерна и (парадоксально но факт) приводит к другим ограничениям. И заметь, Лисп тоже имет основную форму в виде текста. Вопрос преобразовния текста лисп-программы в S-вражения в памти — это вопрос пары строк на том же лиспе. И тут просто нечго обсуждать. АСТ Лиспа (точнее S-вражения) самый расширяемый формат на свете. Гибче ХМЛ-я. Так что если тебе нужно именно это, то бери идею.

M> Его расширяемость даёт слишком небольшой результат, по сравнению с возникающими проблемами.


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

M> В целом он лучше (хотя в частностях может уступать), чем тот-же C#,


Опять же, с удоволствием послушаю про частности.

M> но эти преимущества не настолько велики, чтоб тратить огромные средства на переучивание массы народа, переписывания массы сопутствующих средств вроде IDE.


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

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

M>Мне кажется — это попытка перепрыгнуть пропасть в два прыжка.


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

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

M> Если уже прыгнули в сторону расширяемости через трансформацию AST — то прыгать надо до конца, до полного использования AST на всех стадиях разработки программы. Заменить текст деревом. Конечно, так прыгать прийдётся дальше — зато больше шансов перепрыгнуть, а не потратить усилия впустую.


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

M>Возможность добавлять новые типы узлов, работать с семантическим деревом, а не синтаксическим — позволяет и полную интеграцию расширений в IDE,


Опять же расслабься. Мы и так пользуемся всеми благами цевилизации. То что ты называешь "семантическое дерево" у нас называется типизированным АСТ. Оно не толко доступно нам, но и мы даже отображаем его ветки на ветка обычного АСТ. Это дает высокую точность позиционирования в коде.

Что до расширения самого АСТ, то это пербор. На то есть Лисп. Там АСТ гибок как список списков . Нам хватает того, что в АСТ есть ветки описывающие макросы и эти ветки могут иметь свой синтаксис (в довольно широких пределах).

И главное... нас не гнетет тот факт, что код хранится в текствых файлах. Зато их всегда можно отрыть через web и почитать даже без IDE.

M> и возможность генерировать разный код для разных target платформ,


А нам это без надобности. Это делают Моно и дотнет. Мы полностью абстрагированы от них интерфейсом Reflection.Emit и генерируемым им MSIL-ом.

M> и возможность использовать расширения в VM,


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

M> проводить компиляцию с минимальными потерями семантики (и за счёт этого максимально оптимизировать исполнение программы)


Это вообще глупость. Компилятор терят все что не важно для машинного кода. Чем более поздняя стадия тем больше он теряет. МСЛИ не содержит и 10% информации которая есть в исходника. Зато в процессе компиляции появляется информация о типах. Для одни задач она нужна. Для других нет. И мы можем ее использовать. А возиться с МСИЛ-мо — увольте.

M> и многое другое.


А зачем нам многое и другое?

Нам нужно конктные нужные технологии, а не абстракные мечты. Эта технология работает. Она понятна. Она осязаема. И от нее есть ахринительные приемущества. Единственная проблема это недоделанность и отсуствие свободного времени чтобы вкусить плоды этой технологии.

Так что ты давай мечтай и вещай об этом миру. А мы потихоньку доведем свой примитивный инструмент до ума и начнем получать бенефиты.

На последок актуальный анекдот.

Послали директора колхоза делиться опытом западное фермерское хозяйство...
Приезжает он обратно и колхозники его спрашивают:
— Ну, что Семеныч... как там у них?
— Да... конечно у них на полях так чистенько. Кортошку они, конечно, собирают специальными машинами. Машины эти ни одной кортошины не повреждают и не пропускют. Собирают, сразу пакует в качественную тару и помещает в грузок. Дороги у них не как у нас — земляные, а все из бетона и асфальта. Чистенькие такие. Сами фермеры в чистой одежде...
— Ну, и?
— Но кода я им про наши планы рассказал, то они все на задницы сели!

... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 07.08.07 15:02
Оценка: 2 (2) :))) :)
Здравствуйте, night beast, Вы писали:

NB>Дорогой друг.


Ну разве где-нибудь еще можно так легко найти друзей? Нигде кроме, как на rsdn.

NB>Мы очень рады что вы вообще не программист,


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

NB>но раз уж влезли в дискуссию, то потрудитесь изучить инструмент о котором рассуждаете.


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

NB>Задачи на expression templates уже много лет не являются проблемой для С++ кодеров.


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

NB>Если у вас с этим сложности, то почитайте документацию. Ссылки были озвучены.


Почему Вы считаете, что я ее не читал? Или нужно читать и читать пока не исчезнут все симптомы интереса к линейной алгебре?

NB>Реализовывать в 1001 раз линейную алгебру для вас никто не будет.


Опять верю. Пока что ее никто не реализовал даже 1 раз. Линейную алгебру уже реализовывали на C++ один раз на 0,5, тысячу раз на 0,1 и 90050 раз на 0,01 — в том числе и один раз eao197 лично двумя сообщениями выше, так что вместе как раз 1001. Все это очень интересно, но, как говорил Дуглас Адамс, если миллион человек дыхнет на сырое мясо — оно не превратиться в зажареный бифштекс.
Меня интересует хотябы одна реализация на 1. Ну или, на худой конец, одна реализация на 0,9.
Я понимаю, что уметь выдавать перекрашенный фонарный столб за межконтинентальную баллистическую ракету (ну или хотябы убедить, что нужен именно фонарный столб, а не ICBM) для программиста вопрос профессиональной компетентности, но не согласитесь ли Вы, что я как физик имею больше оснований для оценки библиотеки линейной алгебры чем самый пламенный любитель expression templates?
А пока что выслушаешь рекомендации на Blitz++, укажешь на какой-нибудь пустячек вроде четырехкратного оверхэда как здесь
Автор: Klapaucius
Дата: 11.07.07
, например, а собеседник сразу скучнеет и убегает рекламировать Blitz++ в другое место.
... << 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[34]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 06.08.07 09:35
Оценка: +1 :))) :))
Здравствуйте, FR, Вы писали:

K>>Basic — статически типизированный язык.

FR>Лисп, смалталк, питон и руби тоже.

Звучит феерично и психоделично, конечно. Жаль, что это просто недоразумение.
Я написал слово С Т А Т И Ч Е С К И.
И по буквам:
Станислав.
Тамара.
Алиса.
Теодор.
Инокентий.
Чебурашка.
Евгений.
Сергей.
Константин.
Иоанн.
... << 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[27]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 13:45
Оценка: +1 -3 :))
Здравствуйте, Klapaucius, Вы писали:

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


G>>>Индустрия имела макросы в далеких 70-х. И отказалась от них вместе с ассемблерами и языками-монстрами вроде PL/1 — с появлением простых и понятных языков высокого уровня.

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

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


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

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

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

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


Отчего же. Учитывая, что новые макросистемы делают в конечном счете то же самое, что и старые, совсем не трудно представить, какие грабли ждут энергичных "первооткрывателей" технологий 70-х годов, закрывающих глаза на здравый смысл и на опыт индустрии.
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 20:26
Оценка: 16 (3) +2
Здравствуйте, EvilChild, Вы писали:

IT>>Тогда как ты можешь использовать библиотечные классы и их методы, если ты не знаешь точно, что они делают?

EC>Думаю ты понимаешь о чём я, но делаешь вид, что нет: библиотечные классы и их методы ничего не делают с написанным мной кодом.

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

EC>Можешь привести примеры задач, стоящих перед тобой, которые требуют применения макросов?

EC>Помимо приведённого ранее примера про DAL — там выглядит естественно.
EC>Правда в свете LINQ необходимость этой фичи мне кажется менее востребованной.

Давай возьмём для примера тот же линк и попробуем его применить, допустим, для веб-приложения. У linq есть следующие весьма привлекательные возможности:

— устранение одноразовых структур для ad-hoc запросов;
— устранение pass-through слоёв.

Учитывая, что в большинстве случаев логика веб-приложения диктуется именно UI, у нас вместо трёх слоёв и дополнительной структуры может получится вот такая простая вещь из 3-х строк:

grid.Source = from c in customers   
              join o in orders on c equals o.Customer into oo   
              select new { c.CompanyName, OrderCount = oo.Count()

Пока всё просто замечательно.

Теперь рассмотрим проблемы.

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

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

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

Поехали дальше.

В-третьих. Обрати внимание вот на этот
Автор: fuurin
Дата: 04.08.07
знаковый топик и особенно на ответ.

Нет, потому что штатно LINQ2SQL этого не поддерживает, а расширять генерацию SQL можно будет только в следующей версии.


Учитывая, что разница между версиями у нас 2005 — 2008, то как говорится обещанного три года ждут.

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

В-пятых. Предположим, что я захотел добавить кеширование результата запроса в зависимости от параметров. Как мне поможет в этом линк? Да никак. Мне теперь придётся отказаться не только от анонимного типа, но и вернуться к слоям.

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

Что можно было бы сделать на макросах?

Первый пункт устраняется элементарно. Добавить генерацию интерфейса ICustomTypeDescriptor дело техники. Для MS это тоже не составляет абсолютно никаких проблем, но на каждый чих таких интерфейсов не надобавляешься. Мало ли кому ещё чего понадобится? Здесь я с ними соглашусь, но проблему это не решит.

Второй пункт также решается довольно просто. Раз мы знаем всё о запросе в компайл-тайм, то мы в состоянии сгенерировать наиболее эффективный код.

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

Пятый пункт решается элементарно добавлением атрибута withcache(blah-blah-blah).

Шестой. Тоже ничего невозможного. Более того, в компайл тайм можно было бы генерировать не один запрос, а, например, три. Один для админов совсем без фильтрации, один для пользователей с правами и ещё один для гостей. В рантайм было бы достаточно авторизировать пользователя и решить какой из запросов выполнять.

Что касается сложности написания библиотеки макросов подобной линку. Это не просто ложно, это очень сложно. Но! Кто сказал, что нам нужно писать именно такую библиотеку. Сложность решения напрямую зависит от попытки сделать функциональность универсальной. Например, универсальный качественный генератор SQL довольно сложная задача, которая должна учитывать множество деталей и нюансов. Но достаточно убрать эти детали и нюансы, завязаться на свою собственную специфику и генерация SQL превратится в простую задачу для школьников. И уж точно не придётся править компилятор для того, чтобы повторить возможности линка, т.к. никуда не надо будет проталкивать expression tree. Всё можно будет посчитать в компайл-тайм.

И самое главное, не нужно будет ждать 2-3 года до выхода VS 2008.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.07.07 00:54
Оценка: 4 (3) +2
Здравствуйте, Курилка, Вы писали:

WH>>Вопрос в том сколько ты это бущешь писать, сколько отлаживать и с какой скоростью это будет работать.


К>А можно поподробней по поводу выделенного? Макросы по дефолту ускоряют результирующий код чтоль?


В принцепе WH уже ответил. Хочу дополнить примером. Маппинг в BLToolkit на больших объёмах данных работает быстрее рукописного кода. Точнее, быстрее правильного рукописного кода. Никакой вменяемых программист не будет осуществлять доступ к полям в рекордсете по номерам, только по именам полей. BLToolkit проводит предварительную инициализацию, за счёт чего на большом количестве записей вырывается вперёд. Сгенертрованный макросом код, обладающий всей информацией о запросе и структуре мапируемого объекта может генерировать наиболее оптимальный код сразу. Т.е. мы получаем не только более надёжный код, но ещё и максимально быстрый, который, в принципе, вручную написать можно, но это будет означать убийство сопровождаемости кода.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 06.08.07 13:45
Оценка: 2 (1) +4
Здравствуйте, 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.


Понятно, что никто не требует возможности получить типы в для таких языков. Я, собственно, так и написал. И указал это естественной причиной того, что макросистемы именно в таких языках и появились. Но для языка, для которого доступна статическая информация о типах — требовать доступа к информации о типах в макросистеме естественно. Именно поэтому первые макросистемы для статических языков и появились так поздно — при разворачивании макросов основные сложности с типизацией.
... << 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[10]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 08.07.07 10:07
Оценка: +5
VGn>Вопрос, наверное, не в возможности-невозможности, а в удобстве.
VGn>Макросы дефакто более высокоуровневый механизм.
VGn>Мне, допустим, претит строит на классах тяжеловесные паттерны, когда можно обойтись парой строчек макроса.

пример пожалуйста.

VGn>Опять же, паттерны — это всё таки какое-никакое дублирование рализации.

VGn>А как мы уже давно обсуждали, все паттерны в язык не встроишь, да и не надо.

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


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

VGn>Слишком навороченный язык — имхо тоже зло.


ага. И каждый ваш новоопределенный макрос — каждый, делает этот язык все более навороченным — причем, без контроля и толковых спецификаций. Что может быть и ускорит разработку, когда вы работаете в одиночку, но приведет к катастрофе, если над проектом работает большая группа. Сразу напишете неподдерживаемый код, который потом в помойку пойдет через пару лет.
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 13:56
Оценка: +1 -4
Здравствуйте, 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>Конечно, существовало сотни разновидностей бэйсика, так что какой-нибудь из них мог быть динамическим, я точно не знаю. Но большинство реализаций были статически типизированым.


Большинство были как раз динамическими — а именно — все интерпретируемые бейсики проверяли типы в динамике.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: deniok Россия  
Дата: 06.08.07 15:52
Оценка: +1 :))) :)
Здравствуйте, Klapaucius, Вы писали:


K>Одними car и cdr? Это не путь настоящих джедаев. Рекомендую попробовать программировать только с помощью S и K.


Не, современный джедай использует один комбинатор X. Зачем излишества?
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.08.07 09:47
Оценка: +5
Здравствуйте, Cyberax, Вы писали:

C>Почему-то, .NET-программисты страдают "туннельным видением" — все не-MS-технологии они просто не замечают.

Гм.
C> Удобные mapper'ы в виде iBatis'а и Hibernate работают в Java уже который год. И ничего, никакой LINQ не нужен.
Почему-то, Java-программисты страдают "туннельным видением" — все технологии за пределами Java они просто не замечают. Любые нововведения они объявляют изначально ненужными. Но как только эти или аналогичные нововведения таки внедряются в Java, они тут же становятся нужными и верными.
Поэтому енумы в жаве нужны, а проперти — нет; анонимные методы — ересь, а анонимные классы — благо; делегаты — извращение, а классы, вложенные в объект — руль и мастхэв. Ну и так далее. Генерики были не нужны вплоть до какой джавы? Вроде бы 1.5, да? Автобоксинг был вреден до какой джавы?

Не надо сравнивать частные решения с общим подходом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 10:41
Оценка: 22 (4)
Здравствуйте, VladD2, Вы писали:

VD>Я вот все больше склоняюсь к тому, что простое решение — это решение описанное максимально близко к терминам предметной области (максимально высокоуронево). Ну, то есть с Виртом в корне не согласен. А макросы как раз позволяют мне встроить в язык такие прикладные решения. Системы типов этого не позволяют. Даже хаскелевская... если конечно не заниматься на ней МП.


Почему априори считается, что МП — это обязательно макросы?

Что касается встраивания в язык DSL, то на Haskell это получается замечательно. Просто там другой подход, и, разумеется, есть отличия от подхода с макросами. Вот в этой статье, например сказано, что именно Haskell не умеет делать, в отличие от макросов, а что умеет. Но делает это по своему, и не выглядит неестественным.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 09.07.07 12:36
Оценка: 16 (2) +2
Здравствуйте, lomeo, Вы писали:

L>Можно подробнее о выделенном? Почему этого можно добиться только макросами?


Я, конечно, не Gaperton, но раскрыть тему попытаюсь.

Имеем:
x := alpha * p + omega * s;

Разворачивается в:
for(i = 0; i < x.Length; i++)
{
    x[i] = alpha * p[i] + omega * s[i];
}

Даже такой элементарный пример позволяет, в общем-то проиллюстрировать. Чуть более сложный
r := b - A*x;

мне уже расписывать лень.
Каким еще способом можно добиться того, чтобы DSL не проигрывал в производительности коду a la FORTRAN?
Лично мне очень интересно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'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[19]: Являются ли макросы свидетельством недостаточной выр
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 10.07.07 05:33
Оценка: 14 (3) :)
Klapaucius,

K>>Вот Хаскель — продвинутый язык, и в нём можно во многих случаях сделать то, что в Лиспе делается исключительно на макросах. Но не всё. Так почему же Хаскелю не нужны макросы?


K>Ну... Те кто делал Template Haskell по всей видимости думали, что Haskell макросы нужны.


Да, думали...

The single biggest criticism that can be launched against Template Haskell is the lack of compelling applications. We have explored a handful of scenarios in which Template Haskell would be useful, the coolest, albiet unimplemented, being the universal algebraic-fold. But the list of possible applications that we have assembled doesn't warrant the technical effort that Template Haskell represents; nor do the examples that Simon Peyton Jones and Tim Sheard provide in their paper... And so the most interesting question is, perhaps, why the scope of Template Haskell's applicability seems to be so narrow.

(обращаю внимание на первое и последнее предложения)

Наиболее часто применение TH я встречал в виде хаков и триков для достижения убойного перфоманса. Например, известно, что на продолжениях можно получить офигенный прирост производительности — это один из легальных способов форсирования вычислений и избегания ленивости. Но писать в таком стиле довольно тяжело, поэтому TH здесь может оказаться полезен ("может", потому что эффект от прироста производительности и сахара запросто может быть нивелирован усложнением разработки из-за появившейся двухслойности).
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 17:41
Оценка: 6 (1) +2 -1
Здравствуйте, EvilChild, Вы писали:

EC>Я правильно понимаю, что для того, чтобы понять что делает макрос нужно довольно подробно представлять как устроено AST,


Зависит от сложности макроса. Наример, для написания такого макроса много знать не надо:

macro repeatmacro (times, body)
syntax ("repeat", "(", times, ")", body)
{
  <[ for (mutable t = $times; t > 0; --t) $body ]>
}


EC>какие есть фазы компиляции, как AST может трансформироваться на каждой из них?


Для написания более сложных вещей желательно иметь полное представление.

EC>Т.е. при применении макроса с моим кодом может произойти практически любая трансформация?


Практически любая.

EC>Если так, то именно это людей и настораживает.


Пока я услышал только две версии, которые настораживают людей:

— обезъянкам будет трудно;
— неадекватные девелоперы накосячат.

EC>Потому как я применяя yield return точно знаю, что сделает компилятор и как это всё локализовано.


Тогда как ты можешь использовать библиотечные классы и их методы, если ты не знаешь точно, что они делают?

Вообще, есть одна простая мысль, которую я уже неоднократно высказывал.

Сложность/качество/функциональность/добавить-по-вкусу программного обеспечения не может превышать более чем на порядок сложности/качества/функциональности/дабавить-по-вкусу инструмента, на котором оно разработано.

Нельзя в одиночку выкопать котлован для многоэтажного здания с помощью совковой лопаты. Нужен экскаватор. Но и экскаватор абсолютно бессилен перед вечной мерзлотой. Здесь уже нужен Камацу или Катарпиллер со специальным клыком. Может ли быть опасен Камацу в обычных условиях? Может. Сам видел в стройотряде в Новом-Уренгое, как один советский камацист, нажрамшись показывал нашему комиссару как работает буржуазная техника. По неосторожности опустил клык и, даже не заметив этого, пропахал попрёк всю автобазу. Опасно? Опасно. Но, простите, господа, советский камацист был в жопу пьян. Если бы тогда тяжелую технику не стали использовали по причине того, что пьяные трактористы (читай неадекватные девелоперы) будут представлять на ней опасность, то сегодня Вова не показывал бы факи налево и направо всяким Англиям.

Не вижу никакой разницы для производства софта. Сегодня мы уже ограничены теми средствами, которые используем. Всё, приплыли. Даже такая контора как MS, в которой работают тысячи талантливых программистов не может вот так взять и с нуля зафигачить новую операционную систему. Попробовали, не получилось. Пришлось по быстрячку перекрашивать 2003-й сервер в Висту. А почему? Не из-за уровня ли используемых средств разработки? Думаю, во многом из-за этого тоже.

Короче, пора переходить на декларацию, а это в крупных масштабах возможно только с макросами.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: mkizub Литва http://symade.tigris.org
Дата: 05.07.07 20:37
Оценка: +1 -3
Здравствуйте, EvilChild, Вы писали:

G>>Это каждый сам для себя решает, в силу своих знаний и умений. Чем больше твои знания и умения, тем более "гражданская" для тебя разработка, и тем реже тебе требуются макросы. Не наоборот.

EC>Т.е. получается что хочется макросов от недостаточного владения инструментом? Как-то противоречиво звучит.

Это ещё и практике противоречит. Например, моей личной практике — чем больше я работаю, тем больше мне нужно мета-программирование.
Впрочем, на полноту не претендую. Некоторые животные для выживания эволюционируют в более сложные существа, а некоторые с той же целью деградируют. Видимо Gaperton из вторых.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[3]: Являются ли макросы свидетельством недостаточной выра
От: deniok Россия  
Дата: 05.07.07 23:40
Оценка: +4
Здравствуйте, VladD2, Вы писали:

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


VD>Дык, макросы и нужны для языковых расширений. 90% применения в прикладном коде для макросов, на мой взгляд, — это DSL-и. Остальные 10% — это допиливание языка напильником для применения в конкретной сфере. Это допиливание легко ложится в библиотеки и может просто пополнять язык (делая его удобнее для конкретных областей применения).


Безотносительно к системам типов: а почему для DSL-ей обязательно нужны макросы?

Вот в Хаскелле библиотека комбинаторов для парсинга Parsec вполне себе создаёт удобный DSL для соответствующих задач, позволяя легко собирать парсеры из более простых, и вообще использовать их как первоклассные объекты — помещать в списки, передавать и возвращать из функций, etc. И никакой особой магии с типами не требуется, монад (которые, кстати, пользователю библиотеки не видны) вполне достаточно.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка: -1 :)))
Здравствуйте, lomeo, Вы писали:

L>Подозреваю, ... За исключением...По идее...Не знаю, сработает ли здесь.


Что я могу скзать? Может в этом и состоит разница? Вот я, например, не сомневаюсь, что все тоже самое с соблюдением синтаксиса можно залудить средствами макросов Немерла и при этом плучить настолько оптимальный код насколько его вообще можно получить на Немерле (т.е. не отличающийся от оптимального рукописного кода). А ты сомневашся. И сомнения твои вызваны неполноценностью средства, сложностю и тормознутостью самого языка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: FR  
Дата: 11.07.07 02:04
Оценка: +4
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Andrei N.Sobchuck, Вы писали:


VD>>>Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.


ANS>>Белая гарячка


VD>у вас, маньяков? Несомненно. Вы же даже возразить аргументированно не умеете.


Влад ты на самом деле бредишь, возражать на это бессмысленно.
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 09:00
Оценка: :))) :)
Здравствуйте, VladD2, Вы писали:

L>> Даже для 2001. Очень-очень сомневаюсь, что это связано с тем, что реализация не на макросах. Надо с Happy сравнить. Полагаю, проблема всё таки в строках Haskell-а, которые как известно, медленные. Можно попробовать подключить binary string и померить.


VD>Предлагаю запенисометрировать.


Не я. Времени катастрофически нет — сижу на твои посты отвечаю
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Являются ли макросы свидетельством недостаточной выра
От: jazzer Россия Skype: enerjazzer
Дата: 11.07.07 14:14
Оценка: :))) :)
Здравствуйте, VladD2, Вы писали:

D>2. Является ли не нужной ложка если в прниципе суп можно хлебать через край тарелки, а гущу есть вилкой?


Ты, Влад, возможно, не поверишь, но японцы суп именно так и едят, причем вместо вилки — палочки
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 06.08.07 15:43
Оценка: +1 :)))
Здравствуйте, 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[43]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.08.07 06:40
Оценка: +2 :))
Здравствуйте, Cyberax, Вы писали:

C>
C>class UI
C>{
C>  void OnLoad()
C>  {
C>    binder.List = myMapper.select("from c in Customer select c").list();
C>  }
C>}
C>

C>Нужно только сделать соответствующий mapper.

Это мне напоминает Единую Теорию Поля. Скорее всего, Уравнение Всего имеет вот такой вид:
#A = 0;

где A — это некоторый вектор-потенциал, а # — какой-то дифференциальный оператор.
Осталось узнать, что за вектор и что за оператор. И этой фигней народ мается уже восемьдесят лет.
Так же и с маппером — примерно года с 95 если не раньше, народ пытается сделать маппер. Только они всё больше выходят какие-то на диво несоответствующие.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 10.08.07 13:32
Оценка: +4
Здравствуйте, mkizub, Вы писали:

CU>> МП само по себе и "в собственном соку" меня не интересует, а как одно из "в одном флаконе" (наряду с ФП, СП, ПП, ООП, ДП и проч.) — очень даже.


M>SOP является языко-независимой (нейтральной) концепцией и ортогональной остальным парадигмам. Вот то, что ты пишешь — это оно и есть.


CU>>Я хотел что-то увидеть, "уделывающее" лисп по МП, не не такое как N Ан нет — не существует.


M>Опять ты путаешь слова. Оно есть, существует, но ты его не увидел. Нечем, видимо, было увидеть.


Просто нечего увидеть. Недопарадигма без документации и спецификации. И недопрограмма "сама в себе", ограниченная VM, прямо сейчас ничего не дающая. DOC-файл, наполненный маркетологическим бредом и не содержащий ни малейшей структурной информации. Что увидеть?! В сад!

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


Но языком физики достаточно легко описать трудности/возможные решения. А на словах "возьми шест и маши" конечно ничего не опишешь!

M>Так же и парадигмы программирования, вроде ООП/ФП/логической/императивной и пр. — это не просто слова, которые достаточно прочитать. Это такой способ думать.


Бред сивой кобылы. (сорри) Все парадигмы ("настоящие") элементарно описываются обычным человеческим языком. "Неформализуемую" информацию оставьте сектантам.

M>И его надо осваивать так-же, как учиться ходить на канате. А пока ты это не попробовал (а ты даже для себя не сформулировал что ты ищешь) — ты не поймёшь, что такого особенного в SOP.


Опять бред. Не "попробовав" ФП/ООП трудно оценить эффективность парадигмы для определённых задач, но понять сами парадигмы по документации — элементарно.

P.S. А не против именно SOP — но я не увидел именно документации. А сопли "а вот раньше... большинство программистов... было невозможно... а теперь элементарно..." — оставьте маркетологам.

P.P.S. Можете банить — не считаю необходимым вести спор "в техническом русле" с оппонентами, шарахающимися тех. информации как чёрт ладана.

P.P.P.S. Все остальным — ещё раз "сорри"
Re[54]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 22.08.07 23:14
Оценка: :))) :)
Здравствуйте, Cyberax, Вы писали:

C>Мне НЕ нравятся полностью неограниченые макросы.


Дык, а макросы для чего? Ведь всегда можно ограничить неограниченные макросы с помощью неограниченных макросов!
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.08.07 17:41
Оценка: 87 (2) +1
Здравствуйте, EvilChild, Вы писали:

AVK>>enumerator pattern это несколько большее, нежели просто реализация IEnumerable/IEnumerable<T>

EC>Насколько мне известно для foreach необходима и достаточна реализация одного из этих интерфейсов.
EC>Или что-то ещё в этот паттерн включается?

Что то еще. Я не знаю про макрос Nemerle, но в случае C# имеем:

A type C is said to be a collection type if it implements the System.Collections.IEnumerable interface or implements the collection pattern by meeting all of the following criteria:
• C contains a public instance method with the signature GetEnumerator() that returns a struct-type, class-type, or interface-type, which is called E in the following text.
• E contains a public instance method with the signature MoveNext() and the return type bool.
• E contains a public instance property named Current that permits reading the current value. The type of this property is said to be the element type of the collection type.
A type that implements IEnumerable is also a collection type, even if it doesn't satisfy the conditions above.

... << RSDN@Home 1.2.0 alpha rev. 714 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.08.07 13:16
Оценка: 84 (3)
Здравствуйте, VladD2, Вы писали:

G>>Приведи мне пример паттерна, который будет строиться на базе ФВП и паттернматчинга, и покажи, как ты его макросом обернешь.


VD>Возможно неплохим примером будет оператор foreach из Nemerle. О его возможностях можно прочесть тут
Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.
.


Мне кажется именно это решение возможно на чистых ФВП и ПМ:

Предствим фильтра как набор комбинаторов, тогда foreach :: (a -> Bool) -> [a] -> (a -> m r) -> m [r]
Т.е. foreach принимает набор комбинаторов, по ним фильтрует входной поток и применяет к отфильтрованным значениям функцию. m здесь тип, имеющий экземпляр Monad (чтобы использовать WriteLine).

Примерная реализация:

foreach pred xs f = mapM f (filter pred xs)


Пусть есть комбинатор is :: a -> Type -> Bool, isPubluc :: a -> Bool и т.д.

1. Вы можете отфильтровать нужные элементы по типу. Например, предположим, что вам требуется из общего списка членов (typeMembers) некоторого типа отфильтровать только те элементы, которые реализуют интерфейс IMethod (то есть являются методами). Это можно сделать следующим образом:


foreach (method is IMethod in typeMembers)
  processMethod(method);


foreach (`is` IMethod) typeMembers processMethod


2. Вы можете использовать защиту, чтобы обработать только нужные элементы. Например, вот так можно исключить из обработки элементы, значения которых равны null:


foreach (elem when elem != null in someList)
  process (elem);


foreach (!= null) someList process


Другой пример – вы можете захотеть обработать только публичные методы:


foreach (method is IMethod when method.IsPublic in typeMembers)
  processMethod(method);


foreach (\method -> method `is` IMethod && isPublic method) typeMembers processMethod


Тут кстати можно описать комбинатор для объединения двух условий, и пусть он тоже называется when:

when :: (a -> Bool) -> (a -> Bool) -> (a -> Bool)
when f g x = f x && g x


Тогда

foreach ((`is` IMethod) `when` isPublic) typeMembers processMethod


3. Вы можете указывать один образец варианта. При этом будут отфильтрованы только те элементы, которые соответствуют этому образцу:


def expressions = [Literal(1.23), Mul(Literal(2), Literal(3))];
foreach (Mul(_, _) as mul in expressions)
  WriteLine(mul);


Тут сложнее, в том смысле, что мы должны создать функцию для определения Mul это или нет. Как лямбду или с именем — неважно, но должны. Если выразить foreach через list comprehension, то такой необходимости не будет:

expressions = [Literal 1.23, Mul (Literal 2, Literal 3)]
forM [ mul | mul@Mul{} <- expressions ] print


Если же мы пишем универсальный комбинатор, то должны выразить предикат, определяющий Mul-ность терма.

expressions = [Literal 1.23, Mul (Literal 2, Literal 3)]

foreach isMul expressions print
        where
                isMul Mul{} = True
                isMul _     = False


3. (кстати, почему опять три?!) Вы можете производить декомпозицию вариантов и кортежей непосредственно при объявлении элемента в foreach:


def expressions = [Literal(1.23), Mul(Literal(2), Literal(3))];
foreach (Mul(e1, e2) as mul in expressions)
  WriteLine($"$(mul.Eval()) = $e1 * $e2");


Аналогично (строку не буду собирать)

expressions = [Literal 1.23, Mul (Literal 2, Literal 3)]

-- решение на LH
forM [ mul | mul@(Mul e1 e2) <- expressions ] print (e1*e2)

-- решение на универсальном комбинаторе
foreach isMul expressions (\(Mul e1 e2) -> print (e1 * e2))
        where
                isMul Mul{} = True
                isMul _     = False


4. Самый сложный случай практически аналогичен анонимному применению match в функциях:


def expressions = [Literal(1.23), Mul(Literal(2), Literal(3))];

foreach (expr in expressions)
{
  | Mul(e1, e2) => WriteLine($"$(expr.Eval()) = $e1 * $e2");
  | Div(e1, e2) => WriteLine($"$(expr.Eval()) = $e1 * $e2");
  ...
}


expressions = [Literal 1.23, Mul (Literal 2, Literal 3)]

-- пусть будет ещё один комбинатор - предикат, всегда возвращающий True
ok = const True

foreach ok expressions $ \expr ->
        case expr of
                Mul e1 e2 -> ...
                Div e1 e2 -> ...
                
-- разумеется всё что после $ можно вынести в отдельную (вложенную) функцию, чтобы избавиться от case и expr.


Мне кажется макросы нужны когда нужно нагенерить кучу кода, здесь же обычная "управляющая структура"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 06.08.07 09:22
Оценка: 77 (3)
Здравствуйте, Klapaucius, Вы писали:

K>Честно говоря, принимая во внимание лисповский синтаксис и общую идеологию code is data is code, я вообще с трудом представляю, зачем в LISP нужно (квази)цитирование, как я его понимаю. И термин этот вместе с LISP вообще очень редко встречается. Но я не поленился и поискал статьи по этой теме на CiteSeer. Да, статьи по квазицитированию в LISP есть. Самая старая, что я нашел — 1999 года.


Если эта статья -- Alan Bawden. Quasiquotation in Lisp, то поглядите там раздел History.

В двух словах. Сам термин квазицитирование придуман в 40-х Квином (W.V.O.Quine) -- тем самым логиком, по имени которого называют программы, выводящие свой собственный код. В пралиспе МакКарти (60-е) квазицитирования не было (видимо, он тоже не понимал зачем оно нужно в лиспе). Развитие ИИ в 60-70х, опыт работы с S-expressions привели к тому, что многие лисп-системы поимели новые техники -- в статье говорится о ПМ над S-expr (видимо аналог схемовского syntax-rules) и template instantiation — в общем уже близко в quote/unquote. Наиболее близким аналогом квазицитирования в те годы была нотация языка Conniver (кстати — один из разработчиков — Сусман). Там даже сплайсинг (,@) был. Это у нас 1972 год. Сам Bawden подрубился в 1977 году. Он заявляет, что тогда уже квазицитирование было. В конце 80х оно появилось в стандартах CL и Scheme.

Хотя к предмету спора это и имеет мало отношения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: Kisloid Мухосранск  
Дата: 06.08.07 09:26
Оценка: 77 (3)
Здравствуйте, Klapaucius, Вы писали:

C>>Я точно знаю, что квазицитирование в нем точно использовалось.


K>Честно говоря, принимая во внимание лисповский синтаксис и общую идеологию code is data is code, я вообще с трудом представляю, зачем в LISP нужно (квази)цитирование, как я его понимаю. И термин этот вместе с LISP вообще очень редко встречается. Но я не поленился и поискал статьи по этой теме на CiteSeer. Да, статьи по квазицитированию в LISP есть. Самая старая, что я нашел — 1999 года.


Самая известная в этой области работа Алана Баудена здесь. В свое время она мне очень помогла и действительно проливает хоть какой-то свет на этот загадочный термин квази-цитирование
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Re[23]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 01.08.07 16:06
Оценка: 33 (1) +2
Здравствуйте, Gaperton, Вы писали:

G>1) У тебя там применяются атрибуты. Добавление кастомных атрибутов никак не меняет синтаксис языка, и не увеличивает indirection level языковых конструкций.


В этом смысле да. Но в том же немерле синтаксис атрибутов является лишь одним из форм макросов.

Что касается синтаксических конструкций... честно говоря, я пытаюсь понять почему вы считаете это плохой практикой и пока никак не могу понять Почему, например, расширение linq захардкоженное, прибитое гвоздями к C# и VB это хорошо, а набор макросов, делающий тоже самое — это плохо. Почему printf("%d %s", a), убивающий программу или string.Format("{0} {1}", a), приводящий к run-time exception — это хорошо, а $"$a", где просто нет шансов на ошибку — это плохо.

G>2) Удобный биндинг к БД — это даже более ходовая и популярная задача, чем создание парсеров. И для ее решения, так же как ex/yacc, вполне оправдано сделать внешний макропроцессор, совсем не обязательно иметь поддержку макросов в языке. Насколько я понимаю, в твоем тулките, на который ты ссылаешься, так и сделано — макросисиема там не применяется. Этой же цели, кажется, служит явский hybernate? Опять, обошлись без макросистемы. Что имеем в сухом остатке? Индустрия подверждает мой тезис о макросах, не так ли?


Индустрия банально не имеет макросов, поэтому извращается как может. Проблемы pre-compile и run-time кодогенерации хорошо известны и, к сожалению, неразрешимы. Я, например, в своё время поимел много гемороя с pre-compile-time генерацей код. Народ по незнаю правил такой код вручную и когда это всплывало через несколько месяцев, то наступал полный паралич. Перегенерация отменит исправления, а что сломает такое исправление никто уже не помнит. Хорошо, если компилятор матюгнётся, а так можно вообще пропустить отмену и словить потом проблемы где-нибудь у заказчика.

У run-time кодогенерации тоже есть свои козявки. Приходится использовать абстрактные классы, которые к тому же всегда должны быть публичные. Классы, которые не генерируются, но для которых что-то генерируется тоже должны обязательно быть публичными. Мелочь, а неприятно.

Нормальная макросистема может все эти недостатки легко устранить. Но пока что мейнстрим до неё ещё не дорос. Хотя странно это. По-идее, на сегодняшний день это единственный способ существенно увеличить производительность девелоперов.
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 20:29
Оценка: 31 (2) :)
Здравствуйте, AndrewVK, Вы писали:

AVK>К LISP паттерн-матчинг в 70 году был, манипуляция AST в нем тоже была.


Вообще-то, насколько я знаю, LISP стал таким монстром, в котором как в Греции все есть гораздо позже 70го года. Мне бы очень хотелось посмотреть на этот самый pattern-matching в LISP, если честно. В LISP (в CLOS) есть мультиметоды, которые покрывают ту часть задач, которую с пом. PM решают в Haskell — фактически это обеспечение полиморфизма. Другая часть задач, которую решает PM — а именно декомпозиция сложных структурных типов данных в лиспе нужна примерно также, как и газонокосилка на Марсе, ведь типов данных в нем, по большому счету, аж целых два: список и несписок. Поэтому-то PM-у просто нечего матчить, со всем можно справится стандартными комбинаторами. Что-то я не слышал, чтобы в LISP-овских макросах применялся PM.
Примитивный синтаксис и отсутствие необходимости возиться с типами вообще сильно облегчает создание макросистемы. Поэтому метапрограммирование и получило развитие первоначально в динамических языках. Создание приличной макросистемы в статическом языке — задача гораздо более нетривиальная.
Кроме того, тут ведь речь идет об индустрии, не так ли? Утверждается, что макросы, дескать, опробированы в 70-е годы индустрией, и все с ними теперь ясно. Вот только PL/I и макроассемблеры не имеют никакого отношения к макросам, а LISP не имеет никакого отношения к индустрии.
Динамические языки индустрия вообще не приняла. Единственный индустриальный динамический язык общего назначения, который я могу вот так сходу вспомнить — это Смолток, и нужно ли акцентировать внимание на том, что его судьба по сравнению с другими индустриальными средствами, мягко говоря, печальна?
Казалось бы, если индустрия так хорошо все это опробировала, то можно ведь привести ссылки на исследования. Тот же Gaperton любит приводить исследования, в которых с точностью до процента высчитывается превосходство Erlang над C++ по всем возможным показателям. Абстрагируемся от того, насколько они точны — в данном случае важно, что они есть. И если бы были соответствующие исследования по данной проблеме, он бы их нашел — я в нем не сомневаюсь. Но нет. Он рассказывает про какие-то макроассемблеры, которые не только не родственники, но и не однофамильцы. Все дело в том, что таким исследованиям неоткуда взяться. Самый дальний родственник нынешнего Template Haskell и Nemerle — это, наверное, MetaML — а по нему и статей старее 1998-го года нет. Мне, как физику, совершенно непонятно, как могут плоды исследования 1998-го года быть опробированы в 1970-м.
... << 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[26]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.08.07 07:59
Оценка: 24 (1) +1 -1
Здравствуйте, IT, Вы писали:

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

IT>Гапертон пока предпочитает молчать, может быть ты мне ответишь на этот вопрос? Чем принципиально отличается плоходокументированный макрос от плоходокументированного метода?


Тем же, чем отличается незнакомое русское слово в русской речи от речи, скажем, на турецком языке.

IT> Можно перефразировать в текущем контексте. Чем принципиально отличается необходимость разбираться в незнакомом коде, в котором используются незнакомые тебе классы от от кода, в котором используются незнакомые тебе макросы?


Тем, что возможые эффекты от метода несопоставимы с эффектами от макроса. Т.е. метод делает всегда одно и то же — получает на вход параметры, возможно меняет состояние, и возвращает результат. А вот макрос может делать за кадром что угодно, возможности у него значительно шире (собственно, для этого макросы и придумывали). Too big gun и этим все сказано.

AVK>>Спорно. Идее ситаксических макросов 200 лет в обед. Однако ж не прижились пока что.


IT>Интересно, почему тогда народ с таким самозабвением извращается на плюсовых шаблонах?


Спроси у них. Практически все мои лично знакомые программисты относятся к этому крайне негативно.

IT> Не потому ли, что это хоть что-то, что появилось в мейнстриме за последние 20 лет. А все те идеи о которых ты говоришь были всего лишь идеями и никогда к мейнстриму даже близко не относились?


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

AVK>>Это не проблема технических средств, это проблема организации процесса разработки.


IT>Почему ты тогда считаешь, что его нельзя построить так, чтобы не было проблем с макросами?


Зависит от масштаба применения макросов.

IT>А у моих ума хватило за полгода. Что теперь делать?


Учить, разумеется. ИМХО объяснить, что если в начале файла написано autogenerated, do not touch, то ни в коем случае этот файл не трогать совсем не сложно. В особо запущенных случаях можно для SVN скрипт написать, который запретит коммитить генерируемые файлы.

AVK>>Это, мягко говоря, неправда. Skip visibility check еще никто не отменял.


IT>Что неправда? То, что генератор, исходный класс и результирующий находятся в разных сборках? Ну так это я тебе как специалист говорю. Могу даже исходники показать.


А я тебе как специалист говорю — в случае применения для кодогенерации LWCG достаточно в параметре skipVisibilityCheck передать true, и можно спокойно обращаться к приватным полям любых классов в любой сборке.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 09:55
Оценка: 21 (1) :))
Здравствуйте, EvilChild, Вы писали:

EC>Я правильно понимаю, что для того, чтобы понять что делает макрос нужно довольно подробно представлять как устроено AST,

EC>какие есть фазы компиляции, как AST может трансформироваться на каждой из них?
EC>Т.е. при применении макроса с моим кодом может произойти практически любая трансформация?
EC>Если так, то именно это людей и настораживает.
EC>Потому как я применяя yield return точно знаю, что сделает компилятор и как это всё локализовано.

Свобода действий устрицы ограничена двумя состояними — открытой или закрытой раковиной. Именно это деалет поведение устриц столь понятным и надёжным. Увы, пока эти значительные преимущества не превратились в доминирование устриц как биологического вида, но природа работает над этим.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 11.07.07 04:50
Оценка: 18 (3)
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Курилка, Вы писали:


VD>>>Любой DSL.


К>>Ммм, значит DSL на хаскеле или скале "не считаются"?


VD>Считается. Но они получаются слишком ограниченные в сравнении с прмыми решениями. В прочем, причем тут Скала вообще не ясно. Там система типов мало чем не отличается от Ява/Шарпа.


Т.е. DSL рассматриваются только в свете системы типов, остальные возможности языка выкидываем? Интересно...
А по поводу скалы, вот простенький пример отсюда :

val res = db.executeStatement {
select fields ("name" of characterVarying(50)) from "person"
}


Подход, принятый тут (называемый авторами “zygotictype-directed growth”), описан здесь
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 12:18
Оценка: 11 (2) +1
Здравствуйте, konsoletyper, Вы писали:

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


K>Т.е. система типов Хаскелля по отношению к нетривиальным фичам не есть то же самое, что шаблоны в C++? А можно об этом поподробнее, на примерах? И подоступнее, а то там чёрт ногу сломит.


Ты, наверное, насмотрелся на Олега

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

См. например STM Тут несколько статей
Ссылку даю, потому что первая статья для тех, кто Хаскель не знает.

Есть несколько операций readTVar, writeTVar, которые выполняются только в пределах монады STM.
По русски это означает, что объединять эти действия ты можешь только с такими же.
Для того, чтобы вычисление произвести есть операция atomically :: STM a -> IO a, которая проводит STM-акцию.
Никаким другим образом ты не сможешь записать или прочитать TVar-переменную.

Или ST-монада. Это монада состояния работает аналогично. Ты не можешь записать переменную в одном вычислении, а прочитать в другом. Смысл в том, что мы имеем императивный язычок, на котором пишем вычиление, снаружи выглядящее абсолютно referential transparent.

Или обычные IORef ссылки, работать с ними можно только в пределах IO-монады. Грязный код отделяется от чистого системой типов.
Она для этого и предназначена.

Такое возможно на макросах?
Если да, будет ли это так же легко как и здесь?

Это мы ещё не затрагивали классы типов. А там — см. библиотеки Generics, Dynamics и т.д.

Есть и более мощные системы типов — с dependent types.
В частности они позволяют ставить на код такие ограничения, как (из примеров)

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

И всё это определяет компилятор. Это, кстати, можно сделать и на Haskell с MPTC/fundeps/GADT и ещё парочкой флажков, но выглядеть конечно не будет так красиво, как на языках, имеющих такую систему типов.

Как это сделать на макросах?

K>PS: а всякие ката-, хило- и прочие морфизмы, про которые Мейер писал, можно на одном только Хаскелле в общем виде для любых алгебраических типов реализовать, или тут надо привлекть что-то помощнее?


Даже относительно катаморфизма в общем виде ничего не могу сказать:
Тут с mibori было обсуждение.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.07.07 15:38
Оценка: 10 (3)
Здравствуйте, VladD2, Вы писали:

VD>Откровенно говоря я не знаю что такое json. Но наверно пойдет.


Так! Парсер написал. Думал дольше времени уйдёт, наверное, рука набита

Если у тебя есть установленный Haskell, то это сообщение можешь просто скопировать в файл, обозвать его, дав ему расширение lhs, и запустить. В этом файле весь код идёт после '>'.
Он ожидает один аргумент с командной строки -- имя файла, который будет парситься. Твою задачу -- подсчитать кол-во токенов -- я немного изменил, чтобы можно было показать как парситься структура (а то можно было просто накапливать счётчик да и всё).

Сейчас задание такое -- подсчитать кол-во значений в иерархии.

Вроде всё, остальные замечания дальше.

Итак, нам потребуются кое какие библиотеки, например, сам Parsec.

> import Control.Monad (liftM)

> import Data.Char (isControl)
> import System.Environment (getArgs)
> import Text.ParserCombinators.Parsec
> import Text.ParserCombinators.Parsec.Language (emptyDef)
> import qualified Text.ParserCombinators.Parsec.Token as P

Парсить мы будем JSON-овскую структуру, которая состоит из неких значений. Значения могут быть объектом (набор пар — имя/значение), массивом (набор значений), строкой, числом, логическим значением или null.
Всё это выражено в следующем АТД.

> data JsonValue = JObject [(String, JsonValue)]

> | JArray [JsonValue]
> | JString String
> | JNumber Double
> | JBool Bool
> | JNull

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

> main = do

> [fname] <- getArgs
> parseJson fname

Шаблонная для таких целей функция. Читаем файл, парсим его (parseFromFile), если были ошибки -- выводим их, нет -- обрабатываем (handle) распаршенное.

> parseJson :: SourceName -> IO ()

> parseJson fname =
> do parsed <- parseFromFile jsonSource fname
> case parsed of
> Left err -> print err
> Right v -> print (handle v)

Обработка в нашем случае -- это подсчёт всех переданных значений.

> handle = countJsonValue


Собственно сам подсчёт. Ничего сложного. Все значения (даже null) имеют цену 1, массив и объект ещё добавляют к ней колво потрохов.

> countJsonValue (JObject xs) = 1 + sum (map (countJsonValue . snd) xs)

> countJsonValue (JArray xs) = 1 + sum (map countJsonValue xs)
> countJsonValue _ = 1

Та-а-а-ак. Теперь начинается интересное. Для лексера в Parsec есть удобная штука, которая называется TokenParser.
Это просто набор полезных комбинаторов. Для каждого языка он разумеется свой, но ничто не мешает нам воспользоваться чужим.
Комбинаторов этих много, некоторые, которые нам пригодятся, я описал их ниже.

Сначала создадим сам лексер, задав ключевые слова (в принципе нужды в них нет, ну да пусть будут).
Если в json есть комментарии, то их тоже можно было бы здесь задать. И ещё несколько параметров.

> lexer :: P.TokenParser ()

> lexer = P.makeTokenParser $ emptyDef
> {
> P.reservedNames = ["true", "false", "null"]
> }

А вот и сами комбинаторы. Названия в принципе говорят сами за себя.
stringLiteral я здесь закомментировал, а ниже написал свой, т.к. родной не подходит (увы) для парсинга строк именно JSON-а.
Заодно, возможно, будет интересно поглядеть, как пишут лексер. Названия комбинаторов погляди — это инструменты, с которыми мы будем работать.

> lexeme = P.lexeme lexer

> --stringLiteral = P.stringLiteral lexer
> symbol = P.symbol lexer
> float = P.float lexer
> reserved = P.reserved lexer
> brackets = P.brackets lexer
> braces = P.braces lexer
> commaSep = P.commaSep lexer

Итак, это было стандартное вступление, не особо интересное. Сейчас будем писать собственно парсер.
Смотреть, начиная отсюда Комментировать буду уж совсем непонятное.

> jsonSource = object <|> array


Объект это что то вроде:
object ::= '{' members '}' , вернуть JObject members

'{' members '}' -- это braces members
а liftM JObject возвращает нужное нам значение объекта.

> object = liftM JObject $ braces members


члены -- это разделённые запятыми пары.

> members = commaSep pair


pair, думаю, понятно — читаем строку, пропускаем ':', читаем значение, возвращаем пару.

> pair = do name <- stringLiteral

> symbol ":"
> val <- value
> return (name, val)

array аналогично object.

> array = liftM JArray $ brackets elements


elements аналогично members

> elements = commaSep value


value просто перечисляет возможные JSON-значения.
Функция choice разворачивает свои аргументы, разделяя их <|>. Тупой options, в общем.

> value = choice [object, array, jstring, jnumber, jtrue, jfalse, jnull]


jstring, jnumber -- возвращают соответствующее распаршенному значение.
Т.е. float распарсит нам d :: Double, а jnumber вернёт (JNumber d).

> jstring = liftM JString stringLiteral


> jnumber = liftM JNumber float


Для keyword-ов написал отдельную функцию, в принципе это делать было необязательно. Так для удобства.

> keyword kw ctr = reserved kw >> return ctr


> jtrue = keyword "true" (JBool True)


> jfalse = keyword "false" (JBool False)


> jnull = keyword "null" JNull


А теперь более низкий уровень. Как разбирается строка.
Сам stringLiteral — это просто лексема, у которой между кавычками куча символов:

> stringLiteral = lexeme $ between quote quote (many stringChar)

> where
> quote = char '"'

Символ -- это либо заэскейпленный символ, либо обычная буква.

> stringChar = stringEscape <|> stringLetter


Заэскейпленный символ -- читаем '\', дальше меняем букву на соответствующий символ.
См. два списка в функции. Кстати, на разбор строки на konsoletyper-овском парсере было бы интересно посмотреть.

> stringEscape = do

> char '\\'
> choice $ zipWith escaped ['\\', '/', '"', 'b', 'f', 'n', 'r', 't']
> ['\\', '/', '"', '\b', '\f', '\n', '\r', '\t']
> where
> escaped chr sym = char chr >> return sym

Буква — это не кавычка, на слеш, не управляющий символ. Юникод пропустил -- лень писать, там ещё одна-две строчки.

> stringLetter = satisfy (\c -> c /= '"' && c /= '\\' && not (isControl c))


Отличие, которое заметно сразу -- это то, что у меня структуру (АТД) Parsec не генерит в отличие от.
Насчёт first-class правил в парсере konsoletyper-а было бы интересно узнать. Они позволяют делать то, что в bnf нельзя.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.08.07 13:22
Оценка: 10 (1) +1 :)
Здравствуйте, lomeo, Вы писали:

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


Кодогенерация при деплойменте.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re: Являются ли макросы свидетельством недостаточной выразит
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.07 02:00
Оценка: 1 (1) -2
Здравствуйте, EvilChild, Вы писали:

EC>Имеются в виду взрослые макросы a-la Lisp или Nemerle, а не те, что в C.

EC>Или так: нужны ли макросы в таких языках как Haskell?

Сначала ответь на похожие ответы из жизни:
1. Являются ли печки не нужными если есть автомабили с хреновым охлождением двигателя и хреновой теплоизоляцией в которых движок греет ноги?
2. Является ли не нужной ложка если в прниципе суп можно хлебать через край тарелки, а гущу есть вилкой?
...

В общем, являются ли ненужными прмые решения предназначенные для решения каких-то проблем, если тоже самое можно сделать "через жопу, автогеном" (с)?

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

Макросы же — это прямое решение проблемы. При этом совсем не обязательно иметь примитивную систему типов. Она может быть сложна и гибка. Вот толко к ней уже не нужно предявлять требований полноты по Тюрингу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: EvilChild Ниоткуда  
Дата: 04.07.07 17:29
Оценка: +3
Здравствуйте, mkizub, Вы писали:

M>Заниматься мета-программированием через типизацию — это использовать неверный инструмент.

Я не предлагал заниматься метапрограммированием используя систему типов.
Я сделал предположение, что мощная система типов делает макросы менее востребованными.
И хотел услышать аргументы в пользу или против этого предположения.
А вы опять про ножики и ложки
Детский сад в картинках.
now playing: Noisia — Silicon
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: mkizub Литва http://symade.tigris.org
Дата: 04.07.07 19:06
Оценка: +3
Здравствуйте, EvilChild, Вы писали:

M>>Заниматься мета-программированием через типизацию — это использовать неверный инструмент.

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

Да, просто детский сад.
Ну вы хоть себя почитайте.
Макросы — это мета-программирование. Зачем нужно мета-программирование? Чтоб добавить
в язык понятия, которые в нём не существовали. Чем более в язык уже напихано — тем менее
в него нужно добавлять, потому как оно уже там есть. Ерго, мощная система типов делает
макросы менее востребованными. Буквально исходя из определений и одного логического
телодвижения. Очень простой, очень правильный и совершенно бесполезный вывод. Бо
детский сад.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: Gaperton http://gaperton.livejournal.com
Дата: 05.07.07 22:14
Оценка: +3
G>>>Это каждый сам для себя решает, в силу своих знаний и умений. Чем больше твои знания и умения, тем более "гражданская" для тебя разработка, и тем реже тебе требуются макросы. Не наоборот.
EC>>Т.е. получается что хочется макросов от недостаточного владения инструментом? Как-то противоречиво звучит.

M>Это ещё и практике противоречит. Например, моей личной практике — чем больше я работаю, тем больше мне нужно мета-программирование.


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

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


однажды сеймура крея спросили — почему вы используете в своих суперкомьютерах такую простую систему команд? Он улыбнулся и ответил: сложную я просто не понимаю.

мне близка позиция сеймура крея, по сути и по духу. Сложно сделать, уважаемый — любой дурак может. Нет ничего труднее чем выдумывать простые вещи. Которые потом любому идиоту будут понятны.
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 10:41
Оценка: +2 -1
Здравствуйте, VladD2, Вы писали:

EC>>Я не предлагал заниматься метапрограммированием используя систему типов.


VD>Меж тем замена макросов в Хаскле получается только при использования метапрограммирования с использованием системы типов.


Речь не о замене. Речь о том, что необходимость в макросах отпадает, т.к. задача решается другим путём, не с помощью эмуляции макросов, что, конечно же, неествественно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 09.07.07 13:45
Оценка: +3
Здравствуйте, konsoletyper, Вы писали:

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


G>>валяйте, давайте сюда пример, и я покажу, как его сделать без макросов и паттернов. Мне хватит паттерн-матчинга, атомов, и первоклассных функций.


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


Я воспользуюсь flex, или любой подобной тулзой. По ним хотя-бы документация есть, и мой код все поймут, а в велисипеде на макросах еще рабираться надо будет стороннему программеру. Недостатка в генераторах лексеров и парсеров нет ни для какого языка. Буквально для любого языка есть выбор.

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


K>Введение в язык средств абстракции вроде функций, модулей, объектов так же чревато тем, что кто-то понапишет кривых библиотек (вспомним, как было с C++ и строками). И ничего, вроде как-то пишут вполне поддерживаемый код, не отказываясь от этих абстракций.


Странно, пишешь вроде просто и понятно, но такое впечатление — что люди либо не читают, либо не понимают. Проблема не в наличии абстракций вроде функций, модулей, и объектов. Проблема в том, что твои собственные расширения языка никто не знает, и знать, что характерно, не хочет. А по нормальным языкам есть толковая документация и (даже!) учебники. Которые детально разжевывают для непонятливых предназначение абстракций. Ничего кроме нечленораздельного мата у инженера, который потом за тобой баги будет править, твои расширения в большинстве случаев вызывать не будут — потому что на саппорте надо багу бытро править и уметь быстро разбираться в коде (желательно, нешифрованном макросами коде написанном на всем известном языке).

Ты будешь по учебнику писать к каждой своей программе? А если у вас 20 человек пишут один программный комплекс, и каждый шибко умный — макросы пишет, — что тогда? Каждый будет учебники писать? Почему никто не задумывается о том, как процесс разработки реальных систем в больши командах на языках с макросредствами пойдет, и чем кончится, интересно? Это шибко сложно, представить, какой кавардак начнется? Вы знаете, что менеджер сделает первым делом в таком проекте? Он, если у него чувство самосохранения и остатки здравого смысла есть — первым делом строго ограничит применение макросов — они будут запрещены к применению вне рамок очень компактного ядра системы — фреймворка, если он, тот фреймворк, вообще у вас в задаче будет. Потому что он далеко не всегда вообще нужен. И пишут его редко, и допущены к его правке всего несколько человек.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 09.07.07 14:38
Оценка: +3
Здравствуйте, Gaperton, Вы писали:

G>Я воспользуюсь flex, или любой подобной тулзой. По ним хотя-бы документация есть, и мой код все поймут, а в велисипеде на макросах еще рабираться надо будет стороннему программеру. Недостатка в генераторах лексеров и парсеров нет ни для какого языка. Буквально для любого языка есть выбор.


А чего в макросе, генерящем лексер, велосипедного? Если этим всерьёз заняться, написать документацию — будет не хуже любого flex. Тем более, что ничего сверхъестественного там нет — тот же самый EBNF, что и во всяких там ANTLR, синтаксис один-в-один. Да и разбираться в том же ANTLR тоже нужно, как и с макросом. Только, ИМХО, lex-образные утилиты таскать за собой менее удобно, чем ту же самую спеку писать тут же, рядом с кодом, который всё это обрабатывает. Заодно у макросов есть достоинство — любые ошибки в спецификации тут же подчёркиваются IDE.

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


K>>Введение в язык средств абстракции вроде функций, модулей, объектов так же чревато тем, что кто-то понапишет кривых библиотек (вспомним, как было с C++ и строками). И ничего, вроде как-то пишут вполне поддерживаемый код, не отказываясь от этих абстракций.


G>Странно, пишешь вроде просто и понятно, но такое впечатление — что люди либо не читают, либо не понимают. Проблема не в наличии абстракций вроде функций, модулей, и объектов. Проблема в том, что твои собственные расширения языка никто не знает, и знать, что характерно, не хочет.


Нет, я читал внимательно. Но знаешь, в некоторой степени, функции и классы — тоже расширение языков, пусть и примитивное. Мои собственные библиотеки тоже знать никто не знает и знать не хочет (хотя это мы ещё посмотрим ). Чем в этом смысле библиотека макросов отличается от библиотеки функций?

G> А по нормальным языкам есть толковая документация и (даже!) учебники.


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

G>Которые детально разжевывают для непонятливых предназначение абстракций.


В книгах по .NET Framework (точнее, по его отдельным частям ) тоже детально разжёвываются предназначения абстракций. И это не мешает людям писать кривые библиотеки, котрыми больше никто не пользуется. Хотя в случае с C# ситуация лучше, чем была с C++.

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


Я могу так же взять C#, как всем известный язык. Но начать юзать для него вместо .NET Framework библиотеки, написанные неизвестно кем (хотя бы даже свои). И знаешь, инженер, который будет править баги, будет материться не меньше.

G>Ты будешь по учебнику писать к каждой своей программе? А если у вас 20 человек пишут один программный комплекс, и каждый шибко умный — макросы пишет, — что тогда? Каждый будет учебники писать? Почему никто не задумывается о том, как процесс разработки реальных систем в больши командах на языках с макросредствами пойдет, и чем кончится, интересно?


Это уже проблемы команды. Если у них нет толкового архитектора, нет нормального менеджмента, то они всё равно плохо кончат.

G> Это шибко сложно, представить, какой кавардак начнется? Вы знаете, что менеджер сделает первым делом в таком проекте? Он, если у него чувство самосохранения и остатки здравого смысла есть — первым делом строго ограничит применение макросов — они будут запрещены к применению вне рамок очень компактного ядра системы — фреймворка, если он, тот фреймворк, вообще у вас в задаче будет.


Ага, правильно менеджер сделает.

G> Потому что он далеко не всегда вообще нужен. И пишут его редко, и допущены к его правке всего несколько человек.


Но так это же не отменяет полезности макросов. А в команде, которая решила юзать язык с макросами, можно просто ввести долю тоталитаризма.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 10.07.07 06:58
Оценка: +3
Здравствуйте, VladD2, Вы писали:

FR>>В Смаллталке нет супер системы типов, нет и макросов, однако гибкость языка (+ метаклассы) позволяет легко решать те же задачи для которых используются макросы.


VD>Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.


Белая гарячка
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.07.07 15:12
Оценка: +1 :))
Здравствуйте, deniok, Вы писали:

D>Ну почему бы не прооптимизировать конкретный модуль, если видно, как?


Это всё не то Хочется всего и сразу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: IT Россия linq2db.com
Дата: 12.07.07 00:52
Оценка: :)))
Здравствуйте, Константин Л., Вы писали:

КЛ>Ха. А ты думал. Скорость поедания супа палками сравнима со скоростью написания немерле компайлера на с++. Так что все как бы правильно.


Т.е. они макают палки в суп, а потом облизывают их? Но ведь это же ужасно не эффективно
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 30.07.07 10:16
Оценка: +2 -1
VD>Нет. Не знаю. У них только два недостатка:
VD>1. Их нужно писать и отлаживать (как любой код).
VD>2. Они меняют семантику языка.

VD>Оба недостатка будут у любого средства ДСЛ-естроения.


похоже, ты путаешь DSL и eDSL. DSL — это просто любой язык, интерепретатор/компилятор которого ты реализуешь. embedded DSL — это DSL, реализованный как расширение твоего ЯП. через доп. функции, классы, макросы и т.д. т.е. библиотека матричных операций — это уже eDSL. а скажем, любой язык, реализуемый с помощью ParseC — это DSL, но при этом сам ParseC реализует eDSL для описания грамматик

ещё примеры: всякие boost::lambda — это eDSL функционального программирования внутри C++, а byson или regexps — это средства создания DSL
Люди, я люблю вас! Будьте бдительны!!!
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 30.07.07 15:35
Оценка: +3
Здравствуйте, VladD2, Вы писали:

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


G>>Я воспользуюсь flex, или любой подобной тулзой. По ним хотя-бы документация есть, и мой код все поймут, а в велисипеде на макросах еще рабираться надо будет стороннему программеру. Недостатка в генераторах лексеров и парсеров нет ни для какого языка. Буквально для любого языка есть выбор.


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


Я пробовал. И могу сказать, что реальная необходимость писать сложные лексеры-парсеры до такой степени редка в моей работе, что я не буду выбирать язык по критерию чтобы он круто позволял такие задачи решать. Это глупость. Я лучше в том редком случае, когда надо что-то сложное разобрать, воспользуюсь flex/byson или подобными.

А вот если я провожу масштабные исследования в области языков и компиляторов, то тогда да. Тогда я воспользуюсь каким-нибудь OCaml — он позволяет клево с языковыми расширениями играться, в том числе и на чужой, не окамловкой грамматике. Это свойство мне существенно съекономит время. Тем более, что есть замечательная книга — Compilers Construction with ML с примерами, которую можно почитать и новичкам потом дать.

Только я в своей работе не провожу исследований в области языков и компиляторов. Поэтому я в крайней и редкой ситуации — когда припрет — воспользуюсь flex и bison. Чем офигенно обрадую тех людей, кто будет потом разбираться в моем коде — они его поймут.
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 31.07.07 09:14
Оценка: +3
Здравствуйте, WolfHound, Вы писали:

G>>Короче, макросы и раные там навороченные шаблоны конечно крутая штука для шифрования исходного кода и чесания левой пяткой за правым ухом, только на практике не нужная. Думаете, почему в большинстве современных языков нет макросов? В 70-х годах вот были популярны развитые макросистемы. Сейчас — нет, потому что нафиг не нужны. Рынок, так сказать, голосует.

WH>Наверное я программы писать не умею... ибо мне постоянно попадаются задачки которые без кодогенератора не решить...

Действительно странно. Вроде как все языки программирования у нас тьюринг-полные. Я вот ни разу такой задаси не встречал. Может, поделишься задачкой, наконец? А то все говорите, говорите...

WH>вот буквально недавно написал кодогенератор который парсит ~12К кода и генерит еще ~70К (из которых примерно 44К вызовы сишных макросов те в конце концов кода получается еще больше).

WH>Внутри есть алгоритм со сложностью O(N^4)... На данный момент N == 19 но будет рости по ходу добавления функциональности.
WH>И делать ручками то для чего нужен алгоритм четвертой степени при малейших изменениях исходных деклараций мне мягко говоря не хочется. Особенно при том что машина это делает за доли секунды и без ошибок.

У тебя сложность кодогенератора О(N^4)? Ужас какой. Ну так давай пример в студию, посмотрим на этого зверя . В смысле — задачу опиши.
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: jazzer Россия Skype: enerjazzer
Дата: 02.08.07 03:32
Оценка: :)))
Здравствуйте, IT, Вы писали:

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


IT>>>Java — суксь Немерля — the dest


К>>От destiny?


IT>Очепятался


А все потому, что у тебя нет макроса
$theirStupidLanguage - суксь :))) Немерля - the Best :super:
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 02.08.07 07:03
Оценка: +1 :))
Здравствуйте, Cyberax, Вы писали:

>>>Для Немерля есть IDEA?

J>>Ты же был поклонником CodeBlocks & XRef, no?
C>Я вообще на всем пишу (С, С++, Java, C#, Python, Nemerle ). Просто лучшей IDE, чем IDEA я пока просто еще не видел.

Дело не в личных пристрастиях, а в том, что IDE (Idea, Eclipse, MS VS) должна понимать, что происходит в коде.
Тогда она становится "магической" — организовывает поиск, рефакторинг, автодополнения и прочее. Она помогает писать код.
А если IDE не понимает кода, если он для неё просто кусок текста — тогда оно больше мешает писать код, бестолковое.

Тогда что делать мета-языкам, которые ориентированы на макросы и прочие способы расширения? Вносить информацию
о конкретных макросах и мета-данных (аннотациях) в IDE. И что у нас получается в итоге? В итоге — первичным
становится внутрнее описание программы в IDE и компиляторе, а отображением кода оно может свободно манипулировать.
Эти процессы происходят параллельно и в Eclispse, и в Idea, и наверняка в Visual Studio. Это объективная
тенденция — даже не-макросовый язык развивается (новые версии — Java 1.1-1.6, C# 1.0-3.0 и т.д.) и у них
появляются мета-данные, генераторы кода и прочая и прочая.

На что похожа такая среда разработки и доведённый до логического конца язык программирования? Правильно — на
SymADE, на MPS от JetBrains, на среду разработки Intentional Programming.

Поэтому немерле и есть суксь. Она отчаянно цепляется за текстовое представление кода, и для неё принципиально
нельзя создать IDE такого же уровня, как Idea или Eclipse.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 13:27
Оценка: +1 -2
Здравствуйте, 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
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.08.07 09:29
Оценка: :)))
Здравствуйте, Константин Л., Вы писали:
КЛ>дык, посмотри на VladD2. Народ реально с ними парится.

да-да. вот сейчас тут нету Влада и никто с ним не парится
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 03:14
Оценка: :)))
Здравствуйте, Sinclair, Вы писали:

S>Так что не надо за меня оценивать угол моего обзора.


Синклер, ты адекватен.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 08.08.07 15:41
Оценка: +1 :))
Здравствуйте, cl-user, Вы писали:

M>>Заменить текст деревом.


CU>Деревом-деревом!.. В виде списка... в текстовом файле


Пробовали — херня получается , Lisp называется.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 16.08.07 06:48
Оценка: -3
Здравствуйте, BulatZiganshin, Вы писали:

M>>>>А mutable локальные переменные как апдейтить?

C>>>А какие проблемы с mutable-переменными, если есть настоящие замыкания?

M>>Эффективность кода.


BZ>это проблема компилятора, который должен уметь их инлайнить


А вот и не угадал.
Если нам компилятор/язык гарантирует, что данный метод будет заинлайнен — то это те-же макросы, вид сбоку.
Спрашивается, нафига козе баян? Если в N уже есть макросы, более мощные чем инлайн-функции — нафига делать через инлайн, а не макросы?!
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 16.08.07 10:13
Оценка: +3
Здравствуйте, mkizub, Вы писали:

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


BZ>>я как раз вижу templates — это по твоему не полиморфизм?


M>Из википедии (так себе источник, но для справки можно попользовать):


M>

M>Полиморфизм (в языках программирования) — взаимозаменяемость объектов с одинаковым интерфейсом.

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


M>Никакий "различной реализации" для шаблонов я не вижу. Параметризация (что и служит для инстантиирования типа из шаблона) за полиморфизм, IMHO, не канает.


это потому, что и ты, и авторы этой фразы знаете о полиморфизме только из книжек по ООП отгадай, как называется первая статья о type classes?
Люди, я люблю вас! Будьте бдительны!!!
Re[26]: Являются ли макросы свидетельством недостаточной выр
От: Mikl Kurkov Россия  
Дата: 01.08.07 19:22
Оценка: 36 (1) +1
Здравствуйте, konsoletyper, Вы писали:

G>>Индустрия имела макросы в далеких 70-х.


K>Ну-ка, поподробнее об этом. Первый раз такое слышу.


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

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

1974 год.
--
Mikl
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: mkizub Литва http://symade.tigris.org
Дата: 04.07.07 20:23
Оценка: 34 (1) +1
Здравствуйте, EvilChild, Вы писали:

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

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

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

Ну а пересечение множеств этих задач зависит исключительно от конкретной реализации
макросов и конкретной реализации системы типов. Так что имеет смысл сравнивать конкретно
Lisp и ML или Nemerle и Haskell. А макросы вообще и типизацию вообще — ответ
я уже привёл. Тоже этакий "вообще" ответ.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 09.07.07 09:26
Оценка: 33 (1) +1
Здравствуйте, lomeo, Вы писали:

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


L>Для лексера необходимости в макросах нет. Погляди Parsec.


Уже давно глядел. Не понравилось. Во-первых, все эти <###> смотрятся коряво, а хотелось бы человеческого EBNF-образного синтаксиса. Кроме того, мнее вообще непонятно, как это всё работает. Для этого надо сначала монады вкурить (а я этого не осилил), да потом ещё придумать, как извратиться, чтобы на монадах всё это построить. А на макросах я генератор лексера без какой-либо серьёзной математики сделал. Вон, на C++ тоже есть boost::spirit. И вот после мне говорят, что нафиг нужны макросы? А спрашивается, если их уже давно эмулируют через левое плечо на монадах и шаблонах, так почему бы не ввести в язык сами макросы. Даже если согласиться с утверждением, что макросы порождают кривизну, то отсюда следует, что эмуляция макросов породит её большую кривизну.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 09.07.07 10:49
Оценка: 33 (1) +1
Здравствуйте, lomeo, Вы писали:

K>>Во-первых, все эти <###> смотрятся коряво, а хотелось бы человеческого EBNF-образного синтаксиса.


L>Синтаксис очень близок к EBNF вплоть до переименования.

L>Вместо "|" здесь "<|>", вместо +/* — many1/many, вместо '(' — char '(', "abc" — string "abc".

Вот именно это и не нравится. Выглядит не по-BNF-ному.

K>>Кроме того, мнее вообще непонятно, как это всё работает.


L>Это тоже вряд ли сойдёт за аргумент


Нет, тут немножко другой оттенок. Как юзать, я понял. Мне непонятно, как это всё написано. А отсюда следует простейшее умозаключение, что чтобы понять, как подобные вещи вообще пишутся на Хаскелле, нужны жутко извращённые мозги. Типа, если что-то в этом роде захочет написать обычнй средний программист, он наткнётся на БОЛЬШИЕ проблемы, что отталкивает людей от написания чего-то макросозаменяющего. Вот на том же Nemerle я без всяких проблем написал макрос, генерирующий лексер. Причём если какие-то проблемы и были, то они чисто технического плана. Мозги извращать не приходилось.

L>Поверь, для этого не надо вкуривать монады. Достаточно понять, что парсер это функция, дальше всё просто.

L>Да и вообще — у тебя уже есть готовый DSL. Зачем тебе знать на чём он построен — на макросах или монадах?

А если я сам захочу приделать подобную "фичу" к языку, мне не всё равно на чём её писать. Макрос — это легко. А вот монады понять тяжело. Боюсь даже, это не из-за самих монад, а из-за того, как их подают. Пытался читать "The Haskell Programmer’s Guide to the IO Monad". Споткнулся на естественных преобразованиях. Во-первых, в самой статье для объяснения естественных преобразований применяется жуткая нотация, которая не оговорена нигде вообще. Как прекрасно для статьи, претендующей на вводную. Во-вторых, я всё-же нашёл в других источниках более внятное определение естественных преобразований, но так и не увидел объяснения, что же это такое.

L>Так в том то и дело, что макросы не надо эмулировать, если язык позволяет обойтись без них.


Дык, а чем, скажем, шаблоны C++ хуже макросов? Я так понимаю,

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


направлен не на макросы, а на метапрограмиирование вообще? Типа, любое добавление фичи в язык приводит к неподдерживаемому коду. А чем же в этом смысле монады, тьюринг-полные типы и шаблоны лучше?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 16:08
Оценка: 33 (1) +1
Здравствуйте, Курилка, Вы писали:

К>Будет новый набор решений, но вот обязательны ли для них макросы?


Я не знаю. Это будет напрямую зависеть от решаемой задачи. Главное, что я предпочитаю иметь в своём арсенале весь набор возможных средств, а не только тот, который мне определили те, кто считает нас всех обезъянками.

К>Имхо, нужно ограничить их реализумость/применимость/видимость. Т.е. сделать что-то аля "только программист с чёрным поясом по N может писать макросы и он должен учитывать по возможности последствия их применения".


Какие именно последствия? Ты можешь однозначно, не в терминах "базовый уровень", "изменение граммитики" и прочей лабуды ответить на этот вопрос? Боюсь что нет. И никто не может, потому что опыта такого пока ни у кого нет. Точнее у некоторых он есть, причем положительный, но их здесь всё равно слушать никто не будет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: palm mute  
Дата: 09.07.07 17:05
Оценка: 14 (2)
Здравствуйте, konsoletyper, Вы писали:

K>Я уже писал генератор парсера на Nemerle. Генератор парсера — это функция, отображающая некоторое подмножество конекстно-свободных грамматик на множество детерминированных автоматов с МП. В принципе, у меня были идеи, как написать всё это дело на чистом языке. Но это неудобно. Некоторые вещи вообще императивно реализуются проще — например, часто встречающаяся задача отыскать элементы множества, заданного индуктивно. Я так и не придумал хорошей реализации в терминах чистой функции, за исключением грубой эмуляции очереди и множества, просто в чистом случае му ничего не модифцируем, а таскаем очередь и множество в параметрах функции.


Перечисление элементов множества, определенного индуктивно, реализуется элементарно:
inductiveSet constants rules = concat (iterate derive constants)
    where derive elems = concat [ rule elems | rule <- rules ]


Например, множество арифметических выражений:

-- тип данных 
data Expr = Const Int | Expr :+: Expr | Expr :-: Expr

-- преобразование выражения в строку
instance Show Expr where
    show (Const n) = show n    
    show (x :+: y) = showBinop "+" x y
    show (x :-: y) = showBinop "-" x y

showBinop op x y = printf "(%s %s %s)" (show x) op (show y)

-- правила вывода

binop op exprs = [ x `op` y | x <- exprs, y <- exprs ]
addition = binop (:+:)
subtraction = binop (:-:)

-- выражения
expressions = inductiveSet [Const x | x <- [0..5]] [addition, subtraction]

*Main> take 50 expressions
[0,1,2,3,4,5,(0 + 0),(0 + 1),(0 + 2),(0 + 3),(0 + 4),(0 + 5),(1 + 0),(1 + 1),(1 + 2),(1 + 3),(1 + 4),(1 + 5),(2 + 0),(2 + 1),(2 + 2),(2 + 3),(2 + 4),(2 + 5),(3 + 0),(3 + 1),(3 + 2),(3 + 3),(3 + 4),(3 + 5),(4 + 0),(4 + 1),(4 + 2),(4 + 3),(4 + 4),(4 + 5),(5 + 0),(5 + 1),(5 + 2),(5 + 3),(5 + 4),(5 + 5),(0 - 0),(0 - 1),(0 - 2),(0 - 3),(0 - 4),(0 - 5),(1 - 0),(1 - 1)]
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: c-smile Канада http://terrainformatica.com
Дата: 11.07.07 22:44
Оценка: 8 (1) +1
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, c-smile, Вы писали:


CS>>Я согласен с тем что язык программирвания должен быть адекватен задаче.

CS>>Но в системах где язык строится под задачу мы имеем проблему обучения — освоение превращается в нетривиальную и постоянно меняющуюся задачу.

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




Да пожалуйста:
http://terrainformatica.com/sciter
http://terrainformatica.com/tiscript
http://c-smile.sourceforge.net/

VD>DSL-и принципиально проще чем унивирсальные языки. И учить из заранее не надо. Когда человек сталкивается с новой предметной областью, то изучение специального микро-языка является самым малым, что ему требуется изучить. Причем если ему не прийдестя учить этот микро-яызык, то он будет изучать библиотеки облегчающие решение задачи (что как минимум не проще), а потом пытаться писать код которые будет совершенно точно занчительно более сложным и ниуклюжим нежели код на специализированном языке. А если он решит не использовать ни ДСЛ-и, ни библиотеки, то он будет вынжден или создать библиотеки самостоятельно, или вообще нагородить море дублирующегося кода и с вероятностью 99% завалить проект.


Да ты понимаешь... для нового человека в команде много чего учить приходится. Библиотеки , термины, предметную область...
И очень сильно сомневаюсь что самодельный language extension содержит при том достаточно документации для освоения.

CS>>В результате получается...


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




CS>>Я думаю что можно говорить о том что BISON/YACC + С есть некий супер-мета-язык.


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


Входной язык бизона есть именно тот самый микс из синтаксическиъ метаопредений близких к Backus и Naur нотации *плюс* определения хост языка С или С++. Собственноо примерно то же что их себя представляет входной язык Nemerle.

CS>>Такой подход в котором мухи с котлетами отдельно подчас более честный что-ли.


VD>А что там отделено, то? Там как раз довольно глупо все намешано. Вот погляди
Автор: konsoletyper
Дата: 31.03.07
как тоже самое реализовал konsoletyper на Немерле. Вот это действительно отделение мух от котлет. С помощью EBNF описывается чистая грамматика. На ее базе генерируется набор алгебраических типов (вариантов), и уже они разбираются прикладной логикой, которая и делает все что нужно. Это позволяет читать чистую грамматику с одной стороны, и обрабатывать любые тонкости разобранного представления с другой. То есть, действительно, котлеты и мухи отделены по полной порограмме.


"как тоже самое" — что конкретно то же саме? Bison на Nemerle?
А зачем?

VD>Дополнительные бенефиты такого подхода заключается в том, что при изменении грамматики автоматически перегенерируются варианты, что с одной стороны приводит к тому, что все разбираемые конструкции доступны в интелисенсе, а с другой к тому, что правильность кода контролируется в реальном времени (ошибки просто подсвечиваются в IDE).


Я ничего не понял... чем это все принципиально лучше прогона файла граматики через Бизон и показа тех же ошибок в IDE или просто в консоли?

На вот тебе http://blogs.msdn.com/devdev/archive/2005/09/13/465034.aspx статью про то как интегрировать Бизон в VS если так уж надо.

VD>BISON/YACC нервно курят в сторнке. Он просто прошлый век. С подобным решением может тягаться только специализированная IDE вроде той, что разрабатывается для ANTLR 3. Вот только трудозатраты тут уже несопоставимы. Если для парсинга такую IDE написать могут, то для прикладной задачи — это уже будет совершенно неподемная задача. А тут все в автомате. Да и специализированную поддержку для решения на макросах тоже можно сделать. Причем это будет значительно проще нежели создавать специализированную IDE с нуля.


IDE для разаработки языков программирования?
... не, ну наверное кому-нибудь оно надо... ЯП-мазохистам например которые по языку в неделю выпускают. Но я таких даже и не знаю где искать.

Чего-то ты как-то неадекватно все воспринимаешь. YACC и всяко разных других Compiler Compilers было, есть и будет.
См. http://en.wikipedia.org/wiki/List_of_compiler-compilers . Или это я опять на твою больну мозоль граблей наступил?
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 08.08.07 08:49
Оценка: 6 (1) +1
Здравствуйте, WolfHound, Вы писали:

G>>Плохо объясняешь? Если ты словами задачу и проблему объяснить понятным образом не можешь,

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

G>>то каково то по твоему коду будет разбирать, интересно? С мега-макросами и всем прочим.

WH>А мой код очень простой.
WH>Причем он простой именно благодоря макросам.
WH>Хотя не только. Я еще использовал визитеры, замыкания и немного зашаблонил.

Сомневаюсь. Ты даже на plain russian не в состоянии "очень просто" задачу описать.

WH>Обязьянка конечно не поймет но их к разработке это либы и близко не подпустят.

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

G>>Почему их несколько, а не один?

WH>По тому что надо.
Умному и воспитанному человеку не составит разницы это объяснить. Раз не объясняешь — значит опять боишься.

G>>Сколько у тебя таких кластеров — в штуках, и сколько всего пространств, тоже в штуках?

WH>А какая разница? Ибо либа не стоит на месте и в любой момент могут появится новые.
Тебе сложно ответить на этот вопрос? Интересно, почему?

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

WH>Работаю я в основном с плавучкой.
WH>Но:
WH>1)Я не в вакууме работаю
Аргумент однако .

WH>2)Некоторым алгоритмам пофигу с каким именно цветовым пространством они работают.

WH>Те я могу загрузить картинку, повернуть ее на 90 градусов, увеличить в 2 раза (point sampler'ом) и сохранить.
WH>При этом ни разу не приведя картинку в пространство с плавающей точкой.
И чего в этом хорошего? Короче, все проясняется. Понятно теперь, откуда ты сложности на свою голову нашел.

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

Не надо домножать каналы на значение альфы. Она отдельным каналом идет, и пусть идет.
Нелинейные коррекции проводить при преобразовании к плаващей запятой тоже не обязательно

WH>3)Некоторым алгоритмам нужны битмапы с низкой разрядностью.

Если это причина — то потери точности у нас не будет.

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

WH>Тогда теряется контроль компилятора.
WH>А это критично. Ибо если использовать цвета которые скоректированны не так то полезут артефакты.
Контроль копилятора — это не критично. Проверяй тип картинки в динамике (заводишь член класса — тип картинки). Это одно целочисленное сравнение — против десятков тысяч-миллионов операций на одно преобразование, так что никакой просадки производительности не будет. Так же в динамике можно и пространства между собой преобразовывать автоматически — логика выбора преобразования это чушь по сравнению с самой обработкой. От динимики еще никто не умирал пока, из тех, кто имеет привычку писать регрешшн и unit-тесты.

WH>А делать коррекции на каждый чих это очень дорого.

WH>Я пробовал.
WH>Это просадило библиотеку и по скорости и по объему и по запутанности кода.
Что именно ты пробовал. На сколько именно процентов это "просадило" библиотеку по скорости. На сколько увеличился объем кода.

На слово тебе я не поверю. Ты так изумляешься, что я тебе не верю, когда ты говоришь, "так надо", смешно, сил нет. Напоминаю тебе — ты не Иисус Христос, чтобы тебе верить. К тому же, я уже пересказал твои макросные идеи нашим специалистам по обработке изображений, они ржали как ненормальные, услышав про анализ графа. Удивляются, как это так выходит, что буквально всем кроме тебя отсутствие макросов работать в этой области не мешает вот уже как пару десятков лет.

G>>Приведи пример двух разных RGB, если тебя не затруднит.

WH>Линейное и прецептурно линейное. Отличаются грубо говоря гамма-коррекцией (реально там болие сложная зависимость но гамма-коррекция дает неплохое приближение).
WH>Путать их нельзя. Иначе полезут артефакты.
Ну не путай, кто тебе мешает. Есть масса вариантов, как их не спутать. Заведи у класса Image член под названием color_space и не путай себе на здоровье.
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.08.07 11:10
Оценка: 6 (1) +1
Здравствуйте, VladD2, Вы писали:

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


VD>У меня универсальный механизм компайл-тайм рефлексии и средсва прмого генерирования кода. С их помощью создание частных, всокопопроизводительных случаев дело времени и техники.


Не понял в чём отличие от моего случая.

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

VD>А зачем вообще сам Хаскель? Вопрос из той же серии.

Да нет, я не о том. Я согласен, что IDE — это совсем неплохо. Я имею в виду зачем именно VS?
Есть же Emacs, vim, есть собственные IDE — hIDE например или yi.

У меня в Emacs есть автодополнение, навигация по коду, подсказки по типам функций например, список для быстрого нахождения нужной функции/класса/инстанса, рефакторинг, запуск в GHCi. Сам же редактор очень даже неплохой.

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


Да.

VD>Сразу пояляется две вароса.

VD>1. Это только мне кажется все слишком запутанным, а всем мало-мальски знакомым с Хаскелем все очевидно? Например, я так и не понял как этот волшебный deriving объясняет компилятору как отображать поля некой записи (или как там составные типы в Хаскеле обзывают?). Что при этом происходит со встроенными типами вроде кортежа? В общем, откровенно говоря я так и не вкурил тонкостей. Мне все это кажется магией (т.е. содержит много необъясненных моментов).

В GHC деривинг для Data, Typeable встроен. Но его можно описать: это решение называлось раньше (как сейчас не вспомню, если интересно, потом поищу) — derivable type classes, когда мы описываем класс сразу с шаблоном реализацией, т.е. по сути это специализированные макросы, как и в случае с rewrite rules.

VD>2. Что делать если в каких-то частных случаях нужно сделать частный алгоритм обхода? Ну, как с тем же зацикливаением бороться?


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

VD>Дык маросы это и есть такие средства. Точнее не сами макросы, а их реализация. Просто в случае с макросами для меня все намного очевиднее. Я просто имею API статической рефлексии (т.е. API позволяющий читать описание типов в компилируемом проекте). С его помощью я могу сгенерировать специализированный код любой сложности (от gmap, до частных случаев вроде описанного мной).


В SYB в принципе неважно пользуешься ли ты автоматической генерацией экземпляров классов или пишешь их вручную. Идея не в этом. Писать там мало, но пользовать gmap можно везде. Автоматическая генерация — это следующая задача по сокращению кода, и она уже лучше всего (IMHO, как и всякая задача по генерации кода) решается макросами или специальными средствами, подобными макросам.

VD>У этого подхода есть как приемущества так и недостатки. Приемущетсва: гибкость, наивысшая скорость получаемого кода, прямолянейность реализации. Недостатки... пожалуй он один, но глобальный — это компайлатайм-решение. И оно не может применяться для типов о которых неизвестно во время компиляции (например, о типах из динамически подключаемых библиотек).


Почему? макросы же могут и в рантайме работать.

VD>Можно об этом по продробнее? И особенно о том как можно совместить генерируемые компилятором сущности (ну, там Typeable и т.п.) с custom-кодом который нужен прикладному программисту.


То, что в других языках делается рефлексией, в Хаскеле просто является экземпляром класса Typeable:

data Person = MkPerson { personName :: String, personAge :: Int }

instance Typeable Person where
    typeOf _ = mkTyConApp (mkTyCon "Main.Person") []
        
instance Data Person where
        toConstr person =
                mkDataConstr (dataTypeOf person) "MkPerson" Prefix
        dataTypeOf person = ... -- неохота писать, смысл ясен полагаю.


То же самое сгенерится в случае если мы укажем deriving (Typeable, Data).
Затем мы может получать информацию о типе, которую сами же и забили.

VD>Ну, скажем простейшая задача. Хочу сгенерировать некий код для Х типов меня в нем код функции в зависимости от тех или иных условий. Ну, скажем если в типе есть строки, то вывести их на консоль, а если нет, то ничего не делать.


Это тот же gmap , только не gmapT, тип которого (forall b. b -> b) -> a -> a, а gmapQ :: (forall b. b -> r) -> a -> [r], т.е. мы не отображаем одну структуру в точно такую же, но с изменёнными полями, а делаем по ней запрос для отдельных полей и собираем результаты этих запросов в список. deniok уже привёл пример с подробностями.

Могу лишь добавить, что этих gmap-ов три штуки. Два уже ты знаешь. Третий угадаешь, если вспомнишь на каком языке мы пишем Разумеется, он называется gmapM и относится к монадам. Т.е. это тот же gmapQ, только результат не список, а монада: gmapM :: (forall b. b -> m b) -> a -> m a

На самом деле есть более универсальный комбинатор, через который выражаются все эти три gmap-а, и называется он, разумеется gfold

VD>Ктр такрй SYB?


Scrap Your Boilerplate. Решения, о которых мы говорим.

VD>Может быть, может быть... Но хотелось бы глянуть на реальном тесте. Да и объяснения "природы" более подробнрые не помешали бы.


Ну, я постарался тебе дать самую общую схему, поэтому не могу понять, что именно не ясно?

VD>Хм... Одно "но". Не выполняем (это уже динамическая рефлексия), а генерируем. Чувствуещь разницу? Выполнение по условию в рантайме это немного не то. И гибкость не та, и скрость фиговая.


Да. В SYB для каждого поля делается проверка cast-ом. У тебя сразу выбираются нужные поля.
Насчёт производительности сейчас ничего не скажу, но когда авторы меряли ручное решение и через gmap (с самописным тормозным cast-ом!!) — у них было отставание в 3,5 раза.
Сейчас и cast встроен и он гораздо быстрее, да и оптимизации, которые они для GHC обещали тогда (1999?) наверняка были написаны. Это, конечно, не оправдание, ручное (либо сгенерированное) скорее всего будет быстрее — там всё таки сразу выбираются нужные поля, но вполне возможно, что сейчас разница уже практически незаметна.

VD>1. Когда производится анализ содержимого типа? В рантайме или в компайлатайме? Т.е. генерируется ли компилятором код вроде:

В рантайме

VD>2. Как можно вмешаться "руками"?

Есть комбинаторы, например, everywhereBut. Задачу надо смотреть.

VD>Дык, а эта тема о чем тогда?

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

Но ведь изначально вопрос стоял так: являются ли макросы неким маркером, сигналящем о недостаточной выразительности языка в той области, в которой они в этом языке применяются. Я считаю это мнение совсем небезосновательным. Т.е. есть, наверное, некоторые области (в частности кодогенерация) в которых лучше макросов нет, за исключением частных случаев. Но в тех областях, о которых приводили примеры — парсер, обход — существуют отличные решения без макросов. Просто в языке хватило средств для выражения простых решений.

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

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


VD>Значит такие макросы.


Ну представь, что у тебя нет getClass, typeof или как определение типа называется в Немерле. Как ты напишешь быстрый каст, который просто будет сравнивать два указателя?
Хотя это мы отвлекаемся.

VD>Руби, Питон и ЯваСкрипт — это скрипыт. Скрпты до мозга костей. Их методы метапрограммирования на прочь убивают любые потуги в лпане повышения производительности (компиляции), надежности (статические проверки) и поддерживаемости.


Это другой разговор. Раз кто-то ими пользуется, значит кого-то устраивает производительности и надёжность, обеспечиваемые этими языками. Речь не об этом, а о выразительности в построении DSL.

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


Не знаю, я бы не назвал его типичным. На нём же можно писать без аннотаций типов.

VD>На счет просты — вопрос спорный. Я вот так и не понял мноих аспектов реализации. Хотя похоже на счет gmap я ошибся. Но что-то мне кажется, что в описанинии gmap приведенном тут содержатся "чудесные" средства. То есть нечто, что нельзя сделать если ты не создатель компиляора. Макрсоы же это четко детерминированные средства развития компилятора. Минимальный АПИ который позволяет создавать "чудесные вещи" вроде gmap. Причем, что немаловажно, позволяют любому смертному.


Да нет там ничего Просто визитор.

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


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


VD>Лучше бы объяснил термин.


Управляющие структуры? if, for, while, repeat. Ветвление и цикл.
Наверное имелось в виду, что if, while и прочее — легко нарисовать в виду функций, в силу ленивости.


Большое письмо получилось, может разбить?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 30.07.07 12:01
Оценка: 5 (1) :)
L>>>Чувствую придётся всё таки мне переписать Parsec на ByteString и написать какой нибудь простой лексер.

BZ>>если не ошибаюсь, это один из GSOC проектов этого года


L>Э-э-э, а там какие-то сложности?

L>Вместо CharParser написать свой (+ все комбинаторы над ним, разумеется), для этого State для GenParser сделать либо независимым от списка токенов, т.е. с возможностью использования любой коллекции, ну или сам State сделать классом, а не типом.

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

L>Кстати, уже что нибудь есть в этом проекте? Есть где почитать?


ой, это надо искать. лучше спроси в кафе/irc
Люди, я люблю вас! Будьте бдительны!!!
Re: Являются ли макросы свидетельством недостаточной выразит
От: Gaperton http://gaperton.livejournal.com
Дата: 05.07.07 10:33
Оценка: 2 (1) -1
Здравствуйте, EvilChild, Вы писали:

EC>Имеются в виду взрослые макросы a-la Lisp или Nemerle, а не те, что в C.

EC>Или так: нужны ли макросы в таких языках как Haskell?
Я думаю, и так понятно, кто за, а кто против . Влад уже выступил, могу добавить от себя — я сторонник тезиса, что необходимость в макроподдержке при гражданской разработке является симптомом недостаточной выразительности языковых средств, в т.ч. и системы типов.

За исключением случая разработки языковых расширений — здесь хорошая макросистема способна сократить трудозатраты на его создание и поддержку.
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 04.08.07 20:25
Оценка: 2 (1) +1
Здравствуйте, IT, Вы писали:

M>>Новый тип типов. Мне его удобно для примера пользовать, так как в Java изначально небыло enum-ов, и они реализуются сравнительно просто в виде "расширения", как трансформация AST (кодогенерация).


IT>Понятно. Т.е. если я правильно понял, то enum в джаве представляет собой просто синтаксический сахар.


Нет, записи "enum Color" и "class Color extends Enum" не эквивалентны. Синтаксический сахар — это упрощённый способ записи, а не определение нового семантического понятия.
Скажем, в Python записи "self.foo()" и "foo(self)" просто эквивалентны, потому accssor для call является синтаксическим сахаром — в нём нет семантики.

M>>Теперь внимание — вопрос.

M>>Каким образом из правил кодогенерации (трансформации AST) IDE сможет понять, что red, green, blue — это константы,

IT>То что это константы следует из final. Правильно?


final — это sealed, неизменяемая ссылка или значение. А константы в яве — это числа, символы и прочее. В switch можно было использовать только int/char, а теперь и enum (но не в перемешку с int!!!) — константность эта семантическая, а с точки зрения JVM они не являются константами.

enum-ы я привёл в качестве простого примера. Легко привести и более "продвинутые" примеры. Взять тот-же embedded SQL или GUI designer-ы.
В IDE, которая понимает SQL можно встроить дизайнер базы данных, auto-completition для embedded SQL.
В IDE, которая понимает GUI можно визуально строить диалоги, привязывать их к обработчикам событий и пр.
Наглядный пример — продукты Борланда. Дельфи и JBuilder имеют интегрированную поддержку SQL и GUI на уровне недоступном Nemerle как компилятору отдельному от IDE.
Аналогично MS Access и Visual Basic.
При этом дизайнер таблиц в Дельфи или Access — это полноценный язык программирования, только "визуальный", а не текстовый.

M>>Эти правила (что есть enum как понятие) — присутствуют в мозгах программиста. Трансформация AST — это применение этих правил, а не определение этих правил.


IT>Для данного конкретного случая достаточно обучить IDE выдавать список констант определённых в классе. Вся информация для этого у нас есть в AST. То, что это именно enum знать совершенно не обязательно. В результате это будет работать не только для enum, а для любых вариантов данного паттерна.


Вот именно. Надо обучить IDE. Обучим мы его конкретно enum-ам или целому классу подобных расширений — не суть важно. Я именно и говорю о необходимости обучения IDE тем расширениям, которые мы добавляем в компилятор. Тогда обученный IDE может интегрировать в единое целое и embedded SQL, и GUI designer, и редактировать комментарии в виде HTML/XML кода, и генерировать конфигурационные файлы (в формате XML, например) из настроек проекта и т.д. и т.п.

IT>Нет, совсем не так. Они не просто не видят полезности, они яро протестуют. Большая разница.


Они бы протестовали значительно меньше, если бы имели реальный опыт работы, и этот опыт показал полезность расширяемости компилятора. Плюс, эта полезность должна превышать потери. Возможно, их представления о потерях другие — для кого-то утрата GUI designer-а не представляет проблем, а для кого-то это ключевая фича инструмента. Полезность включает в себя много аспектов, вроде лёгкости освоения, типичных задач которые решал (и собирается решать) в своей жизни программист, качество поддержки и широта community и так далее.

IT>Меня в данном случае интересует именно компилятор. Все другие возможные на сегодняшний день способы автоматизации моей работы я уже прошёл и они мне действительно малоинтересны.


IT>AST нам даёт всё что нужно. Возможно мы просто понимаем под AST разные вещи.


Я не говорю о сегодняшнем дне, я говорю о завтрашнем.
Вы говорите о Nemerle, который работает только в рамках фиксированного набора AST узлов (и расширения компилятора строятся на композиции узлов) — это день сегодняшний.
А я говорю о расширяемом AST, где узел дополнительно описывает свою семантику, которая и служит как компилятору, так и IDE и VM, для работы с данным типом узлов — это день завтрашний.
Nemerle пытается остаться в рамках текстового представления, и тем ограничивает свою расширяемость и возможности интеграции расширений в другие средства разработки и исполнения программ. Его расширяемость даёт слишком небольшой результат, по сравнению с возникающими проблемами. В целом он лучше (хотя в частностях может уступать), чем тот-же C#, но эти преимущества не настолько велики, чтоб тратить огромные средства на переучивание массы народа, переписывания массы сопутствующих средств вроде IDE.

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

Возможность добавлять новые типы узлов, работать с семантическим деревом, а не синтаксическим — позволяет и полную интеграцию расширений в IDE, и возможность генерировать разный код для разных target платформ, и возможность использовать расширения в VM, проводить компиляцию с минимальными потерями семантики (и за счёт этого максимально оптимизировать исполнение программы) и многое другое. Компилятор сам по себе, новый язык программирования сам по себе — это слишком мало, слишком маленькая часть всех средств разработки и исполнения программ.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 06:05
Оценка: 1 (1) +1
Здравствуйте, konsoletyper, Вы писали:

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


Для лексера необходимости в макросах нет. Погляди Parsec.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.07.07 07:30
Оценка: 1 (1) +1
Здравствуйте, VladD2, Вы писали:

FR>>На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.


VD>Решение конечно на шаблонах с применением Буста?


Принципиальная схема реализации отложенных вычислений в C++ изложена у Страуструпа в 3-м издании "Язык программирования C++" (Б.Страуструп, Язык программирования C++, спец. изд./Пер.с англ. — М.;СПб.:"Издательство БИНОМ" — "Невский Диалект", 2001г. — 1099с., ил.) Раздел 22.4.7 "Временные массивы, копирование и циклы", стр.743.

Без шаблонов и Буста.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: mkizub Литва http://symade.tigris.org
Дата: 06.07.07 14:05
Оценка: -1 :)
Здравствуйте, the_dip, Вы писали:

VD>>Я вот все больше склоняюсь к тому, что простое решение — это решение описанное максимально близко к терминам предметной области (максимально высокоуронево). Ну, то есть с Виртом в корне не согласен. А макросы как раз позволяют мне встроить в язык такие прикладные решения. Системы типов этого не позволяют. Даже хаскелевская... если конечно не заниматься на ней МП.


_>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?


Написать Windows Vista за 3 года уложившись в бюджет 1 млрд. баксов.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: Константин Л. Франция  
Дата: 09.07.07 16:33
Оценка: +2
Здравствуйте, konsoletyper, Вы писали:

[]

K>Я могу так же взять C#, как всем известный язык. Но начать юзать для него вместо .NET Framework библиотеки, написанные неизвестно кем (хотя бы даже свои). И знаешь, инженер, который будет править баги, будет материться не меньше.


Зато отладка макросов это очень неприятное занятие.

[]
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.07 18:35
Оценка: -1 :)
Здравствуйте, FR, Вы писали:

FR>В Смаллталке нет супер системы типов, нет и макросов, однако гибкость языка (+ метаклассы) позволяет легко решать те же задачи для которых используются макросы.


Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: c-smile Канада http://terrainformatica.com
Дата: 09.07.07 20:23
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


Я согласен с тем что язык программирвания должен быть адекватен задаче.
Но в системах где язык строится под задачу мы имеем проблему обучения — освоение превращается в нетривиальную и постоянно меняющуюся задачу.
В результате получается что единтсвенным пользователем разлапистой системы макросов (нового ЯП фактически) становится сам автор этой системы.
Т.е. сама супергибкая система теряет смысл очень часто.

Я думаю что можно говорить о том что BISON/YACC + С есть некий супер-мета-язык.
Такой подход в котором мухи с котлетами отдельно подчас более честный что-ли.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 10.07.07 09:52
Оценка: +2
Здравствуйте, FR, Вы писали:

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



FR>>>Так что думаю на любой функциональный язык перепишется.


G>>Ну, это все-таки жесть В схеме можно и замыкания с деструктивными присваиваниями использовать — должно быть проще.


FR>Ты сходи по ссылке, нет там императивщины.


Я знаю. Эта ссылка проходила в одной дискуссии в декларативном программировании. Мне еще тогда не понравилось, как там сделано. Мне кажется, сделать классы на схеме с императивщиной (выразить через замыкания на общих переменных) должно быть проще. Am I wrong?
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка: -2
Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.


ANS>Белая гарячка


у вас, маньяков? Несомненно. Вы же даже возразить аргументированно не умеете.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 11.07.07 08:27
Оценка: +1 :)
Здравствуйте, Курилка, Вы писали:

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


FR>>Разве обошлись, вроде в тех же запросах используются именно ленивое вычисление параметров.

К>Аргументируй, не вижу там ничего ленивого, или наличие ф-ции, которая вызывает/выполняет DSL и есть такая ленивость?

Я не совсем понял как там передаются те же условия в запрос, ведь они не должны вычислятся сразу, раньше тут на RSDN был пример реализации своих управляющих конструкции на Scala и аналогов на D, там использовались именно ленивые параметры (http://www.digitalmars.com/d/lazy-evaluation.html) так что я подумал что здесь тоже самое.

FR>>Лямбды конечно тоже.

К>Тогда макросы — тоже ленивость? Ониж генерируют код, который сразу не выполняется.
К>Плюс паттерны стратегия/комманда тоже туда пойдут.
К>Т.е. теоретически, конечно, это есть некая ленивость, но вот с термином ленивых вычислений, аля как в хаскеле это не очень соотносится имхо.

Теоретически оно конечно Но я хотел сказать только следующее достаточно блоков кода (или аналогов из функциональщины в виде лямбд и фвп) чтобы язык был настолько гибким чтобы практически не нуждатся в макросах (например http://www.rebol.com который и без макросов в гибкости не уступает лиспу)
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: Константин Л. Франция  
Дата: 11.07.07 21:46
Оценка: :))
Здравствуйте, IT, Вы писали:

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


J>>Мой профайл будет тебе ответом


IT>Ага. Ну тогда объяни мне как есть миса-суп палочками, если всё, что можно выловить там палочкой — это пара листов какой-то зелени?


Ха. А ты думал. Скорость поедания супа палками сравнима со скоростью написания немерле компайлера на с++. Так что все как бы правильно.
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: deniok Россия  
Дата: 12.07.07 06:50
Оценка: +2
Здравствуйте, A.Lokotkov, Вы писали:

AL>Не вдаваясь в детали скажу, что вся эта муть должна быть совместима с C. C++, увы, имеется не для всех целевых платформ.


То есть в контексте обсуждаемой темы делаем вывод: макросы C являются свидетельством недостаточной выразительности языка C?
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: WolfHound  
Дата: 27.07.07 05:40
Оценка: -1 :)
Здравствуйте, jazzer, Вы писали:

J>С европейскими приборами решений проблемы последнего куска три:

А немного наклонить тарелку в голову не приходило?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 08:54
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>>>Тебе не кажется, что "очень близок" на практике означет "непохож"?


L>>Нет.


VD>Ну, тогда я тебе отрою тайну — это так.


Ложь.

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


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

С кем ты разговариваешь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 31.07.07 15:13
Оценка: +1 :)
Здравствуйте, lomeo, Вы писали:

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


VD>>>>Тебе не кажется, что "очень близок" на практике означет "непохож"?


L>>>Нет.


VD>>Ну, тогда я тебе отрою тайну — это так.


L>Ложь.


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


L>Где я говорил, что макросы — бяка? Нигде.

L>Где я говорил, что для решения задач надо использовать плохо подходящие средства? Нигде.
L>Где я говорил, что нужен новый синтаксис? Нигде.

L>С кем ты разговариваешь?


Со множественным лицом, которое ненавидит макросы, конечно . Он думает, ты из клана "makroz haters"
Re[24]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 16:29
Оценка: +2
Здравствуйте, IT, Вы писали:

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


G>>1) У тебя там применяются атрибуты. Добавление кастомных атрибутов никак не меняет синтаксис языка, и не увеличивает indirection level языковых конструкций.


IT>В этом смысле да. Но в том же немерле синтаксис атрибутов является лишь одним из форм макросов.


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

IT>Что касается синтаксических конструкций... честно говоря, я пытаюсь понять почему вы считаете это плохой практикой и пока никак не могу понять Почему, например, расширение linq захардкоженное, прибитое гвоздями к C# и VB это хорошо, а набор макросов, делающий тоже самое — это плохо. Почему printf("%d %s", a), убивающий программу или string.Format("{0} {1}", a), приводящий к run-time exception — это хорошо, а $"$a", где просто нет шансов на ошибку — это плохо.


Я тоже никак не могу понять, почему ты думаешь, что я любое захардкоженное языковое расширение считаю хорошим, а любое сделанное на макросах — плохим. Мне как, его пользователю, вообще пофигу, на чем оно сделано. Мне главное, чтобы 1) их было поменьше, и 2) они были хорошо документированы. Я не хочу иметь дело с языком класса PL/1, который умел делать все, и поддерживал абсолютно все на уровне языка, да еще быть лишенным мануала. А если вы не хотите городить второго PL/1, и его лавры дают, так сказать, покой, — так объясните еще раз — зачем нужны меняющие синтаксис макросы?

Пользователю языка, и языкового расширения — части языка все равно, как они сделаны, на макросах, или нет. Дело в другом — реальная необходимость писать языковые расширения настолько редка (при нормальном языке), что мне лично пофигу, имеет язык макросистему или нет. Это последнее, на что я обращу внимание при выборе языка.

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

IT>Нормальная макросистема может все эти недостатки легко устранить. Но пока что мейнстрим до неё ещё не дорос. Хотя странно это. По-идее, на сегодняшний день это единственный способ существенно увеличить производительность девелоперов.


Индустрия имела макросы в далеких 70-х. И отказалась от них вместе с ассемблерами и языками-монстрами вроде PL/1 — с появлением простых и понятных языков высокого уровня.
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: jazzer Россия Skype: enerjazzer
Дата: 03.08.07 00:57
Оценка: +1 :)
Здравствуйте, WolfHound, Вы писали:

WH>ЗЫ Я с картинками почти год вожусь. За это время я прошолся по тАкому колличеству очень неочивидных граблей... Причем они нигде не описаны ибо практикам не до написания статей, а теоретики забивают на крайние случаи. Короче наивные методы не работают. Вобще.


А раз ты практик, то и от тебя мы статей, похоже, не дождемся?
Все практики, наверное, хранят потом и кровью добытые ноу хау при себе...
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 04.08.07 18:13
Оценка: :))
Здравствуйте, IT, Вы писали:

M>>VM имеет непосредственное отношение к языковым средствам, так как для того и была создана — как промежуточный уровень абстракции между языком и железом.


IT>VM без разницы на каком языке был сгенертрован байт-код и с помощью каких расширений. Это как бы одна из основополагающих идей.


Между языком и VM тоже нет принципиальной разницы. Можешь рассматривать байткод как некий язык программирования со специфическим синтаксисом.

M>>IDE и VM были упомянуты не для перевода стрелок и отвлечения внимания. Они имеют непосредственное отношение к макросам, о чём я и написал достаточно подробно. Если вы этого не видите и не хотите видеть — так бы и сказали, мол обсуждать не хочу.


IT>Давай обсуждать, если очень хочется. Why not?

IT>По-моему мнению VM не имеет никакого отношения к расширению компилятора. Т.е. вообще никакого. Продукт компиляции — это байт-код. Как он был получен это не важно. Я генертрую байт код вручную с помошью emit'а без всякой компиляции. Тем не менее VM на меня за это вовсе не в обиде.

Этот процесс ничем не отличается от компиляции исходников OCaml в C. Они могут компилировать свои исходники в байткод для своей VM, а могут в исходный код на С.
Когда я говорю о расширении VM, то имеется в виду что-то вроде расширяемого байткода. Так же, как в Nemerle вы можете определять новые операторы, так и для такой расширяемой VM можно определять новые инструкции. Самый простой пример — определение SIMD операций, ты их можешь определить в Nemerle для работы с 3D вычислениями. Если это расширение компилятора — то эти операции должны будут скомпилироваться либо в вызовы библиотечных методов, либо развернуться в последовательность скалярных операций. Если это расширение VM, то эти операции будут скомпилированы либо в вызовы библиотечных методов, либо развёрнуты в последовательность скалярных операций, либо могут использоваться непосредственно аппаратные SIMD инструкции CPU.

M>>Скажем, у нас есть "расшитрение" для enum типов, и их использования в выражениях и switch/case. Для case value мы бы хотели в IDE иметь автодополнение, которое предлагало бы список перечислымых значений из декларации enum.


IT>Что такое "расширение" для enum типов? Это новый тип типов или новый enum?


Новый тип типов. Мне его удобно для примера пользовать, так как в Java изначально небыло enum-ов, и они реализуются сравнительно просто в виде "расширения", как трансформация AST (кодогенерация).

M>>Так вот, никаким образом этот тип автодополнения не появится автоматически из правил преобразования enum->class на уровне AST.

M>>IDE уровня Eclipse или IntelliJ Idea понимает код, работает с ним на уровне семантики. Поэтому и является настолько удобным инструментом. А вы под IDE подразумеваете редактор+обработчик сообщений компилятора?

IT>Я понимаю это как редактор + компилятор. Не секрет, что тот же Resharper включает в себя большую часть самописного компилятора C#. Фактически для IDE не нужна лишь последняя фаза кодогенерации. Остальное в ней присутствует в полный рост. Не думаю, что Idea и Eclipse в этом сильно отличаются. Что касается Немерле, то его интеграция с VS использует непосредственно сам компилятор. Соотвественно, если макрос, например, сгенертровал новый тип или метод в существующем типе, то он автоматически появится в списке интелисенс. Тоже самое касается новых ключевых слов.


Вот и смотрим, что произойдёт с гипотетическим расширением "enum типы". В Java это было сделано так

enum Color { red, green, blue }
...
int rgb(Color c) {
  switch (c) {
  case red: return 0xff;
  case green: return 0xff00;
  case blue: return 0xff0000;
  }
}


компилируется в

final class Color extends Enum {
  public static final red = new Color(0,"red");
  public static final green = new Color(1,"green");
  public static final blue = new Color(2,"blue");
  private Color(int ord, String name) { super(ord,name); }
  ...
}
...
int rgb(Color c) {
  switch (c.ordinal()) {
  case 0: return 0xff;
  case 1: return 0xff00;
  case 2: return 0xff0000;
  default: throw new Error();
  }
}


Теперь внимание — вопрос.
Каким образом из правил кодогенерации (трансформации AST) IDE сможет понять, что red, green, blue — это константы, что автодополнение кода в case value должно выдавать список из red,green,blue, каким образом IDE узнает, что существуют только 3 варианта значения Color и что switch может иметь максимум эти 3 case-а и так далее. Эти правила (что есть enum как понятие) — присутствуют в мозгах программиста. Трансформация AST — это применение этих правил, а не определение этих правил.

Idea и Eclipse построены именно на понимании явовского кода, а не его формальном AST представлении. Кроме самого AST туда ещё много чего напихано. Именно поэтом миграция на Java 1.5 (в которой эти enum-ы появились, а так-же generics, autoboxing и прочее) заняла пару лет для IDE, уже после того, как компилятор был выпущен.

IT>Пофантазировать можно конечно. MS research работает над проектом Феникс, возможно это из этой серии.


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

IT>>>Это неверное утверждение. Как я уже сказал, интеграция Немерле со студией автоматически подхватывает все расширения. Есть определённые технические проблемы, которые решаемы, но принципиальных проблем нет.


M>>Расскажите мне о решении принципиальной проблемы изложенной выше. Как будет происходить пониание кода средой разработки на основании одних только правил преобразования AST, не говоря уже о расширениях вроде изменения системы типов.


IT>Интеграция с VS использует сам компилятор. Т.е. исходный код проекта банально пропускается через компилятор и в результате IDE получает в своё распоряжение AST. В процессе компиляции выполняются в том числе и макросы. Соответственно, все сделанные ими изменения попадают в результирующее AST.


Как я написал выше, результирующее AST нам даёт очень мало, для понимания сути написанного. А если IDE не понимает сути написанного, то она превращается просто в редактор.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.08.07 19:45
Оценка: +1 -1
Здравствуйте, IT, Вы писали:

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


Не, аргументы это когда спорят. А спорить я не хочу.

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


IT>Базовый уровень не изменяется. Мы не меняем компилятор, мы его расширяем.


Расширение это тоже изменение. Не меняем, это когда мы действительно не меняем грамматику языка.

IT>Кстати, вопрос к тебе, на который Гапертон тоже не ответил. Ты отрицательно относишься только к макросам, которые вводят новый синтаксис, либо абсолютно ко всем?


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

IT>Не вижу никаких проблем.


IT, еще раз — мне не интересно спорить. Поэтому мне все равно, что считаешь ты. Я высказываю свою точку зрения, ничего сверх того.

IT> Ознакомление с новой системой всегда требует определённых усилий и ознакомление с макросами не будет ничем сверхестественным по сравнению с пониманием архитектуры приложения и ознакомлением с исходными кодами.


Я считаю иначе.

AVK>>А 20? А 100?


IT>Столько сколько нужно. Опять же, замечу ещё раз. За год работы на Немерле я не написал ни одного макроса.


Ничуть в том не сомневаюсь.

IT> Не нужно было. Почему вы считаете, что наличие макросов в языке приведёт к тотальному увлечению ими я не понимаю


Потому что я вижу, что происходит с шаблонами на С++.

AVK>>Да были всякие разные типа Open C++. Но, как я предполагал, разговор скатывается во флейм.


IT>Это не флейм.


Это именно он и есть. И чем дальше, тем его больше.

IT>Это принципиальный вопрос. Одно дело, если ты с ними поигрался да и бросил. Другое — если ты использовал Open C++ в серьёзном проекте и твои утверждения о вреде макросов основываются не на домыслах, а на реальном опыте их применения.


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

AVK>>А в том, что слишком много логики остается за кадром исходного кода.


IT>Так это как раз и есть наша главная цель. Убрать частоповторяющуюся логику подальше,


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

IT> а в прикладном коде оставить максимум декларации. Почему тебя не пугает, например, что за вызовом метода Rsdn.Janus.Synchronizer.SyncForums остаётся много логики за кадром?


Потому что эта логика жестко ограничивается контрактом, причем контрактом явным. Могут быть, конечно, побочные эффекты. Но в случае макросов и с контрактом неясно, и с побочными эффектами может быть все очень непросто.

IT>Это не проблема.


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

IT>Тем не менее это ни меня, ни многих других не останавливает. Я точно знаю что я делаю и знаю какие бенефиты в результате получу.


Рад за тебя.

IT>Я с этим не согласен. Тебя сильно интересует реализация паттернов foreach, override, yield return, this?


Конечно.

IT>А твоим обезъянкам так вообще по барабану.


Нет, и обезьянкам не по барабану. Но foreach — часть языка, и обезьянка не имеет права не разбираться хотя бы в базовых моментах foreach. Грубо говоря, обезьянка будет изучать foreach за свой счет, чтобы потом устроится на работу в качестве C# developer.

AVK>>SQL например. Или XSLT.


IT>А... ну да. Нам как раз здесь не хватает именно такого замеса.


Тем не менее паттерн-матчинг в мейнстриме есть.

IT>>>Лямб пока нет. Есть убожество, называемое анонимными делегатами.

AVK>>Во первых анонимными МЕТОДАМИ.

IT>Начинается терминологический булшит?


Нет, просто поправил, уж больно глаза режет.

IT>Впрочем, я не одинок.


Уробы, чего на них равняться?

AVK>>Во-вторых это те же лямбды, вид в профиль.


IT>Если уж мы начали упираться в терминологию


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

IT>И как ощущение от пережитого? Что тебя большего всего угнетало: обилие фич или дремучесть вообще?


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

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

AVK>>Я вот думаю, это Nemerle делает вас столь непримиримыми, или функциональное программирование вообще?

IT>Это кто из нас здесь непримиримые?


Ну а как еще расценивать? Сотню раз уже наверное повторил — не хочу с тобой спорить, а все равно гора агитации в ответ. Ты всерьез надеешься после того, как я не по одному разу выслушал все аргументы любителей N, все таки переубедить меня?
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 15:29
Оценка: :))
Здравствуйте, eao197, Вы писали:

K>>Это решение моей задачи? Я прямо-таки недоумеваю, дорогая редакция!


E>Именно:

E>

E>Имеем: x := alpha * p + omega * s;

E>Разворачивается в:
E>

E>for(i = 0; i < x.Length; i++)
E>{
E>    x[i] = alpha * p[i] + omega * s[i];
E>}
E>

E>конкретно это и производится.

Я заметил. А где возможность написать второй пример из моей задачи?

r := b - A*x;


K>>Правильно ли я понял, что предлагается писать вручную реализации для всех возможных выражений.

E>Нет. Не правильно. Но вы, я вижу, больше математик, чем программист. Может быть, что-то и не допоняли.

Что Вы! Я не просто "больше математик, чем программист" — я вообще не программист, а физик. Образования программиста я не получал.
И хотя некоторые физики не любят, когда их называют математиками, мне все равно очень приятно, спасибо.

E>Поскольку из показанного мной решения можно сделать, например, вот такое:


Да. Вы привели пример решения какой-то другой задачи, из которого таки можно сделать пример решения моей. С этим я согласен.

E>
<...>

E>void
E>main()
E>    {
E>        const int vector_size = 5;
E>        float a_src[ vector_size ] = { 1, 2, 3, 4, 5 };
E>        float b_src[ vector_size ] = { 0.5, 1.5, 2.5, 3.5, 4.5 };

E>        vector_t a( a_src, a_src + vector_size );
E>        vector_t b( b_src, b_src + vector_size );
E>        vector_t d( b_src, b_src + vector_size );
E>        vector_t c;

E>        c << 0.0 * a + 2.0 * b - 1 * d + b / 0.2;

E>        std::cout << c << std::endl;
E>    }
E>

E>А если потратить еще некоторое количество времени, то можно сделать еще и поддержку некоторых других сочетаний. Но здесь, вероятно, придется задействовать динамическую память, чтобы классы, производные от vector_element_extractor_t могли сохранять свои операнды по указателю. Чтобы можно было обрабатывать выражения типа:
E>
E>((a1 * v + a2 * v2)/0.5 - (a3*v3 - a4*v4)*2) * 0.75;
E>

E>Но такие операции будут эффективны только на больших размерностях. В противном случае расходы на new/delete окажутся значительно дороже, чем сами вычисления.

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

E>Все проще. Если вы решаете свои вычислительные задачи в рамках своей работы, то можете сами оценить, во что обходится качественный, надежный, универсальный и расширяемый библиотечный код. Соответственно, можете предположить, что я не могу пренебречь своей собственной работой для того, чтобы потратить несколько дней на проектирование достаточно хорошей библиотеки отложенных векторно-матричных вычислений. Тем не менее, данный код показывает, что в C++ можно значительно к этому делу приблизится.


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

E>Сначала я дал точную ссылку на Страуструпа, где показан принцип отложенных вычислений. Розовый слон косвенно обвинил меня в трепачестве.


Я знаю о Вашей войне с "Розовым слоном" и был бы просто счастлив, если бы Вы меня в нее не вовлекали.

E>Я потратил 15 минут на воспроизводство примера Страуструпа и еще 15 минут своего времени на оформление сообщения с этим кодом. Это практически все, что я мог себе позволить. Вам этого недостаточно? Отлично, я потратил еще 45 минут на это сообщение и новый пример. Что дальше?


Да ничего. Я от Вас вообще ничего не требую. Разумеется, я безмерно благодарен Вам за потраченное на меня время, пусть даже это и было сделано ради тактического контр-наступления на "Розового слона" или чего-то вроде того.
... << 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[36]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.08.07 16:04
Оценка: +2
Здравствуйте, mkizub, Вы писали:

M>Свобода действий устрицы ограничена двумя состояними — открытой или закрытой раковиной. Именно это деалет поведение устриц столь понятным и надёжным. Увы, пока эти значительные преимущества не превратились в доминирование устриц как биологического вида, но природа работает над этим.


Доказательство по аналогии есть голая демагогия.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 17:54
Оценка: :))
Здравствуйте, Cyberax, Вы писали:

C>Так ведь такой макрос почти бесполезен. А сложные макросы уровня реализации LINQ'а писать будет нааамного сложнее.


Я разве утверждал обратное? Я лишь ответил на вопрос. Может быть не достаточно ясно? Но ты — молодец, безжалостно эту неясность искоренил
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 17:54
Оценка: +2
Здравствуйте, Cyberax, Вы писали:

K>>На самом деле макросов, как преобразований над AST, индустрия не имела никогда.

C>???????
C>LISP!

А что, LISP широко применялся индустрией? Вот это новость.

C>Я точно знаю, что квазицитирование в нем точно использовалось.


Честно говоря, принимая во внимание лисповский синтаксис и общую идеологию code is data is code, я вообще с трудом представляю, зачем в LISP нужно (квази)цитирование, как я его понимаю. И термин этот вместе с LISP вообще очень редко встречается. Но я не поленился и поискал статьи по этой теме на CiteSeer. Да, статьи по квазицитированию в LISP есть. Самая старая, что я нашел — 1999 года.
... << 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]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 20:33
Оценка: +2
Здравствуйте, Cyberax, Вы писали:

C>А вот для макросов у нас отладчиков пока нормальных нет.


Макрос отлаживается тем же отладчиком что и любой другой код.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 22:19
Оценка: :))
Здравствуйте, BulatZiganshin, Вы писали:

BZ>бейсик.


Basic — статически типизированный язык.

BZ>препроцессор pl/1 имел синтаксис, аналогичный самому pl/1


Ну так что? Ключевой момент то в том, что это был препроцессор. Даже очень крутой препроцессор вроде Camlp4 все равно не является макросистемой, ведь он не может получить информацию о типах — для статически типизированного языка это имеет значение.
... << 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[36]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 06.08.07 08:55
Оценка: :))
Здравствуйте, Klapaucius, Вы писали:

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


IT>>>За год я не написал ни одного макроса. Ещё раз повторить?

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

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


Мне правильно кажется что в немерле вообще очень затруднительно не пользоватся макросами?
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: jazzer Россия Skype: enerjazzer
Дата: 06.08.07 10:04
Оценка: :))
Здравствуйте, Kisloid, Вы писали:

K>г) нормальная возможность отладки макросов


K>В немерле с этим щас не очень хорошо.


Зато в С элементарно
Скрипт, который будет выводить результат действия макроса, пишется за 3 минуты: вызов компилятора в режиме "только препроцессор" (в gcc это ключ -E), отсечение по какой-нть метке всякой ненужной фигни, которая придет с многочисленными include (проще всего через awk) и напускание какой-нть утилиты типа indent или astyle для приведения результата в читабельный вид.

Хотя это, конечно, смотря что понимать под отладкой макроса.
Если то, какой в результате текст он генерит — такого простого скрипта достаточно с головой.
Если надо — могу привести текст.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 06.08.07 13:45
Оценка: +1 -1
Здравствуйте, 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, а значит переменные совместимы. Впрочем, можно складывать и целые с дробными, при этом делается неявное приведение. Но неявное приведение — ещё не признак динамики.

Конечно, существовало сотни разновидностей бэйсика, так что какой-нибудь из них мог быть динамическим, я точно не знаю. Но большинство реализаций были статически типизированым.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 06.08.07 15:10
Оценка: -1 :)
Здравствуйте, lomeo, Вы писали:

M>>Макрос — это "декларативное" описание изменений, а ещё AST можно трансформировать императивно, напрямую создавая и меняя узлы.


L>Вовсе необязательно. Макрос -- это то же код, какая разница декларативный он или императивный. Или я не о том?


Я в смысле

macro for (init, cond, change, body)
{
  <[ 
    $init;
    def loop () : void {
      if ($cond) { $body; $change; loop() } 
      else ()
    };
    loop ()
  ]>
}


это же декларация (как данные для некоего кода, который с ними будет работать). А вот

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>Э-э-э не понял. Это же мой пост


Блин, это RSDN, который не меняет URL при клике на другой пост
http://rsdn.ru/forum/message/2610368.1.aspx
Автор: mkizub
Дата: 05.08.07
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 06.08.07 15:43
Оценка: +1 :)
Здравствуйте, 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[37]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 15:51
Оценка: +2
Здравствуйте, konsoletyper, Вы писали:

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


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


K>Многие диалекты не поддерживали постфиксы ! и % (и, кажется, там ещё что-то было) потому, что в них не было соотв. типов. Например, в спектрумовском бэйсике было всего два базовых типа — single и string. Не было даже целочисленных переменных.


Были там целочисленные значения у переменных, были. Плавающая запятая эмулировалась программно, и работала крайне медленно. Поэтому, интерпретатор различал целые числа и плавающие в динамике, несмотря на то, что этих постфиксов-префиксов (не помню уже) там не было. Так вел себя любой бейсик для слабых процов без аппаратной плавающей запятой, таких как Z80.

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


K>Таким же макаром я могу доказать, что и Хаскель — динамически типизированный. А всего-то и нужно, что написать интерпретатор, который не проверяет типы заранее, а добавляет метки типов ко всем объектам. Ах да, забыл, это даст нехороший побочный эффект! Все функции станут обладать свойством "type polymorphism"! Ну ничего, можно и этот недостаток залатать, если подумать как.


Таким макаром ты ничего доказать не можешь. В хаскеле есть декларации типов, а семантика стандарта предполагает статическую проверку. В бейсике ничего подобного нет. Там даже DIM — объявление массива не является декларацией — это конструктор массива, работающий в динамике — семантика такая.
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 15:56
Оценка: +2
Здравствуйте, Klapaucius, Вы писали:

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


K>Вот только все "индустриальные" Бэйсики, которые позиционировались как языки общего назначения были компиляторами.


Ага щаз. "Индустриальные" бейсики по началу все были интерпретаторами без исключения. Компиляторы из бейсиков стали делать уже сильно позже — и эти языки бейсиками можно уже с натяжкой было назвать — это уже сильно расширенные диалекты. И то, современные "индустриальные" бейсики днамические, например Visual Basic, не путать со скриптом VBScript и встраиваемым Visual Basic for applications.
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 17:52
Оценка: +2
Здравствуйте, GlebZ, Вы писали:

GZ>вторая запись не менее визуальна чем первая. И в такой записи, запросы вполне можно собирать.


К Хейлсбергу и Коробкину.

GZ>>>На фоне генерации грида и работы с бд — выигрыш будет очень незначительным.

IT>>Точно? Проверял или сам догадался?
GZ>Нет. Догадался.

Я так и знал.

GZ>Опять. Трансформация OQL-подобных запросов в SQL — не является ресурсоемкой задачей.(если конечно в Microsoft не напортачили )


Линк не шустр. Думаю, проблема не только в генерации SQL. Скорее всего проблема комплексная. Здесь посчитали задачу нересурсоёмкой, там догадались, что выигрыш будет незначительным и вот тебе результат. А потом мы удивляемся, почему 4 гига памяти и 4 ядра в процессоре не могут справиться с нашими задачами.

В общем, я твою точку зрения понял. Я её не разделяю.

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

GZ>Если ты сможешь выйти за рамки LINQ2SQL — то безусловно.

Мне не нужно выходить за эти рамки. Я вообще в них даже входить не собираюсь, если ты не понял.

GZ>А тут вопрос не декларатива/императива. Это всего лишь вопрос использования инструмента. А как ты его оформишь декларативно(с помощью макросов или без оных) или императивно — это твое личное дело.


Ещё раз посылаю тебя к Хейлсбергу. К Боксу тоже зайди.

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

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

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

GZ>LINQ2SQL — можно считать заменителем или хелпером для DAL.


Ты вообще в курсе для чего нужен DAL?

GZ>Бизнес-логику полностью на нем не сделаешь.


Её вообще не надо делать. Напомню что такое pass-through:

class UI
{
  void OnLoad()
  {
    binder.List = BusinessLogic.GetCustomerList();
  }
}

class BusinessLogic
{
  List<Customer> GetCustomerList()
  {
    return DataAccessor.GetCustomerList();
  }
}

class DataAccessor
{
  List<Customer> GetCustomerList()
  {
    return ExecuteList<Customer>("SELECT * FROM Customer");
  }
}

Всё это теперь заменяется на:

class UI
{
  void OnLoad()
  {
    binder.List = from c in Customer select c;
  }
}

Можно для лучшей наглядности замешать сюда ещё и ad-hoc запрос.

Теперь сформулируем вопрос по-другому. Что тебе реально даст оставление двух таких pass-through методов в данном случае, учитывая что вся логика здесь диктуется UI? Только пожалуйста без ООП и прочей чуши. Лучше давай оперировать такими понятиями как сопровождаемость.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.08.07 06:40
Оценка: +2
Здравствуйте, IT, Вы писали:
IT>Едет, но хреново. На самом деле, при наличии макросов большинство выкрутасов хибернейта и биэлтулкита нафиг не нужны. Тот же маппинг как понятие появился исключительно благодаря лени разработчиков и нежеланию постоянно писать кучу тупого кода. Макросами эта задача решается влёт. Особенно зная контекст выполнения. Можно, кстати, попытаться вообще обойтись без создания объектов. Если отложить запрос до момента рендеринга, то мапить можно DataReader непосредственно в response стрим.
Ай, как хорошо сказал!
Вот тут, кстати, недалеко обсуждали мегастроки в хаскеле.
Я по диагонали статью прочел — она всё ж не шибко популярная, не то что Лукьяненко — но суть в целом уловил.
Там парни не то чтобы строки придумали — это ерунда. Они придумали способ редуцировать алгоритмы на строках и списках. Ленивость во всей красе.
Пример на пальцах: допустим, есть задача отфильтровать строку, оставив только заглавные гласные буквы. Одним из способов решения будет цепочка из двух фильтров — один для заглавных, другой для гласных.
Косяк в том, что
а) по строке придется пробегать два раза, а это не то же самое, что один раз, но медленнее — из-за кэша
б) неленивый алгоритм породит промежуточную строку, которая нафиг не нужна.

Умный программист напишет сразу фильтр с обоими предикатами, и обойдется одним проходом и без временного объекта.
Умный компилятор/рантайм сведет цепочку к оптимальному преобразованию.

Ты говоришь ровно о том же: если у нас есть цепочка мапперов DataReader->DTO->BO->XML->HTML, то самым оптимальным будет свернуть это всё в один маппер, который проджитится, заоптимизируется, и будет работать практически без выделения мусора и оптимально по кэшу. Сие и есть наша самая заветная мечта.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: IB Австрия http://rsdn.ru
Дата: 07.08.07 13:27
Оценка: -2
Здравствуйте, Cyberax, Вы писали:

C>А я ему расписал в чем он не прав.

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

C> А больше у нас ничего для работы с данными от MS и нет.

Для работы с данными нужен примитивный маппер, коих навалом.

C>LINQ пока даже не появился.

LINQ не для БД.

C>Ок. Успешные крупные проекты. Blogger.com, например, или Google Adwords.

А без разницы, от крупноты тоже ничего не зависит.

C>А по сути есть что ответить?

Сначала спроси посути, нефиг стрелки на DBA переводить..

C> Почему Hibernate — морально устарел,

Потому что изначально тупиковое направление.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 20:12
Оценка: +2
Здравствуйте, Cyberax, Вы писали:

C>Я тебе в который (пятый?) раз говорю, что можно для большинства запросов Hibernate сделать контроль типов с помощью плугина к IDE. И это уже сделано. И это уже работает.


Ты понимаешь какую чушь ты говоришь? А если файл, которые затронули мои изменения не открыт в IDE? Всё, не шмагла?

C>Для байндинга так вообще типизированность обычно пофиг — grid'у все равно что отображать, главное чтобы порядок правильный был.


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

IT>>В твоём примере ты делаешь точно тоже, что делалось 10 лет назад — ты используешь нетипизированную работу с данными.

C>У меня возвращается List<BusinessObject>, который вполне типизирован.

Ты строкой задаёшь запрос, в котором используются строковые имена таблиц и полей. Дальнейшее уже не важно.
Если нам не помогут, то мы тоже никого не пощадим.
Re[57]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 17:53
Оценка: :))
Здравствуйте, Cyberax, Вы писали:

C>А ты просто не используй Windows. Какие проблемы-то?


Всё, я больше не могу Кто-нибудь там поближе, киньте в этого маньяка чем-нибудь тяжёлым!
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 09.08.07 06:56
Оценка: +1 -1
Здравствуйте, mkizub, Вы писали:

M>>>Заменить текст деревом.


CU>>Деревом-деревом!.. В виде списка... в текстовом файле


M>Пробовали — херня получается , Lisp называется.


1. "ниасилил"?

2. Вы просто не умеете его готовить.

P.S. Можно выбрать оба варианта
Re[51]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 10.08.07 12:01
Оценка: +1 :)
Здравствуйте, mkizub, Вы писали:

CU>>"Имя, сестра, имя!"


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


Из чего это следует? Хотя в одном ты прав — МП само по себе и "в собственном соку" меня не интересует, а как одно из "в одном флаконе" (наряду с ФП, СП, ПП, ООП, ДП и проч.) — очень даже.

Я и не собирался ничего обсуждать. Я хотел что-то увидеть, "уделывающее" лисп по МП, не не такое как N Ан нет — не существует.
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.08.07 00:41
Оценка: +1 :)
Здравствуйте, FR, Вы писали:

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


Ну, почему же? Истенному профи ФП это не составит труда. Опертор match и вызов/описание фунции в нем встроенные. Остельное, правда, почти все макросы, но это же не повод отчаиваться?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 13.08.07 08:23
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Мне кажется этот код очевиден.


"Очевидный" это когда пара строчек. А когда три экрана текста, которые нельзя охватить взглядом, то слово "очевидный" уже не в кассу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 13.08.07 09:53
Оценка: :))
Здравствуйте, VladD2, Вы писали:

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


Он у меня давно есть, и работает на славу.
Но я не об этом. Я случайно увидел твой ответ, обычно я сообщения от тебя просто пропускаю — ты в игноре.
Спасибо за понимание.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[26]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 15.08.07 19:26
Оценка: -2
AVK>>Спорно. Идее ситаксических макросов 200 лет в обед. Однако ж не прижились пока что.

VD>Можно источник? Насколько мне известно превый статически типизированный язык в котором реализованы макросы — это МетаМЛ.


как следует из той де книги, которую я цитировал насчёт pl/1 — синтаксические макросы реализовывадись ещё для алгола в 60-е годы

кстати, если бы в немерле были клозуры, то как я понимаю все эти управляющие структуры, которые ты приводишь (while, foreach) — можно было бы реализовать в виде обычных процедур, как это делается в руби, например
Люди, я люблю вас! Будьте бдительны!!!
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 15.08.07 20:35
Оценка: +2
Здравствуйте, BulatZiganshin, Вы писали:

BZ>более того, C++ не ООП язык, поскольку на нём можно писать без классов RTTI — это как раз *следствие* частично-динамической типизации ООП. получая ссылку на A, ты не знаешь, какого на самом деле типа указуемый объект и RTTI сущетсвует как раз чтобы определить этот тип в случае использования техник, основанных на динамической типизации


RTTI не нужен для полиморфизма, для него нужен диспатчинг методов в зависимости от ран-тайм типа аргумента. Что никак не противоречит "набору операций, которые можно с данными произвести" — набор операций тот-же самый, вот только код выполнится разный. Не путай динамическую типизацию с полиморфизмом. Да, там унутри есть виртуальные таблици или ещё какая хрень, которая в рантайме предоставляет возможность определения типа. Но это внутренние детали, а проверка типов на этапе компиляции полная.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 16.08.07 05:22
Оценка: +2
Здравствуйте, mkizub, Вы писали:

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


M>>>А mutable локальные переменные как апдейтить?

C>>А какие проблемы с mutable-переменными, если есть настоящие замыкания?

M>Эффективность кода.


это проблема компилятора, который должен уметь их инлайнить
Люди, я люблю вас! Будьте бдительны!!!
Re[51]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 21.08.07 17:10
Оценка: :))
Здравствуйте, EvilChild, Вы писали:

EC>Я правильно понимаю, что этот подход работает только, если нагенерённый код руками не трогали?


Правильно. Но его нельзя не трогать. Нужно как минимум поменять anything на something
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.09.07 09:55
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Ладно. Это музыка будет вечна, если вдруг с дури заменить батерейки. Позиции всех участников дискуссии понятны. Мое мнение — попытки оправадать подобный подход не более чем фанатизм который не позволяет правильно оценить выбор интрумента. Обсуждать тут больше не чего. Прелдагаю закрыть дискуссию.


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

Что касается самой задачи, то её решение что на типах, что на макросах считаю одинаково неправильным. Эта задачка для простого скрипта, какие могут быть практические соображения, чтобы писать её решение в компайл тайм, не понимаю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.09.07 11:18
Оценка: :))
Здравствуйте, Курилка, Вы писали:

К>Кстати, вот Mirrorer кинул тут на днях ссылку — не совсем парсек, конечно, но рядом с этим (и на шарпе).


Угу, решение аналогичное парсеку.

Да я в последнее время вообще мало читаю, поэтому ссылку не видел — сейчас просто увидел, что на рсдн мне кто то ответил — и понеслась

Ссылка прикольная, только там линк (читай монады) используется, это для Влада чёрная магия
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 13.09.07 11:36
Оценка: +2
Здравствуйте, lomeo, Вы писали:

L>М-м-м. Кажется я понял, в чём у нас недопонимание. Для меня сабж — "является ли использование макросов для такой то задачи маркером того, что язык не обладает для этой задачи достаточно выразительными средствами", а не "является ли наличие макросов в языке свидетельством недостаточной выразительности этого языка вообще".


Ок, так конкретнее. Но даже в таком варианте всё зависит от характера задачи. И к тому-же в языках, имеющих встроенные макросистемы, различные "встроенные" инструкции создаются именно на макрах — ибо зачем для одного и того-же иметь два инструмента? Не повод же это утверждать, что у них компилятор "недоделанный" Так что без конкретики сабж не проходит ни в каком варианте

L>В Хаскеле, например, макросы есть, только их очень мало используют. Я не скажу, что я сторонник этой гипотезы, например, для кодогенерации средства лучше не найдёшь. Но я и не противник — а может быть в каком нибудь языке и не нужна эта кодогенерация (пример с gmap).


Кодогенерация "не нужна" не в языке, а для определённых задач (или нужна для определённых задач). А в Хаскеле макры мало используют скорее всего потому, что он сам по себе довольно лаконичен и "засахарен", и макры таки в нём "сбоку", а не "внутри".
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 13.09.07 13:25
Оценка: :))
Здравствуйте, VladD2, Вы писали:

L>>Более мощная система типов позволяет вынести больше ошибок из рантайма в компиляцию.


VD>Это домыслы. А вто то, что с ее помощью можно сделать больше ошибок — это факт.


Свершилось твоё превращение в сторонника динамической типизации?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.07 14:40
Оценка: +1 :)
Здравствуйте, ., Вы писали:

.>Никто не сможет удержать разработчика приводить всё к void*. И что?


Ну, почему же? Отсутствие в языке void* отлично защищает программиста от его использования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 30.07.07 09:22
Оценка: 34 (1)
L>Ты запутался, одно дело синтаксис, EBNF, другое дело ByteString, который включается через Rewrite Rules только в GHC и Hugs кажется.

в hugs нет rewrite rules — нахрена они там?

VD>>В прочем я еще сильно сомневаюсь в том, что Парсер обеспечивает внятную диагностику грамматических ошибок (выявление неоднозначностей, например).


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

а вообще диагностика там есть и очень удобно подцепляется комбинатором <?>

L>Чувствую придётся всё таки мне переписать Parsec на ByteString и написать какой нибудь простой лексер.


если не ошибаюсь, это один из GSOC проектов этого года

Влад, есть отличное введение в использование ParseC — http://www.cs.uu.nl/people/daan/download/parsec/parsec.html . для того, чтобы немного разобраться в возможностях, предоставляемых библиотекой, лучше всего почитать его

Описание же принципов создания монадических парсеров можно прочесть в http://www.cs.nott.ac.uk/~gmh//pearl.pdf с реализацией в http://www.cs.nott.ac.uk/~gmh/pearl.hs — 150 строк

и разумеется, ты прав, что всё это делается с помощью монад. монады — это просто универсальный способ написания "фабрик кода", что-то типа поддержки создания паттернов в самом языке. монады, создаваемые для парсинга, весьма напоминают Прологовский механизм унификации с бэктрекингом. просто здесь он реализован в виде библиотеки, а монады обеспечивают необходимый сахар в лице 'do' плюс high-order functions
Люди, я люблю вас! Будьте бдительны!!!
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: Кодт Россия  
Дата: 02.08.07 09:49
Оценка: 34 (1)
Здравствуйте, VladD2, Вы писали:

FR>>>>На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.

VD>>>Решение конечно на шаблонах с применением Буста?
FR>>На шаблонах без буста. Я такой велосипед писал когда про буст еще не слышал.
VD>Дык, изобрази... посмеемся вместе.

Вот очень грубый эскиз
// исходный контейнер
struct vector
{
    int size() const;
    double operator[](int) const;
    double& at(int);
    
    template<class V> operator=(const V& v)
    {
        for(int i=0, n=size(); i!=n; ++i)
            at(i) = v[i];
    }
};

// ленивая арифметика: кирпичики
template<class V> struct vmul_t
{
    const V& v; double m;
    vmul_t(const V& v, double m) : v(v), m(m) {}
    double operator[](int i) const { return v[i]*m; }
};
template<class V>
    vmul_t<V>
        vmul(const V& v, double m) { return vmul_t<V>(v,m); }

template<class V1, class V2> struct vsum_t
{
    const V1& v1; const V2& v2;
    vsum_t(const V1& v1, const V2& v2) : v1(v1), v2(v2) {}
    double operator[](int i) const { return v1[i]+v2[i]; }
};
template<class V1, class V2>
    vsum_t<V1,V2>
        vsum(const V1& v1, const V2& v2) { return vsum_t<V1,V2>(v1,v2); }

// обёртка над кирпичиками позволяет избежать комбинаторного взрыва
template<class V> struct vid_t
{
    const V& v;
    vid_t(const V& v) : v(v) {}
    double operator[](int i) const { return v[i]; }
};
template<class V>
    vid_t<V>
        vid(const V& v) { return vid_t<V>(v); }

// строим выражения: сперва с участием конкретных типов слева (вектор, число)

template<class V>
    vid_t<vmul_t<V> >
        operator* (double m, const V& v) { return vid(vmul(v,m)); }

    vid_t<vmul_t<vector> >
        operator* (const vector& v, double m) { return vid(vmul(v,m)); }
    vid_t<vmul_t<vector> >
        operator/ (const vector& v, double m) { return vid(vmul(v,1/m)); }

template<class V2>
    vid_t<vsum_t<vector,V2> >
        operator+ (const vector& v1, const V2& v2) { return vid(vsum(v1,v2)); }
template<class V2>
    vid_t<vsum_t<vector,vmul_t<V2> > >
        operator- (const vector& v1, const V2& v2) { return vid(vsum(v1,vmul(v2,-1))); }

// а теперь слева шаблон vid_t

template<class V>
    vid_t<vmul_t<V> >
        operator* (const vid_t<V>& v, double m) { return vid(vmul(v,m)); }
template<class V>
    vid_t<vmul_t<V> >
        operator/ (const vid_t<V>& v, double m) { return vid(vmul(v,1/m)); }

template<class V1, class V2>
    vid_t<vsum_t<V1,V2> >
        operator+ (const vid_t<V>& v1, const V2& v2) { return vid(vsum(v1,v2)); }
template<class V1, class V2>
    vid_t<vsum_t<V1,vmul_t<V2> > >
        operator- (const vid_t<V>& v1, const V2& v2) { return vid(vsum(v1,vmul(v2,-1))); }


Здесь можно добавить следующие вещи:
1) избавиться от лишней косвенности (т.е. снимать обёртку)
template<class V> struct clean_t { typedef V type; };
template<class V> struct clean_t<vid_t<V> > { typedef V type; };

template<class V> const V& clean(const V& v) { return v; }
template<class V> const V& clean(const vid_t<V>& v) { return v.v; }

// и пропатчить все операторы вот так:

template<class V1, class V2>
    vid_t<vsum_t<typename clean_t<V1>::type, typename clean_t<V2>::type> >
        operator+ (const vid_t<V>& v1, const V2& v2) { return vid(vsum(clean(v1), clean(v2)); }

2) протащить через выражения не только operator[], но и функцию size()
3) сделать нормальное деление и вычитание вместо эмуляции на сложении и умножении
и т.д. и т.п.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 18:14
Оценка: 34 (1)
Здравствуйте, EvilChild, Вы писали:

EC>Если речь о том, что макрос чисто технически это просто класс, то это никак дело не менят.

EC>Речь о другом.
EC>Мне пока не встречались библиотеки, модифицирующие код, который я пишу (или может я просто не в курсе).
EC>Макрос же совсем другое дело.

Т.е. библиотеку, которая решает системы линейных уравнений стабилизированным методом бисопряженных градиентов понять, конечно, легче, да?
Речь идет о том, что библиотека написанная с использованием знакомых программисту средств может иметь произвольно сложную семантику. Когда Вы написали, что мол, неважно, что макрос написан на том же языке, что и обычная библиотека — важно то, что этот макрос делает какую-то сложную работу, Вы в общем-то эту идею и подтвердили.
... << 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[30]: Являются ли макросы свидетельством недостаточной выр
От: squiz  
Дата: 25.08.07 14:21
Оценка: 34 (1)
Здравствуйте, Andrei F., Вы писали:

C>>Феникс вообще пока умер. Есть еще RAILS — но они тоже как-то присмерти.

AF>Почему умер? Последний RDK вроде за март этого года.

Даже лучше, в Июле выложили Microsoft Phoenix SDK Pre-release July 2007
Never underestimate those behind you...
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.07.07 16:18
Оценка: 14 (1)
Здравствуйте, Klapaucius, Вы писали:

K>Это решение моей задачи? Я прямо-таки недоумеваю, дорогая редакция!


Именно:

Имеем: x := alpha * p + omega * s;


Разворачивается в:

for(i = 0; i < x.Length; i++)
{
    x[i] = alpha * p[i] + omega * s[i];
}


конкретно это и производится.

K>Правильно ли я понял, что предлагается писать вручную реализации для всех возможных выражений?


Нет. Не правильно. Но вы, я вижу, больше математик, чем программист. Может быть, что-то и не допоняли.
Поскольку из показанного мной решения можно сделать, например, вот такое:
#include <cmath>
#include <iostream>
#include <vector>

typedef std::vector< float > vector_t;

class vector_element_extractor_t
    {
    public :
        virtual float
        operator[]( unsigned int index ) const = 0;

        virtual unsigned int
        size() const = 0;
    };

class delayed_scalar_by_vector_multiply_t
    :    public vector_element_extractor_t
    {
    public :
        delayed_scalar_by_vector_multiply_t(
            float a,
            const vector_t & b )
            :    a_( a )
            ,    b_( b )
            {}

        virtual float
        operator[]( unsigned int index ) const
            {
                return b_[ index ] * a_;
            }
        virtual unsigned int
        size() const
            {
                return b_.size();
            }

    private :
        float a_;
        const vector_t & b_;
    };

delayed_scalar_by_vector_multiply_t
operator*(
    float a,
    const vector_t & b )
    {
        return delayed_scalar_by_vector_multiply_t( a, b );
    }

class delayed_vector_by_scalar_div_t
    :    public vector_element_extractor_t
    {
    public :
        delayed_vector_by_scalar_div_t(
            const vector_t & a,
            float b )
            :    a_( a )
            ,    b_( b )
            {
                if( fabs( b ) < 0.00000000001 )
                    throw std::invalid_argument( "devider is 0" );
            }

        virtual float
        operator[]( unsigned int index ) const
            {
                return a_[ index ] / b_;
            }
        virtual unsigned int
        size() const
            {
                return a_.size();
            }

    private :
        const vector_t & a_;
        float b_;
    };

delayed_vector_by_scalar_div_t
operator/(
    const vector_t & a,
    float b )
    {
        return delayed_vector_by_scalar_div_t( a, b );
    }

class delayed_sum_of_vectors_t
    :    public vector_element_extractor_t
    {
    public :
        delayed_sum_of_vectors_t(
            const vector_element_extractor_t & a,
            const vector_element_extractor_t & b )
            :    a_( a )
            ,    b_( b )
            {
                if( a.size() != b.size() )
                    throw std::invalid_argument(
                            "vectors sizes must be the same" );
            }

        virtual float
        operator[]( unsigned int index ) const
            {
                return a_[ index ] + b_[ index ];
            }
        virtual unsigned int
        size() const
            {
                return a_.size();
            }

    private :
        const vector_element_extractor_t & a_;
        const vector_element_extractor_t & b_;
    };

delayed_sum_of_vectors_t
operator+(
    const vector_element_extractor_t & a,
    const vector_element_extractor_t & b )
    {
        return delayed_sum_of_vectors_t( a, b );
    }

class delayed_sub_of_vectors_t
    :    public vector_element_extractor_t
    {
    public :
        delayed_sub_of_vectors_t(
            const vector_element_extractor_t & a,
            const vector_element_extractor_t & b )
            :    a_( a )
            ,    b_( b )
            {
                if( a.size() != b.size() )
                    throw std::invalid_argument(
                            "vectors sizes must be the same" );
            }

        virtual float
        operator[]( unsigned int index ) const
            {
                return a_[ index ] - b_[ index ];
            }
        virtual unsigned int
        size() const
            {
                return a_.size();
            }

    private :
        const vector_element_extractor_t & a_;
        const vector_element_extractor_t & b_;
    };

delayed_sub_of_vectors_t
operator-(
    const vector_element_extractor_t & a,
    const vector_element_extractor_t & b )
    {
        return delayed_sub_of_vectors_t( a, b );
    }

vector_t &
operator<<(
    vector_t & receiver,
    const vector_element_extractor_t & extractor )
    {
        receiver.clear();
        receiver.reserve( extractor.size() );

        for( unsigned int i = 0, i_max = extractor.size();
                i != i_max;
                ++i )
            receiver.push_back( extractor[ i ] );

        return receiver;
    }

std::ostream &
operator<<(
    std::ostream & to,
    const vector_t & v )
    {
        for( unsigned int i = 0, i_max = v.size(); i != i_max; ++i )
            {
                if( i )
                    to << " ";
                to << v[ i ];
            }
        return to;
    }

void
main()
    {
        const int vector_size = 5;
        float a_src[ vector_size ] = { 1, 2, 3, 4, 5 };
        float b_src[ vector_size ] = { 0.5, 1.5, 2.5, 3.5, 4.5 };

        vector_t a( a_src, a_src + vector_size );
        vector_t b( b_src, b_src + vector_size );
        vector_t d( b_src, b_src + vector_size );
        vector_t c;

        c << 0.0 * a + 2.0 * b - 1 * d + b / 0.2;

        std::cout << c << std::endl;
    }

А если потратить еще некоторое количество времени, то можно сделать еще и поддержку некоторых других сочетаний. Но здесь, вероятно, придется задействовать динамическую память, чтобы классы, производные от vector_element_extractor_t могли сохранять свои операнды по указателю. Чтобы можно было обрабатывать выражения типа:
((a1 * v + a2 * v2)/0.5 - (a3*v3 - a4*v4)*2) * 0.75;

Но такие операции будут эффективны только на больших размерностях. В противном случае расходы на new/delete окажутся значительно дороже, чем сами вычисления.

K>Это шутка? Если это шутка, то ее можно было бы выразить и короче:

K>Зачем макросы, если есть прилежание и усидчивость?

E>>Это демонстрация принципиальной схемы реализации отложенных вычислений в C++, полученная за 15 минут. Более сложные схемы могут быть получены при приложении несколько больших усилий.


K>И, по всей видимости, всего навсего за N * 15 минут, где N — количество всех возможных в линейной алгебре выражений со скалярами, векторами и матрицами? Так ведь можно до конца геологической эпохи не поспеть.


А с макросами, надо полагать, поспели уже.
Видимо, с макросами не нужно все возможные комбинации предусматривать.

E>>Только Nolite mittere margaeritas ante porcas!


K>Да уж, про метание бисера перед свиньями, это к месту, после такого выступления.


Абсолютно.

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


Все проще. Если вы решаете свои вычислительные задачи в рамках своей работы, то можете сами оценить, во что обходится качественный, надежный, универсальный и расширяемый библиотечный код. Соответственно, можете предположить, что я не могу пренебречь своей собственной работой для того, чтобы потратить несколько дней на проектирование достаточно хорошей библиотеки отложенных векторно-матричных вычислений. Тем не менее, данный код показывает, что в C++ можно значительно к этому делу приблизится.

Сначала я дал точную ссылку на Страуструпа, где показан принцип отложенных вычислений. Розовый слон косвенно обвинил меня в трепачестве. Я потратил 15 минут на воспроизводство примера Страуструпа и еще 15 минут своего времени на оформление сообщения с этим кодом. Это практически все, что я мог себе позволить. Вам этого недостаточно? Отлично, я потратил еще 45 минут на это сообщение и новый пример. Что дальше?

Вы считаете, что я над вами решил поиздеваться? Или вы думаете, что я настолько недалек, что не понимаю, насколько демонстрация принципиальной схемы будет далека от промышленного решения? Или вы думаете, что я такой гений, который может за пару часов повторить что-то вроде Blitz++?

Мне кажется, вы забываете где находитесь и что вам здесь никто ничего не должен.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: aka50 Россия  
Дата: 09.07.07 06:12
Оценка: 10 (1)
Здравствуйте, konsoletyper, Вы писали:

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


K>Ой, забыл сказать. Лексер C#. А то лексер вообще можно и за пару минут написать.


Не С# конечно , но просто как иллюстрация

class Parser extends StdTokenParsers with ImplicitConversions {
 // Fill in abstract defs
 type Tokens = Lexer
 val lexical = new Tokens

 // Configure lexical parsing
 lexical.reserved ++= List("true", "false", "null")
 lexical.delimiters ++= List("{", "}", "[", "]", ":", ",")

 // Define the grammar
 def root       = jsonObj | jsonArray
 def jsonObj    = "{" ~ repsep(objEntry,",") ~ "}"
 def jsonArray  = "[" ~ repsep(value, ",") ~ "]"
 def objEntry   = stringVal ~ ":" ~ value ^^ { case x ~ y => (x,y) }
 def value: Parser[Any] = (jsonObj | jsonArray | number | "true" ^^ true | "false" ^^ false | "null" ^^ null | stringVal)
 def stringVal  = accept("string", {case lexical.StringLit(n) => n})
 def number     = accept("number", {case lexical.NumericLit(n) => n.toDouble})
}
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 09.07.07 13:57
Оценка: 10 (1)
Здравствуйте, lomeo, Вы писали:

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


L>>>Можно подробнее о выделенном? Почему этого можно добиться только макросами?


G>>В выражении a = b + c + d, где переменные — матрицы, надо, чтобы все это свернулось в единственный двойной цикл с этой формулой внутри. На плюсах это делается без макросов — через темплейтное метапрограммирование, и выглядит страшно. На макросах, мне думается, реализация выглядела бы проще. Хотя — честно скажу, пока на макросах реализации не видел. Все только говорят, говорят о великих и ужасных макросах — и все .


L>Круто. А можно поглядеть на С++ реализацию?


Гуру из нашей С++ конфы говорят, что есть в библиотеке Blitz++, а вообще решение искать надо по словам expression templates. Сразу предупреждаю — это очень злой С++. Но если попривыкнуть — то там, в сущности, все понятно .
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 30.07.07 17:11
Оценка: 10 (1)
Здравствуйте, lomeo, Вы писали:

VD>>Грамматика была в виде глобального метаатрибута. Что-то типа:


L>Прикольное решение. А в виде чего тогда приходит на макрос BNF параметр после lexer/parser внутри фигурных скобок?

L>Строка? Или уже разобранное лексером от Немерле? Если второе, то разобранное в каком виде? Идентификатор/символ? Можно ли там использовать внешние функции? Можно ли правила использовать снаружи? (последние два вопроса — это насколько правила first-order).

В макрос приходит лексемное дерево. Однако, т.к. версия с генерацией парсера по внешнему описанию использует свои лексер/парсер, то я, чтобы достичь унификации и снизить объём кода, сначала выравниваю лексемное дерево и направляю полученный поток лексем парсеру BNF. Внешние функции нельзя использовать, но это сделано намеренно, чтобы не смешивать грамматику и код — ИМХО, от этого одна только головная боль. Наоборот, я приложил максимум усилий к тому, чтобы можно было писать код/грамматику отдельно, и чтобы это было удобно. Собственно, вот ссылка на рабочий пример — я написал небольшой бенчмарк
Автор: konsoletyper
Дата: 01.05.07
.

К сожалению, сейчас совсем нет времени, так что макрос поддерживает только генерацию лексера. На работе завал. А вот теперь только-только от ICFP отошёл и опять на работе завал Вообще, проблема именно в нехватке времени. Никаких особых технических проблем нет. В своё время поддержку генерации лексера я сделал за пару дней. Если найдётся пара дней, сделаю поддержку парсера. Дело там нехитрое — AST уже есть готовое, надо по нему грамматику и LR-таблицы получить, а по таблицам — сгенерить класс. Последнее — 99% всего, что нужно сделать.

VD>>При этом изменение грамматики автоматически перестраивает генерируемые алгеброические типы, так что сразу доступен комплит-ворд и диагностика ошибок (без какой либо добполниетльной роботы по этому поводу).


L>Не понял, как он ловит ambiguity?


Какой ambiguity?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: GlebZ Россия  
Дата: 06.08.07 13:06
Оценка: 10 (1)
Здравствуйте, lomeo, Вы писали:


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

L>Это не понял. Пример?
По метаданным генерятся типизированные классы. В процессе работы (в runtime), метаданные могут быть изменены пользователем.
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: deniok Россия  
Дата: 08.08.07 20:27
Оценка: 10 (1)
Здравствуйте, VladD2, Вы писали:



VD>Ну, скажем простейшая задача. Хочу сгенерировать некий код для Х типов меня в нем код функции в зависимости от тех или иных условий. Ну, скажем если в типе есть строки, то вывести их на консоль, а если нет, то ничего не делать.


Для этого есть
-- из Data.Generics.Schemes
everywhereBut :: GenericQ Bool -> GenericT -> GenericT
everywhereBut q f x
    | q x       = x
    | otherwise = f (gmapT (everywhereBut q f) x)

-- из Data.Generics.Aliases
-- знакомый нам тип обобщённого трансформера
type GenericT = forall a . Data a => a -> a
-- обобщенный тип запроса, принимающий любой тип a, и возвращающий тип r
type GenericQ r = forall a . Data a => a -> r


Добавим теперь ко всем строкам внутри типа суффикс " hi", не трогая других типов (это аналог твоей задачи)
myTransform  = everywhereBut notStrings (mkT (\s ->  s ++ " hi"))

-- строим конкретный запрос (mkQ - оператор их построения)
notStrings :: GenericQ Bool
notStrings = True ‘mkQ‘ isNotString

isNotString :: String -> Bool
isNotString s = False


Здесь обобщённый запросопостроитель mkQ (родственник mkT):
-- из Data.Generics.Aliases
mkQ :: (Typeable a, Typeable b) => r -> (b -> r) -> a -> r
(r ‘mkQ‘ q) a = case cast a of
                     Just b -> q b
                     Nothing -> r

работает так (ord возвращает ASCII-код)
Prelude> (22 ‘mkQ‘ ord) ’a’
97
Prelude> (22 ‘mkQ‘ ord) ’b’
98
Prelude> (22 ‘mkQ‘ ord) True
22


Вся фишка в том, что тип в Хаскеле — алгебраический: его можно явно рассматривать как дерево и ездить по нему снизу вверх (everywhere) и сверху вниз (everywhere'), по пути фильтруя узлы (everywhereBut) и делая ещё ряд вкусностей:
--Summarise all nodes in top-down, left-to-right order  
 everything :: (r -> r -> r) -> GenericQ r -> GenericQ r 

--Get a list of all entities that meet a predicate  
listify :: Typeable r => (r -> Bool) -> GenericQ [r] 

--Bottom-up synthesis of a data structure; 
-- 1st argument z is the initial element for the synthesis; 
-- 2nd argument o is for reduction of results from subterms; 
-- 3rd argument f updates the synthesised data according to the given term  
synthesize :: s -> (s -> s -> s) -> GenericQ (s -> s) -> GenericQ s
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка: 10 (1)
Здравствуйте, Klapaucius, Вы писали:

K>Честно говоря, принимая во внимание лисповский синтаксис и общую идеологию code is data is code, я вообще с трудом представляю, зачем в LISP нужно (квази)цитирование, как я его понимаю. И термин этот вместе с LISP вообще очень редко встречается. Но я не поленился и поискал статьи по этой теме на CiteSeer. Да, статьи по квазицитированию в LISP есть. Самая старая, что я нашел — 1999 года.


Квазицитирование в Лиспе есть. Когда родилось — не знаю, но родилось именно в нем.

Там вообще клевое цитирование одна ковычка цитирует а другая делает обратное преобразование.

А вот что касается АСТ, то там его нет. Точнее только оно и есть. Нет синтаксиса. S-выражения — это и есть АСТ, так что там не только цитирование в АСТ делалось, но и само программирвоание тоже. От чего язык и ненавдят все те, кто не любит разглядывать 3D-объекты в вэйфрэйме или скажем дома в виде артматуры.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 09.07.07 13:52
Оценка: 8 (1)
Здравствуйте, lomeo, Вы писали:

L>Я не понял, если честно.

L>х у нас заранее создан с нужной длиной?
L>p, s — это матрица или вектора? alpha и omega — скаляры?
L>в чём прикол? почему нельзя просто перемножить и сложить? промежуточные структуры?
L>Можно сам макрос подсмотреть?

Подробности о задаче и решении в этой ветке
http://rsdn.ru/Forum/Default.aspx?mid=1377722&amp;flat=0
Автор: Gaperton
Дата: 12.09.05

На С++.
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 06.08.07 14:00
Оценка: 8 (1)
Здравствуйте, 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>Я не очень понял что значит "управляющие стурктуры". Посему не могу об этом рассуждать. С точки зрения манипуляции функциями Хаскель мало чем отличается от Немерле.


Да и вообще все языки Тьюринг-полные
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 31.07.07 18:58
Оценка: 6 (1)
Здравствуйте, Gaperton, Вы писали:

G>Действительно странно. Вроде как все языки программирования у нас тьюринг-полные. Я вот ни разу такой задаси не встречал. Может, поделишься задачкой, наконец? А то все говорите, говорите...

Да запросто.
Если раскажешь как решить без кодогенерации будет очень интересно послушать.
Долбить генерируемый код ручками не предлогать.

G>У тебя сложность кодогенератора О(N^4)? Ужас какой.

Алгоритм Флойда — Уоршела О(N^3) если нужны только растояния. Мне же нужны сами пути. И если я не разучился считать то изменения которые запоминают пути делают алгоритм О(N^4).

G>Ну так давай пример в студию, посмотрим на этого зверя . В смысле — задачу опиши.

Есть библиотека обработки изображений (данная область представляет собой весьма мутную и плохо изученую магию).
По ходу изучения и эксперементов выяснилось что разные фильтры нужно делать в разных цветовых пространствах.
На данный момент у меня получилось 19. Откуда они взялись не спрашивай. Очень долго объяснять. Просто поверь что надо. Я долго пытался обойтись одним но у меня не получилось.
Так вот для каждого пространства нужно описать свой тип. Описание занимает строк 40-50 при том что они все шаблонные и их разлячия легко укладываются в одну строку.
Писать это руками мне очень быстро надоело. Сейчас данное описание у меня генерируется.
Не смотря на то что структура у некоторых из них одинаковая их необходимо различать на этапе компиляции ибо если не дай бог их перепутать то потом будешь очень долго искать почему картинки получаются с кучей малозаметных артефактов.
Но это не главная засада.
Проблема в том что мне в любой момент может понадобится преобразовать из одного цветового пространства в другое.
И писать N^2 преобразований мне мягко говоря не хочется.
Тем болие что большинство из них сводятся к преобразованию через цепочку пространств.
Вот я и задал основные преобразования, назначил им веса и остальное сгенерил.
Дописывать преобразования по мере необходимости не вариант. Ибо не смотря на то что битмап у меня шаблон таскаю я его через полиморфную базу иначе будет несколько усиливающих друг друга комбинатроных взрыва, а мне и одного хватает... Хотя благодоря кодогенератору он меня не сильно парит.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[58]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 17:04
Оценка: 6 (1)
Здравствуйте, EvilChild, Вы писали:

EC>
EC>    return new Action<Integer>(){int act(){t.method2(param);}};
EC>

EC>Можешь эту строку пояснить? Особенно интересует выделенное.
EC>Я правильно понял, что экземпляр интерфейса по new создать можно или это что-то другое?
Нет, ты создаешь анонимный класс, реализующий интерфейс Action.

Точно так же можно и расширять классы:
interface Action<T>
{
    void act(T param);
    void doNotAct(T param);
}

class ActionAdapter<T> implements Action<T>
{                                          
    void act(T param){} //Do nothing.
    void doNotAct(T param){}
}

class Test2
{
    private final Test t = new Test();

    public Action<T> getAction()
    {
                final int outerVar=123;

        if ((System.currentTimeMillis() % 10)==0)
            return new ActionAdapter<Integer>(){int act(){t.method1(param);}};
        else
            return new ActionAdapter<Integer>()
            {
                                int someVar;
                                {
                                   //Анонимный конструктор
                                   someVar=Math.random(); 
                                   if (someVar%2==0) someVar=outerVar; //Обращаемся к локальным переменным метода
                                }

                int act(){t.method2(param);}
                int doNotAct(){//Haha!}
            };
    }
}
Sapienti sat!
Re[34]: Generic programming
От: BulatZiganshin  
Дата: 15.08.07 18:56
Оценка: 6 (1)
Здравствуйте, VladD2, Вы писали:

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


BZ>>так вот, описание констант или темплейтов в C++ тоже можно считать средставми макроподстановки и генерации кода. тем не менее это средства, которые сингтегрированы в сам язык, и никто их не отделяет от "обычной" порграммы.


VD>Шаблоны С++ не позволяют программировать генерацию. Они просто позволяют подставить праметры. Разумется, что это справедливо, если мы не ведем речь о метапрограммировании на шаблонах в стиле Александреску (с испоьзованием побочных эффектов при частичной специализации и рекурсивных шаблонах).


она программируется, но на другом языке. понимаешь, метаязык — это тоже язык, хотя он выглядит по-другому и даже может быть не Тьюринг-полным и вообще его предназначение — не вычисления, как у базового языка, а генерация кода. вот макроязыки типа немерле, TH или препроцессора pl/1 — они обычные императвиные языки, по идеологии похожие на какой-нибудь С

язык же темпоейтов C++ насколько я в курсе — фнкциоанльый и при этом Тьюринг полный. язык typeclasses хаскеля — логический и тоже Тьюринг-полный. на них обоих иожно реализовать, к примеру, обычную арифметику, используя так называемые Peano numbers — числа, представленные типами:
data Zero 
data Succ a
-- тип Succ Zero представляет 1, Succ(Succ Zero) - 2 и т.д.

class Add a b c | a,b->c  -- класс описывает соотноешние между трёмя типами a,b,c такими что a+b=c
instance Add Zero Zero Zero
instance Add a b c => Add (Succ a) b (Succ c)  
instance Add a b c => Add a (Succ b) (Succ c)  
-- согласно этим правилам вывода этому классу например принадлежит 
-- Add (Succ(Succ Zero)) (Succ Zero) (Succ (Succ(Succ Zero)))


так вот, в то время как макросы обеспечивают доступ к AST генерируемого кода плюс обычные средства ЯП для манипуляции с ним — templates/generics предоставляют свой собственный набор операций, нацеленный именно на generic программирование, и в этой области они позволяют достигать того же эффекта затратой куда меньших усилий. сишные темплейты вероятно не позволяют реализовать то, что тебе нужно, но в хаскеле это одна из поппулярных областей исследований и среди хаскеловских систем generic программирования есть достаточно мощные

в частности, syb подход (у которого есть динамическая и compile-time реализации) позволяет строить достаточно мощные функции, производящие обход структуры данных и различные манипуляции над ней — map, fold, zip и т.д. в статическом подходе с помощью type classes генерится код, специфичный для данного конретного типа. т.е. запись типа такой:

data T = A Int T | B Int String | C String | D [T]
f = gmap (+1)

генерится такой:
f (A n t) = A (n+1) (f t)
f (B n s) = B (n+1) s
f (C s)   = C s
f (D ts)  = D (map f ts)


можешь нарисовать определения type classes/templates для операции "делать +1 рекурсивно" и убедиться, что именно такой код сгенерится. хаскел просто предсоатвляет более высокооуровневые средства, позволяя определить универсальную порцедуру gmap, через которую можно выражать любые рекурсивные обходы данных, в то втремя как в C++ каждый такой gmap(+1) придётся писать индивидуально

подытоживая — речь идёт о том, что задачи generic программирования, которые в C* языках имеют решение только черехз макросы, здесь могут быть рещшены другими средствами, непосредственно отражающими специфику области. вот и всё. макросы, как всегда — универсальный инструмент для реализации всего того, чего ещё нет в языке
Люди, я люблю вас! Будьте бдительны!!!
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 13.09.07 10:58
Оценка: 4 (1)
Здравствуйте, lomeo, Вы писали:

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


VD>>По любому счету ФВП есть почти в любом языке. Так что не надо разводить софистику. Монады — это черная магия непонятная никому кроме тех кто влюблен в Хаскель. И аргументировать хаками с монадами отсуствие необходимости в прямых и понятных средствах, на мой взгляд, просто бессмысленно. Если достаточно ФВП и там скажем замыканий, то флаг вам в руки. Покажите примеры на C# 3.0, скажем, или на Скале.


L>Примеры чего? Парсека? Зачем мне его показывать на шарпе не пойму — чтобы доказать, что монады в парсеке не нужны? Или что? Ты чего хочешь понять/узнать/прояснить?


Кстати, вот Mirrorer кинул тут на днях ссылку — не совсем парсек, конечно, но рядом с этим (и на шарпе).
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: jazzer Россия Skype: enerjazzer
Дата: 14.09.07 03:02
Оценка: 4 (1)
Здравствуйте, lomeo, Вы писали:

L>При чём тут С++?


L>Оффтопик: целочисленные параметры в шаблонах — это, конечно, здорово, а над этими параметрами можно проводить стандартные операции над целыми числами для генерации нового типа?


В смысле? поясни на примере, что ты хочешь получить. Но скорее всего ответ — можно.
Например, из того, что пришло в голову навскидку, вот как можно реализовать быструю конкатенацию двух массивов (скажем, буферов) в третий с контролем длины при компиляции:
template<class T, int n1, int n2>
void array_copy_cat(T (&dest)[n1+n2], const T (&s1)[n1], const T (&s2)[n2])
{
  memcpy(dest,    s1, n1);
  memcpy(dest+n1, s2, n2);
}

int main()
{
  const int asd[] = {1,2,3};
  const int qwer[] = {4,5,6,7};
  int asdqwer[] = {1,2,3,4,5,6,7};
  int asdqwe[] = {1,2,3,4,5,6}; // всего 6 элементов, а надо 7
  
  array_copy_cat(asdqwer, asd, qwer);
  array_copy_cat(asdqwe, asd, qwer); // не скомпилируется
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.09.07 03:06
Оценка: 4 (1)
Здравствуйте, lomeo, Вы писали:
L>Оффтопик: целочисленные параметры в шаблонах — это, конечно, здорово, а над этими параметрами можно проводить стандартные операции над целыми числами для генерации нового типа?
Ну конечно же можно. И проводят — только в путь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.08.07 10:33
Оценка: 3 (1)
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>А какого типа List? (В примере будет Customer, как я понимаю, но меня интересует "вообще"). Там же не Object, который разгребается рефлексией?


Именно что object.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: mkizub Литва http://symade.tigris.org
Дата: 05.07.07 11:26
Оценка: 2 (1)
Здравствуйте, EvilChild, Вы писали:

M>>Видимо, ты всё-же хотел спросить не это, а то — насколько множество задач решаемых

M>>макросами и множество задач решаемых мощной системой типов пересекаются.
EC>Ну, если подходить к формулировке совсем формально, то да.
EC>У тебя есть идеи на этот счёт (я про сформулированный тобой вопрос)?

Мне пришла в голову чуть попозже эта идея.
В хаскеле тоже есть макросы, и в ocaml-е есть макросы. Можно сравнить где используются макросы и
где используются типы. В одном и том-же языке.

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

Всё таки, сколько я на них не смотрю — всё больше видится, что макросы и типы — они
имеют разные области применения, и пересечение этих областей достаточно небольшое.
Но как количественно сравнить лампочки с апельсинами — не вижу пока.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 08.08.07 14:01
Оценка: 2 (1)
Здравствуйте, Gaperton, Вы писали:

G>Не надо домножать каналы на значение альфы. Она отдельным каналом идет, и пусть идет.

G>Нелинейные коррекции проводить при преобразовании к плаващей запятой тоже не обязательно
Если не знаешь как работают с изображениями у которых есть альфа канал и почему нальзя то что ты загрузил из файла обрабатывать без нелинейных коррекций то не выступай.

Чтобы не быть голословным
http://files.rsdn.ru/620/images4gaperton.zip
src — исходное изображение
остальные это увеличеное до 100х100 исходное изображение
good — то как должно быть
bad — без домножения на альфу и нелинейной коррекции цветов (специально для тебя ломал ресайз... с первого раза не получилось... компилятор по рукам надовал )

Из-за альфы мы имеем синий оттенок.
Из-за отсутствия нелинейной коррекции темные переходы между цветами.

А самое плохое то что эти артефакты хорошо видно только на специально подготовленных для этого изображениях.
Но для того чтобы подготовить картинку нужно об этих артефактах знать.
Только не говори что это неуловимый Джо. Мне родственник одного из этих артефактов попортил немало крови. Причем появлялся он на одном из промежуточных изображений на котором был практически не видим... но на рзультате это сказывалось просто катосрофически.

G>Что именно ты пробовал. На сколько именно процентов это "просадило" библиотеку по скорости.

На некоторых фильтрах в разы.

G>На сколько увеличился объем кода.

Величелось не особо мильно но завелось куча мусора.

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

Сссылка на авторитет ни разу не аргумент.
Я не видел ни одной публичной библиотеки которые бы не создавали на картинках артефакты.
Некоторыми артефактами (которых у меня нет) даже фотожаба грешит.
В томже архиве лежат варианты гимпа и фотожабы. Они использовали другие фильтры но это не важно... главное то что и те и другие забыли про нелинейную коррекцию из-за чего получили темный переход между цветами.

Жду варианта от твоих спецов.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.09.07 12:08
Оценка: 2 (1)
Здравствуйте, Gaperton, Вы писали:

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


Ошибка типов может выскачить в С++, C#, Java, VB.NET и т.п. Это не значит, что это не статически типизированные языки. Как совершенно не важно есть ли прибмбасы для частичного вывода типов. Важно скорее другое. Рассчитан ли язык на то чтобы на нем можно было написать программу которая вообще не содержит мест способных вызвать ошибку типов в рантайме. Вот это для С++, C#, Java, VB.NET верно. Хотя и сложно осуществимо... порой...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: FR  
Дата: 17.06.07 11:25
Оценка: 1 (1)
Здравствуйте, Курилка, Вы писали:


FR>>Кроме макросов и страшной системы типов есть и другие способы метапрограммирования, например метаклассы.


К>Ммм, ФВП ты считаешь страшной системой типов?

К>А про метаклассы можно пример?

class metaClass(type):
    def __new__(cls, classname, bases, classdict):       
        
        # сохраняем значение в замыкании
        def get(value):
            return lambda self : value
        
        # перебираем все имена и те что имеют тип readonly подменяем на свойства
        for key, value in classdict.iteritems():
            if isinstance(value, readonly):
                classdict[key] = property(get(value.value))
        
        #setattr(cls, "__setattr__", None)    
        return type.__new__(cls,classname,bases,classdict)


class A(object):
    __metaclass__ = metaClass
    a = readonly(1)
    b = readonly("text")

t = A()
print t.a, t.b


Кроме того в питоне есть другое очень удобное средство метапрограммирования, декораторы, они конечно менее мощные чем метаклассы, но более удобные:
# декоратор
def cache(func):
    map = {}
    def call(*args):
        if map.has_key(args):
            return map[args]
        else:
            result = func(*args)
            map[args] = result
            return result

    return call

@cache
def ack(a, b):
    if b == 0:
        return ack(a - 1, 1)
    elif a==0:
        return b + 1
    else:
        return ack(a - 1, ack(a, b - 1))


К>Или вот здесь, питонский пример есть подобная штука?


Нет, этот пример только показывает, что тот кто его писал не знает питона, там все существенно проще:
def foo(n):
    return lambda i : i + n
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 10:17
Оценка: 1 (1)
Здравствуйте, konsoletyper, Вы писали:

L>>Для лексера необходимости в макросах нет. Погляди Parsec.


K>Уже давно глядел. Не понравилось.


Давай не будем это считать аргументом.

K>Во-первых, все эти <###> смотрятся коряво, а хотелось бы человеческого EBNF-образного синтаксиса.


Синтаксис очень близок к EBNF вплоть до переименования.
Вместо "|" здесь "<|>", вместо +/* — many1/many, вместо '(' — char '(', "abc" — string "abc".

parseValue = choice [litString, litInt, litBool, parseList]

-- можно и ближе к EBNF: litString <|> litInt <|> litBool <|> listParser

parseList = do char '['
               elems <- parseValue `sepBy1` listSep
                             char ']'
                             return (TList elems)

listSep = do skipSpaces
             char ','
                         skipSpaces

skipSpaces = skipMany space


и т.д.

Помимо этого есть expression parsers, ещё более облегчающие описание.

K>Кроме того, мнее вообще непонятно, как это всё работает.


Это тоже вряд ли сойдёт за аргумент

K>Для этого надо сначала монады вкурить (а я этого не осилил), да потом ещё придумать, как извратиться, чтобы на монадах всё это построить. А на макросах я генератор лексера без какой-либо серьёзной математики сделал.


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

K>Вон, на C++ тоже есть boost::spirit. И вот после мне говорят, что нафиг нужны макросы? А спрашивается, если их уже давно эмулируют через левое плечо на монадах и шаблонах, так почему бы не ввести в язык сами макросы. Даже если согласиться с утверждением, что макросы порождают кривизну, то отсюда следует, что эмуляция макросов породит её большую кривизну.


Так в том то и дело, что макросы не надо эмулировать, если язык позволяет обойтись без них.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 10.07.07 04:09
Оценка: 1 (1)
Здравствуйте, mkizub, Вы писали:

FR>>Вот на схеме без использования макросов http://okmij.org/ftp/Scheme/pure-oo-system.scm


M>А при чём тут schema? Про существование CLOS я знаю, что это можно сделать на схеме — тоже.

M>Речь шла о хаскеле.

Вроде речь шла о том что можно реализовать без макросов, там это сделано при том:

; The present code implements a classless, delegation-based OO system, similar
; to those of Self or Javascript. This is a full-fledged OO system with
; encapsulation, object identity, inheritance and polymorphism. It is also
; a purely functional system: there is not a single assignment or
; other mutation in the code below.

Так что думаю на любой функциональный язык перепишется.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: deniok Россия  
Дата: 10.07.07 16:15
Оценка: 1 (1)
Здравствуйте, lomeo, Вы писали:

L>По идее в оптимизаторе была трансформация


L>
L>foo = \x -> C x
L>bar = \(C x) -> f x -- так имел ввиду, а не \C x -> f x ??

L>bar . foo => \x -> f x
L>
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 13:24
Оценка: 1 (1)
Здравствуйте, Klapaucius, Вы писали:

L>>Нет. PackedString прошлый век

L>>Сейчас есть BinaryString.

K>Это что-то ужасно секретное, да? Поиск в Google и на haskell.org ничего не дал.


Ой сорри. Я имел в виду ByteString (Duncan Coutts, Don Stewart)

Начать можно отсюда: Data.ByteString
Основная статья: Rewriting Haskell Strings
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 12:53
Оценка: 1 (1)
Здравствуйте, EvilChild, Вы писали:

EC>Расшифровываю свою мысль специально для юмористов: макросы повышают порог вхождения -> увеличивают стоимость разработки.

EC>Если для более традиционных способов написания кода есть куча техник и практик, то с макросами всё не так радужно.
EC>На данный момент это больше похоже на чёрную магию.
EC>Безусловно, что в прямых руках и при наличии адекватной задачи это может быть лучшее средство.

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

А что до устрицы, то использование живых организмов в качестве примера и повода для размышлений о сложных системах — чрезвычайно удобно. По многим причинам. Включая широчайших диапазон сложности этих организмов, широчайший диапазон различных решений проблем исходящих из этой сложности и так далее. В частности, ни один живой организм не ведёт себя полностью предсказуемо — просто потому, что это невыгодно энергетически, а при определённом уровне сложности — недостижимо в приципе. А бороться за выживание надо. Вот живые организмы и поддерживают оптимальный "баланс" между надёжностью и стоимостью, между сложностью различных уровней иерархии управления и т.д. Думать о целом — это непривычный способ мысли для нас. Надо его в себе воспитывать, использовать, сверять результаты размышлений с реальными сложными, целыми системами. Тогда не будет противоречий в том, что да, макросы повышают порог вхождения -> увеличивают стоимость разработки, и в то-же время в сумме они уменьшают стоимость разработки.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 04:45
Оценка: 1 (1)
Здравствуйте, Cyberax, Вы писали:

IT>>10000 нужно ещё умножать на фактор, зависящий от количества посетителей.

C>Для 100 запросов в секунду — будет всего миллион рефлексий. Кроме того, оптимизатор рефлексии

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

C>вообще сведет оверхед к минимуму (по моим тестам в Java, генерируемые accessor'ы примерно в 10 раз быстрее стандартной рефлексии, которая примерно в 200 раз медленнее прямого вызова).


По моим тестам, генерируемые аксессоры всего лишь в 3-4 раза быстрее рефлекшина, чего достаточно, чтобы кастомер на глаз замечал задержку.

C>Дык без проблем. Вот живой код:

C>
C>List<Need> needs=(List<Need>)sess.createQuery("from Need f inner join fetch f.position"
C>    "where f.date > :date and f.status='OPEN'")
C>    .setDate("date",needDate).setCacheable(true).list();
C>

C>(в строке запроса работает автокомплит, просмотр генерируемого SQL и т.п. — injected languages в IDEA, однако).

Допустим, так получилось, что я переименовал одно поле. Как отреагирует твой ынхибернейт:

List<Need> needs=(List<Need>)sess.createQuery("from Need f inner join fetch f.position"
    "where f.date > :date and f.statuus='OPEN'")
    .setDate("date",needDate).setCacheable(true).list();

C>Ну не знаю, Hibernate держит свой кэш на любом провайдере.

Видишь ли в чём дело. Машина не должна думать, машина должна ездить. Я не люблю когда машина додумывает за меня куда мне нужно ехать.

C>Так может стоит посмотреть? А то все твои проблемы — высосаны из пальца, что называется.


Боюсь, что из пальца как раз высосан твой ынхибернейт. Извини, но этот пост не о монстриках, этот пост о макросах, задача которых убрать из кода тексуальщину и заменить её на проверяемую компилятором декларативность.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 16:53
Оценка: 1 (1)
Здравствуйте, IT, Вы писали:

IT>Ответ неверный. DAL нужен для изоляции кода, работающего с БД от остальных частей приложения. Ключевое слово здесь изоляция. Проблема в том, что фактически мы пишем код на двух языках, при этом один из них, SQL, вообще никак не контролируется компилятором. DAL изолирует этот код и не позволяет ему расползаться по всему приложению.

"А Баба Яга против!" (с) мультфильм.

Я уже привел пример с Hibernate. Почти весь DAL концентрируется в отдельной библиотеке, в результате в основном коде можно не волноваться о мелочах. Статическая проверка тоже в большинстве случаев нормально делается.

IT>>>
IT>>>class UI
IT>>>{
IT>>>  void OnLoad()
IT>>>  {
IT>>>    binder.List = from c in Customer select c;
IT>>>  }
IT>>>}
IT>>>

GZ>>Пример достойный example или простейшего проекта.
IT>О! Видишь что с людями делает декларативщина? Тебе этот код кажется примитивным? Правильно. А почему? Да потому что в нём нет ничего лишнего. Ни одного лишнего элемента. Учитывая, что в обычном коде мусора как правило больше половины, то смотря на такой код хочется зажмурится, как когда смотришь на яркий свет. Что-то тут не так, где-то нас обманывают. Только с декларативностью можно добиться такого примитивизма.
Ужжжас, а не пример.

Откуда мы берем соединение для работы с Cusomer'ом? Что будет при навигации по связям от него? Вернется ли нам disconnected dataset? Какой пользователь используется для работы с данными?
Sapienti sat!
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.08.07 00:41
Оценка: 1 (1)
Здравствуйте, Курилка, Вы писали:

К>Будет новый набор решений, но вот обязательны ли для них макросы?

К>Имхо, нужно ограничить их реализумость/применимость/видимость. Т.е. сделать что-то аля "только программист с чёрным поясом по N может писать макросы и он должен учитывать по возможности последствия их применения".

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

Тут действует естественный отбор. Его код не то что будет содержать фатальные ошибки. Он банально не скомпилируется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.08.07 00:41
Оценка: 1 (1)
Здравствуйте, Kisloid, Вы писали:

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


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

Первый шаг уже сделн. Есть метод который позволяет породить такой код. Он пока работает не всегда и глчит. И не вызвается для макросов-выражений и т.п. Но он показывает приципиальную возможность реализации данного подхода. Так что будет жив Немерле — будет и эта возможность.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Являются ли макросы свидетельством недостаточной выразительн
От: EvilChild Ниоткуда  
Дата: 16.06.07 13:11
Оценка: :)
Имеются в виду взрослые макросы a-la Lisp или Nemerle, а не те, что в C.
Или так: нужны ли макросы в таких языках как Haskell?
now playing: Spor — Ultimate Technology
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: FR  
Дата: 17.06.07 11:27
Оценка: +1
Здравствуйте, Курилка, Вы писали:

К>Ммм, ФВП ты считаешь страшной системой типов?


Нет конечно, там в контексте было про систему типов, а ФВП я считаю хорошим средством сильно уменьшающим потребность в макросах.
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: Кодёнок  
Дата: 20.06.07 07:48
Оценка: +1
Здравствуйте, Курилка, Вы писали:

К>Может путано выразился, но мысль в том, что всякие операции аля +, * — императивны, т.к. преобразуются по сути в ассемблерные инструкции и тот же синус выраженный рядом Тейлора есть результат некоторого последовательного вычисления.


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

Одна и та же запись может быть императивом с одной точки зрения и декларацией с другой. Например, объявление списка
[("add", "ax", "bx"),
("imul", "ax", "dx"),
]
есть чистая декларация с точки зрения языка на котором это написано, и есть чистый императив с точки зрения подпрограммы выполняющей команды из этого списка. Другой пример Лисп: (+ a b) = список из трех элементов.

Императивный или декларативный целиком зависит от того с какой точки зрения посмотреть — является ли это объявлением списка, или инструкцией. Часто и то, и другое. Можно сказать что любая запись есть декларация элементов дерева синтаксического разбора Это как хорошее или плохое — зависит от твоей трактовки.
Re[3]: Являются ли макросы свидетельством недостаточной выра
От: mkizub Литва http://symade.tigris.org
Дата: 04.07.07 17:03
Оценка: +1
Здравствуйте, EvilChild, Вы писали:

EC>Можешь обосновать почему подход Haskell это через жопу автогеном? Желательно на техническом языке, без всяких там печек, ложек и прочей профанации?


Зачем тебе на техническом языке объяснять философские проблемы? Это и есть — через жопу автогеном.
Мета-программирование и система типов — предназначены для решения разных задач.
Заниматься мета-программированием через типизацию — это использовать неверный инструмент.
Вот ножик. Удобная вещь. Им можно много чего. В поход лучше взять ножик, ну ещё топор — и это покроет 90% твоих потребностей в инструментах.
А вот говорить по этому поводу, что раз шурупы можно вертеть ножиком — то давайте отменим отвёртки — это неадекватно.
Это разные инструменты.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.07.07 22:59
Оценка: -1
Здравствуйте, mkizub, Вы писали:

M>Всё таки, сколько я на них не смотрю — всё больше видится, что макросы и типы — они

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

На самом деле, тут все просто. Системы типов Хасклея и С++ допускют вычисления во время компиляции. Естественно, авторами языков это не планировалось как отдельная фича. Так что использование этгого эффекта есть ничто иное как использование незапланированного побочного (наведенного) эффекта. Некоторые техники программирования позволяют используя этот побочный эффект достигать тех же целей, что достигаются полноценными макросистемами (вроде Лисповской, Немерловой и (сюрприз !) ТемплэйтХаскелевской). Естественно, что так как это не прямое средство, то и решения получаются более сложные и ограниченные.

В области типо макросы вообще мало что могут. Конечно ими можно пол языка переписать (если они мощьные), но это все же не то. Посему за рамками метапрограммирования сравнивать их если не бессмысленно, то по крайней мере сравнение будет настолько философским, что теряет всякий прикладной смысл (это я про VTBL на макросах ).

Ну, а как может выигрывать продукт в котором для достижения цели используется побочный эффект по сравнению с продуктом в котором используется специально спроектированная для этого фича лично я понять не могу. Ну, не могу я сравнивать бульдозер с велосипедом к которому приделана совковая лопата.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 06.07.07 15:18
Оценка: +1
Здравствуйте, Курилка, Вы писали:

К>А можно поподробней по поводу выделенного? Макросы по дефолту ускоряют результирующий код чтоль?

Нет.
Но иногда единственный способ добиться оптимальной производительности это сгенерить кучу кода.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: Gaperton http://gaperton.livejournal.com
Дата: 07.07.07 08:22
Оценка: +1
_>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?

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

не каждая задача, которую можно ускорить не жертвуя читабельностью, этого стоит. В действительности, узкие места по производительности обычно хорошо локализованы, и программист плохо их угадывает. Поэтому, применение макросредств для увеличения производительности — это во многих случаях преждевременная оптимизация — это не может быть типовым случаем их применения.
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.07 06:48
Оценка: +1
_>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?

Вопрос, наверное, не в возможности-невозможности, а в удобстве.
Макросы дефакто более высокоуровневый механизм.
Мне, допустим, претит строит на классах тяжеловесные паттерны, когда можно обойтись парой строчек макроса.
Опять же, паттерны — это всё таки какое-никакое дублирование рализации.
А как мы уже давно обсуждали, все паттерны в язык не встроишь, да и не надо.
Слишком навороченный язык — имхо тоже зло.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.07 07:14
Оценка: +1
К>Что есть критерий навороченности? Макросы ведь однозначно делают язык навороченней.

Макросы "наворачивают" язык локально.
Все навороты предусмотреть нельзя, а если попытаться, — язык превратится в тысячеглавого монстра.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 09.07.07 05:37
Оценка: -1
Здравствуйте, mkizub, Вы писали:

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


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

G>>валяйте, давайте сюда пример, и я покажу, как его сделать без макросов и паттернов. Мне хватит паттерн-матчинга, атомов, и первоклассных функций.

M>Реализуйте паттерн ОО, плиз.


Вот на схеме без использования макросов http://okmij.org/ftp/Scheme/pure-oo-system.scm
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 09.07.07 05:57
Оценка: :)
Здравствуйте, FR, Вы писали:

K>>Ой, забыл сказать. Лексер C#. А то лексер вообще можно и за пару минут написать.


FR>По твоему лексер C# написать проще чем большинство паттернов?


Нет. Зато проще, чем парсер С#
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 09.07.07 12:51
Оценка: +1
Здравствуйте, konsoletyper, Вы писали:

K>Вот Хаскель — продвинутый язык, и в нём можно во многих случаях сделать то, что в Лиспе делается исключительно на макросах. Но не всё. Так почему же Хаскелю не нужны макросы?


Ну... Те кто делал Template Haskell по всей видимости думали, что Haskell макросы нужны.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'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[14]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 13:19
Оценка: :)
Здравствуйте, Klapaucius, Вы писали:

L>>Для лексера необходимости в макросах нет. Погляди Parsec.


K>Не подскажете где можно посмотреть сравнение производительности лексеров, написаных с помощью Parsec и других генераторов лексеров?


Не подскажу Я этим как то не интересовался.

В доке от 2001 года говорится, что

Speed. Most combinator libraries lack the speed necessary to be competetive with bottom-up parser generators. Parsec uses some novel techniques to improve its performance. The library is fast, parsing thousands of lines a second on today's machines


Но тысячи в секунду, это как то маловато, если честно. Даже для 2001. Очень-очень сомневаюсь, что это связано с тем, что реализация не на макросах. Надо с Happy сравнить. Полагаю, проблема всё таки в строках Haskell-а, которые как известно, медленные. Можно попробовать подключить binary string и померить.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 13:50
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

L>>Можно подробнее о выделенном? Почему этого можно добиться только макросами?


G>В выражении a = b + c + d, где переменные — матрицы, надо, чтобы все это свернулось в единственный двойной цикл с этой формулой внутри. На плюсах это делается без макросов — через темплейтное метапрограммирование, и выглядит страшно. На макросах, мне думается, реализация выглядела бы проще. Хотя — честно скажу, пока на макросах реализации не видел. Все только говорят, говорят о великих и ужасных макросах — и все .


Круто. А можно поглядеть на С++ реализацию?

На GHC можно через GHC Rewrite Rules свернуть. Т.е. пишем a + b + c, где a, b, c — матрицы, а оно сворачивается в sum3 a b c. Но это именно для этой задачи: сложение трёх элементов. Для произвольного количества сходу придумать не могу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: deniok Россия  
Дата: 09.07.07 13:59
Оценка: :)
Здравствуйте, lomeo, Вы писали:

L>Круто. А можно поглядеть на С++ реализацию?


L>На GHC можно через GHC Rewrite Rules свернуть. Т.е. пишем a + b + c, где a, b, c — матрицы, а оно сворачивается в sum3 a b c. Но это именно для этой задачи: сложение трёх элементов. Для произвольного количества сходу придумать не могу.


Кстати здорово — задача оптимизации решается прямым указанием оптимизатору! Rewrite Rules rulez
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 09.07.07 16:32
Оценка: +1
Здравствуйте, mkizub, Вы писали:

M>С того, что речь в этой ветке идёт о хаскеле, с его крутой системой типов. Которая может и заменяет макросы (в чём я соменваюсь), а вот с ОО не дружит принципиально.


В этой подветке, которую начал я, я про Хаскель с его крутой системой типов речи не вел.

M>Но если вы о схеме речь завели — то лисп со схемой — это макросо-ориентированные языки по самые гланды. Там это на макросах сделано, а не на системе типов.


Вам ясно сказали, черным по белому, что в схеме ОО делается без макросов. На замыканиях оно делается в схеме.
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.07 18:35
Оценка: :)
Здравствуйте, the_dip, Вы писали:

_>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?


Любой DSL.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: FR  
Дата: 10.07.07 04:28
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


FR>>В Смаллталке нет супер системы типов, нет и макросов, однако гибкость языка (+ метаклассы) позволяет легко решать те же задачи для которых используются макросы.


VD>Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.


Влад ты демонстрируешь сейчас абсолютного Блаба.
В том же смаллтаке очень многое (например управляющие инструкции) реализуется без метаклассов, чисто на блоках кода.
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.07.07 06:14
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Испоьзовать фунции высшего порядка и их комбинации сегодня можно даже в C#. Но вот для реальной жизни нужно порой изменять синтаксис и/или производить вычисления во время компиляции.


Изменение синтаксиса и вычисление во время компиляции — это да. Это область макросов, но при чём тут DSL?

VD>Причем не важно реализуется МП макросами или выкрутасами с системой типов Хасклея/С++.


Что такое выкрутасы с системой типов Хаскеля? Вот мы тут с konsoletyper про Parsec говорили. Это выкрутасы?

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


VD>Но, самое смешное, что в Хаскеле (точнее его базовой реализации) есть прямой путь для решения этих проблем. ТемлэйтХаскель никто не оменял.


Ну про базовую не верно. Я кроме GHC не знаю где ещё есть.

VD>И для решения проблем с помощью МП он подходит намного лучше чем просто Хаскель. Да что там говорить? Сам факт наличия этого расширения говорит о том, что кому-то оно было нужно. Не так ли?


Да. Оно нужно для того, для чего нужны макросы — компайл-тайм кодогенерация.

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


Где монады при использовании Парсека? Там вообще парсер сделали монадой только чтобы можно было в do писать. А так писал бы, ствавя вместо EBNF-ной запятой свой значок.

Вон konsoletyper написал код для парсинга JSON-а. Повтори на Парсеке — будет практически один в один.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 10.07.07 11:28
Оценка: :)
Здравствуйте, Gaperton, Вы писали:

G>Вам ясно сказали, черным по белому, что в схеме ОО делается без макросов. На замыканиях оно делается в схеме.


Пришлось посмотреть. Убого. Крайне убого. Ни о какой производительности такой реализации и речи быть не может. Игрушка.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка: -1
Здравствуйте, c-smile, Вы писали:

CS>Я согласен с тем что язык программирвания должен быть адекватен задаче.

CS>Но в системах где язык строится под задачу мы имеем проблему обучения — освоение превращается в нетривиальную и постоянно меняющуюся задачу.

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

DSL-и принципиально проще чем унивирсальные языки. И учить из заранее не надо. Когда человек сталкивается с новой предметной областью, то изучение специального микро-языка является самым малым, что ему требуется изучить. Причем если ему не прийдестя учить этот микро-яызык, то он будет изучать библиотеки облегчающие решение задачи (что как минимум не проще), а потом пытаться писать код которые будет совершенно точно занчительно более сложным и ниуклюжим нежели код на специализированном языке. А если он решит не использовать ни ДСЛ-и, ни библиотеки, то он будет вынжден или создать библиотеки самостоятельно, или вообще нагородить море дублирующегося кода и с вероятностью 99% завалить проект.

CS>В результате получается...


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

CS>Я думаю что можно говорить о том что BISON/YACC + С есть некий супер-мета-язык.


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

CS>Такой подход в котором мухи с котлетами отдельно подчас более честный что-ли.


А что там отделено, то? Там как раз довольно глупо все намешано. Вот погляди
Автор: konsoletyper
Дата: 31.03.07
как тоже самое реализовал konsoletyper на Немерле. Вот это действительно отделение мух от котлет. С помощью EBNF описывается чистая грамматика. На ее базе генерируется набор алгебраических типов (вариантов), и уже они разбираются прикладной логикой, которая и делает все что нужно. Это позволяет читать чистую грамматику с одной стороны, и обрабатывать любые тонкости разобранного представления с другой. То есть, действительно, котлеты и мухи отделены по полной порограмме.

Дополнительные бенефиты такого подхода заключается в том, что при изменении грамматики автоматически перегенерируются варианты, что с одной стороны приводит к тому, что все разбираемые конструкции доступны в интелисенсе, а с другой к тому, что правильность кода контролируется в реальном времени (ошибки просто подсвечиваются в IDE).

BISON/YACC нервно курят в сторнке. Он просто прошлый век. С подобным решением может тягаться только специализированная IDE вроде той, что разрабатывается для ANTLR 3. Вот только трудозатраты тут уже несопоставимы. Если для парсинга такую IDE написать могут, то для прикладной задачи — это уже будет совершенно неподемная задача. А тут все в автомате. Да и специализированную поддержку для решения на макросах тоже можно сделать. Причем это будет значительно проще нежели создавать специализированную IDE с нуля.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка: -1
Здравствуйте, Gaperton, Вы писали:

G>В выражении a = b + c + d, где переменные — матрицы, надо, чтобы все это свернулось в единственный двойной цикл с этой формулой внутри. На плюсах это делается без макросов — через темплейтное метапрограммирование, и выглядит страшно. На макросах, мне думается, реализация выглядела бы проще. Хотя — честно скажу, пока на макросах реализации не видел. Все только говорят, говорят о великих и ужасных макросах — и все .


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

Вводится поератор. Оператор = использовать нельзя так как он уже прегружен для ругих целей. Но вместо него можно ввести что угодно. Скажем тот же :=. Далее все просто как неучить уроков. Макрос принимает в качестве параметров два выражения в виде АСТ. Первое выражение — это то во что будет присвоено результирующее значение. Второе — что за выражение нужно вычислить. Далее остается только разобрать выражение и переписать его оптимальным образом. С использованием паттерн-матичинга это не составит труда.

Собственно практически тоже самое делает макрос $ в Немерле. Он берет строку вида $"Просто текст $(вычисляемое + выржение) и еще просто текст." и преобразует его в вызов вида:
string.Concat("Просто текст ", (вычисляемое + выржение).ToString(), " и еще просто текст.");

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

Собственно — это есть отличный пример встраеваемого микро-DSL-я. И как видишь уже второй который ты можешь приводить в качестве примера .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

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


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

G>валяйте, давайте сюда пример, и я покажу, как его сделать без макросов и паттернов. Мне хватит паттерн-матчинга, атомов, и первоклассных функций.


Хватит, или сможешь решать задачи компактнее, быстрее и порождая более производительный код? Если говорить о "хватит" в общем-то С для любой задачи хватит. Вот только паттерны от этого не исчезнут. Они просто будут строиться на базе ФВП и паттернматчинга.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 08:39
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>Я к тому, что в ФП функция рассматривает несколько по другому нежели в "обычных языках". Это первоклассная сущность.


VD>Сори, а на кого направлен этот балшит? Может еще разведем балшит по повоту продвинутости структурного программирования в сравнении с ассемблерами?


Ты о чём вообще? Мы говорили о конкретной задаче и как она решается.
konsoletyper сказал, что не понимает устройство Parsec, я попытался дать основное, что в нём есть.
При чём тут ассемблер и структурное программирование?

VD>Насколько я помню на свете есть очень мало языков в которых макросы достигли своего апогея. Все эти языки, как один, являются фунциональными (Лисп, Темлэйт Хаскель, Немерле). Так зачем нас грузить ФП?


И?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 08:50
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>Без проблем! Меняем названия на EBNF-ные.


VD>На EBNF есть ISO-стандарт. Вот кода вы на Хаскеле его повторить сможете (ну, процентов так на 99 хотя бы), тогда можено будет поговорить. А пока тебе прийдется признать, что решение на Хаскеле не полноценно.


А в чём проблема? Я же сказал, что вплоть до переименования там подходит практически всё. (Практически, потому что цитировать стандарт не смогу, а лезть для сверки не хочу.) Мало того, есть дополнительные расширения.
В коде konsoletyper я заметил, что он тоже не пользуется ISO-шным стандартом. И правильно делает, нафиг делать ненужную работу. И пусть ты считаешь его решение неполноценным, по мне там всё ок.

L>>Нужны мозги, готовые писать декларативно.


VD>Хм. Решение на макросах получается короче и понятнее, но оно не декларативно? Забавные выводы.


Влад, с твоей логикой я уже знаком. Демонстрировать мне её ещё раз бесполезно.
Во первых, я не видел решения на макросах, поэтому сказать короче оно или понятнее не могу. Точно также не могу сказать декларативно оно или нет. Речь шла о том, что человек не понимает как написан Parsec, наверное он смотрел его код. Наверное, его что то смутило. Ничего сложного там нет, возможно человека всего лишь отпугнул синтаксис Хаскеля. Я попытался выяснить, что именно. Остальное додумала твоя безудержная фантазия.

VD>Ну, так не бери для сравнения Лисп. Старичку все же уже 50 лет! Возми Немерле. Он в большинстве случаев не уступает Хаскелю в выразительности сам по себе и при этом еще содержит макросы. В прочем все эти ТемлэйтХаскели и РеврайтРулезы ни что иное как маросы. Так что ты лучше обясни как решить конфликт между наличием этих фич и утверждением о том, что макросы не нужны. Это будет куда интереснее.


Я утверждал, что макросы не нужны??
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 09:00
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Тебе не кажется, что "очень близок" на практике означет "непохож"?


Нет.

VD>Понимаеш ли в чем дело?... На макросах можно получить как раз тот синтаксис что тебе требуется. И делается это проще.


Да, для создания синтаксиса макросы практически незаменимы. Я это уже говорил. И?

L>>Вместо "|" здесь "<|>", вместо +/* — many1/many, вместо '(' — char '(', "abc" — string "abc".


VD>Да, да... Вот только в лексере konsoletyper-а вместо "|" используется (ты не поверишь) "|" и т.д.


Да ты что? Ну, тогда я должен убегать — мне ещё надо переименовать <|> на |. Это ведь так сложно и займёт у меня целую неделю!

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


При чём тут монады?

L>>Поверь, для этого не надо вкуривать монады. Достаточно понять, что парсер это функция, дальше всё просто.


VD>Мне показалось он говорит о реализации.


Тебе правильно показалось.

L>>Так в том то и дело, что макросы не надо эмулировать, если язык позволяет обойтись без них.


VD>Макросы не надо эмулировать. Это правда. Они мощьнее чем вырктасы шаблонного МП в С++ и куда монад в Хаскеле. Они прямое средство переписывания кода так как надо программисту. И нихрена в этой области с ними не сравнится.


В области переписывания кода, не сравнится, да. И что? Как это относится к лексеру?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 09:41
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>Что касается встраивания в язык DSL, то на Haskell это получается замечательно.


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


Почему убогие?

L>> Просто там другой подход, и, разумеется, есть отличия от подхода с макросами.


VD>Дык о том и речь. Но МП оно и в африке МП и все претензии, что можно предявить к нему применимы как к макрам, так и к любым другим его видам. А вот результат... Он 100%-но более качественен у макр, да и понять решения на макросах, на мой взгляд, проще. В прочем, последнее утверждение конечно спорно. Но и первого хватет.


Тут не поспоришь. Непонятно одно. Почему ты всё не пишешь на макросах?

VD>Дык если что-то не умеет, начи уже менее мощьный. При этом еще и более сложный.


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

VD>Что имеем в итоге?

VD>1. Большую сложность реализации.
VD>2. Меньшие возможности.
VD>3. Меньшую скорость результирующего кода.
VD>4. Все (гипотетические, так как на мой взгляд это домыслы) недостатки МП.

1. Почему большую сложность реализации? Инструмент использовать надо для того, для чего он предназначен.
Надо тебе нагенерить тучу кода — нагенерь макросами. Если же ты знаешь как избежать дублирования без макров, то зачем их использовать?

2. Почему меньшие возможности? Ровно те, что достаточны для решения задачи.

3. Проблема производительности решается не только макросами, честное пионерское.

4. Э? Какие недостатки ты имеешь в виду?

VD>Ну, и где здесь приемущества? Отсутсвие слова "макросы"? Ахринеть (с)!


Ты не знаешь, что у макросов есть недостатки, которых нет у штатных конструкций языка?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 09:51
Оценка: +1
Здравствуйте, VladD2, Вы писали:

D>>Кстати здорово — задача оптимизации решается прямым указанием оптимизатору! Rewrite Rules rulez


VD>А в чем разница между ними и макросами? И почему тогда "макросы сакс", а "Rewrite Rules rulez", а?


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

Допустим, x $ y z => x (y z) можно сделать макросом.
А вот как сделать трансформацию map f . map g => map (f . g) макросом я не представляю.

Таким образом, с помощью рулесов можно писать обычный "красиво выглядящий" код с обычными функциями, которые трансформируется в оптимизированный.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 10:02
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>Подозреваю, ... За исключением...По идее...Не знаю, сработает ли здесь.


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


Слава макросам Немерле!

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

Будет время — проверю. Моя же мысль такая — и это можно сделать без макросов и без изворотов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 11.07.07 12:02
Оценка: +1
Здравствуйте, lomeo, Вы писали:

L>В доке от 2001 года говорится, что

L>

L>Speed. Most combinator libraries lack the speed necessary to be competetive with bottom-up parser generators. Parsec uses some novel techniques to improve its performance. The library is fast, parsing thousands of lines a second on today's machines

L>Но тысячи в секунду, это как то маловато, если честно. Даже для 2001.

Я это и сам читал в свое время. Конечно, утверждение про thousands of lines отбивает охоту смотреть сравнения, но мне все равно интересно.

L>Полагаю, проблема всё таки в строках Haskell-а, которые как известно, медленные. Можно попробовать подключить binary string и померить.


PackedString что-ли? Это возможно? К ним же стандартные списковые функции применять нельзя. (Ну почему в Haskell нет класса типов List?!) И придется слишком многое переписывать, нет? Это более чем сомнительное удовольствие.
К тому же лично мне не понятно, почему Parsec так написан? Вообще-то производительность лексера и парсера имеет значение. Это же вроде бы не просто proof-of-concept, он позиционируется как построитель парсеров пригодный для реального использования. Кроме того, он еще и объявлен быстрым. Слово "fast" — даже в заголовок описания вынесено. Это шутка?
... << RSDN@Home 1.2.0 alpha rev. 677>>
'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[17]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 11.07.07 12:02
Оценка: +1
Здравствуйте, Курилка, Вы писали:

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


FR>>Разве обошлись, вроде в тех же запросах используются именно ленивое вычисление параметров.

К>Аргументируй, не вижу там ничего ленивого, или наличие ф-ции, которая вызывает/выполняет DSL и есть такая ленивость?

Просто без ленивости (или макросов) такие DSL не сделать. Помните упражнение из SICP про самописный if и вечный цикл?
Вот и в Scala используется ленивость, а точнее non strict. Об этом и здесь
Автор: Vermicious Knid
Дата: 24.08.06
и здесь
Автор: eao197
Дата: 24.11.06
писали.

К>Т.е. теоретически, конечно, это есть некая ленивость,


Практически. Но не ленивость, а non strict семантика. Результат после первого вычисления не кэшируется, насколько я помню.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'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[18]: Являются ли макросы свидетельством недостаточной выр
От: jazzer Россия Skype: enerjazzer
Дата: 11.07.07 16:28
Оценка: :)
Здравствуйте, Klapaucius, Вы писали:

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


L>>Нет. PackedString прошлый век

L>>Сейчас есть BinaryString.

K>Это что-то ужасно секретное, да? Поиск в Google и на haskell.org ничего не дал.


Значит, Google и иже с ним — тоже прошлый век
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: jazzer Россия Skype: enerjazzer
Дата: 11.07.07 16:59
Оценка: :)
Здравствуйте, IT, Вы писали:

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


J>>Ты, Влад, возможно, не поверишь, но японцы суп именно так и едят, причем вместо вилки — палочки


IT>Ты уверен насчёт супа? Что-то я ни разу не видел в японском ресторане что бы кто-то ел миса-суп палочками. Для этого выдаётся специально обученный прибор.


Мой профайл будет тебе ответом

В России вообще много чего странного можно встретить в "японских" ресторанах.
Например, из бросающегося в глаза — там перед едой приносят полотенца и тут же, как только вытер руки, их забирают обратно. Видимо, дефицит у них полотенец
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 00:23
Оценка: :)
Здравствуйте, FR, Вы писали:

VD>>>>Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.


ANS>>>Белая гарячка


VD>>у вас, маньяков? Несомненно. Вы же даже возразить аргументированно не умеете.


FR>Влад ты на самом деле бредишь, возражать на это бессмысленно.


Отличное подтверждение моих слов.

Лучше бы попробовал привести код генерирующий тело метода.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: jazzer Россия Skype: enerjazzer
Дата: 27.07.07 02:33
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


J>>Ты, Влад, возможно, не поверишь, но японцы суп именно так и едят, причем вместо вилки — палочки


VD>Дык они еще сепуку делают. Очень полезное занятие для всех кто не может есть ложкой.


Не вижу связи. Ты, вроде, говоришь об удобстве и эффективности? Так вот суп очень удобно есть палочками, проверено на собственном ежедневном опыте (например, сразу изчезает проблема, когда на дне тарелки остается кусочек чего-нибудь, и ты минут пять гоняешь его ложкой/вилкой по тарелке, пытаясь поддеть и отправить в рот). Макароны, кстати, тоже.

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

С европейскими приборами решений проблемы последнего куска три:
1. Использовать ручное управление: следить за тем, чтобы у тебя не оставалось кусков на дне тарелки (т.е. есть их пока достаточно жидкости).
2. Использовать костыль в виде куска хлеба. Тут мы тоже имеем вариант проблемы с первым решением — надо следить, чтоб осталось достаточно хлеба.
3. Использовать костыль в виде пальца/ножа/вилки/второй ложки.

Ну и радикальные: есть только супы-пюре; забить на этот последний кусок; нанять специально обученного человека, который будет следить, чтоб не кончалась жидкость/хлеб, а при необходимости — цапал этот кусок руками...
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 08:54
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>Неинтересно.


VD>И я знаю почему...


Да, да. Я помню, ты же у нас телепат.

Если серьёзно, то я не понимаю — зачем это тебе. Вроде взрослый человек, а занимается ерундой.
Ну, потратишь ты моё и konsoletyper'а время (или только моё, а? может тогда пусть на входе небольшой хаскель проект будет, чтобы вам тоже не скучать . Узнаешь, что bytestring-парсек на 14.73% медленнее или наоборот быстрее, и что?!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 08:54
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>Ты о чём вообще? Мы говорили о конкретной задаче и как она решается.

L>>konsoletyper сказал, что не понимает устройство Parsec, я попытался дать основное, что в нём есть.
L>>При чём тут ассемблер и структурное программирование?

VD>При том, что сегодня ФВП полноцено не поддерживаются разве что в С++. И эти тирады несколько смешны.


Ты с кем разговариваешь? Какое ФВП и С++?

VD>>>Насколько я помню на свете есть очень мало языков в которых макросы достигли своего апогея. Все эти языки, как один, являются фунциональными (Лисп, Темлэйт Хаскель, Немерле). Так зачем нас грузить ФП?


L>>И?


VD>И не надо нам сотый раз про это. Лучше бы дал прямой ответ на вопрос товарища. Мне вот тоже не ясно где там простота.


В сотый раз про что? Кому "вам"? Я отвечал на вопрос konsoletyper'а. Может быть ответил не то, что он спрашивал, но это судить ему. А ты на что отвечаешь? Причём тут макросы в апогее?
Мы говорим о парсеке. Мы даже уже не говорим, почему это вдруг он не написан на таких замечательных макросах — с этого начинался разговор, но он давно уже оттуда ушёл.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 08:54
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>Макросы генерят код по поименованному определению макроса. Это имя используется в коде для вызова макроса компилером.


VD>Это ты домысливашь. Реально же макросы довольно гибкий инструмент и могут делать все что им угодно с кодом проекта (при этом в самом коде не присуствуя).


В чём именно я не прав? Что именно я домысливаю? Можешь выражаться яснее, а не отделываться общими фразами про то, что макросы это гибкий инструмент?

Насчёт "(при этом в самом коде не присуствуя)" — как? На уровне сборки? Там можно сразу находить нужные куски причём обработанные до этого другими макросами? Или придётся парсить весь код, чтобы выделить (map f (map g) xs)?

L>>Рулесы делают трансформацию без поименований с уже имеющимися функциями. Компилер находит шаблоны и меняет их.


VD>Но по сути же делается все тоже самое... Согласись...


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

Аналогия: множественное наследование и трейты, ссылки на функции и ФВП и т.д. Первое более мощное, чем второе, да. Почему тогда многие считают МН не очень удачным решением?

VD>Мы меняем код неочевидным для прикладного программиста образом. Все зло макросов, как я понимаю, приписывается именно этому свойству.


При отключенных рулесах код будет работать. При отключённых макросах — нет. В общем случае, разумеется.
Применение рулесов — это задание эквивалентных, но более эффективных выражений.

VD>Как-то странно, что изменение названия и способа запуска сразу превращет зло во благо. А?


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

L>>Допустим, x $ y z => x (y z) можно сделать макросом.

L>>А вот как сделать трансформацию map f . map g => map (f . g) макросом я не представляю.

VD>Если есть код перебора выражений (а он есть), то достаточно найти нужный паттерн и заменить его другим.


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

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


VD>Неубедительно.


В чём именно сомнения? Конкретнее претензии плиз.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 27.07.07 13:11
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>Задача

x := alpha * p + omega * s;

, изложенная Klapaucius вот здесь
Автор: Klapaucius
Дата: 09.07.07
может быть решена, например, так:


E>
<...>
E>class delayed_sum_of_scalar_to_vector_multiply_t
E>    {
E>    public :
E>        delayed_sum_of_scalar_to_vector_multiply_t(
E>            const delayed_scalar_by_vector_multiply_t & a,
E>            const delayed_scalar_by_vector_multiply_t & b )
E>            :    a_( a )
E>            ,    b_( b )
E>            {}

E>        void calc_and_store_to( vector_t & receiver ) const
E>            {
E>                if( a_.vector().size() != b_.vector().size() )
E>                    throw std::invalid_argument( "vectors must have the same size" );

E>                receiver.clear();
E>                receiver.reserve( a_.vector().size() );

E>                for( unsigned int i = 0, i_max = a_.vector().size();
E>                        i != i_max;
E>                        ++i )
E>                    receiver.push_back(
E>                            a_.vector()[ i ] * a_.scalar() +
E>                            b_.vector()[ i ] * b_.scalar() );
E>            }

E>    private :
E>        delayed_scalar_by_vector_multiply_t a_;
E>        delayed_scalar_by_vector_multiply_t b_;
E>    };
<...>
E>


Это решение моей задачи? Я прямо-таки недоумеваю, дорогая редакция!

Правильно ли я понял, что предлагается писать вручную реализации для всех возможных выражений?
Это шутка? Если это шутка, то ее можно было бы выразить и короче:
Зачем макросы, если есть прилежание и усидчивость?

E>Это демонстрация принципиальной схемы реализации отложенных вычислений в C++, полученная за 15 минут. Более сложные схемы могут быть получены при приложении несколько больших усилий.


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

E>Только Nolite mittere margaeritas ante porcas!


Да уж, про метание бисера перед свиньями, это к месту, после такого выступления. Боюсь, что у меня и в самом деле недостаточно широкие взгляды, для того чтобы оценить такое решение моей задачи по достоинству. Или, может быть, я вовсе не свинья, может быть это бисер у Вас какой-то сомнительный, а?
... << RSDN@Home 1.2.0 alpha rev. 677>>
'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[19]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 17:02
Оценка: :)
Здравствуйте, lomeo, Вы писали:

VD>>Мне совершенно все равно как там работает bytestring. Но мне очень интересно сравнить Хаскель с его подходом к ДСЛ-естроению с Немерле на реальной (боевой, можнос сказать) задаче. А вот наши беседы мне становятся менее и менее интересны, и не потому, что я тебя не уважаю или стопроцентно уверен в своем мнении, а потому, что не несут рационального зерна. Это не более чем наши мнения.


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


Как минимум ты (мы, точнее) сможешь в своих утверждениях ссылаться на четкие эксперементальные данные. Это уже немало. Что до времени, то на пустую болтавню мы тут его больше убили. А так глядишь еще статейку забацали бы совместными усилиями — "Сравнительный анализ разных подходов к ДСЛ-естроению" — звучить, однако!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: Gaperton http://gaperton.livejournal.com
Дата: 30.07.07 16:07
Оценка: +1
Здравствуйте, A.Lokotkov, Вы писали:

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


G>>Мой тезис говорит о том, что макросистемы — темная сторона силы. Настоящий джедай управится и без них...


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


AL>А показано ниже описание одной из подсистем в некотором хидере, который включается много раз с разными определениями одних и тех же макро перед каждым включением. Каждый джедай занимается своей подсистемой, реализуя функции для каждой вершины ее графа состояний.

AL>Ясен пальчик(с), что писать всю эту ахинею руками не очень обязательно, -- можно сделать тул, позволяющий рисовать графы и генерить все, что нужно автоматом. А также верифицировать и т.п.

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

Или могу предложить джедаям совсем радикальный и нестандартный ход, но вот он даст вам в перспективе рывок в производительности труда. Если система работает не на пределе производительности, в качестве языка для высокоуровневого кодирования применить Форт (есть такой жутко гибкий макроязык для встраиваемых систем — по гибкости не уступает LISP, по близости к железу — ассемблеру и С). При таком подходе джедаи будут писать критичные к скорости и просто монолитные функционально законченные куски на С, а компоновать их вместе на FORTH. Живые мертвым позавидуют, реально, и производительность сильно не должна просесть.
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 01.08.07 06:01
Оценка: :)
WH>Так вот для каждого пространства нужно описать свой тип. Описание занимает строк 40-50 при том что они все шаблонные и их разлячия легко укладываются в одну строку.
WH>Писать это руками мне очень быстро надоело. Сейчас данное описание у меня генерируется.
WH>Не смотря на то что структура у некоторых из них одинаковая их необходимо различать на этапе компиляции ибо если не дай бог их перепутать то потом будешь очень долго искать почему картинки получаются с кучей малозаметных артефактов.
WH>Но это не главная засада.
WH>Проблема в том что мне в любой момент может понадобится преобразовать из одного цветового пространства в другое.
WH>И писать N^2 преобразований мне мягко говоря не хочется.
WH>Тем болие что большинство из них сводятся к преобразованию через цепочку пространств.
WH>Вот я и задал основные преобразования, назначил им веса и остальное сгенерил.

а темплейты не подойдут? язык-то хоть C++?

у меня в одной программе 48 вариантов кода генерятся именно на шаблонах. вот небольшой кусочек кодогенератора:

// tor_compress template parameterized by MatchFinder and Coder
template <class MatchFinder, class Coder>
int tor_compress4 (PackMethod m, INOUT_FUNC *read_f, INOUT_FUNC *write_f)
{
    switch (m.match_parser) {
    case GREEDY: return tor_compress <             MatchFinder,  Coder> (m, read_f, write_f);
    case LAZY:   return tor_compress <LazyMatching<MatchFinder>, Coder> (m, read_f, write_f);
    }
}

// tor_compress template parameterized by MatchFinder and Coder
template <class MatchFinder, class Coder>
int tor_compress3 (PackMethod m, INOUT_FUNC *read_f, INOUT_FUNC *write_f)
{
    switch (m.hash3log) {
    case 0:  return tor_compress4 <      MatchFinder,  Coder> (m, read_f, write_f);
    default: return tor_compress4 <Hash3<MatchFinder>, Coder> (m, read_f, write_f);
    }
}

// tor_compress template parameterized by Coder
template <class Coder>
int tor_compress2 (PackMethod m, INOUT_FUNC *read_f, INOUT_FUNC *write_f)
{
    switch (m.hash_row_width) {
    case 1:    return tor_compress3 <MatchFinder1, Coder> (m, read_f, write_f);
    case 2:    return tor_compress3 <MatchFinder2, Coder> (m, read_f, write_f);
    default:   return tor_compress3 <MatchFinderN, Coder> (m, read_f, write_f);
    }
}
Люди, я люблю вас! Будьте бдительны!!!
Re[22]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 14:29
Оценка: :)
Здравствуйте, IT, Вы писали:

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


IT>>>Хочешь я поделюсь? Последние года четыре у меня без кодогенерации не обходится ни одни проект. А ты оценишь и скажешь нужно это или нет.


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


IT>Перформанс, конечно, тоже. Как же без этого? В частности для обхода тормозов рефлекшина. Но это действительно не самое интересное.


IT>Гораздо более интересный пример можно найти здесь. Общая идея состоит в том, что для выполнения наиболее "интеллектуальной" работы достаточно описать сигнатуру метода:


IT>Есть и другие случаи применения кодогенерации, но они скорее относятся к экзотическим. Здесь я перечислил лишь то, что используется повседневно.


Ок, случай генерации связующего кода с БД — это хороший пример. Однако, хочу дать пару комментариев.

1) У тебя там применяются атрибуты. Добавление кастомных атрибутов никак не меняет синтаксис языка, и не увеличивает indirection level языковых конструкций. Применение их изолировано, и локализовано. Поэтому, моя аргументация к атрибутам не относится — кастомные атрибуты являются доброй, хорошей магией. От нее вреда практически нет. По своим свойствам, влияющим на процесс разработки и поддержки — это совсем не то же самое, что злые макросы. Это безопасная штука, и мы всеми руками голосуем за кастомные атрибуты. Впрочем, добавлять их кому попало все равно надо запретить, и любую модификацию прогонять через процесс формальных инспекций с привлечением тимлидов и ведущих спецов как инспекторов, как в той ветке в управлении проектами написано — ты ее читал. Плюс, требовать адекватной документации по атрибутам — и ее тоже инспектировать.

2) Удобный биндинг к БД — это даже более ходовая и популярная задача, чем создание парсеров. И для ее решения, так же как ex/yacc, вполне оправдано сделать внешний макропроцессор, совсем не обязательно иметь поддержку макросов в языке. Насколько я понимаю, в твоем тулките, на который ты ссылаешься, так и сделано — макросисиема там не применяется. Этой же цели, кажется, служит явский hybernate? Опять, обошлись без макросистемы. Что имеем в сухом остатке? Индустрия подверждает мой тезис о макросах, не так ли?
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 01.08.07 19:25
Оценка: +1
Здравствуйте, Mikl Kurkov, Вы писали:

G>>>Индустрия имела макросы в далеких 70-х.

MK>Ну вот лежит книга Брауна "Макропроцессоры и мобильность ПО".

И где здесь про всю индустрию?
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.08.07 08:23
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>Почему, например, расширение linq захардкоженное, прибитое гвоздями к C# и VB это хорошо, а набор макросов, делающий тоже самое — это плохо.


Потому что LINQ прописан в стандарте и его будет обязан знать каждый, претендующий на звание C# developer. И когда я уйду из одной команды и приду в другую, там будет все тот же самый LINQ.

IT>Индустрия банально не имеет макросов, поэтому извращается как может.


Спорно. Идее ситаксических макросов 200 лет в обед. Однако ж не прижились пока что.

IT> Проблемы pre-compile и run-time кодогенерации хорошо известны и, к сожалению, неразрешимы. Я, например, в своё время поимел много гемороя с pre-compile-time генерацей код. Народ по незнаю правил такой код вручную и когда это всплывало через несколько месяцев, то наступал полный паралич.


Это не проблема технических средств, это проблема организации процесса разработки. У меня в текущем проекте масса pre-build и студийных кодогенераторов, однако за последние 4 года еще ни у кого не хватило ума править автогенеренный код, хотя уровень девелоперов был очень разный, вплоть до обезьянок.

IT>У run-time кодогенерации тоже есть свои козявки. Приходится использовать абстрактные классы, которые к тому же всегда должны быть публичные. Классы, которые не генерируются, но для которых что-то генерируется тоже должны обязательно быть публичными.


Это, мягко говоря, неправда. Skip visibility check еще никто не отменял.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 02.08.07 12:31
Оценка: :)
Здравствуйте, IT, Вы писали:

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


G>>>>Индустрия имела макросы в далеких 70-х.

MK>>Ну вот лежит книга Брауна "Макропроцессоры и мобильность ПО".

IT>И где здесь про всю индустрию?


Нужно сказать, что на ЕС ЭВМ была масса операционных систем! Дос — это была простая система с фиксированным числом задач и фиксированным распределением памяти. ОС MFT была значителоьно более развита с точки зрения сервиса файловой системы, но распределение памяти тож было фиксированным. Разделы назначались при генерации (сейчас это называется инсталляцией-установкой) конкретной конфигурации системы.
Генерация — потому что ось представляла собой колоссальное количество макросов. Генерация состояла в том, что создавался пакет макровызовов с конкретными параметрами макросов. Для этого на компьютере была предустановлена минимальная система с транслятором-ассемблером (макроассемблером). Процесс генерации занимал несколько часов, потом ситему проверяли на работоспособность — та еще работа... Часто оказывалось, что параметры заданы не те или не так — не стыковались у некоторых макросов сочетания... И приходилось перегенерировать систему. Поэтому в системные программисты (а они как раз и занимались такой работой) старались брать людей, уже имевших опыт


http://rsdn.ru/Forum/Info.aspx?name=FAQ.Learningtofly.LaptevVV.part8
Автор: LaptevVV
Дата: 13.01.05
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 02.08.07 12:54
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>http://rsdn.ru/Forum/Info.aspx?name=FAQ.Learningtofly.LaptevVV.part8
Автор: LaptevVV
Дата: 13.01.05


Осталось только выяснить о каких макросах идёт речь. В C тоже есть макросы, но, я надеюсь, что мы оба понимаем, что речь не о них.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 02.08.07 13:06
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

IT>>Почему, например, расширение linq захардкоженное, прибитое гвоздями к C# и VB это хорошо, а набор макросов, делающий тоже самое — это плохо.


AVK>Потому что LINQ прописан в стандарте и его будет обязан знать каждый, претендующий на звание C# developer. И когда я уйду из одной команды и приду в другую, там будет все тот же самый LINQ.


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

IT>>Индустрия банально не имеет макросов, поэтому извращается как может.


AVK>Спорно. Идее ситаксических макросов 200 лет в обед. Однако ж не прижились пока что.


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

AVK>Это не проблема технических средств, это проблема организации процесса разработки.


Почему ты тогда считаешь, что его нельзя построить так, чтобы не было проблем с макросами?

AVK>У меня в текущем проекте масса pre-build и студийных кодогенераторов, однако за последние 4 года еще ни у кого не хватило ума править автогенеренный код, хотя уровень девелоперов был очень разный, вплоть до обезьянок.


А у моих ума хватило за полгода. Что теперь делать?

IT>>У run-time кодогенерации тоже есть свои козявки. Приходится использовать абстрактные классы, которые к тому же всегда должны быть публичные. Классы, которые не генерируются, но для которых что-то генерируется тоже должны обязательно быть публичными.


AVK>Это, мягко говоря, неправда. Skip visibility check еще никто не отменял.


Что неправда? То, что генератор, исходный класс и результирующий находятся в разных сборках? Ну так это я тебе как специалист говорю. Могу даже исходники показать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 02.08.07 14:50
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>В классе пространств, которые приводятся линейным преобразованием друг к другу (а это, как ты сказал, половина твоих преобразований),

А где я сказал что это один класс?

Лозунги не имеющие отношения к реальности поскипаны.

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

И что я с этим методом буду делать?
Это в моей системе я его просто напишу и запущу генератор.
А в твоей?

G>Необходимости в макросах я тут не вижу.

А я вижу.

G>Почему должна просесть точность и производительность — тоже не понимаю.

Долго расказывать.

G>А вот то, что применение макросов — это переусложнение — это понятно.

Это понятно только тебе. А я получил значительное сокращение и упрощение рукописного кода.
И стал он гораздо понятние ибо у меня остались одни декларации вместо кучи императива.

ЗЫ Я с картинками почти год вожусь. За это время я прошолся по тАкому колличеству очень неочивидных граблей... Причем они нигде не описаны ибо практикам не до написания статей, а теоретики забивают на крайние случаи. Короче наивные методы не работают. Вобще.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 02.08.07 19:28
Оценка: :)
G>Это как раз синтаксические макросы. Речь идет о макроассемблере ЕС ЭВМ

тогда может отгадка состоит в том, что в 80-х годах отказались от самого ассемблера?
Люди, я люблю вас! Будьте бдительны!!!
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 03.08.07 14:20
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

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


Это как?

IT>>Гапертон пока предпочитает молчать, может быть ты мне ответишь на этот вопрос? Чем принципиально отличается плоходокументированный макрос от плоходокументированного метода?


AVK>Тем же, чем отличается незнакомое русское слово в русской речи от речи, скажем, на турецком языке.


Это неверная аналогия. Турецкий — это DSL на XML. А макросы и методы это один и тот же язык.

IT>> Можно перефразировать в текущем контексте. Чем принципиально отличается необходимость разбираться в незнакомом коде, в котором используются незнакомые тебе классы от от кода, в котором используются незнакомые тебе макросы?


AVK>Тем, что возможые эффекты от метода несопоставимы с эффектами от макроса. Т.е. метод делает всегда одно и то же — получает на вход параметры, возможно меняет состояние, и возвращает результат. А вот макрос может делать за кадром что угодно, возможности у него значительно шире (собственно, для этого макросы и придумывали).


Именно. И в этом вся прелесть. Особенно учитывая, что индустрии больше некуда расширяться "шире возможности' — это как раз то, что надо.

AVK>Too big gun и этим все сказано.


Too big gun это только для Хэйлсберга. Ну и его последователей, конечно.

IT>>Интересно, почему тогда народ с таким самозабвением извращается на плюсовых шаблонах?


AVK>Спроси у них. Практически все мои лично знакомые программисты относятся к этому крайне негативно.


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

AVK>Должны же быть какие то причины отсуствия макросов в мейнстриме.


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

IT>>А у моих ума хватило за полгода. Что теперь делать?


AVK>Учить, разумеется.


В 2002-2003-м, когда это происходило ещё сами учителя учились.

AVK>ИМХО объяснить, что если в начале файла написано autogenerated, do not touch, то ни в коем случае этот файл не трогать совсем не сложно.


Это всё слова. Когда ты попадаешь отладчиком в огроменный сгенертрованный исходник, то никто в начало файла уже не смотрит.

AVK>В особо запущенных случаях можно для SVN скрипт написать, который запретит коммитить генерируемые файлы.


Я даже не помню в каком состоянии тогда был SVN, был ли он тогда вообще в каком-либо состоянии. Мы пользовались VSS и студия сама решала что запрешать, а что нет.

AVK>А я тебе как специалист говорю — в случае применения для кодогенерации LWCG достаточно в параметре skipVisibilityCheck передать true, и можно спокойно обращаться к приватным полям любых классов в любой сборке.


Да ни фига. LCG появилось только в 2.0. Я тебе как специалист говорю.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 03.08.07 19:55
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

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


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


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


а если ещё немного поднапрячь память, то матрицей описываются только линейные преобразования
Люди, я люблю вас! Будьте бдительны!!!
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.08.07 22:00
Оценка: +1
Здравствуйте, IT, Вы писали:

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


IT>Это как?


Это так. У меня нет никакого желания что то тебе доказывать. Если тебе интересно мое мнение — я могу его пояснить, если интересно поспорить — я в этом участвовать не хочу. А то вон ваши молодые орлы уже подтянулись, только и ждут.

AVK>>Тем же, чем отличается незнакомое русское слово в русской речи от речи, скажем, на турецком языке.


IT>Это неверная аналогия. Турецкий — это DSL на XML. А макросы и методы это один и тот же язык.


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

IT>Именно. И в этом вся прелесть.


Ага. И в этом, как обычно, еще и главная пакость. И кодогенерацией, и макросами я увлекался намного раньше, чем вы начали махать флагом с буквой N. Только вот на моих задачах я вдоволь наелся и побочных эффектов. И эти эффекты совсем не в том, что кто то где то автогенеренный код поправил.

IT> Особенно учитывая, что индустрии больше некуда расширяться "шире возможности'


Это ты зря. Возможностей масса. Мозгов не хватает. И в прямом и в переносном смысле.

AVK>>Too big gun и этим все сказано.


IT>Too big gun это только для Хэйлсберга. Ну и его последователей, конечно.


Ну а для последователей N, очевидно, нет. Ты что сказать то хотел?

AVK>>Спроси у них. Практически все мои лично знакомые программисты относятся к этому крайне негативно.


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


А меня оно как то слабо волнует.

AVK>>Должны же быть какие то причины отсуствия макросов в мейнстриме.


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


Паттерн-матчинг в мейнстриме присутствует, но не в шарпе. Лямбды в том же шарпе есть уже давно. Ну а прочие полезные вещи ... Gaperton не зря на PL/1 намекал. Мейнстрим на нем весьма обжегся в свое время. Возможно, сейчас дуют на воду конечно, но тем не менее.

AVK>>Учить, разумеется.


IT>В 2002-2003-м, когда это происходило ещё сами учителя учились.


Ну а теперь?

IT>Это всё слова.


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

AVK>>В особо запущенных случаях можно для SVN скрипт написать, который запретит коммитить генерируемые файлы.


IT>Я даже не помню в каком состоянии тогда был SVN, был ли он тогда вообще в каком-либо состоянии.


Скрипты, помнится, и в CVS были.

IT> Мы пользовались VSS и студия сама решала что запрешать, а что нет.


Ну а теперь?

IT>Да ни фига. LCG появилось только в 2.0. Я тебе как специалист говорю.


Ну так появилось же. Какое мне дело до того что было раньше, если здесь отнюдь не ретроспектива обсуждается?
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.08.07 08:45
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>Мнение всегда интересно. А выводы скорее нет, чем да.


Мнение это и есть выводы.

IT>Ну и что?


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

IT> В том же шарпе 99% девелоперов не знают всех возможностей языка. Например, многие понятия не имеют что такое '??'. Так что мне теперь не использовать эти возможности?


Почему не использовать? Использовать. Знать язык в рнмках единого стандарта обязан каждый разработчик. А вот требовать с него изучения языка каждый раз, когда он сталкивается с новым набором макросов имхо перебор.

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


Суживать ничего не надо. Надо чтобы рамки были и менялись эти рамки крайне редко. Тогда есть шанс массового соответствия этим рамкам.

IT> Как ты правильно сказал, учить надо. И всё. Обучить вменяемого человека 10-ти макросам — это вообще не проблема.


А 20? А 100?

IT>Интересно какими же ты макросами увлекался намного раньше?


Да были всякие разные типа Open C++. Но, как я предполагал, разговор скатывается во флейм.

AVK>>Только вот на моих задачах я вдоволь наелся и побочных эффектов. И эти эффекты совсем не в том, что кто то где то автогенеренный код поправил.


IT>А в чём?


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

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


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

IT>>>Too big gun это только для Хэйлсберга. Ну и его последователей, конечно.


AVK>>Ну а для последователей N, очевидно, нет. Ты что сказать то хотел?


IT>То, что он это может быть брякнул не сильно подумав и сразу забыл, а кое-кому потом стыдно будет признаться, что он потом эту чушь за ним так часто повторял.


Ну понеслась. IT, мне не интересно доказывать свою правоту тебе. Пускай ты будешь прав. Если хочешь, я закончу сюда писать, только не надо переходит на банальную перепалку.

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


AVK>>Паттерн-матчинг в мейнстриме присутствует, но не в шарпе.


IT>А где?


SQL например. Или XSLT.

AVK>>Лямбды в том же шарпе есть уже давно.


IT>Лямб пока нет. Есть убожество, называемое анонимными делегатами.


Во первых анонимными МЕТОДАМИ. Во-вторых это те же лямбды, вид в профиль. В-третьих, оставь подобные флеймогонные эпитеты.

IT>Думаю, ни тебе, ни Гапертону на PL/1 писать не приходилось.


Не угадал. Приходилось, хотя и в небольших объемах.

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


Я вот думаю, это Nemerle делает вас столь непримиримыми, или функциональное программирование вообще?

IT>Такое ощущение, что ты никогда не поддерживал кода


Опять скатился к флейму. Почему то каждый раз все в итоге своддится к тому, что ты начинаешь обвинять меня в непрофессионализме.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 04.08.07 16:17
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Потому что речь идёт именно о языковых средствах. Если интересно пообсуждать IDE или VM, то это тоже можно сделать, но этот топик не об этом.


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

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

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


Конечно это невозможно. Или мы о разных IDE.
Скажем, у нас есть "расшитрение" для enum типов, и их использования в выражениях и switch/case. Для case value мы бы хотели в IDE иметь автодополнение, которое предлагало бы список перечислымых значений из декларации enum.
Так вот, никаким образом этот тип автодополнения не появится автоматически из правил преобразования enum->class на уровне AST.
IDE уровня Eclipse или IntelliJ Idea понимает код, работает с ним на уровне семантики. Поэтому и является настолько удобным инструментом. А вы под IDE подразумеваете редактор+обработчик сообщений компилятора?

IT>Если я понимаю как можно сделать расширение компилятора, то как сделать расширяумую VM я без понятия. Если есть идеи, то можно обсудить.


Так я же написал — VM это рантайм плюс компилятор.
Собственно говоря, после того как исходный код разобран (parsed & resolved), проверен на отсутствие ошибок — дальнейшая работа компилятора полностью автоматизирована (и представляет собой трансформацию дерева/графа), и может быть спокойно перемещена из source-to-bytecode компилятора в bytecode-to-native компилятор. Конечно, это самый первый уровень расширяемости VM, но у вас уже есть повод поразмышлять, если интересно.

IT>Это неверное утверждение. Как я уже сказал, интеграция Немерле со студией автоматически подхватывает все расширения. Есть определённые технические проблемы, которые решаемы, но принципиальных проблем нет.


Расскажите мне о решении принципиальной проблемы изложенной выше. Как будет происходить пониание кода средой разработки на основании одних только правил преобразования AST, не говоря уже о расширениях вроде изменения системы типов.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 04.08.07 17:38
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

IT>>Мнение всегда интересно. А выводы скорее нет, чем да.

AVK>Мнение это и есть выводы.

Не совсем так, но спорить я не буду. Если ты считаешь, что это одно и тоже, то меня не интересует ни то, ни другое. Т.е. твой вывод, что макросы плохо, меня не интересует, а вот то почему ты так думаешь, очень даже интересно. Как мы это назовём? Аргументы? Доводы?

IT>>Ну и что?


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


Базовый уровень не изменяется. Мы не меняем компилятор, мы его расширяем.

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

IT>> В том же шарпе 99% девелоперов не знают всех возможностей языка. Например, многие понятия не имеют что такое '??'. Так что мне теперь не использовать эти возможности?


AVK>Почему не использовать? Использовать. Знать язык в рнмках единого стандарта обязан каждый разработчик. А вот требовать с него изучения языка каждый раз, когда он сталкивается с новым набором макросов имхо перебор.


Не вижу никаких проблем. Ознакомление с новой системой всегда требует определённых усилий и ознакомление с макросами не будет ничем сверхестественным по сравнению с пониманием архитектуры приложения и ознакомлением с исходными кодами. Это будет уж точно не сложнее, чем понять формат используемых в приложении XML файлов, которые точно так же вводят в приложение новые конструкции, но при этом не проверяются компилятором.

IT>> Как ты правильно сказал, учить надо. И всё. Обучить вменяемого человека 10-ти макросам — это вообще не проблема.


AVK>А 20? А 100?


Столько сколько нужно. Опять же, замечу ещё раз. За год работы на Немерле я не написал ни одного макроса. Не нужно было. Почему вы считаете, что наличие макросов в языке приведёт к тотальному увлечению ими я не понимаю

IT>>Интересно какими же ты макросами увлекался намного раньше?


AVK>Да были всякие разные типа Open C++. Но, как я предполагал, разговор скатывается во флейм.


Это не флейм. Это принципиальный вопрос. Одно дело, если ты с ними поигрался да и бросил. Другое — если ты использовал Open C++ в серьёзном проекте и твои утверждения о вреде макросов основываются не на домыслах, а на реальном опыте их применения.

AVK>А в том, что слишком много логики остается за кадром исходного кода.


Так это как раз и есть наша главная цель. Убрать частоповторяющуюся логику подальше, а в прикладном коде оставить максимум декларации. Почему тебя не пугает, например, что за вызовом метода Rsdn.Janus.Synchronizer.SyncForums остаётся много логики за кадром?

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


Это не проблема. Написание макросов на порядок проще, чем генерация кода с помощью эмита. Тем не менее это ни меня, ни многих других не останавливает. Я точно знаю что я делаю и знаю какие бенефиты в результате получу.

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


Я с этим не согласен. Тебя сильно интересует реализация паттернов foreach, override, yield return, this? Думаю не очень. Может быть ты лично и разобрался один раз как они работают. Но не думаю, что ты это делаешь каждый раз при их применении. А твоим обезъянкам так вообще по барабану.

AVK>>>Паттерн-матчинг в мейнстриме присутствует, но не в шарпе.

IT>>А где?
AVK>SQL например. Или XSLT.

А... ну да. Нам как раз здесь не хватает именно такого замеса.

IT>>Лямб пока нет. Есть убожество, называемое анонимными делегатами.

AVK>Во первых анонимными МЕТОДАМИ.

Начинается терминологический булшит? Анонимные МЕТОДЫ вводятся в коде ключевым словом delegate. Извините, если я неправильно выразился. Впрочем, я не одинок.

AVK>Во-вторых это те же лямбды, вид в профиль.


Если уж мы начали упираться в терминологию, то хочу обратить твоё внимание на тот факт, что термин Lambda Expressions вводится только в C# 3.0.

AVK>В-третьих, оставь подобные флеймогонные эпитеты.


Но ведь это же абсолютная правда

IT>>Думаю, ни тебе, ни Гапертону на PL/1 писать не приходилось.

AVK>Не угадал. Приходилось, хотя и в небольших объемах.

И как ощущение от пережитого? Что тебя большего всего угнетало: обилие фич или дремучесть вообще?

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

AVK>Я вот думаю, это Nemerle делает вас столь непримиримыми, или функциональное программирование вообще?

Это кто из нас здесь непримиримые? Я пишу и на C# и на Немерле и знаю их возможности не по наслышке. И я уж точно не буду говорить too big gun или что-то подобное о вещах, в которых не разбираюсь досконально.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.08.07 21:59
Оценка: +1
Здравствуйте, IT, Вы писали:

AVK>>Я крайне отрицательно отношусь к макросам, которые меняют синтаксис, и очень настороженно к макросам, которые пользуются синтаксисом существующим.


IT>Т.е. негативно к макросам вообще.


Я сказал то что сказал, не надо меня перефразировать.

AVK>>IT, еще раз — мне не интересно спорить. Поэтому мне все равно, что считаешь ты. Я высказываю свою точку зрения, ничего сверх того.

AVK>>Я считаю иначе.

IT>AVK, мне все равно, что считаешь ты.


А мне все равно что считаешь ты, я тебе это с самого начала пытался сказать. Но ты все рвешься в бой.

AVK>>Потому что я вижу, что происходит с шаблонами на С++.


IT>В самих по себе шаблонах C++ нет ничего плохого. Проблема в том, что для метапрограммирования в C++ используются побочные эффекты компилятора. Как следствие, маловразумительный, запутанный код.


А мне кажется, что сама идея кодогенерации тоже играет немаловажную роль.

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


Ты мне это для чего говоришь? Мне все равно чего там в Nemerle, абсолютно.

IT>Заметь. Я старательно убираю из дискуссии все места, где ты обвиняешь меня во флейме. Причём до сих пор делал это молча, надеясь на конструктив. Но со временем это начинает надоедать, особенно когда ты продолжаешь это делать и по странному стечению обстоятельств как раз в тех местах, где тебе либо нехочется отвечать, либо нечего сказать. Это неконструктивно.


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

IT>В общем, всё ясно.


Мне тоже. Увы, мои предсказания сбылись на 100%, несмотря на массу усилий избежать этого.

IT>О любой цене никто не говорит. Я тебе ещё раз могу повторить. За год я не написал ни одного макроса. Ещё раз повторить?


А зачем ты мне это повторяешь?

AVK>>Потому что эта логика жестко ограничивается контрактом, причем контрактом явным. Могут быть, конечно, побочные эффекты. Но в случае макросов и с контрактом неясно, и с побочными эффектами может быть все очень непросто.


IT>Что именно может быть не просто? Только, пожалуйста, без общих фраз типа базовый уровень и грамматика языка. Лучше всего конкретный пример.


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

IT>Т.е. получается что ты вообще против кодогенерации. Я правильно понимаю?


Против кодогенерации как базовой возможности языка.

IT>Я даже не знаю что сказать. Аргумент, конечно, железный, на и настолько же бестолковый.


Аргумента нет.

IT>Зачем мешать всё в одну кучу? Только для того, чтобы... блин, без мата не могу даже фразу построить... о... чтобы додолбаться до слов оппонента?


Оппонент может быть только в споре. Я с тобой принципиально спорить не хочу.

IT>Ну тогда и я тебя поправлю. В спецификации языка это называется анонимными функциями.


У тебя какая то странная спецификация.
C# Version 2.0 Specification, July 2005, page 6

19.2 Anonymous methods


IT>Короче, всё ясно.


Мне тоже.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 05.08.07 05:02
Оценка: -1
Здравствуйте, IT, Вы писали:


IT>О любой цене никто не говорит. Я тебе ещё раз могу повторить. За год я не написал ни одного макроса. Ещё раз повторить?


Подтверждаешь основную мысль оппонентов, что для хорошего достаточно гибкого языка макросы особо и не нужны.
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.08.07 07:41
Оценка: +1
Здравствуйте, IT, Вы писали:

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


Будет новый набор решений, но вот обязательны ли для них макросы?
Имхо, нужно ограничить их реализумость/применимость/видимость. Т.е. сделать что-то аля "только программист с чёрным поясом по N может писать макросы и он должен учитывать по возможности последствия их применения".
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 09:26
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>Т.е. получается, что изменение грамматики плохо, потому что мы меняем базовый уровень. А базовый уровень плохо, потому что мы меняем грамматику языка. Понял.


Я правильно понимаю, что для того, чтобы понять что делает макрос нужно довольно подробно представлять как устроено AST,
какие есть фазы компиляции, как AST может трансформироваться на каждой из них?
Т.е. при применении макроса с моим кодом может произойти практически любая трансформация?
Если так, то именно это людей и настораживает.
Потому как я применяя yield return точно знаю, что сделает компилятор и как это всё локализовано.
now playing: Extrawelt — Zu Fuss
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 14:19
Оценка: :)
Здравствуйте, Gaperton, Вы писали:

G>

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


Это пять. Все равно как если бы Испания сегодня попыталась привлечь астронома Фрэнка Дрэйка к отвественности за Номбре де Диос. "Верни наше серебро, подлый пират!"
... << 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[27]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 14:32
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

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


Вы определитесь. А то ведь Nemerle и Haskell тоже к индустрии отношения не имеет.

K>70-е годы это раннее детство Scheme, с ее гигиеническими макросами, ну а Scheme никогда в индустрии широко не использовалась.


А Dylan куда забыли? IMHO, по идеологии очень мало от него Nemerle ушло.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 05.08.07 17:44
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>Зависит от сложности макроса. Наример, для написания такого макроса много знать не надо:

IT>
IT>macro repeatmacro (times, body)
IT>syntax ("repeat", "(", times, ")", body)
IT>{
IT>  <[ for (mutable t = $times; t > 0; --t) $body ]>
IT>}
IT>

Так ведь такой макрос почти бесполезен. А сложные макросы уровня реализации LINQ'а писать будет нааамного сложнее.
Sapienti sat!
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.08.07 18:52
Оценка: -1
Здравствуйте, Klapaucius, Вы писали:

K>См. выделенное. Я говорил не про pattern-matching вообще — а про pattern-matching, как средство декомпозиции AST в макросистеме.


К LISP паттерн-матчинг в 70 году был, манипуляция AST в нем тоже была.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: Константин Л. Франция  
Дата: 06.08.07 07:23
Оценка: -1
Здравствуйте, IT, Вы писали:

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


EC>>Я правильно понимаю, что для того, чтобы понять что делает макрос нужно довольно подробно представлять как устроено AST,


IT>Зависит от сложности макроса. Наример, для написания такого макроса много знать не надо:


IT>
IT>macro repeatmacro (times, body)
IT>syntax ("repeat", "(", times, ")", body)
IT>{
IT>  <[ for (mutable t = $times; t > 0; --t) $body ]>
IT>}
IT>


и ради этого есть макросы? Это для меня откровение!

EC>>какие есть фазы компиляции, как AST может трансформироваться на каждой из них?


IT>Для написания более сложных вещей желательно иметь полное представление.


Для изучения которого нужно потратить полгода.

EC>>Т.е. при применении макроса с моим кодом может произойти практически любая трансформация?


IT>Практически любая.


EC>>Если так, то именно это людей и настораживает.


IT>Пока я услышал только две версии, которые настораживают людей:


IT>- обезъянкам будет трудно;


само собой, ведь другие обезьянки такого нахреначат...

IT>- неадекватные девелоперы накосячат.


и обезьянки уволятся

EC>>Потому как я применяя yield return точно знаю, что сделает компилятор и как это всё локализовано.


IT>Тогда как ты можешь использовать библиотечные классы и их методы, если ты не знаешь точно, что они делают?


IT>Вообще, есть одна простая мысль, которую я уже неоднократно высказывал.


IT>Сложность/качество/функциональность/добавить-по-вкусу программного обеспечения не может превышать более чем на порядок сложности/качества/функциональности/дабавить-по-вкусу инструмента, на котором оно разработано.


гениально, сэр.

[]
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 06.08.07 08:56
Оценка: -1
Здравствуйте, Klapaucius, Вы писали:

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


BZ>>бейсик.


K>Basic — статически типизированный язык.


Лисп, смалталк, питон и руби тоже.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 06.08.07 10:34
Оценка: +1
Здравствуйте, mkizub, Вы писали:

EC>>Можете привести какие-то из задач, которые вы решаете где макросы самое оно?

M>Чем сложнее программа, тем проще привести пример.

M>Я написал систему трансформации AST, которая мне генерирует все необходимые дополнительные классы и методы.


Если нужна кодогенерация, то лучше макросов ничего нет. Однако в этом смысле исходный вопрос этого топика можно перефразировать как "Является ли кодогенерация свидетельством недостаточной выразительности языка, в который мы генерим". К сожалению, я не знаю подробностей задачи — что именно ты генеришь, чем отличаются эти сущности и т.д. Сам скажи — если бы таргет язык был более мощным (если да — то что именно для этого надо) — можно было бы обойтись без макросов?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 06.08.07 13:08
Оценка: :)
Здравствуйте, lomeo, Вы писали:

M>>Я написал систему трансформации AST, которая мне генерирует все необходимые дополнительные классы и методы.


L>Если нужна кодогенерация, то лучше макросов ничего нет.


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

L>Однако в этом смысле исходный вопрос этого топика можно перефразировать как "Является ли кодогенерация свидетельством недостаточной выразительности языка, в который мы генерим". К сожалению, я не знаю подробностей задачи — что именно ты генеришь, чем отличаются эти сущности и т.д. Сам скажи — если бы таргет язык был более мощным (если да — то что именно для этого надо) — можно было бы обойтись без макросов?


Нет, нельзя, ибо генерируемый код и правила генерации являются чисто project-specific.
Если же под "более мощным" понимать язык, в который пихают всякий специфический мусор — то PL/1 покажется стройным и простым
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 13:29
Оценка: -1
Здравствуйте, Klapaucius, Вы писали:

G>>

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


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


Это десять. Я привел эту цитату в подтверждение того, что макросы применялись в мэйнстриме в 70-х. У вас по существу вопроса есть что сказать? Фрэнк Дрейк и его серебро мне малоинтересно.
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 06.08.07 13:43
Оценка: -1
Здравствуйте, Klapaucius, Вы писали:

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


K>>>Basic — статически типизированный язык.

FR>>Лисп, смалталк, питон и руби тоже.

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


Молодец чувствуется нордический характер
Если это так то и мой список состоит из статически типизированных языков.
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 13:58
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

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


Что не так? Я без проблем отлаживаю даже сам компилятор.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 06.08.07 14:36
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

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


Многие диалекты не поддерживали постфиксы ! и % (и, кажется, там ещё что-то было) потому, что в них не было соотв. типов. Например, в спектрумовском бэйсике было всего два базовых типа — single и string. Не было даже целочисленных переменных.

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


Таким же макаром я могу доказать, что и Хаскель — динамически типизированный. А всего-то и нужно, что написать интерпретатор, который не проверяет типы заранее, а добавляет метки типов ко всем объектам. Ах да, забыл, это даст нехороший побочный эффект! Все функции станут обладать свойством "type polymorphism"! Ну ничего, можно и этот недостаток залатать, если подумать как.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 06.08.07 14:48
Оценка: +1
Здравствуйте, mkizub, Вы писали:

M>Макрос — это "декларативное" описание изменений, а ещё AST можно трансформировать императивно, напрямую создавая и меняя узлы.


Вовсе необязательно. Макрос -- это то же код, какая разница декларативный он или императивный. Или я не о том?

M>Вот тут немного об этом написал

M>http://www.rsdn.ru/Forum/message/2611455.aspx
Автор: lomeo
Дата: 06.08.07


Э-э-э не понял. Это же мой пост
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: deniok Россия  
Дата: 06.08.07 15:03
Оценка: +1
Здравствуйте, lomeo, Вы писали:

Осталось дать ссылку не главный пункт сдачи металлолома и на исходную (вроде бы) статью по этой тематике. В ней за давностью лет (2003 год) вместо стандартного класса типов Data из модуля Data.Generics.Basics используется класс типов Term.
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 16:28
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

G>>Это не "эрудиция", это плохая память, коллега . Все-таки, в 31 год тяжело вспомнить детали угребищного языка, на котором писал много, но в школе. Я с тех пор настолько много чему научился, что мне не стыдно забыть $ перед строковой переменной, а смешно .


K>Завидую. А мне вот становиться невыносимо стыдно всякий раз, как я что-нибудь забываю.


А мне нет, особенно если это бейсик 80-х годов. Надо будет — вспомню, я в себя верю. Но надеюсь, ЭТОГО мне вспоминать не понадобится.

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


K>А с чего Вы взяли, что Basic — интерпретируемый язык? Интерпретируемый язык или нет — зависит от его дизайна. Язык, который проектировали как статически типизированный можно компилировать и интерпретировать — но при интерпретации пользоваться бенефитами динамической типизации практически нельзя — дизайном не предусмотрена-с. Язык, который проектируется как язык с динамической типизацией — можно интерпретировать со всеми бенефитами динамики, но компилировать практически невозможно. Опять-таки дизайн.

K>Basic — язык, который относится к первым, а не ко вторым. Так что правильнее сказать Все бейсики, как компилируемые языки, проверяли типы при компиляции, за исключением скриптов-диалектов. От того, что есть интерпретатор Haskell и OCaml, они ведь динамическими не становяться?

Бейсик — с момента своего появления был интерпритируемым языком, и оставался таковым очень долго. Также, не было его единого стандарта — это не единый язык, а куча диалектов. Его сильно расширенные диалекты, далеко ушедшие от "бейсиков", проверявшие типы статически, появвлись только в конце 80-х начале 90-х. Турбо Бейсик, по моему, один из первых.

K>Речь шла об индустриальных динамических языках. Я вспомнил Smalltalk и незаслуженно забыл про Erlang. Но уж бейсик то точно из другой оперы. Все индустриальные GP бейсики — компиляторы.


Да ладно, предлагаю замять для ясности.
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 19:19
Оценка: :)
Здравствуйте, Константин Л., Вы писали:

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


КЛ>Только тут мы с тобой по разные стороны


По разные стороны чего? А... понял. Ты считаешь, что Хейлсберг вполне заслуженно считает нас с тобой обезъянками. Так?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 07.08.07 13:32
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

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


G>>Гут. Ты все почти разрюхал.

WH>Да ничего вы не разрюхали.
Плохо объясняешь? Если ты словами задачу и проблему объяснить понятным образом не можешь, то каково то по твоему коду будет разбирать, интересно? С мега-макросами и всем прочим.

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

WH>У меня есть несколько кластеров с линейными преобразованиями внутри кластера.
Почему их несколько, а не один? Сколько у тебя таких кластеров — в штуках, и сколько всего пространств, тоже в штуках?

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

WH>По другому НЕЛЬЗЯ.
Не может такого быть, чтобы по другому было нельзя.
G>>Вторая половина приводится к гражданским пространствам типа RGB нелинейно,
WH>К сведеню: RGB бывают разные.
Да? И чем эти разные RGB отличаются, интересно? Ну не разрядностью же, ты ведь наверняка в плавающей запятой из преобразуешь, как разумный человек. Тогда чем? Нелинейной шкалой яркости? При применении плавающей запятой это никак не повлияет на точность, все эти гамма-коррекции и прочие нелиейные шкали яркости правильно вынести за рамки пространств, сделав преобразованиями.

WH>И очень важно использовать именно тот RGB который нужен.

Приведи пример двух разных RGB, если тебя не затруднит.
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 14:09
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

AVK>>Еще один. Анонимные МЕТОДЫ. И анонимные методы это совсем не то же самое, что анонимные классы.

C>Это философский вопрос. Делаешь интерфейс с одним методом "public <T> T execute(Object ...params)" и все.
Type safety тебя не заботит?
now playing: Kim — Wet n Wild (Midnight Juggernaughts Mix)
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 15:51
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>>>>>На фоне генерации грида и работы с бд — выигрыш будет очень незначительным.

IT>>>>Точно? Проверял или сам догадался?
GZ>>>Нет. Догадался.
IT>>Я так и знал.
GZ>
GZ>Факты в виде цифр есть?

Вообще-то, это мой вопрос.

IT>>В общем, я твою точку зрения понял. Я её не разделяю.

GZ>А по моему, нет. Я против такого термина как pass-through как плюса подхода LINQ2SQL.

pass-through как термин существует вне зависимости от линка. Это объективная реальность, присутствующая в большинтсве правильно спроектированных проектах, в которых логика диктуется UI.

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


Макросы как альтернативу линку я привёл лишь в качестве примера. Мысль состоит в том, что на макросах можно было бы сделать такой же линк и даже лучше, но ещё вчера.

IT>>ООП не может быть преимуществом сам по себе. Это тоже самое что сказать, что преимущество гвоздя в том, что он забивается молотком.

GZ>ООП — это преимущество перед гипотетическими макросами. Его подводные камни — известны. И как писать сопровождаемый код вполне известно.

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

GZ>>>LINQ2SQL — можно считать заменителем или хелпером для DAL.

IT>>Ты вообще в курсе для чего нужен DAL?
GZ>Получение(изменение) данных, и трансформация из модели источника к логической модели и наоборот.

Ответ неверный. DAL нужен для изоляции кода, работающего с БД от остальных частей приложения. Ключевое слово здесь изоляция. Проблема в том, что фактически мы пишем код на двух языках, при этом один из них, SQL, вообще никак не контролируется компилятором. DAL изолирует этот код и не позволяет ему расползаться по всему приложению.

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

Что делает линк. Линк позволяет работать с БД в терминах основного языка, компилятор которого теперь может на 100% контролировать правильность кода работы с БД ещё в компайлтайм. Это происходит потому, что линк не оперирует строками, а исключительно строготипизированными метаданными. Кстати, на макросах можно было бы пойти ещё дальше — автоматически синхронизировать эти метаданные с БД во время компайл-тайм.

Так вот, теперь подумай, если проблема, которую раньше решал DAL исчезла, то зачем нужен сам DAL?

IT>>
IT>>class UI
IT>>{
IT>>  void OnLoad()
IT>>  {
IT>>    binder.List = from c in Customer select c;
IT>>  }
IT>>}
IT>>

GZ>Пример достойный example или простейшего проекта.

О! Видишь что с людями делает декларативщина? Тебе этот код кажется примитивным? Правильно. А почему? Да потому что в нём нет ничего лишнего. Ни одного лишнего элемента. Учитывая, что в обычном коде мусора как правило больше половины, то смотря на такой код хочется зажмурится, как когда смотришь на яркий свет. Что-то тут не так, где-то нас обманывают. Только с декларативностью можно добиться такого примитивизма.

IT>>Можно для лучшей наглядности замешать сюда ещё и ad-hoc запрос.

GZ>Можешь показать как?

Я уже показывал выше. Впрочем, вот копипейст:

grid.Source = from c in customers   
              join o in orders on c equals o.Customer into oo   
              select new { c.CompanyName, OrderCount = oo.Count()

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

IT>>Теперь сформулируем вопрос по-другому. Что тебе реально даст оставление двух таких pass-through методов в данном случае, учитывая что вся логика здесь диктуется UI?

GZ>Логика по любому диктуется UI. Если пользователь не чуствует работу той, или иной функции — то эта функция не нужна.

И как тебе в этом случае поможет наличие pass-through методов?

GZ>OK. Кое что, ты уже описал. Нужно вставлять кэширование, секьюрити, логгирование и e.t.c. И желательно, чтобы вызовы были в одном слое,


Зачем? Какую проблему мы решаем располагая все вызовы в одном слое?

GZ>а посему — даже во избежание бардака стоит делать pass-thought когда оных функциональностей нет. Одни и те-же вызовы могут использоваться в различных прецедентах, в том числе которые могут быть написаны после оной итерации.


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

GZ>В ситуации бардака, стоимость внесения изменений увеличивается.


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

GZ>Ежели оные объекты еще публикуются через API (то есть должны быть отчуждаемы), то все совсем плохо. Но что совсем плохо — проект без выделенного слоя становится не тестируемым.


Что именно ты собираешься тестировать? Соответствие имён полей структур и полей таблиц в БД? Так это за тебя уже сделал компилятор.

GZ>А посему — LINQ2SQL может быть заменой(хедпером) DAL, но не более того. В остальном он сопровождаемых решений не дает.


Это заблуждение. Точнее, нежелание отказываться от старых привычек.
Если нам не помогут, то мы тоже никого не пощадим.
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.08.07 16:04
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>У меня вот тоже в кластере железо пару раз подглючивало (RAID-карты оказались кривыми). И ничего, все работало — клинеты даже ничего не замечали, все прозрачно делало failover.


Так мы тоже можем failover сделать. Оплатишь?
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[62]: Являются ли макросы свидетельством недостаточной выр
От: . Великобритания  
Дата: 07.08.07 18:54
Оценка: :)
EvilChild wrote:

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

> локальным конекстом. Как такое
> .>делается в c#?
> Методы можно. Мне кажется этого достаточно, если знаешь когда нет, то
> приведи пример.
Разница есть на уровне детализации. Интерфейс может содержать несколько методов, их удобнее переопределять пачкой,
скажем событие FocusObserver имеет два метода — onFocus/onBlur. Ну и класс может содержать собственное состояние.
Скажем:
...
FocusObserver fo = new FocusObserver()
{
    int howMuch = 0;
    onFocus(){++howMuch;}
    onBlur(){killUser();}
};
control.setObserver(fo);
control.kick();
if(fo.howMuch...)
...
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: awson  
Дата: 07.08.07 19:02
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Это понятно, но это уже не декларативно Не проще было бы обойтись вообще без ифоф? Если у меня пять таких полей, то нужно будет наприсать 10 строчек такого кода. А можно просто перечислить все пять полей в одной. Опять же повторю. Такой паттерн имеет смысл унифицировать, если он действительно часто повторяется. Ради одного-двух раз париться не стоит.


Я линком никогда не пользовался, но знаю, что он вырос из embedded dsls типа haskelldb. Еще я вижу код Sinclair. Из всего этого я заключаю, что queries в linq являются composable, т.е., попросту говоря, first-class. Таким образом, все (может быть, почти все — точно не проверял) Ваши высказывания на эту тему идут лесом. Привет.
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.08.07 03:27
Оценка: :)
Здравствуйте, IT, Вы писали:
IT>Вместо этого хотелось бы иметь что-то типа:

IT>
IT>grid.Source = from c in customers   
IT>              join o in orders on c equals o.Customer into oo   
IT>              filterby StartDate1, StartDate2, StartDate3, StartDate4, StartDate5
IT>              select new { c.CompanyName, OrderCount = oo.Count()
IT>

Ага, вот теперь я понял. Итак, у нас бывают являния Более Высокого Порядка, когда даже синтаксис Линка получается слишком многословным. Далеко глядишь
Да, здесь злые макросы всё же зарулят доброго линка. Да, таки зарулят.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Являются ли макросы свидетельством недостаточной выр
От: night beast СССР  
Дата: 08.08.07 05:21
Оценка: :)
Здравствуйте, Klapaucius, Вы писали:

NB>>Дорогой друг.


K>Ну разве где-нибудь еще можно так легко найти друзей? Нигде кроме, как на rsdn.


На улицу выходить не пробовали?

NB>>Мы очень рады что вы вообще не программист,


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


Пара индивидуумов вас устроит. Иль еще поискать?

NB>>но раз уж влезли в дискуссию, то потрудитесь изучить инструмент о котором рассуждаете.


K>Хороший совет, правда стилистически невыверенный. Начали с дорогого друга, а закончили хамством. Но совет хороший. Раз уж Вы присоединились к дискуссии, то почему бы для начала не выяснить о чем мы тут говорим, и о чем рассуждаю я? Вообще если в этой теме и обсуждается инструмент — то этот инструмент — макросы. Здесь же я рассуждаю не об инструменте, а о задаче. И критикую решение задачи, а не инструмент.


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

Еще вы вроде говорили о потере производительности.
Хотелось бы взглянуть на цифры.

NB>>Задачи на expression templates уже много лет не являются проблемой для С++ кодеров.


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


Похоже трудности только у вас

NB>>Если у вас с этим сложности, то почитайте документацию. Ссылки были озвучены.


K>Почему Вы считаете, что я ее не читал? Или нужно читать и читать пока не исчезнут все симптомы интереса к линейной алгебре?


Нет. Пока не поймете как пользоваться

NB>>Реализовывать в 1001 раз линейную алгебру для вас никто не будет.


K>Опять верю. Пока что ее никто не реализовал даже 1 раз. Линейную алгебру уже реализовывали на C++ один раз на 0,5, тысячу раз на 0,1 и 90050 раз на 0,01 — в том числе и один раз eao197 лично двумя сообщениями выше, так что вместе как раз 1001. Все это очень интересно, но, как говорил Дуглас Адамс, если миллион человек дыхнет на сырое мясо — оно не превратиться в зажареный бифштекс.


Угу. Цифры впечатляют. Сами придумали или генераторос случайных чисел воспользовались.

K>Меня интересует хотябы одна реализация на 1. Ну или, на худой конец, одна реализация на 0,9.


www.oonumerics.org
не считая кучи велосипедов настроенных под свои нужды.

K>Я понимаю, что уметь выдавать перекрашенный фонарный столб за межконтинентальную баллистическую ракету (ну или хотябы убедить, что нужен именно фонарный столб, а не ICBM) для программиста вопрос профессиональной компетентности, но не согласитесь ли Вы, что я как физик имею больше оснований для оценки библиотеки линейной алгебры чем самый пламенный любитель expression templates?


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

K>А пока что выслушаешь рекомендации на Blitz++, укажешь на какой-нибудь пустячек вроде четырехкратного оверхэда как здесь
Автор: Klapaucius
Дата: 11.07.07
, например, а собеседник сразу скучнеет и убегает рекламировать Blitz++ в другое место.


рекомендации простые.
не можешь пользоваться, не берись.
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.08.07 09:06
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>btw, вопрос к тебе как к знатоку. Где то в этом форуме, я видел утверждения, что типы генерируемые Linq-ом не доступны в других сборках. Означает ли это, что Linq-запросы можно использовать только in-place? И что, вообще, то утверждение означает ?


Ты все перепутал. Анонимные типы недоступны компилятору за пределами метода. С точки зрения рантайма (а биндинг работает только в рантайме) никаких анонимных типов нет, есть обычные классы.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[55]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 15:01
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

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


Так просто не используй макрос, написанный индусами

IT>>Но по сути это же просто обыкновенная затычка. Теперь оказывается нужно не только компилятор запускать, но ещё перед ним не забыть запустить инспектор.

C>А ты не забываешь запустить компиляцию перед запуском приложения?

Нет, это необходимый минимум, чтобы получить запускаемый код. Компилятор + инспектор не минимальный набор, следовательно всегда существует возможность использовать минимальный, чем твои индусы обязательно воспользуются.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.08.07 17:54
Оценка: +1
Здравствуйте, lomeo, Вы писали:

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


У меня универсальный механизм компайл-тайм рефлексии и средсва прмого генерирования кода. С их помощью создание частных, всокопопроизводительных случаев дело времени и техники.

Собственно мне и хочетс увидить такие же гибкие механизмы без макросов.

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


А зачем вообще сам Хаскель? Вопрос из той же серии.
У меня на твой вопрос два ответа.
1. Это нельзя объяснить тем кто работает каменным молотком. Без обид. IDE с хорошим редактором, интергрированной отладкой, навигацией по коду, автодополнению при вводе, визардами, рефакторингом и т.п. давно стали стандартами дефактов в промышленной разработке ПО. И без них самые крутые языки дают просто черепашю производительность.
2. Спрос это у тех кто делает эту интеграцию.

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


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

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

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


ОК. То есть мы ведем речь по сути о полиморфном решении проблемы и пользуемся тем фактом, что полиморфизм в Хаскеле определяется классами типами которые являются эдакими аналогами внешних интерфейсов Явы.

Сразу пояляется две вароса.
1. Это только мне кажется все слишком запутанным, а всем мало-мальски знакомым с Хаскелем все очевидно? Например, я так и не понял как этот волшебный deriving объясняет компилятору как отображать поля некой записи (или как там составные типы в Хаскеле обзывают?). Что при этом происходит со встроенными типами вроде кортежа? В общем, откровенно говоря я так и не вкурил тонкостей. Мне все это кажется магией (т.е. содержит много необъясненных моментов).
2. Что делать если в каких-то частных случаях нужно сделать частный алгоритм обхода? Ну, как с тем же зацикливаением бороться?

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


L>Не понимаю, чем лучше, если он создан в виде макроса.


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

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


Дык маросы это и есть такие средства. Точнее не сами макросы, а их реализация. Просто в случае с макросами для меня все намного очевиднее. Я просто имею API статической рефлексии (т.е. API позволяющий читать описание типов в компилируемом проекте). С его помощью я могу сгенерировать специализированный код любой сложности (от gmap, до частных случаев вроде описанного мной).

У этого подхода есть как приемущества так и недостатки. Приемущетсва: гибкость, наивысшая скорость получаемого кода, прямолянейность реализации. Недостатки... пожалуй он один, но глобальный — это компайлатайм-решение. И оно не может применяться для типов о которых неизвестно во время компиляции (например, о типах из динамически подключаемых библиотек).

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


Можно об этом по продробнее? И особенно о том как можно совместить генерируемые компилятором сущности (ну, там Typeable и т.п.) с custom-кодом который нужен прикладному программисту.

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

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


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


Ктр такрй SYB?

L>Ты погляди -- это же тупой визитор.


Может быть, может быть... Но хотелось бы глянуть на реальном тесте. Да и объяснения "природы" более подробнрые не помешали бы.

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


L>Проверяем — наш ли тип — нет, спускаемся к его полям, да — выполняем функцию.


Хм... Одно "но". Не выполняем (это уже динамическая рефлексия), а генерируем. Чувствуещь разницу? Выполнение по условию в рантайме это немного не то. И гибкость не та, и скрость фиговая.

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


Еще раз...
1. Когда производится анализ содержимого типа? В рантайме или в компайлатайме? Т.е. генерируется ли компилятором код вроде:
x = X(y.a, y.b) // в терминах явы

или происходит какая-то магия в рантайме?

2. Как можно вмешаться "руками"?

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


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


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

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


VD>>Согласен.


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


А ты не выдирай цитаты из контекста .

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


Значит такие макросы.

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


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


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

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

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


На счет просты — вопрос спорный. Я вот так и не понял мноих аспектов реализации. Хотя похоже на счет gmap я ошибся. Но что-то мне кажется, что в описанинии gmap приведенном тут содержатся "чудесные" средства. То есть нечто, что нельзя сделать если ты не создатель компиляора. Макрсоы же это четко детерминированные средства развития компилятора. Минимальный АПИ который позволяет создавать "чудесные вещи" вроде gmap. Причем, что немаловажно, позволяют любому смертному.

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


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


Лучше бы объяснил термин.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 09.08.07 11:48
Оценка: +1
Здравствуйте, mkizub, Вы писали:

M>>>Что есть ЯВУ вообще? Удобный синтаксис (отображение, восприятие кода),


CU>>субъективно


M>Безусловно. Плюс — привычка. Исследования показывают, что человек читает буквенный текст (слова) так-же, как иероглифы — как целое. Высокоуровневые конструкции языка человек тоже воспринимает целиком, а не разбивает их на кусочки — конечно, после определённой практики. Степень автоматизма доходит до того, что даже индентация/пробелы влияют на распознавания "образа" и читаемость кода, не говоря уже о различиях С и Паскаль-подобного синтаксиса, и уж тем более синтаксиса Лиспа и Форта.


Это к тому, что для перехода на лисп множеству "гуру" придётся переучиваться? Так лисп здесь ни при чём — это с любыми новшествами так. Причём (следуя из текста про математиков) — определённым новшествам обучаться "обязательно", иначе "иди с метлой".

M>Кроме субъективности есть ещё и объективные показатели. Например, история развития математики показывает, что она сделала гигантский скачёк в развитии именно за счёт изобретения буквенно-операторной записи математических формул и соотношений. Без этого — сложная математика была просто невозможна, а вершиной её достижений было решение квадратных уравнений. К объективным показателям читаемости Лиспа можно отнести и массовость "ниасиливших". Безусловно, есть те, кому синтаксис Лиспа подошёл, но на порядок больше тех, кому он не подошёл.


Статистика — ложь. Есть сведения, скольким студентам MIT, в которых пихали схему и которые до этого не знали других языков, списочный синтаксис "не подошёл" (именно _не подошёл_, а не "в следствии объективных причин вынуждены были использовать другие языки")?

А то мы говорим о том, что в средние века большинство населения в Европе умывалось чуть ли не раз в месяц а то и реже — гигиену гнать!

M>Далее. Возможность отображать дерево не целиком, а многоуровнево, скрывая несущественные детали — это объективный показатель. В качестве примера можно привести бесконечные пальцы веером у ФП программистов по поводу выводимости типов. А фактически вся эта выводимость сводится к тому, что часть кода не нужно писать/отображать. Очень небольшую часть кода — всего лишь типы. На фоне возможности, скажем, визуальных редакторов GUI, которые показывают как будет выглядеть диалог, скрывая детали вроде обработчиков событий и настроек layout manager-а — возможности сокрытия ненужной информации при выводе типов — это детский лепет.


Сокрытие информации к её представлению имеет опосредованное отношение. А в подавляющем числе случаев воспринимать и обрабатывать детерминированную информацию проще, когда она имеет текстовый вид.

M>Лисп задаёт не только новую семантику узлов дерева, но и её реализацию. Она у него неотрывно привязана к декларации макроса. Соотвественно и трансформация дерева макросом предполагается только одна. А если отделить декларацию семантики от транформации, то можно преобразовывать одну абстракцию в разные реализации для разных платформ, или разные реализации в зависимости от настроек компилятора и проекта. Это даст как большую модульность, так и большую переносимость кода.


Лисп задаёт _только_ списочный (древообразный) "вид" кода — больше ничего. У вас есть почти полностью управляемый reader и есть возможность вообще вставить свой — какие здесь могут быть ограничения?

И что значит "одна трансформация дерева"? Как можно модифицировать дерево (таким образом, как лисп не может)? Или вы про свой SymADE и про "переносимость AST-а между разными языками"? Так может лучше про ИИ?

M>Людей мало интересуют имена параметров — это детали внутренней реализации. Людей больше заботит семантика и удобство отображения. Скажем, как это сделано для автоматической генерации кода в IDE — набираем слово for жмём Ctrl-Enter и нам генерят и показывают код


M>
M>for ( <init> ; <check> ; <iterate> ) <statement>
M>


M>После чего <поля> заполняются как поля ввода, а не редактирование текста. При этом внутренняя реализация узла для for loop может иметь много других полей, являющихся деталью реализации — скажем, labels для break и continue и т.п., не говоря уже о именах слотов для хранения под-узлов, которые совсем не обязаны быть init, check, iterate.


Писать код "формочками" — увольте

CU>>SLIME использует средства инспектирования каждой отдельной реализации.


M>А он есть для Eclipse?


нет, но для Eclipse вроде есть что-то для лиспа, правда я этого зверя не видел.

CU>>Так, это, более ВУ Я нет?


M>Это вообще не язык. Это концепция (парадигма) программирования (с упором на мета-программирование) и его реализация.


Это пока ещё только концепция и ничего больше.

Так и запишем: "Лисп — ассемблер в МП. Но С ещё не придумали..."
Re[50]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 10.08.07 08:55
Оценка: +1
Здравствуйте, cl-user, Вы писали:

CU>"Имя, сестра, имя!"


У тебя просто неконструктивная позиция. Тебе не интересно следующее поколение средств мета-программирования, что-бы ты об этом не декларировал. Не вижу смысла в дальнейшем обсуждении.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[52]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 10.08.07 12:44
Оценка: :)
Здравствуйте, cl-user, Вы писали:

CU> МП само по себе и "в собственном соку" меня не интересует, а как одно из "в одном флаконе" (наряду с ФП, СП, ПП, ООП, ДП и проч.) — очень даже.


SOP является языко-независимой (нейтральной) концепцией и ортогональной остальным парадигмам. Вот то, что ты пишешь — это оно и есть.

CU>Я хотел что-то увидеть, "уделывающее" лисп по МП, не не такое как N Ан нет — не существует.


Опять ты путаешь слова. Оно есть, существует, но ты его не увидел. Нечем, видимо, было увидеть.
Никто, в здравом уме и памяти не станет считать себя умелым канатоходцем просто от того, что ему рассказали или он книжку прочитал — как ходить по канату.
Так же и парадигмы программирования, вроде ООП/ФП/логической/императивной и пр. — это не просто слова, которые достаточно прочитать. Это такой способ думать. И его надо осваивать так-же, как учиться ходить на канате. А пока ты это не попробовал (а ты даже для себя не сформулировал что ты ищешь) — ты не поймёшь, что такого особенного в SOP.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 12.08.07 20:19
Оценка: :)
VD>А можно где-то почитать описание препроцессора pl/1? Чем он манипулировал?

текстовым представлением программы. помесь макросов С со средствами управления самого pl/1. вот пример, генерящий 10 строк кода:

%do i=1 to 10 do
a(i)=0
%end

почитать об этом можно в книге 78-го года: "макросредлства pl/1 представляют собой случайный набор возможностей с наложенными на них произвольными ограничениями" "...извинить его разработчиков может только то что они были чуть ли не первыми 1964 год)"
Люди, я люблю вас! Будьте бдительны!!!
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 23:22
Оценка: :)
Здравствуйте, cl-user, Вы писали:


CU>>>Деревом-деревом!.. В виде списка... в текстовом файле


M>>Пробовали — херня получается , Lisp называется.


CU>1. "ниасилил"?


CU>2. Вы просто не умеете его готовить.


CU>P.S. Можно выбрать оба варианта


Ты это... окуратнее. А то тут и так проповедников лиспа выше крыши. И у всех психика хромает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 23:22
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>Почему не использовать? Использовать. Знать язык в рнмках единого стандарта обязан каждый разработчик. А вот требовать с него изучения языка каждый раз, когда он сталкивается с новым набором макросов имхо перебор.


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

Почему не использовать? Использовать. Знать язык в рамках единого стандарта обязан каждый разработчик. А вот требовать с него изучения библиотек каждый раз, когда он сталкивается с новым набором макросов имхо перебор.

или

Почему не использовать? Использовать. Знать язык в рамках единого стандарта обязан каждый разработчик. А вот требовать с него изучения семантики пользовательских атрибутов каждый раз, когда он сталкивается с новым набором макросов имхо перебор.

или

Почему не использовать? Использовать. Знать язык в рамках единого стандарта обязан каждый разработчик. А вот требовать с него изучения паттернов проектирования каждый раз, когда он сталкивается с новым набором макросов имхо перебор.


Звучит как првда, вот люди и покупаются.

На самом деле, конечно базу надо знать всем. Но кроме базы есть еще и прикладные знания. Их по любому изучать. И будет ли это имя макроса, функции, класса или даже небольшое синтаксическое расширение совершенно не важно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.08.07 00:41
Оценка: :)
Здравствуйте, FR, Вы писали:

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


Да, вот, например, Питон хороший язык. В нем "это" додумались не называть макросами. Побочные эффектыи не контролируемость даже больше, но на душе спокойно. Это же ведь не макросы!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.08.07 11:22
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>С каких пор SQL динамически типизированный?


С таких. Во-первых CASE может возвращать разнотипные значения в зависимости от условия, во-вторых типы параметров указываются только в момент выполнения запросов.
... << RSDN@Home 1.2.0 alpha rev. 710 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 15.08.07 04:53
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Вообще-то это была ирония, если кто не заметил...

Ты в таких сложных местах комментарии (смайлы) добавляй,
потому как людям не использующим макросы такой юмор ещё не понятен
now playing: Marc Antona — Love Factor
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.08.07 13:02
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>А ты процитируй, то о чем ведешь речь.


9.3 Set operation result data types

Function

Specify the Syntax Rules and result data types for <case expres-
sion>s and <query expression>s having set operators.

Syntax Rules

1) Let DTS be a set of data types specified in an application of
this Subclause.

2) All of the data types in DTS shall be comparable.

3) Case:

a) If any of the data types in DTS is character string, then
all data types in DTS shall be character string, and all of
them shall have the same character repertoire. That charac-
ter repertoire is the character repertoire of the result. The
character set of the result is the character set of one of
the data types in DTS. The specific character set chosen is
implementation-dependent. The collating sequence and the co-
ercibility attribute are determined as specified in Table 2,
"Collating coercibility rules for dyadic operators".

Case:

i) If any of the data types in DTS is variable-length char-
acter string, then the result data type is variable-length
character string with maximum length in characters equal
to the maximum of the lengths in characters and maximum
lengths in characters of the data types in DTS.

ii) Otherwise, the result data type is fixed-length character
string with length in characters equal to the maximum of
the lengths in characters of the data types in DTS.

b) If any of the data types in DTS is bit string, then all data
types in DTS shall be bit string.

Case:

i) If any of the data types in DTS is variable-length bit
string, then the result data type is variable-length bit
string with maximum length in bits equal to the maximum of
the lengths in bits and maximum lengths in bits of the data
types in DTS.

ii) Otherwise, the result data type is fixed-length bit string
with length in bits equal to the maximum of the lengths in
bits of the data types in DTS.

c) If all of the data types in DTS are exact numeric, then the
result data type is exact numeric with implementation-defined
precision and with scale equal to the maximum of the scales
of the data types in DTS.

d) If any data type in DTS is approximate numeric, then each
data type in DTS shall be numeric and the result data type is
approximate numeric with implementation-defined precision.

e) If any data type in DTS is a datetime data type, then each
data type in DTS shall be the same datetime data type. The
result data type is the same datetime data type.

f) If any data type in DTS is interval, then each data type
in DTS shall be interval. If the precision of any data type
in DTS specifies YEAR or MONTH, then the precision of each
data type shall specify only YEAR or MONTH. If the preci-
sion of any data type in DTS specifies DAY, HOUR, MINUTE, or
SECOND(N), then the precision of no data type of DTS shall
specify the <datetime field>s YEAR and MONTH. The result
data type is interval with precision "S TO E", where S and E
are the most significant of the <start field>s and the least
significant of the <end field>s of the data types in DTS,
respectively.

General Rules

None.


AVK>>Типы параметров, в отличие от, вывести невозможно. Поэтому в рантайме их приходится задавать отдельно.


VD>1. Возможно.


SELECT @param

Выводи.

VD>2. Если в рантайме их задают, значит они есть.


Выяснение типов в рантайме как раз и есть динамическая типизиция.
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 15.08.07 14:01
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Да, я ничего и не говорю. Просто все просто, а конца и края не видно.


Не надо спорить с АВК на его территории Он принял архитектурное решение, при котором макросы не могут проявить себя никак. Пытаться что-то доказать в такой ситуации что-либо совершенно бесполезное занятие. Здесь вопрос нужно ставить совершенно по-другому. Можно ли найти решение при для той задачи, которую решает АВК, при котором макросы проявят себя в полную силу.
Если нам не помогут, то мы тоже никого не пощадим.
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 15.08.07 16:06
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

AVK>Затем, что сервер должен перехватывать обращения к бизнес-классам. Сразу оговорюсь — написание бизнес-кода на Nemerle и наличие рантайма сервера при компиляции неприемлемо все по тому же ТЗ.


А кто ТЗ составлял?
Если нам не помогут, то мы тоже никого не пощадим.
Re[54]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.08.07 09:57
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>А кто ТЗ составлял?


Не я.
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 16.08.07 10:12
Оценка: -1
Здравствуйте, mkizub, Вы писали:

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


BZ>>а зачем в С константы, если это по сути дела те же макросы — ты не догадываешься?


M>Ты опять не угадал. Мы же не о С-щных макросах говорим. В С++ const и inline ввели как type safe замену С-шных макросов.

M>А мы говорим об "умных" макросах. Которые сами по себе type safe.

ну ты ведь понял, что не всё, что можно реализовывать макросами — нужно обязательно реализовывать макросами? в случае с константами проблема была в type safety, поддержке отладки

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


M>Я же не против closures или inline. Иначе бы я не делал closures в своём компиляторе.

M>Речь зашла о том, что foreach в N можно сделать в виде closures, и инлайнинге метода foreach.
M>Можно, но есть такая вещь как сложность. Это фундаментальная проблема программирования, вокруг попыток упростить разработку программ вообще всё программирование вертится. Это в нём главное, иначе мы бы до сих пор в машинных кодах программировали бы.
M>Так вот. Силы разработчиков компилятора N ушли на макросы. У них пока руки не дошли обычный if оптимизировать (нормально скомпилировать, а не как http://rsdn.ru/forum/message/2618909.1.aspx
Автор: Othello
Дата: 13.08.07
), а ты говоришь об инлайнинге. Конечно, если N будет жить — то доделают и инлайнинг, и всё остальное. Но это ещё не скоро. А пока они взяли то, что у них сделано хорошо (макросы) и на них сделали foreach. И правильно сделали. А вот когда (и если) доделают инлайнинг — тогда кто-нибудь ради прикола напишет метод inline foreach(...) и будет приколисту щастье.


да, макросы имеют превосходное соотношение цена/результат, пока не требуется большая надёжность
Люди, я люблю вас! Будьте бдительны!!!
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 16.08.07 13:32
Оценка: -1
BZ>>кстати ООП — это динамическая типизация, даже когда она привнесена в статические языки
G>Ну разумеется, нет. Это один из способов привнести в статические языки полиморфизм.

меня зовут Вася
Люди, я люблю вас! Будьте бдительны!!!
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 21.08.07 03:48
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:
Вкратце: тип результата case однозначно определяется по типу операндов, приоритет у строки, дальше идут числа и даты.
AVK>Выяснение типов в рантайме как раз и есть динамическая типизиция.
Никакой динамики там нет. К моменту выполнения запроса все типы, включая тип результата case, известны.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[38]: Generic programming
От: BulatZiganshin  
Дата: 21.08.07 15:33
Оценка: -1
Здравствуйте, awson, Вы писали:

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


BZ>>type classes — это не generic, а polymorhic programming. я уже многоркатно говорил, что здесь ижёт терминологическая путаница. generic programming — это операции типа gmap или gfold, позволяющие сгенерить операции отображения или скажем сериализации для сколь угодно сложного типа

A>Только (пока) эти операции в Хаскелле целиком и полностью реализуются на классах типов, которые и обеспечивают "обход" типа.

откуда у вас столь глубокие познания предмета? из моих же постов, где я объясняю как это можно сделать через type classes. однако это только одна из групп подходов, также используются макросистемы, спец. надстройки над хаскел, RTTI. читайте

Comparing Approaches to Generic Programming in Haskell [http://www.cs.uu.nl/~johanj/publications/ComparingGP.pdf]
Люди, я люблю вас! Будьте бдительны!!!
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 22.08.07 08:31
Оценка: :)
Здравствуйте, EvilChild, Вы писали:

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


C>>Ага. А если тронешь код, помеченый паттерном — IDE инспекцией по голове

C>>стукнет.
EC>А если кому-то лицензия на IDE ещё не пришла или человек приверженнец другой IDE, то пипец?
EC>Убей себя Notepad'ом?
EC>Мне вот странно слышать подобное именно от тебя, человека чей кругозор не ограничен Java,
EC>закалённого C++ template metaprogramming'ом, такие вещи.
М-да... Нам, пнимаешь, закаленным бейсиком ZX Spectrum с его строчным редактором, такого не точно понять .
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 22.08.07 09:51
Оценка: +1
EvilChild wrote:
> C>Ага. А если тронешь код, помеченый паттерном — IDE инспекцией по голове
> C>стукнет.
> А если кому-то лицензия на IDE ещё не пришла или человек приверженнец
> другой IDE, то пипец?
А если тебе комплятор не дают использовать (лицензия не пришла) — писать
на MSIL будешь?

Ну а с "другой IDE" — это просто стандарт нужно написать, который IDE
будут реализовывать.

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

> не ограничен Java,
> закалённого C++ template metaprogramming'ом, такие вещи.
Мне НЕ нравятся полностью неограниченые макросы. Эффекты С++-ных
темплейтов хотя бы локализованы.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.08.07 11:44
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Почему-то, Java-программисты страдают "туннельным видением" — все технологии за пределами Java они просто не замечают. Любые нововведения они объявляют изначально ненужными. Но как только эти или аналогичные нововведения таки внедряются в Java, они тут же становятся нужными и верными.

S>Поэтому енумы в жаве нужны, а проперти — нет; анонимные методы — ересь, а анонимные классы — благо; делегаты — извращение, а классы, вложенные в объект — руль и мастхэв. Ну и так далее. Генерики были не нужны вплоть до какой джавы? Вроде бы 1.5, да? Автобоксинг был вреден до какой джавы?

С одной стороны полностью согласен. С другой стороны все те же симптому наблюдаются и у дотнетчиков. Это видимо какая-то мания защищать и хвалить исключительно свое болото. Принцип один — "у нас есть — хорошо, у нас нет — и не нужно". Прицип в общем-то очень губительный для индустрии, но похоже ничего поделать с ним нельзя. Это на уровне психологии.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 23.08.07 12:17
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD> С другой стороны все те же симптому наблюдаются и у дотнетчиков./.../ похоже ничего поделать с ним нельзя. Это на уровне психологии.


Я точно читаю это у Влада?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 23.08.07 23:58
Оценка: :)
Здравствуйте, EvilChild, Вы писали:

EC>Пора ник апгрейдить на VladD3, чтобы людей не путать


Для начала можно VladD2++.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 24.08.07 05:12
Оценка: :)
Здравствуйте, EvilChild, Вы писали:

EC>Здравствуйте, Andrei N.Sobchuck, Вы писали:


VD>>> С другой стороны все те же симптому наблюдаются и у дотнетчиков./.../ похоже ничего поделать с ним нельзя. Это на уровне психологии.


ANS>>Я точно читаю это у Влада?


EC>Пора ник апгрейдить на VladD3, чтобы людей не путать


Рано, сначало надо узнать что он думает про этот симптом у поклоников Немерли
Re[50]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.08.07 12:10
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>Рано, сначало надо узнать что он думает про этот симптом у поклоников Немерли


Дык в процессе больбы с оным свойством мы и пришли к Немерле. Мы отдаем себе отчет в том, что Немерле не идеал, но по сравнению с Шарпом и Явой это рельный (и не малый) шаг вперед и при этом он не являтся игрушками ученого мира, а вполне может прменяться в тех задачах где используются Ява и Шарп.

Мы как раз и отличаемся тем, что отсуствующие фичи мы воспринимаем адекватно. Макросы и открытый компилятор позволяют хотя бы надеяться на то, что нужные фичи появятся в языке.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.09.07 11:41
Оценка: +1
Здравствуйте, lomeo, Вы писали:

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


L>Может быть, но это уже философский спор о терминах


Не может быть, а точно. Вернее так: RULES — это частное средство метапрограммирования котрое может быть воспроизведено средствами макросов — более универсального средства метапрограммирования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.07 12:05
Оценка: -1
Здравствуйте, lomeo, Вы писали:

L>Более мощная система типов позволяет вынести больше ошибок из рантайма в компиляцию.


Это домыслы. А вто то, что с ее помощью можно сделать больше ошибок — это факт.

L> Что в этом ужасного, если она для этого и предназначается?


Ужасно использование вещей не по назначению. Система типов предназначена для описания типов. А молоток для забивания гвоздей.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.09.07 15:25
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>А вот тут как раз есть форум по С++. Посмотри сколько траха с МП на шаблонах. Посмотри во что превратился Буст и т.п. А С++ действительно имеет более удобную для МП систему типов (допускающую целочисленные параметры в шаблонах).


При чём тут С++?

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

L>>Я вот смои домыслы могу подвердить отсылкой к dependent types, предназначенных именно для уже неоднократно перечисленных мной примеров.


VD>Ты лучше сам этоти проповеди читай. Я как-то не проникаюсь.


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

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

L>>Просто в некоторых системах можно задавать тип — "список длины n", "список длины m", "список длины n+m". А в некоторых — нет.


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


В некоторых системах для описания типов используется тот же язык, что и основной, т.е. мы можем, например, писать функции над типами. Например, MapAppend
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[50]: Являются ли макросы свидетельством недостаточной выр
От:  
Дата: 14.09.07 13:12
Оценка: +1
Hello, VladD2!
You wrote on Fri, 14 Sep 2007 12:59:17 GMT:

YК>> Потрясающая компетентность и аргументация. Слышал звон..

YК>> Член с пальцем не надо сравнивать.

V> Научишся общаться, подходи пообщаемся. А пока, пока.


Не, извини. Я с фантазерами предпочитаю не общаться
Posted via RSDN NNTP Server 2.1 beta
Re: Являются ли макросы свидетельством недостаточной выразит
От: EvilChild Ниоткуда  
Дата: 16.06.07 13:14
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Имеются в виду взрослые макросы a-la Lisp или Nemerle, а не те, что в C.

EC>Или так: нужны ли макросы в таких языках как Haskell?

Не знал, что есть ограничение на длину темы, поэтому продублирую её:
Являются ли макросы свидетельством недостаточной выразительности системы типов?
Re[2]: Являются ли макросы свидетельством недостаточной выра
От: Курилка Россия http://kirya.narod.ru/
Дата: 16.06.07 13:22
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Являются ли макросы свидетельством недостаточной выразительности системы типов?


Ну...
Всёж типы и код вещи немного разные, хотя, конечно, есть изоморфизм Жирарда-Рейнольдса, только вот с практической точки зрения различия в "обычных" языках довольно значительны, поэтому прямая манипуляция с самим кодом проще, имхо
Re[3]: Являются ли макросы свидетельством недостаточной выра
От: EvilChild Ниоткуда  
Дата: 16.06.07 14:28
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Всёж типы и код вещи немного разные,

Первое и второе есть инструмент для решения задачи.

К>хотя, конечно, есть изоморфизм Жирарда-Рейнольдса, только вот с практической точки зрения различия в "обычных" языках довольно значительны, поэтому

К>прямая манипуляция с самим кодом проще, имхо
Чем?
now playing: Photek — Junk
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: Курилка Россия http://kirya.narod.ru/
Дата: 16.06.07 14:48
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Здравствуйте, Курилка, Вы писали:


К>>Всёж типы и код вещи немного разные,

EC>Первое и второе есть инструмент для решения задачи.
Только вот использовать надо оба. Конечно, теоретически всякое можно (чуток обсуждалось здесь
Автор: Курилка
Дата: 09.05.07
, касательно джина, который из типа код выводит) благодаря вышеупомянутому изоморфизму, но вот покажи мне законченную программу, которая была бы только из определений типов, без определений функций, ну и желательно, чтоб она что-нибудь делала, а не просто NOP.

К>>прямая манипуляция с самим кодом проще, имхо

EC>Чем?
Наверное в силу привычки, ведь даже в функциональном программировании есть по сути "императивная" составляющая, когда скажем sin(x) вычисляется в результате некоторых действий. Как вот ты этот самый синус типами выразишь?
Хотя к макросам это отношение имеет слабое, конечно
Тут вот подумал, возможно, ФВП аналогичны макросам по вычислительной мощности, т.к. манипуляции с кодом по сути, наверное, не отличаются от манипуляций с функциями. Но вот момент манипуляции будет разным — в случае ФВП "развёртка" будет в рантайме, тогда как макросы, как правило манипулируют кодом при компиляции.
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: FR  
Дата: 17.06.07 01:22
Оценка:
Здравствуйте, Курилка, Вы писали:

К>>>прямая манипуляция с самим кодом проще, имхо

EC>>Чем?
К>Наверное в силу привычки, ведь даже в функциональном программировании есть по сути "императивная" составляющая, когда скажем sin(x) вычисляется в результате некоторых действий. Как вот ты этот самый синус типами выразишь?
К>Хотя к макросам это отношение имеет слабое, конечно
К>Тут вот подумал, возможно, ФВП аналогичны макросам по вычислительной мощности, т.к. манипуляции с кодом по сути, наверное, не отличаются от манипуляций с функциями. Но вот момент манипуляции будет разным — в случае ФВП "развёртка" будет в рантайме, тогда как макросы, как правило манипулируют кодом при компиляции.

Кроме макросов и страшной системы типов есть и другие способы метапрограммирования, например метаклассы.
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: Курилка Россия http://kirya.narod.ru/
Дата: 17.06.07 06:55
Оценка:
Здравствуйте, FR, Вы писали:

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


К>>Тут вот подумал, возможно, ФВП аналогичны макросам по вычислительной мощности, т.к. манипуляции с кодом по сути, наверное, не отличаются от манипуляций с функциями. Но вот момент манипуляции будет разным — в случае ФВП "развёртка" будет в рантайме, тогда как макросы, как правило манипулируют кодом при компиляции.


FR>Кроме макросов и страшной системы типов есть и другие способы метапрограммирования, например метаклассы.


Ммм, ФВП ты считаешь страшной системой типов?
А про метаклассы можно пример?
Или вот здесь, питонский пример есть подобная штука?
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: deniok Россия  
Дата: 17.06.07 14:28
Оценка:
Здравствуйте, Курилка, Вы писали:


К>>>прямая манипуляция с самим кодом проще, имхо

EC>>Чем?
К>Наверное в силу привычки, ведь даже в функциональном программировании есть по сути "императивная" составляющая, когда скажем sin(x) вычисляется в результате некоторых действий. Как вот ты этот самый синус типами выразишь?

Чего в синусе "императивного"? Он, как и все остальные мат. функции, декларируется рядом Тэйлора:
-- Представляем ряд Тэйлора
-- f(x) = a(0)+a(1)*x+a(2)*x^2+a(3)*x^3+...
-- в виде 
-- f(x) = k_ini(x)*(1+k_n(x,1)*(1+k_n(x,2)*(1+k_n(x,3)*(1+...)))))
-- где k_ini и k_n специфичны для конкретной функции
taylor k_ini k_n x = k_ini x * foldr (.) id (map (app k_n x) [2..100]) 1 -- 100 членов хватит за глаза и за уши
                     where app k a n = (1+) . (k a n *)

-- Для экспоненты exp x = 1+x/1!+x^2/2!+x^2/3!+... =
-- = 1*(1+x/1*(1+x/2*(1+x/3*(1+...))))
-- k_ini x = 1
exp_my x = taylor (\x->1) k_n x
   where k_n x n =  x / fromIntegral (n-1)

-- Для синуса sin x = x/1!-x^3/3!+x^5/5!-... =
-- = x*(1-x^2/(2*3)*(1-x^2/(4*5)*(1-...)))
-- k_ini x = x -- id
sin_my x = taylor id k_n x
   where k_n x n = - x^2 / fromIntegral ((2*n-2)*(2*n-1))

-- Для косинуса  cos x = 1-x^2/2!+x^4/4!-x^6/6!+... =
-- = 1*(1-x^2/(1*2)*(1-x^2/(3*4)*(1-...)))
-- k_ini x = 1
cos_my x = taylor (\x->1) k_n x
   where k_n x n = - x^2 / fromIntegral ((2*n-3)*(2*n-2))




А в типы его поднимать незачем, ибо ни фига он не полиморфен
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: Курилка Россия http://kirya.narod.ru/
Дата: 17.06.07 16:04
Оценка:
Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Курилка, Вы писали:



К>>>>прямая манипуляция с самим кодом проще, имхо

EC>>>Чем?
К>>Наверное в силу привычки, ведь даже в функциональном программировании есть по сути "императивная" составляющая, когда скажем sin(x) вычисляется в результате некоторых действий. Как вот ты этот самый синус типами выразишь?

D>Чего в синусе "императивного"? Он, как и все остальные мат. функции, декларируется рядом Тэйлора:

[cut]
D>
Ну ежу понятно про ряды
Может путано выразился, но мысль в том, что всякие операции аля +, * — императивны, т.к. преобразуются по сути в ассемблерные инструкции и тот же синус выраженный рядом Тейлора есть результат некоторого последовательного вычисления.

D>А в типы его поднимать незачем, ибо ни фига он не полиморфен

Вот об этом сути и речь, что даже если и выражается он в типах, это нафиг особо никому не упало. Ну не будем же мы арифметику на числах Чёрча писать
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: deniok Россия  
Дата: 17.06.07 16:34
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Может путано выразился, но мысль в том, что всякие операции аля +, * — императивны, т.к. преобразуются по сути в ассемблерные инструкции и тот же синус выраженный рядом Тейлора есть результат некоторого последовательного вычисления.


А почему не параллельного? Хотя это уже offtop, но распараллелить процесс суммирования ряда при необходимости довольно легко.

D>>А в типы его поднимать незачем, ибо ни фига он не полиморфен

К>Вот об этом сути и речь, что даже если и выражается он в типах, это нафиг особо никому не упало. Ну не будем же мы арифметику на числах Чёрча писать

Ну речь же не идёт о том, чтобы всё поднять на уровень типов/макросов.

При программировании бывают ситуации, когда ты занимаешься нудной однотипной работой, но ограниченные выразительные средства языка не дают возможности эту однотипность оформить в универсальный код. Тогда и используются макросы (ну или другие инструменты повышения гибкости, в примере с рядом Тэйлора я напихал достаточно ФВП ) Мне Хаскелл нравится ко всему прочему и тем, что совершенно не ограничивает уровень абстрагирования.
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: Курилка Россия http://kirya.narod.ru/
Дата: 17.06.07 16:58
Оценка:
Здравствуйте, deniok, Вы писали:

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


Вот об этом "неограничении" и был вопрос, насколько я понимаю — действительно ли на том же Хаскеле можно примерно также просто решать задачи "повышения абстракции", которые решаются на макросах Лиспа/Немерле и иже с ними.
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: deniok Россия  
Дата: 17.06.07 17:18
Оценка:
Здравствуйте, Курилка, Вы писали:

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


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


К>Вот об этом "неограничении" и был вопрос, насколько я понимаю — действительно ли на том же Хаскеле можно примерно также просто решать задачи "повышения абстракции", которые решаются на макросах Лиспа/Немерле и иже с ними.


ИМХО, задачи повышения абстракции просто решать ни в каком языке не получится. Абтракцию сперва абстрагировать надо. Причём в контексте наличного языкового инструментария.

Что касается Template Haskell, где есть квазицитирование a-la Nemerle, то я не вижу, чтобы народ активно этим пользовался. Для Haskell'а это немножко инородно и тяжеловесно выглядит, хотя это, опять же, ИМХО.
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 17.06.07 18:11
Оценка:
Здравствуйте, deniok, Вы писали:

D>ИМХО, задачи повышения абстракции просто решать ни в каком языке не получится. Абтракцию сперва абстрагировать надо. Причём в контексте наличного языкового инструментария.

ммм, не понял, что ты тут имел в виду...

D>Что касается Template Haskell, где есть квазицитирование a-la Nemerle, то я не вижу, чтобы народ активно этим пользовался. Для Haskell'а это немножко инородно и тяжеловесно выглядит, хотя это, опять же, ИМХО.

template-то как раз никто не произносил тут пока
Хотя с другой стороны вопрос — а почему оно инородно?
Может оно там и не нужно особо-то и имеющихся средств вполне хватает для сих нужд?
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: deniok Россия  
Дата: 17.06.07 19:29
Оценка:
Здравствуйте, Курилка, Вы писали:

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


D>>ИМХО, задачи повышения абстракции просто решать ни в каком языке не получится. Абтракцию сперва абстрагировать надо. Причём в контексте наличного языкового инструментария.

К>ммм, не понял, что ты тут имел в виду...

Ну, если задача хорошо решается простыми средствами, то незачем городить огород. А если простые средства по каким-то причинам не подходят (много кода, неэффективно, просто невозможно), то подключаем более мощные инструменты (макросы, ФВП, sexy types) и в терминах этих инструментов думаем как задачу решить.

D>>Что касается Template Haskell, где есть квазицитирование a-la Nemerle, то я не вижу, чтобы народ активно этим пользовался. Для Haskell'а это немножко инородно и тяжеловесно выглядит, хотя это, опять же, ИМХО.

К>template-то как раз никто не произносил тут пока
К>Хотя с другой стороны вопрос — а почему оно инородно?
К>Может оно там и не нужно особо-то и имеющихся средств вполне хватает для сих нужд?

Я не специалист в Template Haskell, так, чуть-чуть пробовал. Наверное, просто опыта нет. У Булата есть отличные tutorial'ы haskell.org/bz/th3.htm и haskell.org/bz/thdoc.htm.
Re: Являются ли макросы свидетельством недостаточной выразит
От: vdimas Россия  
Дата: 19.06.07 17:24
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Имеются в виду взрослые макросы a-la Lisp или Nemerle, а не те, что в C.

EC>Или так: нужны ли макросы в таких языках как Haskell?

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

Да и термин "достаточно/недостаточно" — весьма субъективный, смысл его сугубо интимный для каждого программиста. Так что ответ примерно такой: макроподдержка является инструментом, позволящим приблизить выразительность к уровню достаточности конкретного разработчика.
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.07 02:00
Оценка:
Здравствуйте, FR, Вы писали:

FR>а ФВП я считаю хорошим средством сильно уменьшающим потребность в макросах.


Точно. Надо Лиспарям и самому себе рассказать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Являются ли макросы свидетельством недостаточной выра
От: EvilChild Ниоткуда  
Дата: 04.07.07 16:45
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В общем, являются ли ненужными прмые решения предназначенные для решения каких-то проблем, если тоже самое можно сделать "через жопу, автогеном" (с)?


Можешь обосновать почему подход Haskell это через жопу автогеном? Желательно на техническом языке, без всяких там печек, ложек и прочей профанации?
now playing: State Of Mind — Human Torch
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: EvilChild Ниоткуда  
Дата: 04.07.07 19:19
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Макросы — это мета-программирование. Зачем нужно мета-программирование? Чтоб добавить

M>в язык понятия, которые в нём не существовали. Чем более в язык уже напихано — тем менее
M>в него нужно добавлять, потому как оно уже там есть. Ерго, мощная система типов делает
M>макросы менее востребованными.
Очевидная мысль изложена хорошо, но вопрос воспринят слишком буквально.
Интересуют преимущества каждого подхода: для решения каких задач удобнее первый, для каких второй.
now playing: Jeff Bennett — Metals
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: EvilChild Ниоткуда  
Дата: 05.07.07 04:23
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Видимо, ты всё-же хотел спросить не это, а то — насколько множество задач решаемых

M>макросами и множество задач решаемых мощной системой типов пересекаются.
Ну, если подходить к формулировке совсем формально, то да.
У тебя есть идеи на этот счёт (я про сформулированный тобой вопрос)?
now playing: Jeff Bennett — Allocations
Re[2]: Являются ли макросы свидетельством недостаточной выра
От: WolfHound  
Дата: 05.07.07 13:18
Оценка:
Здравствуйте, Gaperton, Вы писали:

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

А можно определить где "гражданская" разработка, а где нет?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Являются ли макросы свидетельством недостаточной выра
От: Gaperton http://gaperton.livejournal.com
Дата: 05.07.07 15:35
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

WH>А можно определить где "гражданская" разработка, а где нет?

Это каждый сам для себя решает, в силу своих знаний и умений. Чем больше твои знания и умения, тем более "гражданская" для тебя разработка, и тем реже тебе требуются макросы. Не наоборот.
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: EvilChild Ниоткуда  
Дата: 05.07.07 18:42
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Это каждый сам для себя решает, в силу своих знаний и умений. Чем больше твои знания и умения, тем более "гражданская" для тебя разработка, и тем реже тебе требуются макросы. Не наоборот.

Т.е. получается что хочется макросов от недостаточного владения инструментом? Как-то противоречиво звучит.
now playing: Jeff Bennett — Intro
Re[3]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.07.07 22:18
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


VD>>В общем, являются ли ненужными прмые решения предназначенные для решения каких-то проблем, если тоже самое можно сделать "через жопу, автогеном" (с)?


EC>Можешь обосновать почему подход Haskell это через жопу автогеном? Желательно на техническом языке, без всяких там печек, ложек и прочей профанации?


А у тебя мыслительный процесс туго идет?
Я врде так отчетливо намекнул...

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

Какие проблемы спросите вы? Да элементарные. Язык метапрограммирования в этих языках не тоже самое, что основной язык. Это приводит к тому, что нельзя просто написать библиотеку и использовать ее как в метапрограмме, так и в обычной программе. Отладка не то чтобы затруднена, а ее попросту нет. Даже нормального способа вывести сообщение об ошибке и то нет. Все через зад автогеном.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.07.07 22:18
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Я не предлагал заниматься метапрограммированием используя систему типов.


Меж тем замена макросов в Хаскле получается только при использования метапрограммирования с использованием системы типов.

Так что или ты просто не знаешь Хаскель, или ты пытаешся кого-то обмануть.

EC>Я сделал предположение, что мощная система типов делает макросы менее востребованными.


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

EC>И хотел услышать аргументы в пользу или против этого предположения.


Тебе их высказали, но ты похоже просто не понимашь, что делает Хаскель и С++ стль гибкими на фоне языков в которых нет не МП, ни полной по Тьюрингу системы типов (допускющей вычисления во время компиляции).

EC>А вы опять про ножики и ложки

EC>Детский сад в картинках.

Не детский сад, а профаны лезующие в философию. Уж извини за грубось.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.07.07 22:59
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Система типов не может заменить наличия метапрограммирования (МП). Она, при использовании в своем исходном предназначении, не может решать задач метапрограммирования. А когда система типов превращается в средство для нелегальной реализации МП, то мы получам те же макросы, только, как я уже упомянул, "через жопу... автогеном".

И твой тезис о том, что макросы что-то там нехорошее высвечивают сразу же бьет по Хаскелям и С++ с вдвойной силой. Бо это уже не только макросистемы, но еще и кривые и неудобные макросистемы.

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


Дык, макросы и нужны для языковых расширений. 90% применения в прикладном коде для макросов, на мой взгляд, — это DSL-и. Остальные 10% — это допиливание языка напильником для применения в конкретной сфере. Это допиливание легко ложится в библиотеки и может просто пополнять язык (делая его удобнее для конкретных областей применения).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.07.07 22:59
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>однажды сеймура крея спросили — почему вы используете в своих суперкомьютерах такую простую систему команд? Он улыбнулся и ответил: сложную я просто не понимаю.


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


Осталось выяснить, что имеется в виду под сложным, а что под простым. Вот Вирт считает простым все что минималистично. Например, оператор foreach и параметрический полиморфизм он считает излишествами. Ведь без них можно жить (переберем все while-ами, а полиморфизм на указателях врантайме обеспечим). Другие вот придумывают лист-компрехеншоны и тоже считют это простым.

Я вот все больше склоняюсь к тому, что простое решение — это решение описанное максимально близко к терминам предметной области (максимально высокоуронево). Ну, то есть с Виртом в корне не согласен. А макросы как раз позволяют мне встроить в язык такие прикладные решения. Системы типов этого не позволяют. Даже хаскелевская... если конечно не заниматься на ней МП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: FR  
Дата: 06.07.07 02:08
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>ОК. Посню для тех кто в танке. Хаскель как и С++ не содержит прямых средств решения пробелемы. Вместо этого в нем используется побочный эффект от избыточной мощности системы типов реализованной в языке. Системы типов Хаскеля и С++ полны по Тюрингу и допускают ограниченные вычисления в ее рамках. В результате с огромными усилиями, нехилыми проблемами и ограничениями получается решать часть задач которые, скажем, в Лиспе решались за десятки лет до появления Хасклей и С++-ов просто и элегантно.


VD>Какие проблемы спросите вы? Да элементарные. Язык метапрограммирования в этих языках не тоже самое, что основной язык. Это приводит к тому, что нельзя просто написать библиотеку и использовать ее как в метапрограмме, так и в обычной программе. Отладка не то чтобы затруднена, а ее попросту нет. Даже нормального способа вывести сообщение об ошибке и то нет. Все через зад автогеном.


В Смаллталке нет супер системы типов, нет и макросов, однако гибкость языка (+ метаклассы) позволяет легко решать те же задачи для которых используются макросы.
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: EvilChild Ниоткуда  
Дата: 06.07.07 04:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я врде так отчетливо намекнул...

Т как-то очень мутно намекнул, никакой конкретики. Я такое сам тебе рассказать могу.

VD>ОК. Посню для тех кто в танке. Хаскель как и С++ не содержит прямых средств решения пробелемы. Вместо этого в нем используется побочный эффект от избыточной мощности системы типов реализованной в языке.

Конкретнее, что именно? Какая фича языка? Ну, типа как в плюсах шаблоны, а в хаскеле?
now playing: Phace — Born Under Saturn
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: the_dip Таджикистан  
Дата: 06.07.07 13:16
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я вот все больше склоняюсь к тому, что простое решение — это решение описанное максимально близко к терминам предметной области (максимально высокоуронево). Ну, то есть с Виртом в корне не согласен. А макросы как раз позволяют мне встроить в язык такие прикладные решения. Системы типов этого не позволяют. Даже хаскелевская... если конечно не заниматься на ней МП.


Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: WolfHound  
Дата: 06.07.07 13:53
Оценка:
Здравствуйте, the_dip, Вы писали:

_>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?

Все полные по Тьюрингу языки позволяют решать один и тотже набор задач.
Вопрос в том сколько ты это бущешь писать, сколько отлаживать и с какой скоростью это будет работать.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 06.07.07 14:28
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


_>>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?

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

А можно поподробней по поводу выделенного? Макросы по дефолту ускоряют результирующий код чтоль?
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 08.07.07 06:57
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>Слишком навороченный язык — имхо тоже зло.


Что есть критерий навороченности? Макросы ведь однозначно делают язык навороченней.
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 08.07.07 10:47
Оценка:
Здравствуйте, Gaperton, Вы писали:

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

G>валяйте, давайте сюда пример, и я покажу, как его сделать без макросов и паттернов. Мне хватит паттерн-матчинга, атомов, и первоклассных функций.

Реализуйте паттерн ОО, плиз.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 08.07.07 11:45
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>валяйте, давайте сюда пример, и я покажу, как его сделать без макросов и паттернов. Мне хватит паттерн-матчинга, атомов, и первоклассных функций.


Ну, можно чего попроще. Лексер написать. Кстати, сначала ты скажи, сколько у тебя это времени заняло, а потом я отвечу и мы сравним.

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


Введение в язык средств абстракции вроде функций, модулей, объектов так же чревато тем, что кто-то понапишет кривых библиотек (вспомним, как было с C++ и строками). И ничего, вроде как-то пишут вполне поддерживаемый код, не отказываясь от этих абстракций.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 08.07.07 11:46
Оценка:
K>Ну, можно чего попроще. Лексер написать. Кстати, сначала ты скажи, сколько у тебя это времени заняло, а потом я отвечу и мы сравним.

Ой, забыл сказать. Лексер C#. А то лексер вообще можно и за пару минут написать.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 09.07.07 05:39
Оценка:
Здравствуйте, konsoletyper, Вы писали:

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


K>Ой, забыл сказать. Лексер C#. А то лексер вообще можно и за пару минут написать.


По твоему лексер C# написать проще чем большинство паттернов?
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 10:41
Оценка:
Здравствуйте, aka50, Вы писали:

A>
A>class Parser extends StdTokenParsers with ImplicitConversions {
...
A>}
A>


Да, замечательно.
Ты думаешь, что естественным образом это достигается только с помощью макросов?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 10:41
Оценка:
Здравствуйте, Gaperton, Вы писали:

_>>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?


G>единственный известный мне пример, 100 %оправдывающий макрогенерацию — библиотека работы с матрицами, которая об'единяет циклы в алгебраических выражениях. Получается что понятный код не жертвует скоростью, в той задаче, где скорость критична. По сути, здесь идет речь о языковом расширении.


Можно подробнее о выделенном? Почему этого можно добиться только макросами?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 09.07.07 10:57
Оценка:
Здравствуйте, lomeo, Вы писали:

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


Т.е. система типов Хаскелля по отношению к нетривиальным фичам не есть то же самое, что шаблоны в C++? А можно об этом поподробнее, на примерах? И подоступнее, а то там чёрт ногу сломит.

PS: а всякие ката-, хило- и прочие морфизмы, про которые Мейер писал, можно на одном только Хаскелле в общем виде для любых алгебраических типов реализовать, или тут надо привлекть что-то помощнее?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 11:37
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Вот именно это и не нравится. Выглядит не по-BNF-ному.


Без проблем! Меняем названия на EBNF-ные.

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


Нужны мозги, готовые писать декларативно.
Если хочешь, я объясню на пальцах строение Parsec. Знание монад вряд ли тебе понадобится.

На самом деле, когда я с Лиспа перешёл на Хаскель, я тоже недоумевал, как же так? А где макросы? Поработав через некоторое время я почувствовал, что для большинства вещей они там не нужны. Макросы в Лиспе большей частью нужны были для подслащивания: реализации ленивости (эта часть выполняется только если...), более удобной записи вызовов (вместо всех этих lambda что то вроде карринга), и прочей кодогенерации (скажем куча определений вместо одного) и т.д.
Всё это есть в Хаскель задаром. Последнее делается разве что немного по другому.

K>Типа, если что-то в этом роде захочет написать обычнй средний программист, он наткнётся на БОЛЬШИЕ проблемы, что отталкивает людей от написания чего-то макросозаменяющего. Вот на том же Nemerle я без всяких проблем написал макрос, генерирующий лексер. Причём если какие-то проблемы и были, то они чисто технического плана. Мозги извращать не приходилось.


Ну тебе же пришлось сначала понять, что такое макрос. Это уже определённое извращение мозгов
Что осталось сделать сейчас — это чуть чуть поднапрячься и понять, что такое функция

K>А если я сам захочу приделать подобную "фичу" к языку, мне не всё равно на чём её писать. Макрос — это легко. А вот монады понять тяжело.


Их легко понять на самом деле. Если ты их ещё не понял, то когда грокнешь, поймёшь, что легко.
С макросами я тоже не сразу разобрался, например.

K>Боюсь даже, это не из-за самих монад, а из-за того, как их подают.


+1

K>Пытался читать "The Haskell Programmer’s Guide to the IO Monad". Споткнулся на естественных преобразованиях. Во-первых, в самой статье для объяснения естественных преобразований применяется жуткая нотация, которая не оговорена нигде вообще. Как прекрасно для статьи, претендующей на вводную. Во-вторых, я всё-же нашёл в других источниках более внятное определение естественных преобразований, но так и не увидел объяснения, что же это такое.


В этой статье много ТК. Для объяснения монад ТК не нужно. Представляй монаду как интерфейс для вычислений, этого вполне достаточно.
Для объяснения монад воспользуйся лучше другими статьями. Ссылки уже были, если не найдёшь, накидаю.

L>>Так в том то и дело, что макросы не надо эмулировать, если язык позволяет обойтись без них.


K>Дык, а чем, скажем, шаблоны C++ хуже макросов? Я так понимаю,


Тем, что они эмулируют макросы, IMHO.

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


Или просто функции? Они же тоже добавляют фичу в язык?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 09.07.07 12:30
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Нужны мозги, готовые писать декларативно.

L>Если хочешь, я объясню на пальцах строение Parsec. Знание монад вряд ли тебе понадобится.

Ладно, сам разберусь, когда время придёт. Меня вообще смутила приставка "monadic".

L>Ну тебе же пришлось сначала понять, что такое макрос. Это уже определённое извращение мозгов


Не, самое интересное, что мозги извращать не приходилось. Помню, когда начинал, для понимания Паскаля мозги не напрягал. Потом то же было с C/C++/Java/C#. Позже не было никаих проблем с SICP. А вот Александреску я долго не мог понять. Монады не понял до сих пор.

L>Что осталось сделать сейчас — это чуть чуть поднапрячься и понять, что такое функция


Дык вроде и так понимаю.

L>В этой статье много ТК. Для объяснения монад ТК не нужно.


Ну, самые простые вещи понять можно без ТК, на интуитивном уровне. Но вот я видел такие выверты, что тут без ТК, ИМХО, не обошлось.

L>Для объяснения монад воспользуйся лучше другими статьями. Ссылки уже были, если не найдёшь, накидаю.


Спасибо, но я и так много чего с "Декларативного программирования" в избранное положил. Поищу, наверняка посты с ссылками там лежат.

L>Тем, что они эмулируют макросы, IMHO.


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

L>Или просто функции? Они же тоже добавляют фичу в язык?


Ага, у меня, собственно, такой же вопрос. Вот Хаскель — продвинутый язык, и в нём можно во многих случаях сделать то, что в Лиспе делается исключительно на макросах. Но не всё. Так почему же Хаскелю не нужны макросы? Или что-то, что их может полноценно заменить.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 09.07.07 12:42
Оценка:
Здравствуйте, FR, Вы писали:

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

G>>>валяйте, давайте сюда пример, и я покажу, как его сделать без макросов и паттернов. Мне хватит паттерн-матчинга, атомов, и первоклассных функций.

M>>Реализуйте паттерн ОО, плиз.


FR>Вот на схеме без использования макросов http://okmij.org/ftp/Scheme/pure-oo-system.scm


А при чём тут schema? Про существование CLOS я знаю, что это можно сделать на схеме — тоже.
Речь шла о хаскеле.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 09.07.07 12:46
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Для лексера необходимости в макросах нет. Погляди Parsec.


Не подскажете где можно посмотреть сравнение производительности лексеров, написаных с помощью Parsec и других генераторов лексеров?
... << RSDN@Home 1.2.0 alpha rev. 677>>
'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[18]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 12:57
Оценка:
Здравствуйте, konsoletyper, Вы писали:

L>>Что осталось сделать сейчас — это чуть чуть поднапрячься и понять, что такое функция


K>Дык вроде и так понимаю.


Я к тому, что в ФП функция рассматривает несколько по другому нежели в "обычных языках". Это первоклассная сущность.
Один из ярких примеров — это представление данных функцией. Скажем множество обычно представляют как некий контейнер, хранящий разные элементы. Если при работе с множеством нам нет необходимости перечислять его элементы, а достаточно определять — входит ли элемент в множество, то это можно сделать так:

Мы определяем множество как функцию типа a -> Bool, т.е. функцию, которой передаётся элемент, а она возвращает True, если элемент принадлежит множеству.

type Set a = a -> Bool


Теперь мы можем определить добавление элемента в множество:

add :: a -> Set a -> Set a
add x set = \y -> if x == y then True else set y


пересечение множеств:

intersect :: Set a -> Set a -> Set a
intersect s1 s2 = \x -> s1 x && s2 x


объединение множеств:

union :: Set a -> Set a -> Set a
union s1 s2 = \x -> s1 x || s2 x


и т.д.

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

K>Ну, самые простые вещи понять можно без ТК, на интуитивном уровне. Но вот я видел такие выверты, что тут без ТК, ИМХО, не обошлось.


Глубоко же ты копал. А где, если не секрет?

L>>Тем, что они эмулируют макросы, IMHO.


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


Я согласен, но спорить тут не возмусь — это вопрос того кто и как смотрит на такое понятие как чувство меры. Gaperton считает, что макросы нецелесообразны, а ты наоборот. Не думаю, что есть ответ на вопрос "кто из вас прав". А если и есть, то я его не знаю.

L>>Или просто функции? Они же тоже добавляют фичу в язык?


K>Ага, у меня, собственно, такой же вопрос. Вот Хаскель — продвинутый язык, и в нём можно во многих случаях сделать то, что в Лиспе делается исключительно на макросах. Но не всё. Так почему же Хаскелю не нужны макросы? Или что-то, что их может полноценно заменить.


Я не говорил, что не нужны. Иначе не было бы Template Haskell например. Я имел в виду, что некоторые вещи можно делать по другому. И получится не хуже.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 13:19
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Я, конечно, не Gaperton, но раскрыть тему попытаюсь.


K>Имеем:

K>
K>x := alpha * p + omega * s;
K>

K>Разворачивается в:
K>
K>for(i = 0; i < x.Length; i++)
K>{
K>    x[i] = alpha * p[i] + omega * s[i];
K>}
K>

K>Даже такой элементарный пример позволяет, в общем-то проиллюстрировать. Чуть более сложный

Я не понял, если честно.
х у нас заранее создан с нужной длиной?
p, s — это матрица или вектора? alpha и omega — скаляры?
в чём прикол? почему нельзя просто перемножить и сложить? промежуточные структуры?
Можно сам макрос подсмотреть?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 09.07.07 13:25
Оценка:
Здравствуйте, lomeo, Вы писали:

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


_>>>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?


G>>единственный известный мне пример, 100 %оправдывающий макрогенерацию — библиотека работы с матрицами, которая об'единяет циклы в алгебраических выражениях. Получается что понятный код не жертвует скоростью, в той задаче, где скорость критична. По сути, здесь идет речь о языковом расширении.


L>Можно подробнее о выделенном? Почему этого можно добиться только макросами?


В выражении a = b + c + d, где переменные — матрицы, надо, чтобы все это свернулось в единственный двойной цикл с этой формулой внутри. На плюсах это делается без макросов — через темплейтное метапрограммирование, и выглядит страшно. На макросах, мне думается, реализация выглядела бы проще. Хотя — честно скажу, пока на макросах реализации не видел. Все только говорят, говорят о великих и ужасных макросах — и все .
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 09.07.07 14:03
Оценка:
Здравствуйте, mkizub, Вы писали:

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


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

G>>>>валяйте, давайте сюда пример, и я покажу, как его сделать без макросов и паттернов. Мне хватит паттерн-матчинга, атомов, и первоклассных функций.

M>>>Реализуйте паттерн ОО, плиз.


FR>>Вот на схеме без использования макросов http://okmij.org/ftp/Scheme/pure-oo-system.scm


M>А при чём тут schema? Про существование CLOS я знаю, что это можно сделать на схеме — тоже.

M>Речь шла о хаскеле.

С чего это вы взяли, коллега, что речь шла о Хаскеле? Слова "Хаскель" я не произносил. Я сказал — "первоклассные функции, атомы, и сопоставление с образцом". Имея в виду, кстати, Эрланг (в котором объекты, кстати, изначально присутствуют, в точности как в Smalltalk 72 — они делаются процессами). Но в схеме все перечисленное тоже есть.
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 09.07.07 14:18
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Я к тому, что в ФП функция рассматривает несколько по другому нежели в "обычных языках". Это первоклассная сущность.


Ага. Я на Nemerle писал, и это ощутил по полной. Ещё и универе мне математику преподают — там всякого навидался.

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


Поняв, что функция — частный случай отношения, можно сделать ещё больше.

Я уже писал генератор парсера на Nemerle. Генератор парсера — это функция, отображающая некоторое подмножество конекстно-свободных грамматик на множество детерминированных автоматов с МП. В принципе, у меня были идеи, как написать всё это дело на чистом языке. Но это неудобно. Некоторые вещи вообще императивно реализуются проще — например, часто встречающаяся задача отыскать элементы множества, заданного индуктивно. Я так и не придумал хорошей реализации в терминах чистой функции, за исключением грубой эмуляции очереди и множества, просто в чистом случае му ничего не модифцируем, а таскаем очередь и множество в параметрах функции.

Но вот в чём беда. На том же Хаскелле я в принципе могу написать генератор парсера, который бы выдавал код, вроде Yacc. Но как сделать, чтобы всё это было бесшовно. Разве что на замыканиях, но это же медленно. Кроме того, хотелось бы, чтобы парсер конструировался не в рантайме.

K>>Ну, самые простые вещи понять можно без ТК, на интуитивном уровне. Но вот я видел такие выверты, что тут без ТК, ИМХО, не обошлось.


L>Глубоко же ты копал. А где, если не секрет?


Копал не глубоко. Просто по всяким книжкам и статьям по Хаскелю пытался разобраться, но понял только в пределах простейших вещей в IO. В той же самой статье приводятся примеры, которых я не понял. Например, когда на монадах основаны Maybe, списки и т.д. Говорят, что вроде это способствует лучшей модульности. Я вот и пытаюсь понять, как.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 09.07.07 14:19
Оценка:
Здравствуйте, Gaperton, Вы писали:

M>>А при чём тут schema? Про существование CLOS я знаю, что это можно сделать на схеме — тоже.

M>>Речь шла о хаскеле.

G>С чего это вы взяли, коллега, что речь шла о Хаскеле? Слова "Хаскель" я не произносил. Я сказал — "первоклассные функции, атомы, и сопоставление с образцом". Имея в виду, кстати, Эрланг (в 1

якотором объекты, кстати, изначально присутствуют, в точности как в Smalltalk 72 — они делаются процессами). Но в схеме все перечисленное тоже есть.

С того, что речь в этой ветке идёт о хаскеле, с его крутой системой типов. Которая может и заменяет макросы (в чём я соменваюсь), а вот с ОО не дружит принципиально.
Но если вы о схеме речь завели — то лисп со схемой — это макросо-ориентированные языки по самые гланды. Там это на макросах сделано, а не на системе типов.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 14:21
Оценка:
Здравствуйте, deniok, Вы писали:

D>Кстати здорово — задача оптимизации решается прямым указанием оптимизатору! Rewrite Rules rulez


Не думаю, что это здорово. оптимизации надо оставлять оптимизатору, выражение a+b+c очень уж конкретное.
Так никаких рулесов не напасёшься, да и сами реализации этих оптимизаций писать придётся.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 14:55
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Я уже писал генератор парсера на Nemerle. Генератор парсера — это функция, отображающая некоторое подмножество конекстно-свободных грамматик на множество детерминированных автоматов с МП. В принципе, у меня были идеи, как написать всё это дело на чистом языке. Но это неудобно.


Ну у нас не идёт спор чистый vs грязный
Мы пока о макрах.

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


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

K>Но вот в чём беда. На том же Хаскелле я в принципе могу написать генератор парсера, который бы выдавал код, вроде Yacc. Но как сделать, чтобы всё это было бесшовно.


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

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


Тоже не понимаю, в чём проблема.
Замыканий в Haskell-е нет, в том смысле, что переменные неизменны. Т.е. это простые лямбды. Ты про них?
Конструирование парсера в рантайме происходит ровно один раз.

L>>Глубоко же ты копал. А где, если не секрет?


K>Копал не глубоко. Просто по всяким книжкам и статьям по Хаскелю пытался разобраться, но понял только в пределах простейших вещей в IO. В той же самой статье приводятся примеры, которых я не понял. Например, когда на монадах основаны Maybe, списки и т.д. Говорят, что вроде это способствует лучшей модульности. Я вот и пытаюсь понять, как.


Модульности в том смысле, что имеют один интерфейс. Это используется, например, в монад-трансформерах. При композиции монад мы не знаем какую монаду оборачиваем, да нам это и неважно, пока мы работаем на верхнем уровне. Таким образом, мы можем объединить монады в одну (по принципу декоратора) и получить монаду которая и ошибки обрабатывает, и лог пишет, и состояние хранит и т.д. Хотя за каждое поведение отвечает одна единственная составляющая этой монады, таким образом всё не перемешано в одном месте. Может это имелось в виду?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 09.07.07 15:06
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Ну у нас не идёт спор чистый vs грязный

L>Мы пока о макрах.

Мы о macros vs. functions?

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


L>Не понял. Что значит отыскать элементы множества, заданного индуктивно?


Типа, конечное множество задаётся индуктивно. Необходимо перечислить все его элементы. Например, epsilon-замыкание некоторого состояния ДКА. Или множества FIRST и FOLLOW для символа грамматики.

K>>Но вот в чём беда. На том же Хаскелле я в принципе могу написать генератор парсера, который бы выдавал код, вроде Yacc. Но как сделать, чтобы всё это было бесшовно.


L>Не понимаю. Обсуждаемый Parsec не генерит код. Это такой DSL, который используется прямо в коде. Это бесшовно?


Это бесшовно. Но я так не напишу.

L>Тоже не понимаю, в чём проблема.

L>Замыканий в Haskell-е нет, в том смысле, что переменные неизменны. Т.е. это простые лямбды. Ты про них?

Вроде замыкание — это когда переменная вытягивается из контекста. Причём тут изменяемые перменные? Просто замыкания компилятся в не самый хороший и быстрый код.

L>Конструирование парсера в рантайме происходит ровно один раз.


В рантайме? А в compile-time? Тут уж без макросов не обойтись.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[22]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 15:35
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Мы о macros vs. functions?


В общем да.

L>>Не понял. Что значит отыскать элементы множества, заданного индуктивно?


K>Типа, конечное множество задаётся индуктивно. Необходимо перечислить все его элементы. Например, epsilon-замыкание некоторого состояния ДКА. Или множества FIRST и FOLLOW для символа грамматики.


А детерминированные автоматы бывают с эпсилон переходами? Не знаю просто.
Почему нельзя получить не знаю. Достаточно в представлении автомата иметь возможность получить все эпсилон-переходы.
Дальше просто.

eClosure automata state = state : concatMap (\trans -> eClosure automata (trans state)) transitions
        where
                transitions = eTransitions automata state


Если ты про то определение множества, что я дал, то я там оговорил, что оно не для перечисления элементов.
Однако вот это множество чисто и вполне годится и для этой роли.

L>>Тоже не понимаю, в чём проблема.

L>>Замыканий в Haskell-е нет, в том смысле, что переменные неизменны. Т.е. это простые лямбды. Ты про них?

K>Вроде замыкание — это когда переменная вытягивается из контекста. Причём тут изменяемые перменные? Просто замыкания компилятся в не самый хороший и быстрый код.


Может быть. Это же ФВП в конце концов.

L>>Конструирование парсера в рантайме происходит ровно один раз.


K>В рантайме? А в compile-time? Тут уж без макросов не обойтись.


Ну я не знаю во что синлайнится мой код Это просто разные подходы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.07 15:37
Оценка:
Здравствуйте, Gaperton, Вы писали:

L>>Круто. А можно поглядеть на С++ реализацию?


G>Гуру из нашей С++ конфы говорят, что есть в библиотеке Blitz++, а вообще решение искать надо по словам expression templates. Сразу предупреждаю — это очень злой С++. Но если попривыкнуть — то там, в сущности, все понятно .


Пока разобрался до момента инлайна, как врублюсь — отпишу.
Кажется это можно сделать на Хаскеле с помощью простых ФВП и потом deforestation.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[23]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 09.07.07 16:06
Оценка:
Здравствуйте, lomeo, Вы писали:

K>>Мы о macros vs. functions?


L>В общем да.


Тогда я не о чистоте а о функциях. В том смысле, что генерация парсера — тоже функция.

K>>Типа, конечное множество задаётся индуктивно. Необходимо перечислить все его элементы. Например, epsilon-замыкание некоторого состояния ДКА. Или множества FIRST и FOLLOW для символа грамматики.


L>А детерминированные автоматы бывают с эпсилон переходами? Не знаю просто.


О, конечно нет. Это очепятка. Имелся в виду НКА.

L>Почему нельзя получить не знаю. Достаточно в представлении автомата иметь возможность получить все эпсилон-переходы.

L>Дальше просто.

L>
L>eClosure automata state = state : concatMap (\trans -> eClosure automata (trans state)) transitions
L>        where
L>                transitions = eTransitions automata state
L>


L>Если ты про то определение множества, что я дал, то я там оговорил, что оно не для перечисления элементов.

L>Однако вот это множество чисто и вполне годится и для этой роли.

Не, я вообще про другое. Просто хотелось описать задачу, которую не сумел нормально решить в терминах чистого ФП.

А как приведённый код обработает циклы, сотосящие из epsilon-переходов?

L>Ну я не знаю во что синлайнится мой код Это просто разные подходы.


Да я тоже не знаю. Просто чётко знаю, что парсер в получившейся сборке будет уже готовый, никакой генерации в рантайме не будет.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: deniok Россия  
Дата: 09.07.07 16:07
Оценка:
Здравствуйте, lomeo, Вы писали:

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


D>>Кстати здорово — задача оптимизации решается прямым указанием оптимизатору! Rewrite Rules rulez


L>Не думаю, что это здорово. оптимизации надо оставлять оптимизатору, выражение a+b+c очень уж конкретное.

L>Так никаких рулесов не напасёшься, да и сами реализации этих оптимизаций писать придётся.

Ну почему бы не прооптимизировать конкретный модуль, если видно, как?
Кстати твой a+b+c=... вроде незаконен,

The left hand side of a rule must consist of a top-level variable applied to arbitrary expressions.

Очевидно надо так (+) a ((+) b c)=...

Для более общего случая можно замутить что-то вроде:

Пусть у нас есть FastVectors, линейные операции типа сложения над ними определяем через аналог zipWith
a `op` b = zipWithFV op a b

Делаем хинт (ох опасный, но, ладно, только для этой библиотеки )
forall a b c op1 op2. op1 a (op2 b c) = (op1 .## op2) a b c

(где (.##) = (.)(.)(.) ) и хинт
forall op1 op2. (.##) (zipWithFV op1) (zipWithFV op2)  = zipWithFV3 (op1 .## op2)

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

Ну и ещё надо надеятся на то, что ((+) .## (+)) a b c, раскроется в эффективную реализацию сложения a+b+c, что скорее всего так — композиции композиций по наблюдениям порождают быстрый код.
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.07 18:35
Оценка:
Здравствуйте, Курилка, Вы писали:

VGn>>Слишком навороченный язык — имхо тоже зло.


К>Что есть критерий навороченности? Макросы ведь однозначно делают язык навороченней.


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

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

В прочем, грань между макросом и реальной фичей языка очень зыбка. В том же Немерле многие языковые фичи реализованы с помощью маросов или исползуют макросы. Для программиста-пользоватля — это язык. А для программиста-разработчика компилятора макросы — это (в том числе) средство радикально упростить разработку компилятора.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.07 18:35
Оценка:
Здравствуйте, deniok, Вы писали:

D>Безотносительно к системам типов: а почему для DSL-ей обязательно нужны макросы?


D>Вот в Хаскелле библиотека комбинаторов для парсинга Parsec вполне себе создаёт удобный DSL для соответствующих задач, позволяя легко собирать парсеры из более простых, и вообще использовать их как первоклассные объекты — помещать в списки, передавать и возвращать из функций, etc. И никакой особой магии с типами не требуется, монад (которые, кстати, пользователю библиотеки не видны) вполне достаточно.


Испоьзовать фунции высшего порядка и их комбинации сегодня можно даже в C#. Но вот для реальной жизни нужно порой изменять синтаксис и/или производить вычисления во время компиляции. ФВП этого делать не позволяют. Но несоменно, что если задача рашается без метапрограммирования (МП) и при этом получаетя приемлемый (по всем показателям) результат, то прибегать к МП нет никагого смысла. Причем не важно реализуется МП макросами или выкрутасами с системой типов Хасклея/С++.

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

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

Что же касается Парсека, то лично у мепня шарики от него завихиваются. Такое обильное использование монад до добра не доводят. По мне так эти монады ухреначивают код не хуже сишных макросов. В прочем, может это как с маслинам и анчеусами...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 09.07.07 19:34
Оценка:
Здравствуйте, VladD2, Вы писали:

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


_>>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?


VD>Любой DSL.


Ммм, значит DSL на хаскеле или скале "не считаются"?
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 10.07.07 04:04
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Имеем:

K>
K>x := alpha * p + omega * s;
K>

K>Разворачивается в:
K>
K>for(i = 0; i < x.Length; i++)
K>{
K>    x[i] = alpha * p[i] + omega * s[i];
K>}
K>

K>Даже такой элементарный пример позволяет, в общем-то проиллюстрировать. Чуть более сложный
K>
K>r := b - A*x;
K>

K>мне уже расписывать лень.
K>Каким еще способом можно добиться того, чтобы DSL не проигрывал в производительности коду a la FORTRAN?
K>Лично мне очень интересно.

На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.
Re[24]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.07.07 05:52
Оценка:
Здравствуйте, konsoletyper, Вы писали:

L>>
L>>eClosure automata state = state : concatMap (\trans -> eClosure automata (trans state)) transitions
L>>        where
L>>                transitions = eTransitions automata state
L>>


K>А как приведённый код обработает циклы, сотосящие из epsilon-переходов?


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

K>Да я тоже не знаю. Просто чётко знаю, что парсер в получившейся сборке будет уже готовый, никакой генерации в рантайме не будет.


В этом смысле да — макросы как кодогенераторы (если нам нужен именно кодогенератор) в общем случае незаменимы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 10.07.07 06:56
Оценка:
Здравствуйте, FR, Вы писали:

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


FR>>>Вот на схеме без использования макросов http://okmij.org/ftp/Scheme/pure-oo-system.scm


M>>А при чём тут schema? Про существование CLOS я знаю, что это можно сделать на схеме — тоже.

M>>Речь шла о хаскеле.

FR>Вроде речь шла о том что можно реализовать без макросов, там это сделано при том:

FR>

FR>; The present code implements a classless, delegation-based OO system, similar
FR>; to those of Self or Javascript. This is a full-fledged OO system with
FR>; encapsulation, object identity, inheritance and polymorphism. It is also
FR>; a purely functional system: there is not a single assignment or
FR>; other mutation in the code below.

FR>Так что думаю на любой функциональный язык перепишется.

Ну, это все-таки жесть В схеме можно и замыкания с деструктивными присваиваниями использовать — должно быть проще.
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 10.07.07 06:57
Оценка:
Здравствуйте, VladD2, Вы писали:

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


_>>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?


VD>Любой DSL.


А лексо-яко-подобные тулзы никак нам в этом не помогут, да?
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 10.07.07 07:03
Оценка:
Здравствуйте, Gaperton, Вы писали:


FR>>Так что думаю на любой функциональный язык перепишется.


G>Ну, это все-таки жесть В схеме можно и замыкания с деструктивными присваиваниями использовать — должно быть проще.


Ты сходи по ссылке, нет там императивщины.
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 10.07.07 07:05
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Вон konsoletyper написал код для парсинга JSON-а. Повтори на Парсеке — будет практически один в один.


Это не я писал, вообще-то. Я писал код для раскраски C#. Там всё не совсем один-в-один. Типа, я ношусь с идеей отделения кода от спецификации.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 10.07.07 07:26
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>А лексо-яко-подобные тулзы никак нам в этом не помогут, да?

На макросах в подавляющем большинстве случаев гооораздо проще.
Вернее даже так: Я не представляю когда лексо-яки при создании ДСЛ будут лучше.
Может приведешь пример?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.07.07 08:05
Оценка:
Здравствуйте, konsoletyper, Вы писали:

L>>Вон konsoletyper написал код для парсинга JSON-а. Повтори на Парсеке — будет практически один в один.


K>Это не я писал, вообще-то. Я писал код для раскраски C#. Там всё не совсем один-в-один. Типа, я ношусь с идеей отделения кода от спецификации.


В смысле? flex/yacc?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.07.07 08:05
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Ну, это все-таки жесть В схеме можно и замыкания с деструктивными присваиваниями использовать — должно быть проще.


IORef?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 10.07.07 08:48
Оценка:
Здравствуйте, lomeo, Вы писали:

L>В смысле? flex/yacc?


Не, в смысле, код и спецификация — раздельно. В flex/yacc тенденция противоположная — смешивать код и спецификацию.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 10.07.07 09:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

G>>А лексо-яко-подобные тулзы никак нам в этом не помогут, да?

WH>На макросах в подавляющем большинстве случаев гооораздо проще.
WH>Вернее даже так: Я не представляю когда лексо-яки при создании ДСЛ будут лучше.

По мне, так главный плюс макросов в том, что помимо созданного DSL у программиста остаётся "под руками" весь "исходный" язык. В случае создания DSL "самого в себе" придётся строить язык _полностью_, а с макросами достаточно реализовать недостающее.
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 10.07.07 09:58
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


G>>А лексо-яко-подобные тулзы никак нам в этом не помогут, да?

WH>На макросах в подавляющем большинстве случаев гооораздо проще.
WH>Вернее даже так: Я не представляю когда лексо-яки при создании ДСЛ будут лучше.
WH>Может приведешь пример?

Когда тебе нужен скриптовый DSL, чтобы интерпретироваться в рантайме. Например — тебе надо написать веб-браузер с поддержкой JavaScript.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 10.07.07 10:46
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Когда тебе нужен скриптовый DSL, чтобы интерпретироваться в рантайме. Например — тебе надо написать веб-браузер с поддержкой JavaScript.

Жабаскрип имеет слишком большие возможности для ДСЛ. Ибо на нем можно писать далеко не только браузерные скрипты.
Под ДСЛ обычно понимают очень узкоспециализированный язык заточенный под одну конкретную задачу. Не больше и не меньше. Как правило ДСЛи даже не полны по Тьюрингу.

Хотя даже если мне будет нужен жабаскрипт то я скорей всего не стану связываться с лексо-яками ибо геморойно очень, а выхлоп есть только если использовать языки типа C/C++/C#/Java.
А если язык болие мощьный то проще без них.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 10.07.07 13:41
Оценка:
Здравствуйте, WolfHound, Вы писали:

G>>Когда тебе нужен скриптовый DSL, чтобы интерпретироваться в рантайме. Например — тебе надо написать веб-браузер с поддержкой JavaScript.

WH>Жабаскрип имеет слишком большие возможности для ДСЛ. Ибо на нем можно писать далеко не только браузерные скрипты.
WH>Под ДСЛ обычно понимают очень узкоспециализированный язык заточенный под одну конкретную задачу. Не больше и не меньше. Как правило ДСЛи даже не полны по Тьюрингу.

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

WH>Хотя даже если мне будет нужен жабаскрипт то я скорей всего не стану связываться с лексо-яками ибо геморойно очень, а выхлоп есть только если использовать языки типа C/C++/C#/Java.

WH>А если язык болие мощьный то проще без них.

Это я вообще не понял. Что за выхлоп, почему проще без lex-yacc, почему геморройно с генераторами парсеров, чем без них. Странно как-то то все звучит.
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.07.07 15:01
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Гуру из нашей С++ конфы говорят, что есть в библиотеке Blitz++, а вообще решение искать надо по словам expression templates. Сразу предупреждаю — это очень злой С++. Но если попривыкнуть — то там, в сущности, все понятно .


В общем, да, разобрался, спасибо.

Подозреваю, что такое можно сделать на GHC. За исключением того, что приведение будет явным: toVector (v1 + v2 + v3).

Т.е. строится обычный декоратор, как и в примере, функции инлайнятся до toVector включительно, чтобы получить для vs[i] обычное выражение для элементов. Удалится ли конструктор декоратора при специализации toVector — не знаю, надо проверять.

По идее в оптимизаторе была трансформация

foo = \x -> C x
bar = \C x -> f x

bar . foo => \x -> f x


Не знаю, сработает ли здесь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 10.07.07 15:28
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>какая разница, тьюринг-полный он или нет. Ровным счетом никакой. Рассмотри любой пример, когда тебе надо в рантайме подцеплять и интерпретировать описание на специальном языке. Например — веб-браузер. И все — макросы — до свидания.

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

G>Это я вообще не понял. Что за выхлоп, почему проще без lex-yacc, почему геморройно с генераторами парсеров, чем без них. Странно как-то то все звучит.

То и значит.
Лексаяки рулят если нужно написать компилятор на тупом языке типа C/C++/C# но если в языке есть алгебраические типы, сравнение с образцом, ФВП, макросы итп то от лексаяков пользы нет.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.07 15:42
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K> И подоступнее, а то там чёрт ногу сломит.


Кстати, одина из основных претензий к макросам — это как раз то, что в них черт ногу сломит. Собственно лично мне кажется, что ломать ноги, скажем в монадах, куда проще. Так что большой вопрос что является большим злом макросы или монады.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Являются ли макросы свидетельством недостаточной выра
От: thesz Россия http://thesz.livejournal.com
Дата: 10.07.07 16:39
Оценка:
VD>Дык, макросы и нужны для языковых расширений. 90% применения в прикладном коде для макросов, на мой взгляд, — это DSL-и. Остальные 10% — это допиливание языка напильником для применения в конкретной сфере. Это допиливание легко ложится в библиотеки и может просто пополнять язык (делая его удобнее для конкретных областей применения).

То есть, макросы нужны только для DSEL.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 10.07.07 19:14
Оценка:
Здравствуйте, deniok, Вы писали:

L>>bar = \(C x) -> f x -- так имел ввиду, а не \C x -> f x ??


Да, конечно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Вон konsoletyper написал код для парсинга JSON-а. Повтори на Парсеке — будет практически один в один.


Повтори — сравним. Как по выразительности, так и по скорости. А там видно бдет. ОК?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, thesz, Вы писали:

T>То есть, макросы нужны только для DSEL.


В большинстве случаев — да. Хотя конечно это отличное средство для развития самого языка (упрощает компилятор в разы). Кроме того макросы являются отличным средством оптимизации.

Но DSEL — это то где макры являютс просто идеальным решением и все остальные по сравнению с ними курят. В том числе и внешение DSL-и (слишком сложно их создавать).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, Курилка, Вы писали:

VD>>Любой DSL.


К>Ммм, значит DSL на хаскеле или скале "не считаются"?


Считается. Но они получаются слишком ограниченные в сравнении с прмыми решениями. В прочем, причем тут Скала вообще не ясно. Там система типов мало чем не отличается от Ява/Шарпа.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, Gaperton, Вы писали:

VD>>Любой DSL.


G>А лексо-яко-подобные тулзы никак нам в этом не помогут, да?


А это и есть вариант DSL-ей. Только внешних. Это если говорить о самом [E]BNF.

Если же ты говоришь о разработке DSL-ей с помощью "лексо-яко-подобные тулзов", то ты явно не покопался с макросами или покапался слишком мало. Это просто несопоставимые по объему и сложности работ средства. Макросы позволяют задействавать огромную инфрастуруктуру основного языка и его компилятора. Создвая язык с нуля, ты вынужден все до последнего винтика создать самостоятельно.

Темболее, что "лексо-яко-подобные тулзы" так же имеются в вдие макросов
Автор: konsoletyper
Дата: 31.03.07
. Так что по любому макросы решают задачи DSL-естроения лучше и быстрее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, FR, Вы писали:

FR>На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.


Решение конечно на шаблонах с применением Буста?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, deniok, Вы писали:

D>Кстати здорово — задача оптимизации решается прямым указанием оптимизатору! Rewrite Rules rulez


А в чем разница между ними и макросами? И почему тогда "макросы сакс", а "Rewrite Rules rulez", а?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Для лексера необходимости в макросах нет. Погляди Parsec.


Кстати, хорошее предложение. Предлагаю пенисомерию. Сравниваем Parsec с лексером konsoletyper-а.

На входе небольшой проект C#, на выходе количество токенов каждого типа в его файлах.

Как предложение?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, lomeo, Вы писали:

K>>Уже давно глядел. Не понравилось.


L> Давай не будем это считать аргументом.


Ну, почему же?

K>>Во-первых, все эти <###> смотрятся коряво, а хотелось бы человеческого EBNF-образного синтаксиса.


L>Синтаксис очень близок к EBNF вплоть до переименования.


Тебе не кажется, что "очень близок" на практике означет "непохож"?
Понимаеш ли в чем дело?... На макросах можно получить как раз тот синтаксис что тебе требуется. И делается это проще.

L>Вместо "|" здесь "<|>", вместо +/* — many1/many, вместо '(' — char '(', "abc" — string "abc".


Да, да... Вот только в лексере konsoletyper-а вместо "|" используется (ты не поверишь) "|" и т.д.

K>>Кроме того, мнее вообще непонятно, как это всё работает.


L>Это тоже вряд ли сойдёт за аргумент


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

L>Поверь, для этого не надо вкуривать монады. Достаточно понять, что парсер это функция, дальше всё просто.


Мне показалось он говорит о реализации.

L>Да и вообще — у тебя уже есть готовый DSL. Зачем тебе знать на чём он построен — на макросах или монадах?


Очевидно, чтобы написать свои собственные DSL-и. Мы же вроде бы об этом, а не о готовых решения. Ведь на свете уже давно существуют Яки и Антлр-ы. Их можно вкурить не только без знания монад, но и без знания о существовании Хаскеля.

L>Так в том то и дело, что макросы не надо эмулировать, если язык позволяет обойтись без них.


Макросы не надо эмулировать. Это правда. Они мощьнее чем вырктасы шаблонного МП в С++ и куда монад в Хаскеле. Они прямое средство переписывания кода так как надо программисту. И нихрена в этой области с ними не сравнится.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Без проблем! Меняем названия на EBNF-ные.


На EBNF есть ISO-стандарт. Вот кода вы на Хаскеле его повторить сможете (ну, процентов так на 99 хотя бы), тогда можено будет поговорить. А пока тебе прийдется признать, что решение на Хаскеле не полноценно.

L>Нужны мозги, готовые писать декларативно.


Хм. Решение на макросах получается короче и понятнее, но оно не декларативно? Забавные выводы.

L>Если хочешь, я объясню на пальцах строение Parsec. Знание монад вряд ли тебе понадобится.


L>На самом деле, когда я с Лиспа перешёл на Хаскель, я тоже недоумевал, как же так? А где макросы? Поработав через некоторое время я почувствовал, что для большинства вещей они там не нужны. Макросы в Лиспе большей частью нужны были для подслащивания: реализации ленивости (эта часть выполняется только если...), более удобной записи вызовов (вместо всех этих lambda что то вроде карринга), и прочей кодогенерации (скажем куча определений вместо одного) и т.д.

L>Всё это есть в Хаскель задаром. Последнее делается разве что немного по другому.

Ну, так не бери для сравнения Лисп. Старичку все же уже 50 лет! Возми Немерле. Он в большинстве случаев не уступает Хаскелю в выразительности сам по себе и при этом еще содержит макросы. В прочем все эти ТемлэйтХаскели и РеврайтРулезы ни что иное как маросы. Так что ты лучше обясни как решить конфликт между наличием этих фич и утверждением о том, что макросы не нужны. Это будет куда интереснее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Я к тому, что в ФП функция рассматривает несколько по другому нежели в "обычных языках". Это первоклассная сущность.


Сори, а на кого направлен этот балшит? Может еще разведем балшит по повоту продвинутости структурного программирования в сравнении с ассемблерами?

Насколько я помню на свете есть очень мало языков в которых макросы достигли своего апогея. Все эти языки, как один, являются фунциональными (Лисп, Темлэйт Хаскель, Немерле). Так зачем нас грузить ФП?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, lomeo, Вы писали:

L>

L>The library is fast, parsing thousands of lines a second on today's machines


L>Но тысячи в секунду, это как то маловато, если честно.


Ага. Я тоже сполз под стол читая эту цитату.

L> Даже для 2001. Очень-очень сомневаюсь, что это связано с тем, что реализация не на макросах. Надо с Happy сравнить. Полагаю, проблема всё таки в строках Haskell-а, которые как известно, медленные. Можно попробовать подключить binary string и померить.


Предлагаю запенисометрировать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Я воспользуюсь flex, или любой подобной тулзой. По ним хотя-бы документация есть, и мой код все поймут, а в велисипеде на макросах еще рабираться надо будет стороннему программеру. Недостатка в генераторах лексеров и парсеров нет ни для какого языка. Буквально для любого языка есть выбор.


Ты бы попробовал, а потом обсудили бы. А то как-то не смешно. Я вот попробовал и готов потратить время на изучение, чтобы не испытывать тех проблем, что есть с тулзами вроде flex-а.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, Константин Л., Вы писали:

K>>Я могу так же взять C#, как всем известный язык. Но начать юзать для него вместо .NET Framework библиотеки, написанные неизвестно кем (хотя бы даже свои). И знаешь, инженер, который будет править баги, будет материться не меньше.


КЛ>Зато отладка макросов это очень неприятное занятие.


Это не свойство самих макросов. Это свойство реализации. Для макросов можно сделать полноценную отладку. Это чисто техническая проблема. Хотя в том же Немерле она пока что не решена до коца. Это факт.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.07 00:45
Оценка:
Здравствуйте, lomeo, Вы писали:

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


VD>>Я вот все больше склоняюсь к тому, что простое решение — это решение описанное максимально близко к терминам предметной области (максимально высокоуронево). Ну, то есть с Виртом в корне не согласен. А макросы как раз позволяют мне встроить в язык такие прикладные решения. Системы типов этого не позволяют. Даже хаскелевская... если конечно не заниматься на ней МП.


L>Почему априори считается, что МП — это обязательно макросы?


А я так не считаю. Я просто считаю, что макросы (правильно приготовленные) — это лучшее на сегодня средство для преготовления МП.

L>Что касается встраивания в язык DSL, то на Haskell это получается замечательно.


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

L> Просто там другой подход, и, разумеется, есть отличия от подхода с макросами.


Дык о том и речь. Но МП оно и в африке МП и все претензии, что можно предявить к нему применимы как к макрам, так и к любым другим его видам. А вот результат... Он 100%-но более качественен у макр, да и понять решения на макросах, на мой взгляд, проще. В прочем, последнее утверждение конечно спорно. Но и первого хватет.

L> Вот в этой статье, например сказано, что именно Haskell не умеет делать, в отличие от макросов, а что умеет. Но делает это по своему, и не выглядит неестественным.


Дык если что-то не умеет, начи уже менее мощьный. При этом еще и более сложный.

Что имеем в итоге?
1. Большую сложность реализации.
2. Меньшие возможности.
3. Меньшую скорость результирующего кода.
4. Все (гипотетические, так как на мой взгляд это домыслы) недостатки МП.

Ну, и где здесь приемущества? Отсутсвие слова "макросы"? Ахринеть (с)!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 11.07.07 02:05
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.


VD>Решение конечно на шаблонах с применением Буста?


На шаблонах без буста. Я такой велосипед писал когда про буст еще не слышал.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 11.07.07 05:14
Оценка:
Здравствуйте, Курилка, Вы писали:


К>Подход, принятый тут (называемый авторами “zygotictype-directed growth”), описан здесь


Кстати на D это также можно сделать.
Вообще для подобных мелких DSL вполне достаточно чтобы в языке были ленивые вычисления (тот же lazy в D или блоки кода типа Смаллтаковских).
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 11.07.07 05:41
Оценка:
Здравствуйте, FR, Вы писали:

FR>Вообще для подобных мелких DSL вполне достаточно чтобы в языке были ленивые вычисления (тот же lazy в D или блоки кода типа Смаллтаковских).


А в скале вродь как без ленивости обошлись. А блоки кода в смолтолке по сути же лямбды или лямбды мы уже за "отложенные вычисления" считаем?
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 11.07.07 05:52
Оценка:
Здравствуйте, WolfHound, Вы писали:

G>>какая разница, тьюринг-полный он или нет. Ровным счетом никакой. Рассмотри любой пример, когда тебе надо в рантайме подцеплять и интерпретировать описание на специальном языке. Например — веб-браузер. И все — макросы — до свидания.

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

WH>Так что попытка обосновать не нужнось макросов наличием жабаскрипта идет лесом.

Лесом идут такие аргументы вместе с автором. То есть тобой. С пионерами в таком ключе спорь.

WH>Болие того я спокойно могу на лету скомпилить код на томже немерле... с макросами...

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

G>>Это я вообще не понял. Что за выхлоп, почему проще без lex-yacc, почему геморройно с генераторами парсеров, чем без них. Странно как-то то все звучит.

WH>То и значит.
Слушай, когда изъясняться понятно начнешь, по-нормальному, без выхлопов, тогда и поговорим.

WH>Лексаяки рулят если нужно написать компилятор на тупом языке типа C/C++/C# но если в языке есть алгебраические типы, сравнение с образцом, ФВП, макросы итп то от лексаяков пользы нет.


Угу.
Re[3]: Являются ли макросы свидетельством недостаточной выра
От: Gaperton http://gaperton.livejournal.com
Дата: 11.07.07 06:05
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Система типов не может заменить наличия метапрограммирования (МП). Она, при использовании в своем исходном предназначении, не может решать задач метапрограммирования. А когда система типов превращается в средство для нелегальной реализации МП, то мы получам те же макросы, только, как я уже упомянул, "через жопу... автогеном".


Я говорил не о замене метапрограммирования чем-то там, а о повседневной необходимости в нем. Разницу чувствуешь? Объясняю. Где-то придется для "паттерна" конечного автомата заводить макрос, чтоб красиво было. А кое-где — это совершенно обычная задача, не требующая ни выверта, ни паттерна. Смотри:

switch_state( State, Message ) -> State( Message ).

state1( msg1 ) -> ...;
state1( msg2 ) -> ...;

И все. Никаких "через жопу автогеном".

VD>И твой тезис о том, что макросы что-то там нехорошее высвечивают сразу же бьет по Хаскелям и С++ с вдвойной силой. Бо это уже не только макросистемы, но еще и кривые и неудобные макросистемы.


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

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


VD>Дык, макросы и нужны для языковых расширений. 90% применения в прикладном коде для макросов, на мой взгляд, — это DSL-и. Остальные 10% — это допиливание языка напильником для применения в конкретной сфере. Это допиливание легко ложится в библиотеки и может просто пополнять язык (делая его удобнее для конкретных областей применения).


Вот видишь — наступил наконец редкий случай, когда мы с тобой согласны. Ну, почти .
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 11.07.07 06:08
Оценка:
Здравствуйте, Курилка, Вы писали:

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


FR>>Вообще для подобных мелких DSL вполне достаточно чтобы в языке были ленивые вычисления (тот же lazy в D или блоки кода типа Смаллтаковских).


К>А в скале вродь как без ленивости обошлись. А блоки кода в смолтолке по сути же лямбды или лямбды мы уже за "отложенные вычисления" считаем?


Разве обошлись, вроде в тех же запросах используются именно ленивое вычисление параметров.
Лямбды конечно тоже.
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 11.07.07 07:11
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.


ANS>>Белая гарячка


VD>у вас, маньяков? Несомненно. Вы же даже возразить аргументированно не умеете.


Влад, если вышеотквоченный текст это был вопрос и тебе интересно узнать мнение других людей, то попробуй поставить в нужном месте знак вопроса. Если это был сарказм или шутка, то поставь смайлик. Если же то было утверждение, то таки смотри мой коммент строчкой ниже твоего спича.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 11.07.07 07:15
Оценка:
Здравствуйте, FR, Вы писали:

FR>Разве обошлись, вроде в тех же запросах используются именно ленивое вычисление параметров.

Аргументируй, не вижу там ничего ленивого, или наличие ф-ции, которая вызывает/выполняет DSL и есть такая ленивость?
FR>Лямбды конечно тоже.
Тогда макросы — тоже ленивость? Ониж генерируют код, который сразу не выполняется.
Плюс паттерны стратегия/комманда тоже туда пойдут.
Т.е. теоретически, конечно, это есть некая ленивость, но вот с термином ленивых вычислений, аля как в хаскеле это не очень соотносится имхо.
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 09:20
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Для лексера необходимости в макросах нет. Погляди Parsec.


VD>Кстати, хорошее предложение. Предлагаю пенисомерию. Сравниваем Parsec с лексером konsoletyper-а.

VD>На входе небольшой проект C#, на выходе количество токенов каждого типа в его файлах.
VD>Как предложение?

Неинтересно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 11.07.07 09:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Сори, а на кого направлен этот балшит? Может еще разведем балшит по повоту продвинутости структурного программирования в сравнении с ассемблерами?


VD>Насколько я помню на свете есть очень мало языков в которых макросы достигли своего апогея. Все эти языки, как один, являются фунциональными (Лисп, Темлэйт Хаскель, Немерле). Так зачем нас грузить ФП?


Не все, есть еще Forth.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: deniok Россия  
Дата: 11.07.07 10:02
Оценка:
Здравствуйте, VladD2, Вы писали:

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


D>>Кстати здорово — задача оптимизации решается прямым указанием оптимизатору! Rewrite Rules rulez


VD>А в чем разница между ними и макросами? И почему тогда "макросы сакс", а "Rewrite Rules rulez", а?


Rewrite Rules это способ явно записать указания компилятору для оптимизаций. Это — открытый интерфейс оптимизатора конкретного компилятора, GHC, а не часть языка. При этом, правда, правила записываются фактически на том же языке.

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

DSL встроенный в язык — это одно. Здесь мы не можем определять синтаксических конструкций, конфликтующих с синтаксисом исходного языка. Если какое-то ключевое слово основного языка необходимо в DSL'е и должно в нём использоваться по-другому — придётся извращаться (скажем, вместо if писать ifMy).

А отдельный DSL c отдельным интерпретатором — это немножко другая история, мы ведь не о них говорим?
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 10:12
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Вон konsoletyper написал код для парсинга JSON-а. Повтори на Парсеке — будет практически один в один.


VD>Повтори — сравним. Как по выразительности, так и по скорости. А там видно бдет. ОК?


Да блин замени <|> на |.
Тебя, я так понимаю, это больше всего смущает?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 10:21
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Повтори — сравним. Как по выразительности, так и по скорости. А там видно бдет. ОК?


Ты кстати на вопросы не ответил.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 11.07.07 12:02
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Я не понял, если честно.


Бывает.

L>х у нас заранее создан с нужной длиной?


В данном случае да, но это несущественная деталь.

L>p, s — это матрица или вектора? alpha и omega — скаляры?


p и s это вектора. Про скаляры Вы сами догадались. Разве не очевидно из итогового кода?

L>в чём прикол?


Прикол в производительности.

L>почему нельзя просто перемножить и сложить?


Просто — это как?

L>промежуточные структуры?


Не должны создаваться. Когда решаешь СЛАУ из 1M уравнений, например, это не очень весело.

L>Можно сам макрос подсмотреть?


С течением времени.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'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[13]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 11.07.07 12:02
Оценка:
Здравствуйте, FR, Вы писали:

FR>На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.


С проблемами.

Например такой вот пример из Blitz++ (прямо из мануала)

Array<float,1> x(4), y(4);
Array<float,2> A(4,4);

A = cos(x(tensor::i)) * sin(y(tensor::j));


Посчитает и sin и cos по 16 раз, хотя нужно по 4. Писать библиотеку с такими оптимизациями на C++ не очень весело. С макросами такая задача все-таки более реальна.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'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[16]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.07 12:53
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>PackedString что-ли? Это возможно? К ним же стандартные списковые функции применять нельзя. (Ну почему в Haskell нет класса типов List?!) И придется слишком многое переписывать, нет? Это более чем сомнительное удовольствие.


Нет. PackedString прошлый век
Сейчас есть BinaryString.

K>К тому же лично мне не понятно, почему Parsec так написан? Вообще-то производительность лексера и парсера имеет значение. Это же вроде бы не просто proof-of-concept, он позиционируется как построитель парсеров пригодный для реального использования. Кроме того, он еще и объявлен быстрым. Слово "fast" — даже в заголовок описания вынесено. Это шутка?


Я не измерял производительность Parsec.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 11.07.07 13:01
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Нет. PackedString прошлый век

L>Сейчас есть BinaryString.

Это что-то ужасно секретное, да? Поиск в Google и на haskell.org ничего не дал.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'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[3]: Являются ли макросы свидетельством недостаточной выра
От: IT Россия linq2db.com
Дата: 11.07.07 16:46
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Ты, Влад, возможно, не поверишь, но японцы суп именно так и едят, причем вместо вилки — палочки


Ты уверен насчёт супа? Что-то я ни разу не видел в японском ресторане что бы кто-то ел миса-суп палочками. Для этого выдаётся специально обученный прибор.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: IT Россия linq2db.com
Дата: 11.07.07 17:16
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Мой профайл будет тебе ответом


Ага. Ну тогда объяни мне как есть миса-суп палочками, если всё, что можно выловить там палочкой — это пара листов какой-то зелени?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: jazzer Россия Skype: enerjazzer
Дата: 11.07.07 23:46
Оценка:
Здравствуйте, IT, Вы писали:

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


J>>Мой профайл будет тебе ответом


IT>Ага. Ну тогда объяни мне как есть миса-суп палочками, если всё, что можно выловить там палочкой — это пара листов какой-то зелени?


так Влад же сказал, как Описал, так сказать, в деталях, только вилку с палочками перепутал.

Суть в том, что плошка должна быть диаметром где-то в полторы-две обычных чашки.
Поэтому пить из нее очень удобно (ты в детстве пил чай из блюдца?), а палочки нужны как раз для этой самой пары листов и для остального, что могут в этот суп кинуть. Напимер, могут накидать малюсеньких (1 см диаметром) ракушек — палочками тельце моллюска с раковины снимается элементарно (), хотел бы я посмотреть, как это будет проделано ложкой

А еще тут палочками едят макароны.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: A.Lokotkov Россия http://www.linkedin.com/pub/alexander-lokotkov/a/701/625
Дата: 12.07.07 06:07
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Мой тезис говорит о том, что макросистемы — темная сторона силы. Настоящий джедай управится и без них...


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

А показано ниже описание одной из подсистем в некотором хидере, который включается много раз с разными определениями одних и тех же макро перед каждым включением. Каждый джедай занимается своей подсистемой, реализуя функции для каждой вершины ее графа состояний.
#include <sms/fssysasp.h>
// Вершины графа состояний.
// Для каждого состояния подсистемы определяется некий набор функций, вызываемых движком.
F_STATES_LIST_BEGIN(FCfg)
  F_DEFINE_LAYER_STATE(FCfg, Init, INITIAL_STATE)
  F_DEFINE_LAYER_STATE(FCfg, Load, NORMAL_STATE)
  F_DEFINE_LAYER_STATE(FCfg, Config, NORMAL_STATE)
  F_DEFINE_LAYER_STATE(FCfg, Error, NORMAL_STATE)
  F_DEFINE_LAYER_STATE(FCfg, Wait, NORMAL_STATE)
F_STATES_LIST_END(FCfg)
// Ребра графа состояний
F_EDGES_LIST_BEGIN(FCfg)
  F_DEFINE_EDGE(FCfg, Init, Load)
  F_DEFINE_EDGE(FCfg, Load, Config)
  F_DEFINE_EDGE(FCfg, Load, Wait)
  F_DEFINE_EDGE(FCfg, Config, Wait)
  F_DEFINE_EDGE(FCfg, Config, Error)
  F_DEFINE_EDGE(FCfg, Error, Load)
  F_DEFINE_EDGE(FCfg, Wait, Load)
F_EDGES_LIST_END(FCfg)

// Аллокаторы данной подсистемы
F_ALLOCATORS_LIST_BEGIN(FCfg)
  F_DEFINE_DEFAULT_IMMORTAL_ALLOCATOR(FCfg, CfgFixedMemory, 1024, NONE_SAFE_ALLOCATOR)
  //F_DEFINE_DEFAULT_SMALL_HEAP_ALLOCATOR(FCfg, CfgParserMemory, NONE_SAFE_ALLOCATOR, 1024, 4, 50)
F_ALLOCATORS_LIST_END(FCfg)

// Декларация подсистемы
F_DECLARE_SUBSYSTEM_LAYER(FCfg, sms_policy_abort_all, CONSOLE_UNDEFINED, 0)

// Коды возврата данной подсистемы
START_RETCODE_TABLE(F_CFGI_RESULT)
  //DEFINE_RETCODE(F_CFGI_RESULT, NO_CLIENTS)
  DEFINE_RETCODE(F_CFGI_RESULT, SERVER_INIT_FAILED)
  DEFINE_RETCODE(F_CFGI_RESULT, SERVER_DESCRIPTOR_FAILURE)
  DEFINE_RETCODE(F_CFGI_RESULT, NO_MORE_RESOURCES)
  //... etc.
  DEFINE_RETCODE(F_CFGI_RESULT, BATCH_TIMEOUT)
END_RETCODE_TABLE(F_CFGI_RESULT)


Все подсистемы склеиваются в систему в головном (включемом многократно) хидере верховным джедаем примерно так:

#include <sms/fsystasp.h>
// Таблица зависимостей между состояниями разных подсистем,
// чтобы подсистемы согласованно ходили по графу ничего не зная друг о друге
F_SYSTEM_DEPENDENCY_TABLE_BEGIN(CPM705)
// FCfg пойти в Init, когда остальные достигнут Ready
  F_STATE_DEPENDENCY_BEGIN(AppRT2, Ready)
    F_DEFINE_DEPENDANT(FCfg, Init)
  F_STATE_DEPENDENCY_END(AppRT2, Ready)

  F_STATE_DEPENDENCY_BEGIN(ModbusSrv, Ready)
    F_DEFINE_DEPENDANT(FCfg, Init)
  F_STATE_DEPENDENCY_END(ModbusSrv, Ready)

// Всем пойти в Config, когда FCfg пойдет в Config
  F_STATE_DEPENDENCY_BEGIN(FCfg, Config)
    F_DEFINE_DEPENDANT(AppRT2, Config)
    F_DEFINE_DEPENDANT(ModbusSrv, Config)
  F_STATE_DEPENDENCY_END(FCfg, Config)

// Всем пойти в Run, когда FCfg пойдет в Wait
  F_STATE_DEPENDENCY_BEGIN(FCfg, Wait)
    F_DEFINE_DEPENDANT(AppRT2, Run)
    F_DEFINE_DEPENDANT(ModbusSrv, Run)
  F_STATE_DEPENDENCY_END(FCfg, Wait)
F_SYSTEM_DEPENDENCY_TABLE_END(CPM705)

// Собственно объединение списка подсистем в систему
F_DECLARE_STM_SYSTEM_BEGIN(CPM705, NULL, NULL, NULL, NULL)
  F_INCLUDE_STM_SUBSYSTEM(FCfg)
  F_INCLUDE_STM_SUBSYSTEM(AppRT2)
  F_INCLUDE_STM_SUBSYSTEM(ModbusSrv)
  F_INCLUDE_STM_SUBSYSTEM(RPC)
F_DECLARE_STM_SYSTEM_END(CPM705)

// Конфигуратор системы
F_DECLARE_CFG_SERVER_BEGIN(AppRT2, CfgForceSafe, ExternalCfg, ParseOnServer, 0)
  F_INCLUDE_CFG_CLIENT(AppRT2)
  F_INCLUDE_CFG_CLIENT(ModbusSrv)
F_DECLARE_CFG_SERVER_END(AppRT2)


Ясен пальчик(с), что писать всю эту ахинею руками не очень обязательно, -- можно сделать тул, позволяющий рисовать графы и генерить все, что нужно автоматом. А также верифицировать и т.п.
bloß it hudla
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: deniok Россия  
Дата: 12.07.07 06:30
Оценка:
Здравствуйте, A.Lokotkov, Вы писали:

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


G>>Мой тезис говорит о том, что макросистемы — темная сторона силы. Настоящий джедай управится и без них...


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


[skiped]

Эта не та же группа джедаев, которая разарабатывала сложную многоаспектную MFC?

Что здесь (даже в рамках С++) нельзя сделать на шаблонах?
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: A.Lokotkov Россия http://www.linkedin.com/pub/alexander-lokotkov/a/701/625
Дата: 12.07.07 06:37
Оценка:
Здравствуйте, deniok, Вы писали:

D>Эта не та же группа джедаев, которая разарабатывала сложную многоаспектную MFC?


Нет конечно же. Но про аспектное программирование довольно много писалось в свое время, ага.

D>Что здесь (даже в рамках С++) нельзя сделать на шаблонах?


Не вдаваясь в детали скажу, что вся эта муть должна быть совместима с C. C++, увы, имеется не для всех целевых платформ.
bloß it hudla
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: A.Lokotkov Россия http://www.linkedin.com/pub/alexander-lokotkov/a/701/625
Дата: 12.07.07 07:09
Оценка:
Здравствуйте, deniok, Вы писали:

D>То есть в контексте обсуждаемой темы делаем вывод: макросы C являются свидетельством недостаточной выразительности языка C?


Ну, на плюсовых шаблонах также довольно проблематично группировать и совместно обрабатывать отдельные аспекты разных подсистем (сразу говорю, что прямо сейчас недосуг давать строгие определения понятий "подсистема", "система" и "аспект"). Здесь можно почитать немного о предмете.
bloß it hudla
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: Константин Л. Франция  
Дата: 12.07.07 09:07
Оценка:
Здравствуйте, IT, Вы писали:

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


КЛ>>Ха. А ты думал. Скорость поедания супа палками сравнима со скоростью написания немерле компайлера на с++. Так что все как бы правильно.


IT>Т.е. они макают палки в суп, а потом облизывают их? Но ведь это же ужасно не эффективно


как и с++, я же сказал
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 12.07.07 12:17
Оценка:
jazzer,

J>Суть в том, что плошка должна быть диаметром где-то в полторы-две обычных чашки.

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

J>А еще тут палочками едят макароны.


Палочками офигенно удобно есть чипсы и холодец
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 12.07.07 12:44
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Входной язык бизона есть именно тот самый микс из синтаксическиъ метаопредений близких к Backus и Naur нотации *плюс* определения хост языка С или С++. Собственноо примерно то же что их себя представляет входной язык Nemerle.


Это, у меня BNF отдельно, код — отдельно. Код в грамматике ен прописывается, т.к., ИМХО, это криво.

CS>"как тоже самое" — что конкретно то же саме? Bison на Nemerle?

CS>А зачем?

Нет, не Bison. Надо посмотреть ниже по ветке. Там представлен генератор лексера, написанный на макросах. Т.е. мы прописываем грамматику прямо в коде Nemerle. Сейчас я занимаюсь макросом, который генерит парсер. Может, через неделю-две будет готова первая версия.

Ну и второе основное отличие, как я уже сказал, код на Nemerle и описание грамматики не смешиваются.

CS>Я ничего не понял... чем это все принципиально лучше прогона файла граматики через Бизон и показа тех же ошибок в IDE или просто в консоли?


CS>На вот тебе http://blogs.msdn.com/devdev/archive/2005/09/13/465034.aspx статью про то как интегрировать Бизон в VS если так уж надо.


Эту штуковину для VS нужно было написать. А я ничего специально не писал.

CS>IDE для разаработки языков программирования?

CS>... не, ну наверное кому-нибудь оно надо... ЯП-мазохистам например которые по языку в неделю выпускают. Но я таких даже и не знаю где искать.

А DSL?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[3]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 00:23
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Ты, Влад, возможно, не поверишь, но японцы суп именно так и едят, причем вместо вилки — палочки


Дык они еще сепуку делают. Очень полезное занятие для всех кто не может есть ложкой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 00:23
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Палочками офигенно удобно есть чипсы и холодец


А как ими выкадываются глаза!...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 00:23
Оценка:
Здравствуйте, FR, Вы писали:

FR>>>На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.


VD>>Решение конечно на шаблонах с применением Буста?


FR>На шаблонах без буста. Я такой велосипед писал когда про буст еще не слышал.


Дык, изобрази... посмеемся вместе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 00:23
Оценка:
Здравствуйте, eao197, Вы писали:

E>Принципиальная схема реализации отложенных вычислений в C++ изложена у Страуструпа в 3-м издании "Язык программирования C++" (Б.Страуструп, Язык программирования C++, спец. изд./Пер.с англ. — М.;СПб.:"Издательство БИНОМ" — "Невский Диалект", 2001г. — 1099с., ил.) Раздел 22.4.7 "Временные массивы, копирование и циклы", стр.743.


E>Без шаблонов и Буста.


Осталось без трепа изобразить решение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 00:23
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>А в чем разница между ними и макросами? И почему тогда "макросы сакс", а "Rewrite Rules rulez", а?


L>Макросы генерят код по поименованному определению макроса. Это имя используется в коде для вызова макроса компилером.


Это ты домысливашь. Реально же макросы довольно гибкий инструмент и могут делать все что им угодно с кодом проекта (при этом в самом коде не присуствуя).

L>Рулесы делают трансформацию без поименований с уже имеющимися функциями. Компилер находит шаблоны и меняет их.


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

Как-то странно, что изменение названия и способа запуска сразу превращет зло во благо. А?

L>Допустим, x $ y z => x (y z) можно сделать макросом.

L>А вот как сделать трансформацию map f . map g => map (f . g) макросом я не представляю.

Если есть код перебора выражений (а он есть), то достаточно найти нужный паттерн и заменить его другим.

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


Неубедительно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 00:23
Оценка:
Здравствуйте, deniok, Вы писали:

D>Rewrite Rules это способ явно записать указания компилятору для оптимизаций...


... позволяющий изменить до неузноваемости логику компилируемого кода. Да?

D> Это — открытый интерфейс оптимизатора конкретного компилятора, GHC, а не часть языка.


Так зачем тогда вообще говорить о частном решении?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 01:33
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Ты о чём вообще? Мы говорили о конкретной задаче и как она решается.

L>konsoletyper сказал, что не понимает устройство Parsec, я попытался дать основное, что в нём есть.
L>При чём тут ассемблер и структурное программирование?

При том, что сегодня ФВП полноцено не поддерживаются разве что в С++. И эти тирады несколько смешны.

VD>>Насколько я помню на свете есть очень мало языков в которых макросы достигли своего апогея. Все эти языки, как один, являются фунциональными (Лисп, Темлэйт Хаскель, Немерле). Так зачем нас грузить ФП?


L>И?


И не надо нам сотый раз про это. Лучше бы дал прямой ответ на вопрос товарища. Мне вот тоже не ясно где там простота.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 01:33
Оценка:
Здравствуйте, lomeo, Вы писали:

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


L>>>Без проблем! Меняем названия на EBNF-ные.


VD>>На EBNF есть ISO-стандарт. Вот кода вы на Хаскеле его повторить сможете (ну, процентов так на 99 хотя бы), тогда можено будет поговорить. А пока тебе прийдется признать, что решение на Хаскеле не полноценно.


L>А в чём проблема? Я же сказал, что вплоть до переименования там подходит практически всё. (Практически, потому что цитировать стандарт не смогу, а лезть для сверки не хочу.) Мало того, есть дополнительные расширения.


Твои примеры на Парсеке не совместимы с ЕБНФ. Там то и дело грязь разная появляется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 01:33
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Тебе не кажется, что "очень близок" на практике означет "непохож"?


L>Нет.


Ну, тогда я тебе отрою тайну — это так.

VD>>Понимаеш ли в чем дело?... На макросах можно получить как раз тот синтаксис что тебе требуется. И делается это проще.


L>Да, для создания синтаксиса макросы практически незаменимы. Я это уже говорил. И?


И... не надо использовать для решения задач плохо подходящие для них средства. Нужен новый синтаксис? Так и нефига заниматься пуританством. Макросы видите ли бяка... надо найти другой способ. Макрос — это самый прямой способ. Другие дают сложные, неуклюжие и медленные решения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 01:33
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Предлагаю запенисометрировать.


L>Не я. Времени катастрофически нет — сижу на твои посты отвечаю


Как говорят млодые и подвинутые "слив засчитан"...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 01:33
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Ой сорри. Я имел в виду ByteString (Duncan Coutts, Don Stewart)


L>Начать можно отсюда: Data.ByteString

L>Основная статья: Rewriting Haskell Strings

"Byte" означает то о чем я подумал, и Юникод Хаскелю незнаком?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 01:33
Оценка:
Здравствуйте, Klapaucius, Вы писали:

J>>Значит, Google и иже с ним — тоже прошлый век


K>Я всегда знал, что lomeo — человек далекого будущего.


Ага и мне порою кажется, что это бущущее из параллельной реальности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 01:33
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Кстати, хорошее предложение. Предлагаю пенисомерию. Сравниваем Parsec с лексером konsoletyper-а.

VD>>На входе небольшой проект C#, на выходе количество токенов каждого типа в его файлах.
VD>>Как предложение?

L>Неинтересно.


И я знаю почему...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: jazzer Россия Skype: enerjazzer
Дата: 27.07.07 05:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


J>>С европейскими приборами решений проблемы последнего куска три:

WH>А немного наклонить тарелку в голову не приходило?

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

А палочками ты просто цапаешь эти куски, не задумываясь.

И потом, "наклон тарелки" по отношению к программе... Мне навскидку аналогия не приходит.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 08:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>"Byte" означает то о чем я подумал, и Юникод Хаскелю незнаком?


Да.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 08:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Предлагаю запенисометрировать.


L>>Не я. Времени катастрофически нет — сижу на твои посты отвечаю


VD>Как говорят млодые и подвинутые "слив засчитан"...


Молодые и продвинутые хотят, чтобы я тратил время на совершенно неинтересные мне вещи?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 09:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Твои примеры на Парсеке не совместимы с ЕБНФ.


Меня не слышат, это минус.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: Константин Л. Франция  
Дата: 27.07.07 09:12
Оценка:
Здравствуйте, lomeo, Вы писали:

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


VD>>"Byte" означает то о чем я подумал, и Юникод Хаскелю незнаком?


L>Да.


А че так запущено?
Re[22]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 09:37
Оценка:
Здравствуйте, Константин Л., Вы писали:

VD>>>"Byte" означает то о чем я подумал, и Юникод Хаскелю незнаком?


L>>Да.


КЛ>А че так запущено?


Делают Data.CompactString.
А так — просто в самом GHC изначально было плохо с юникодом. Есть различные библиотеки для работы с ним, но это всё не то, разумеется.

В Haskell-prime (следующий шаг после Haskell98) обещали.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.07.07 10:20
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Принципиальная схема реализации отложенных вычислений в C++ изложена у Страуструпа в 3-м издании "Язык программирования C++" (Б.Страуструп, Язык программирования C++, спец. изд./Пер.с англ. — М.;СПб.:"Издательство БИНОМ" — "Невский Диалект", 2001г. — 1099с., ил.) Раздел 22.4.7 "Временные массивы, копирование и циклы", стр.743.


E>>Без шаблонов и Буста.


VD>Осталось без трепа изобразить решение.


Задача

x := alpha * p + omega * s;

, изложенная Klapaucius вот здесь
Автор: Klapaucius
Дата: 09.07.07
может быть решена, например, так:

#include <iostream>
#include <vector>

typedef std::vector< float > vector_t;

class delayed_scalar_by_vector_multiply_t
    {
    public :
        delayed_scalar_by_vector_multiply_t(
            float a,
            const vector_t & b )
            :    a_( a )
            ,    b_( b )
            {}

        float scalar() const { return a_; }
        const vector_t & vector() const { return b_; }

    private :
        float a_;
        const vector_t & b_;
    };

delayed_scalar_by_vector_multiply_t
operator*(
    float a,
    const vector_t & b )
    {
        return delayed_scalar_by_vector_multiply_t( a, b );
    }

class delayed_sum_of_scalar_to_vector_multiply_t
    {
    public :
        delayed_sum_of_scalar_to_vector_multiply_t(
            const delayed_scalar_by_vector_multiply_t & a,
            const delayed_scalar_by_vector_multiply_t & b )
            :    a_( a )
            ,    b_( b )
            {}

        void calc_and_store_to( vector_t & receiver ) const
            {
                if( a_.vector().size() != b_.vector().size() )
                    throw std::invalid_argument( "vectors must have the same size" );

                receiver.clear();
                receiver.reserve( a_.vector().size() );

                for( unsigned int i = 0, i_max = a_.vector().size();
                        i != i_max;
                        ++i )
                    receiver.push_back(
                            a_.vector()[ i ] * a_.scalar() +
                            b_.vector()[ i ] * b_.scalar() );
            }

    private :
        delayed_scalar_by_vector_multiply_t a_;
        delayed_scalar_by_vector_multiply_t b_;
    };

delayed_sum_of_scalar_to_vector_multiply_t
operator+(
    const delayed_scalar_by_vector_multiply_t & a,
    const delayed_scalar_by_vector_multiply_t & b )
    {
        return delayed_sum_of_scalar_to_vector_multiply_t( a, b );
    }

vector_t &
operator<<(
    vector_t & receiver,
    const delayed_sum_of_scalar_to_vector_multiply_t & sum )
    {
        sum.calc_and_store_to( receiver );
        return receiver;
    }

std::ostream &
operator<<(
    std::ostream & to,
    const vector_t & v )
    {
        for( unsigned int i = 0, i_max = v.size(); i != i_max; ++i )
            {
                if( i )
                    to << " ";
                to << v[ i ];
            }
        return to;
    }

void
main()
    {
        const int vector_size = 5;
        float a_src[ vector_size ] = { 1, 2, 3, 4, 5 };
        float b_src[ vector_size ] = { 0.5, 1.5, 2.5, 3.5, 4.5 };

        vector_t a( a_src, a_src + vector_size );
        vector_t b( b_src, b_src + vector_size );
        vector_t c;

        c << 0.0 * a + 2.0 * b;

        std::cout << c << std::endl;
    }


Оператор << используется вместо =, поскольку operator= должен быть нестатическим методом класса, а изменять стандартный std::vector нельзя.

Это демонстрация принципиальной схемы реализации отложенных вычислений в C++, полученная за 15 минут. Более сложные схемы могут быть получены при приложении несколько больших усилий. Только Nolite mittere margaeritas ante porcas!


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 11:48
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Если серьёзно, то я не понимаю — зачем это тебе. Вроде взрослый человек, а занимается ерундой.


Просто мы подходим к жизни по разному. Я конечно тоже хочу видить нечто красивое и изящьное, но рпи этом не отдаленное от реальной жизни. Так что самое изящное решение пойдет в топку если оно не эффективно. А уж если оно будет не очень изящно... Ну, а практика — критерий истины. Если будет одинаковый код на реальной задаче, то его можно будет сравнить как по быстродействию, так и по изаществу (да и по краткости). Без этого все наши разговоры будут пстыми словами приверженцев разных подходов. Можно конечно громко заявлять все что угодно, но это не более чем демагогия. Лично я уверен, что Хаскель не победит в подобном соревновании, так как в худшем (для его конкурентов) случае объем кода будет приблизительно таким же, а вот с понятностью (простым смертным) и быстродействием будут серьезные проблемы. Но это тоже пустые слова. Так как в Хаскеле я профан, то сам сделать подобные тесты не в состоянии (точнее не имею на это морального права).

L>Ну, потратишь ты моё и konsoletyper'а время (или только моё, а? может тогда пусть на входе небольшой хаскель проект будет, чтобы вам тоже не скучать . Узнаешь, что bytestring-парсек на 14.73% медленнее или наоборот быстрее, и что?!


Мне совершенно все равно как там работает bytestring. Но мне очень интересно сравнить Хаскель с его подходом к ДСЛ-естроению с Немерле на реальной (боевой, можнос сказать) задаче. А вот наши беседы мне становятся менее и менее интересны, и не потому, что я тебя не уважаю или стопроцентно уверен в своем мнении, а потому, что не несут рационального зерна. Это не более чем наши мнения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 11:48
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Т.е. DSL рассматриваются только в свете системы типов, остальные возможности языка выкидываем? Интересно...


Нет. Ты не верно понял. Речь шла о подходе в котором система типов задействуется как средсво компайлтайм-вычислений (базовый пример — С++).

К>А по поводу скалы, вот простенький пример отсюда :


К>

К> val res = db.executeStatement {
К> select fields ("name" of characterVarying(50)) from "person"
К> }


К>Подход, принятый тут (называемый авторами “zygotictype-directed growth”), описан здесь


ОК. Теперь давай глянем на более сложные примеры (по той же ссылке).
1:
 val query = (
      select fields ("first" of characterVarying(50)) 
        from "person" where ("last" in "person")=="'D.'"
    )
    val res1 = db.executeStatement {
      query
    }

    Console.print("Whose last name is simply 'D.'?")
    for(val i <- res1;
        val f <- i.fields) {
      Console.println(f.content.sqlString);
    }

Этот запрос в рантайме порождает следующий SQL:
SELECT first FROM person WHERE person.last = 'D.'

Что мы в нем видим?
А видим мы в нем:
1. Отсуствие проверок правильности запроса во время компиляции. Например, ("last" in "person") задает доступ к полю person.last в строковом виде. Понятно, что проверка правильностии имени поля и таблицы может быть произведена только во время исполнения. Причем в случае ошибки будет выдано не вполне внятное сообщение.
2. Доступ к полученым данным полям осуществляется через универсальную объектную систему (аля ADO.NET), что опять же приводит к тому, что в случае обращения к полям их прийдется идентифицировать по текстовым именам или индексам. Это так же переносит момент обнаружения ошибки в рантайм.
3. Код хотя и лучше чем прямое использовние JDBC\ADO.NET, но все же далек от совершенства.

Ну, а теперь сравним все это с тем как тоже самое можно было бы реализовать с помощью макросов http://nemerle.org/SQL_macros.
Вот как будет выглядеть тот же пример:
ExecuteReaderLoop("SELECT first FROM person WHERE person.last = 'D.'", db);
    WritwLine(first);

Не правда ли этот код выглядит луче?
Он еще и надежнее. И SQL и контроль типов параметров/полей осуществляется во время компиляции. Это гарантирует мгновенное обнаружение ошибок.

При этом, мы можем безболезненно использовать как списки полей, так и параметров. Например, можно заменить константный фильтр на фильтр берущийся из переменной:
def filterValue = ReadLine();
ExecuteReaderLoop("SELECT first FROM person WHERE person.last = filterValue", db);
    WritwLine(first);

При этом опять же будут контролироваться типы и если, скажем, person.last имеет не строковый тип, то во время компиляции нам об этом сообщит компилятор.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 12:47
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>При этом, мы можем безболезненно использовать как списки полей, так и параметров. Например, можно заменить константный фильтр на фильтр берущийся из переменной:

VD>
VD>def filterValue = ReadLine();
VD>ExecuteReaderLoop("SELECT first FROM person WHERE person.last = filterValue", db);
VD>    WritwLine(first);
VD>

Тысяча извинений... Параметр нужно пометить знаком доллара:VD>
def filterValue = ReadLine();
ExecuteReaderLoop("SELECT first FROM person WHERE person.last = $filterValue", db);
    WritwLine(first);
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 12:47
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Ты кстати на вопросы не ответил.


Какой?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 12:47
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Я говорил не о замене метапрограммирования чем-то там, а о повседневной необходимости в нем. Разницу чувствуешь? Объясняю. Где-то придется для "паттерна" конечного автомата заводить макрос, чтоб красиво было. А кое-где — это совершенно обычная задача, не требующая ни выверта, ни паттерна. Смотри:


G>switch_state( State, Message ) -> State( Message ).


G>state1( msg1 ) -> ...;

G>state1( msg2 ) -> ...;

G>И все. Никаких "через жопу автогеном".


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

В общем, не спорю, что сувать всюду макросы не нужно. Работая над интеграцией я применил макросы всего пару раз (хотя кода там не так мало было в проекте). Но за то даже один из этих раз дал мне такой прорывной эффект, что никакие хаскели (без метапрограммирования) и рядом не волялись. Например, я с помощь макросов накенерировал код инкрементального изменения (relocation) положений строк (Location-ов). При редактировании кода во многих случаях можно не перепарсивать файл, а просто поправить Location-ы. Получается куча шаблонного кода отличающегося разными нюансами плюс еще сами поля Location-ов нужно отследить. Вручную это было бы нереально. А с макросом вполне реально. Перебрал все типы, выявил те что содержат Location-ы, добавил в них код пересчета, вызвал их рекурсивно и вуаля. И таких примеров масса. А ведь это еще не ДСЛ-ли даже, а так мелкая втоматизация.

VD>>И твой тезис о том, что макросы что-то там нехорошее высвечивают сразу же бьет по Хаскелям и С++ с вдвойной силой. Бо это уже не только макросистемы, но еще и кривые и неудобные макросистемы.


G>Мой тезис говорит о том, что макросистемы — темная сторона силы. Настоящий джедай управится и без них. И все. Никуда он не бьет.


Мне кажется, что джадаи или просто не сталкиваются с некоторым классом здачь, или просто неэффективно их решают. Я уже все сказал о частоте применения макросов. Это сильный антибиотик который нужно применять редко но метко.

G>Вот видишь — наступил наконец редкий случай, когда мы с тобой согласны. Ну, почти .


Сдается мне, что эти случаи не так редки, просто глупо спорить кога мнения совпадают, а без спора и не видно, что они совпадают .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 12:47
Оценка:
Здравствуйте, lomeo, Вы писали:

L>1. Почему большую сложность реализации?


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

L> Инструмент использовать надо для того, для чего он предназначен.

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

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

L>2. Почему меньшие возможности?


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

L>3. Проблема производительности решается не только макросами, честное пионерское.


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

L>4. Э? Какие недостатки ты имеешь в виду?


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

VD>>Ну, и где здесь приемущества? Отсутсвие слова "макросы"? Ахринеть (с)!


L>Ты не знаешь, что у макросов есть недостатки, которых нет у штатных конструкций языка?


Нет. Не знаю. У них только два недостатка:
1. Их нужно писать и отлаживать (как любой код).
2. Они меняют семантику языка.

Оба недостатка будут у любого средства ДСЛ-естроения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 12:47
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>При том, что сегодня ФВП полноцено не поддерживаются разве что в С++. И эти тирады несколько смешны.


L>Ты с кем разговариваешь? Какое ФВП и С++?


Читай внимательнее. В прочем в С++ ФВП тоже конечно есть (или эмулируются). Просто дико неудобно с ними работать.

L>В сотый раз про что? Кому "вам"? Я отвечал на вопрос konsoletyper'а. Может быть ответил не то, что он спрашивал, но это судить ему. А ты на что отвечаешь? Причём тут макросы в апогее?

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

Говоря о Парске мы обнаружили проблемы в синтаксисе которые было предложено решать левыми средствами присутствующими только в одном компиляторе, а так же усомнились в производительности данного решения. В прочем я еще сильно сомневаюсь в том, что Парсер обеспечивает внятную диагностику грамматических ошибок (выявление неоднозначностей, например). На предложение создать реальный (простенький) пример мне было заявлено, что на это нет времени, так как иначе будет некогда отвечать на мои сообщения. Почему-то мне кажется, что время на создание теста должно было бы уйти куда меньше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 13:26
Оценка:
Здравствуйте, eao197, Вы писали:

Пояснил бы суть решения...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 13:56
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>1. Почему большую сложность реализации?

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

Нуу, это надо конкретные случаи рассматривать.

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


Ну да, чего мы опять эту тему обсасываем?

L>>3. Проблема производительности решается не только макросами, честное пионерское.

VD>Вот только макросы позволяют решать ее без шаманства.

Сильно сомневаюсь, что только.

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


Вроде тут говорили не о синтаксисе, а о DSL.

L>>Ты не знаешь, что у макросов есть недостатки, которых нет у штатных конструкций языка?


VD>Нет. Не знаю. У них только два недостатка:

VD>1. Их нужно писать и отлаживать (как любой код).
VD>2. Они меняют семантику языка.

VD>Оба недостатка будут у любого средства ДСЛ-естроения.


Штатные конструкции меняют семантику? Или ты что то другое хотел сказать?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 13:56
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Ты кстати на вопросы не ответил.


VD>Какой?


Там несколько:

1. "Изменение синтаксиса и вычисление во время компиляции — это да. Это область макросов, но при чём тут DSL?" (ну, сейчас уже можно и не отвечать)

2. "Что такое выкрутасы с системой типов Хаскеля? Вот мы тут с konsoletyper про Parsec говорили. Это выкрутасы?" (до сих пор не знаю о чём идёт речь)

3. "Где монады при использовании Парсека?" Это к вопросу о простоте.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 13:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Мне совершенно все равно как там работает bytestring. Но мне очень интересно сравнить Хаскель с его подходом к ДСЛ-естроению с Немерле на реальной (боевой, можнос сказать) задаче. А вот наши беседы мне становятся менее и менее интересны, и не потому, что я тебя не уважаю или стопроцентно уверен в своем мнении, а потому, что не несут рационального зерна. Это не более чем наши мнения.


ОК. Понимаю, тебе интересно. Мне не очень -- просто в силу того, что знание это никакой пользы для меня иметь не будет. Может быть очень маленькую. А вот сил я затрачу массу на написание лексера языка, с которым я не работаю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 14:01
Оценка:
Здравствуйте, c-smile, Вы писали:

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


CS>


CS>Да пожалуйста:

CS>http://terrainformatica.com/sciter
CS>http://terrainformatica.com/tiscript
CS>http://c-smile.sourceforge.net/

Хм. Это не ДСЛ-и. Это ты реализовывал вполне себе стандарный и универсальный скриптовый язык.

CS>Да ты понимаешь... для нового человека в команде много чего учить приходится. Библиотеки , термины, предметную область...

CS>И очень сильно сомневаюсь что самодельный language extension содержит при том достаточно документации для освоения.

Дык, а в чем разница с библиотеками? Учить прийдется так же. Но зато потом будет проще ичить код. И ошибок будет меньше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 14:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Говоря о Парске мы обнаружили проблемы в синтаксисе которые было предложено решать левыми средствами присутствующими только в одном компиляторе,


Ты запутался, одно дело синтаксис, EBNF, другое дело ByteString, который включается через Rewrite Rules только в GHC и Hugs кажется.

VD>а так же усомнились в производительности данного решения.


Эх!

VD>В прочем я еще сильно сомневаюсь в том, что Парсер обеспечивает внятную диагностику грамматических ошибок (выявление неоднозначностей, например).


Пример неоднозначности дай -- я проверю. А то я не понимаю, что это. Бэктрекинг? Если да, то есть try.

-- попытка раз
someKeyword = string "someKeyword"
identifier  = many1 letter
someExpr    = someKeyword <|> identifier -- сломается на "someIdentifier"

-- попытка два
someKeyword = string "someKeyword"
identifier  = many1 letter
someExpr    = try someKeyword <|> identifier -- на "someIdentifier" пройдёт identifier.


Что касается диагностики, то есть <?>:

spaces = skipMany space <?> "white space"


Оно?

VD>На предложение создать реальный (простенький) пример мне было заявлено, что на это нет времени, так как иначе будет некогда отвечать на мои сообщения. Почему-то мне кажется, что время на создание теста должно было бы уйти куда меньше.


Для меня — больше. Мне надо переписать Parsec на ByteString, поглядеть на синтаксис языка С# и написать для него лексер. Причём то, для чего всё это делается — мне совершенно не интересно.

Чувствую придётся всё таки мне переписать Parsec на ByteString и написать какой нибудь простой лексер.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 17:02
Оценка:
Здравствуйте, lomeo, Вы писали:

L>2. "Что такое выкрутасы с системой типов Хаскеля? Вот мы тут с konsoletyper про Parsec говорили. Это выкрутасы?" (до сих пор не знаю о чём идёт речь)


Откровенно говоря, для более детального обсуждения было бы неплохо:
1. Иметь реализации одинаковых грамматик на обсуждаемых системах парсинга (ведь мы уже говорим не совсем о Хаскеле или Немерле, а об ДСЛ-ях созданных на их базе).
2. Краткое описание принципов реализации и других деталей.

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

Так что может все же лучше взять более менее законченный пример (может по проще, но все же реальный) и реализовать его двумя способами. Далее описать, что и где нужно установить чтобы можно было поиграться с ним и тогда уже обсудить конкретику. А?

L>3. "Где монады при использовании Парсека?" Это к вопросу о простоте.


Про монады не знаю. Думаю, речь шла "в общем". Уж больно много выкртасов в Хаскеле через них протаскивается.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 17:02
Оценка:
Здравствуйте, lomeo, Вы писали:

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


L>>>1. Почему большую сложность реализации?

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

L>Нуу, это надо конкретные случаи рассматривать.


Согласен. В данном случае это впечатление создавшееся при просмотре того на что давали ссылки в "Деларативном программировании".

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


L>Ну да, чего мы опять эту тему обсасываем?


Дык мы же тему обсуждаем. Сабж то глянь...

L>>>3. Проблема производительности решается не только макросами, честное пионерское.

VD>>Вот только макросы позволяют решать ее без шаманства.

L>Сильно сомневаюсь, что только.


Опять же бессмысленный разговор.

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


L>Вроде тут говорили не о синтаксисе, а о DSL.


А чем определяется ДСЛ в первую очередь? Ну, можно семантику добавить. Один фиг, в общем-то.

VD>>Нет. Не знаю. У них только два недостатка:

VD>>1. Их нужно писать и отлаживать (как любой код).
VD>>2. Они меняют семантику языка.

VD>>Оба недостатка будут у любого средства ДСЛ-естроения.


L>Штатные конструкции меняют семантику? Или ты что то другое хотел сказать?


А язык Парсека оказывается рассматривается как штатный синтиаксис? Ты действительно смотришь на грамматику как на набор комбинаторов?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 17:28
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Пример неоднозначности дай -- я проверю. А то я не понимаю, что это. Бэктрекинг? Если да, то есть try.


Ну, не знаю. Парсер то какого типа получается? LL(k) или там еще что?

Ну, вот классика для LL(k):
Modifiers      := "public" | "private" | "protected";
Method         := Modifiers ident "(" [ ident (", " ident)* ] ")" "{" ... "}"
AbstractMethod := Modifiers ident "(" [ ident (", " ident)* ] ")" ";"


L>Что касается диагностики, то есть <?>:


L>
L>spaces = skipMany space <?> "white space"
L>


L>Оно?


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

L>Для меня — больше. Мне надо переписать Parsec на ByteString, поглядеть на синтаксис языка С# и написать для него лексер. Причём то, для чего всё это делается — мне совершенно не интересно.


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

L>Чувствую придётся всё таки мне переписать Parsec на ByteString и написать какой нибудь простой лексер.


Да фиг с ним с байтсрингом для начала бы можно и попроще. Неоптимальности потом можно подправить. Хотя бы будет на что смотреть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.07.07 07:45
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А чем определяется ДСЛ в первую очередь? Ну, можно семантику добавить. Один фиг, в общем-то.


Приближенностью к предметной области. Это вовсе не обязательно синтаксис.

VD>А язык Парсека оказывается рассматривается как штатный синтиаксис? Ты действительно смотришь на грамматику как на набор комбинаторов?


Знаешь, не задумывался об этом. Когда как, наверное. Но я имел в виду именно "изменение семантики". Это всё таки Хаскель, так что на грамматику, выраженную на Parsec, иногда смотрю как на комбинаторы. Т.е. как на сущности первого порядка. Это позволяет, например, использовать их в выражениях:

вместо
variable = do
    x <- identifier
        return (Var x)


пишу
variable = liftM Var identifier


и это читается (мне) естественно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.07.07 07:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Так что может все же лучше взять более менее законченный пример (может по проще, но все же реальный) и реализовать его двумя способами. Далее описать, что и где нужно установить чтобы можно было поиграться с ним и тогда уже обсудить конкретику. А?


Эх, ну, давай У вас ещё был JSON. Там писать совсем ничего, да и у вас он уже, насколько я помню, написан.
Кстати, спросить хотел. konsoletyper'а парсер пишется в отдельном файле? Это не встроенный в Немерле язык или что? Можно о его организации чуть чуть — это что то вроде изменения лиспового ридера?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.07.07 08:18
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, не знаю. Парсер то какого типа получается? LL(k) или там еще что?


Да, для lookahead (например, твои примеры) используется try.

VD>Вряд ли. Речь идет о сообщениях при компиляции о том, что в грамматике есть неоднозначность или другая ошибка. Плюс интересно что за сообщения выдает конечный парсер когда ему дают текст с ошибками (не соответствующий грамматике).


Нет, компилятор неоднозначности не найдёт. Ты же о компиляторе Хаскеля? Не думаю, что он умеет определять, что в строках "public", "private" и "protected" все слова начинаются на одну букву

Сам же парсер выдаёт либо сообщение о несработавшем комбинаторе (если поставить явный <?>). Либо говорит о том, что ожидается то-то, а найдено то-то.

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


Так у С# грамматика должна быть не маленькая верно?

VD>Да фиг с ним с байтсрингом для начала бы можно и попроще. Неоптимальности потом можно подправить. Хотя бы будет на что смотреть.


Ясно. Я думал, тебя производительность интересовала в первую очередь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 30.07.07 09:04
Оценка:
CS>>Да пожалуйста:
CS>>http://terrainformatica.com/sciter
CS>>http://terrainformatica.com/tiscript
CS>>http://c-smile.sourceforge.net/

VD>Хм. Это не ДСЛ-и. Это ты реализовывал вполне себе стандарный и универсальный скриптовый язык.


а что, DSL как-то по другому устроены?
Люди, я люблю вас! Будьте бдительны!!!
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 30.07.07 09:09
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

CS>>>Да пожалуйста:

CS>>>http://terrainformatica.com/sciter
CS>>>http://terrainformatica.com/tiscript
CS>>>http://c-smile.sourceforge.net/

VD>>Хм. Это не ДСЛ-и. Это ты реализовывал вполне себе стандарный и универсальный скриптовый язык.


BZ>а что, DSL как-то по другому устроены?


Ну всёж они ведь domain-specific, а не general purpose (ну и скриптовость тоже вещь не обязательная имхо)
Re[26]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.07.07 09:34
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

L>>Ты запутался, одно дело синтаксис, EBNF, другое дело ByteString, который включается через Rewrite Rules только в GHC и Hugs кажется.


BZ>в hugs нет rewrite rules — нахрена они там?


Ух, это я прогнал.

L>>Чувствую придётся всё таки мне переписать Parsec на ByteString и написать какой нибудь простой лексер.


BZ>если не ошибаюсь, это один из GSOC проектов этого года


Э-э-э, а там какие-то сложности?
Вместо CharParser написать свой (+ все комбинаторы над ним, разумеется), для этого State для GenParser сделать либо независимым от списка токенов, т.е. с возможностью использования любой коллекции, ну или сам State сделать классом, а не типом.

Кстати, уже что нибудь есть в этом проекте? Есть где почитать?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: BulatZiganshin  
Дата: 30.07.07 10:11
Оценка:
VD>В общем, не спорю, что сувать всюду макросы не нужно. Работая над интеграцией я применил макросы всего пару раз (хотя кода там не так мало было в проекте). Но за то даже один из этих раз дал мне такой прорывной эффект, что никакие хаскели (без метапрограммирования) и рядом не волялись. Например, я с помощь макросов накенерировал код инкрементального изменения (relocation) положений строк (Location-ов). При редактировании кода во многих случаях можно не перепарсивать файл, а просто поправить Location-ы. Получается куча шаблонного кода отличающегося разными нюансами плюс еще сами поля Location-ов нужно отследить. Вручную это было бы нереально. А с макросом вполне реально. Перебрал все типы, выявил те что содержат Location-ы, добавил в них код пересчета, вызвал их рекурсивно и вуаля. И таких примеров масса. А ведь это еще не ДСЛ-ли даже, а так мелкая втоматизация.

а достаточно ли ты хорошо знаешь хаскел, чтобы это утверждать? это как раз типичная задача на generic programming, которое в хаскеле цветёт бурным цветом (даже я смог насчитать десяток различных средств для него, а ведь я так, мелкий пользователь)

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

data Salary = Salary Double

то это делается одной строчкой:

gmap (\Salary x -> Salary (x*1.1))

в общем и целом, generic программирование обеспечивает автоматическую навигацию по любым контейнерам с организацией обработки только интересующих нас частей информации. основные алгоритмы — gmap, отображающий структуру данных в изоморфную ей, gfold, собирающий информацию (скажем, сумму всех зарплат или список номеров кабинетов), gunfold, конструирующий структуру данных (скажем, при десериализации), gzip, обрабатывающий параллельно два объекта с одинаковой структурой

а наиболее известная статья в этой области — "Scrap your boilerpate!", т.е. "выкиньте ваш шаблонный код!" — как будто написана специально для тебя


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

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

на Немерле, насколько я понял, макросы писать проще, но ситуации, когда их приходится использовать, точно так же высвечивают недостатки языка (и вообще всех языков этой группы). например, в хаскеле можно определять управляющие стурктуры — это всего лишь high-order функции, и они пишутся, используются, типо-порверяются, и передаются куда угодно как самые обычные функции. в немерле, С или лиспе это макросы, имеющие иной способ описания и не проверяющие типы своих аргументов
Люди, я люблю вас! Будьте бдительны!!!
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 30.07.07 10:19
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Пояснил бы суть решения...


просто операции +, * и т.д. создают в памяти структуру, описывающую вычисляемое выражание, а собственно вычисление происходит по спец. команде. в точности то же, что делают lazy языки на уровне самой реализации
Люди, я люблю вас! Будьте бдительны!!!
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 30.07.07 10:28
Оценка:
L>Нет. По сути — разное. На макросах можно вообще целую кучу всего написать, сам говоришь, что они "могут делать все что им угодно с кодом проекта". Рулезы более специфичное решение, возможно, его можно повторить на макросах, возможно, удастся создать удобную форму для записи этих рулезов, но это не значит, что рулезы и макросы по сути одно и то же.

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

кстати, также можно смотреть и на макросы Немерле. в этом отношении понятно, что макросы лучше жёстко зашитого в компилятор кода (хотя в средствах диагностики они и проигрывают), но хуже возможности, доступной на уровне языка
Люди, я люблю вас! Будьте бдительны!!!
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 30.07.07 11:21
Оценка:
Здравствуйте, VladD2, Вы писали:

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


L>>Ой сорри. Я имел в виду ByteString (Duncan Coutts, Don Stewart)


L>>Начать можно отсюда: Data.ByteString

L>>Основная статья: Rewriting Haskell Strings

VD>"Byte" означает то о чем я подумал, и Юникод Хаскелю незнаком?


не хаскелю, а байтовым строкам. интересно, ты вообще хоть что-нибудь читаешь из всех ссылок, что тебе приводят?
Люди, я люблю вас! Будьте бдительны!!!
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.07.07 11:23
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

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


Может быть, но это уже философский спор о терминах
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.07.07 13:27
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Эх, ну, давай У вас ещё был JSON. Там писать совсем ничего, да и у вас он уже, насколько я помню, написан.

L>Кстати, спросить хотел. konsoletyper'а парсер пишется в отдельном файле? Это не встроенный в Немерле язык или что? Можно о его организации чуть чуть — это что то вроде изменения лиспового ридера?

Это вопрос для konsoletyper-а, конечно. Насколько я знаю у него есть два варианта. Один с внешним файлом грамматики (был написан ранее), а второй с макросом. Второй вариант это чистый DSEL. Первый — нет. Но оба варианта используют немерловые варианты (алгеброические типы) для представления граматических элементов. Это и позволяет от делить формальную грамматику от прикладного кода.

Что касается ридеров и т.п., то в них просто нет необходимости, так как макрос — это полноценная программа которая может делать все что делает обычная программа. В том числе читать из файлов и писать в файлы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.07.07 13:46
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это вопрос для konsoletyper-а, конечно. Насколько я знаю у него есть два варианта. Один с внешним файлом грамматики (был написан ранее), а второй с макросом. Второй вариант это чистый DSEL. Первый — нет. Но оба варианта используют немерловые варианты (алгеброические типы) для представления граматических элементов. Это и позволяет от делить формальную грамматику от прикладного кода.


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

2konsoletyper (если читаешь) — а как у тебя DSEL выглядет в коде немерле? можно пример?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.07.07 14:25
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Это вопрос для konsoletyper-а, конечно. Насколько я знаю у него есть два варианта. Один с внешним файлом грамматики (был написан ранее), а второй с макросом. Второй вариант это чистый DSEL. Первый — нет. Но оба варианта используют немерловые варианты (алгеброические типы) для представления граматических элементов. Это и позволяет от делить формальную грамматику от прикладного кода.


L>То, что я видел было только во внешнем файле .bnf кажется, отсюда и вопрос. Насчёт json-а ты не ответил — это пример совсем маленький если тебя интересует запись в Parsec -- могу нарисовать.


Откровенно говоря я не знаю что такое json. Но наверно пойдет.

L>2konsoletyper (если читаешь) — а как у тебя DSEL выглядет в коде немерле? можно пример?


Грамматика была в виде глобального метаатрибута. Что-то типа:
[assembly: BNF(lexer
  {
      Поперли := описывать | правила;
        ...
    })]
[assembly: BNF(parser
  {
      Поперли := описывать | правила;
        ...
    })]


При этом изменение грамматики автоматически перестраивает генерируемые алгеброические типы, так что сразу доступен комплит-ворд и диагностика ошибок (без какой либо добполниетльной роботы по этому поводу).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.07.07 14:34
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>просто операции +, * и т.д. создают в памяти структуру, описывающую вычисляемое выражание, а собственно вычисление происходит по спец. команде. в точности то же, что делают lazy языки на уровне самой реализации


А насколко это универсальное решение?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.07.07 14:34
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

VD>>Хм. Это не ДСЛ-и. Это ты реализовывал вполне себе стандарный и универсальный скриптовый язык.


BZ>а что, DSL как-то по другому устроены?


Ага. Иначе бы они вообще нужны не были бы. Любой GPL (язык общего назначения) можно было бы счиать DSL-ем.

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

К тому же GPL-и слишком гибки и их ползователи сталкиваются с проблемой самовредительства. DSL-и же на против сужают рамки допуастимого и тем самым уберегают пользователей от ошибок.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 30.07.07 14:49
Оценка:
BZ>>просто операции +, * и т.д. создают в памяти структуру, описывающую вычисляемое выражание, а собственно вычисление происходит по спец. команде. в точности то же, что делают lazy языки на уровне самой реализации

VD>А насколко это универсальное решение?


уточни вопрос
Люди, я люблю вас! Будьте бдительны!!!
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 30.07.07 14:53
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Хм. Это не ДСЛ-и. Это ты реализовывал вполне себе стандарный и универсальный скриптовый язык.


BZ>>а что, DSL как-то по другому устроены?


VD>Ага. Иначе бы они вообще нужны не были бы. Любой GPL (язык общего назначения) можно было бы счиать DSL-ем.


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


VD>К тому же GPL-и слишком гибки и их ползователи сталкиваются с проблемой самовредительства. DSL-и же на против сужают рамки допуастимого и тем самым уберегают пользователей от ошибок.


вопрос был в том, почему опыт в реализации "стандарный и универсальный скриптовый язык" делает ошибочными утверждения относящиеся к DSL. кроме того, по-моему, DSL вовсе не обязан быть узким языком. скажем, Lua используемый в игре для скриптования ботов — вполне себе пример DSL. имхо их отличает только то, что реализация языка является только частью общей решаемой задачи, тогда как для колмпилятора это единственная решаемая задача. с этой точки зрения компилятор delphi, встроенный в среду разработки — это тоже DSL
Люди, я люблю вас! Будьте бдительны!!!
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 30.07.07 14:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Откровенно говоря я не знаю что такое json. Но наверно пойдет.


Да лёгкая замена xml-ю. JavaScript Object Notation

Там, кстати, есть решение на Хаскеле, только что то низкоуровневое. Лексер то могли и наворовать.
Сейчас попробую нарисовать.

Минусы именно этого примера — то, что там нет выражений. Т.е. я тебе не смогу показать как в parsec используются таблицы выражений, задаются приоритеты, операции и т.д.

L>>2konsoletyper (если читаешь) — а как у тебя DSEL выглядет в коде немерле? можно пример?


VD>Грамматика была в виде глобального метаатрибута. Что-то типа:


Прикольное решение. А в виде чего тогда приходит на макрос BNF параметр после lexer/parser внутри фигурных скобок?
Строка? Или уже разобранное лексером от Немерле? Если второе, то разобранное в каком виде? Идентификатор/символ? Можно ли там использовать внешние функции? Можно ли правила использовать снаружи? (последние два вопроса — это насколько правила first-order).

VD>При этом изменение грамматики автоматически перестраивает генерируемые алгеброические типы, так что сразу доступен комплит-ворд и диагностика ошибок (без какой либо добполниетльной роботы по этому поводу).


Не понял, как он ловит ambiguity?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 30.07.07 15:26
Оценка:
Здравствуйте, konsoletyper, Вы писали:

L>>Так в том то и дело, что макросы не надо эмулировать, если язык позволяет обойтись без них.


K>Дык, а чем, скажем, шаблоны C++ хуже макросов? Я так понимаю,


K>

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


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


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

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

Короче, макросы и раные там навороченные шаблоны конечно крутая штука для шифрования исходного кода и чесания левой пяткой за правым ухом, только на практике не нужная. Думаете, почему в большинстве современных языков нет макросов? В 70-х годах вот были популярны развитые макросистемы. Сейчас — нет, потому что нафиг не нужны. Рынок, так сказать, голосует.
Re[5]: Являются ли макросы свидетельством недостаточной выра
От: Gaperton http://gaperton.livejournal.com
Дата: 30.07.07 15:56
Оценка:
Здравствуйте, VladD2, Вы писали:

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


G>>Я говорил не о замене метапрограммирования чем-то там, а о повседневной необходимости в нем. Разницу чувствуешь? Объясняю. Где-то придется для "паттерна" конечного автомата заводить макрос, чтоб красиво было. А кое-где — это совершенно обычная задача, не требующая ни выверта, ни паттерна. Смотри:


G>>switch_state( State, Message ) -> State( Message ).


G>>state1( msg1 ) -> ...;

G>>state1( msg2 ) -> ...;

G>>И все. Никаких "через жопу автогеном".


VD>Вообще-то уже через жопу и уже автогеном. Ты ведь с автоматами вручную копаться стал. Понятно, что паттерн-матчинг тут хоршее подспорье, но я бы предпочел работать с EBNF или другим ДСЛ-ем.


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

Есть масса самых разных задач, где встречается КА — например, связанных с реализацией сетевых протоколов. Так что не через жопу и не автогеном. Программеру, который под каждый случай разработки КА будет свое языковое расширение или ДСЛ писать, довольно быстро коллеги отстрелят то, что ему танцевать мешает.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 30.07.07 18:18
Оценка:
K>К сожалению, сейчас совсем нет времени, так что макрос поддерживает только генерацию лексера. На работе завал. А вот теперь только-только от ICFP отошёл и опять на работе завал Вообще, проблема именно в нехватке времени. Никаких особых технических проблем нет. В своё время поддержку генерации лексера я сделал за пару дней. Если найдётся пара дней, сделаю поддержку парсера. Дело там нехитрое — AST уже есть готовое, надо по нему грамматику и LR-таблицы получить, а по таблицам — сгенерить класс. Последнее — 99% всего, что нужно сделать.

а чем это лучше lex/yacc?
Люди, я люблю вас! Будьте бдительны!!!
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 30.07.07 18:26
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>а чем это лучше lex/yacc?


Тем, что не надо таскать за собой постоянно файл со спецификацией и постоянно перегенерировать лексер/парсер. Тем, что в VS во время редактирования грамматики сразу подчёркиваются ошибки в ней. Тем, что после редактирования грамматики в остальном коде (теоретически) должны подчёркиваться те места, которые стали ошибочными.

Ну, кроме этого в lex/yacc код смешивается со спецификацией, что, ИМХО, не есть хорошо. Я попытался решить эту проблему. В результате, получается действительно понятная грамматика и понятный и короткий код, в декларативном стиле.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 30.07.07 22:23
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Короче, макросы и раные там навороченные шаблоны конечно крутая штука для шифрования исходного кода и чесания левой пяткой за правым ухом, только на практике не нужная. Думаете, почему в большинстве современных языков нет макросов? В 70-х годах вот были популярны развитые макросистемы. Сейчас — нет, потому что нафиг не нужны. Рынок, так сказать, голосует.

Наверное я программы писать не умею... ибо мне постоянно попадаются задачки которые без кодогенератора не решить... вот буквально недавно написал кодогенератор который парсит ~12К кода и генерит еще ~70К (из которых примерно 44К вызовы сишных макросов те в конце концов кода получается еще больше).
Внутри есть алгоритм со сложностью O(N^4)... На данный момент N == 19 но будет рости по ходу добавления функциональности.
И делать ручками то для чего нужен алгоритм четвертой степени при малейших изменениях исходных деклараций мне мягко говоря не хочется. Особенно при том что машина это делает за доли секунды и без ошибок.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 31.07.07 05:10
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Какой ambiguity?


"ab" | "aa"

Будет ли ошибка при компляции макроса?

Насчёт смешивания — это ещё вопрос, хорошо это или плохо. Хотя для лексера может особого смысла и нет.
Но я бы не отказался определять правила не только с помощью жёстко забитых значков.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 31.07.07 05:37
Оценка:
Здравствуйте, lomeo, Вы писали:

L>"ab" | "aa"


L>Будет ли ошибка при компляции макроса?


А с чего это она должна быть? Даже в случае:

AA = "aa"
AB = "ab"


Не будет неоднозначности. А неоднозначности вида:

subst Letter = U_Ll | U_Lu | U_Lt | U_Lm | U_Lo;
Identifier = Letter+;
DoKeyword = "do";
IfKeyword = "if";
...


решает в пользу последних правил.

L>Насчёт смешивания — это ещё вопрос, хорошо это или плохо. Хотя для лексера может особого смысла и нет.

L>Но я бы не отказался определять правила не только с помощью жёстко забитых значков.

А с помощью чего ещё?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 31.07.07 08:26
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>А с чего это она должна быть?


А. Я так Влада понял, что у тебя это определяется.

L>>Насчёт смешивания — это ещё вопрос, хорошо это или плохо. Хотя для лексера может особого смысла и нет.

L>>Но я бы не отказался определять правила не только с помощью жёстко забитых значков.

K>А с помощью чего ещё?


Комбинаторов, которые можешь задавать сам.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 31.07.07 12:06
Оценка:
Здравствуйте, lomeo, Вы писали:

K>>А с чего это она должна быть?


L>А. Я так Влада понял, что у тебя это определяется.


А как вообще может нормальный генератор такого не определять?

K>>А с помощью чего ещё?


L>Комбинаторов, которые можешь задавать сам.


А смысл? Можно пример, когда это удобно?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 31.07.07 12:41
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>А как вообще может нормальный генератор такого не определять?


В смысле? Не понял, так ты на стадии компиляции это бракуешь?

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

Modifiers      := "public" | "private" | "protected";
Method         := Modifiers ident "(" [ ident (", " ident)* ] ")" "{" ... "}"
AbstractMethod := Modifiers ident "(" [ ident (", " ident)* ] ")" ";"


Или у тебя парсер всегда LL(k)? Если да, то это вроде как неэффективно.

L>>Комбинаторов, которые можешь задавать сам.


K>А смысл? Можно пример, когда это удобно?


Ну как же. Сокращение дублирования, как всегда. В моём примере, например, есть комбинатор commaSep, применяемый к правилу и означающий, что это правило повторяется N раз, разделяясь запятыми, простые комбинаторы типа brackets, означающее, что правило, к которому оно применяется ищется между скобками и т.д.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 31.07.07 13:11
Оценка:
Здравствуйте, lomeo, Вы писали:

L>В смысле? Не понял, так ты на стадии компиляции это бракуешь?


Имеется в виду Error handling?

L>Вот пример Влада. Я так понял, что парсер должен здесь обеспечивать "внятную диагностику грамматических ошибок".


L>
L>Modifiers      := "public" | "private" | "protected";
L>Method         := Modifiers ident "(" [ ident (", " ident)* ] ")" "{" ... "}"
L>AbstractMethod := Modifiers ident "(" [ ident (", " ident)* ] ")" ";"
L>


L>Или у тебя парсер всегда LL(k)? Если да, то это вроде как неэффективно.


Конечно, нет. Парсер — всегда LALR(1). Но на вход ему поступают лексемы а не символы.

K>>А смысл? Можно пример, когда это удобно?


L>Ну как же. Сокращение дублирования, как всегда. В моём примере, например, есть комбинатор commaSep, применяемый к правилу и означающий, что это правило повторяется N раз, разделяясь запятыми, простые комбинаторы типа brackets, означающее, что правило, к которому оно применяется ищется между скобками и т.д.


Возможно, это будет реализовано в будущем.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[23]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 31.07.07 13:36
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Имеется в виду Error handling?


Да нет, я тоже сначала про это думал. В общем, то имелось в виду именно LL(k)
Проехали.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 31.07.07 13:38
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Действительно странно. Вроде как все языки программирования у нас тьюринг-полные. Я вот ни разу такой задаси не встречал. Может, поделишься задачкой, наконец? А то все говорите, говорите...


Хочешь я поделюсь? Последние года четыре у меня без кодогенерации не обходится ни одни проект. А ты оценишь и скажешь нужно это или нет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 31.07.07 15:07
Оценка:
Здравствуйте, IT, Вы писали:

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


G>>Действительно странно. Вроде как все языки программирования у нас тьюринг-полные. Я вот ни разу такой задаси не встречал. Может, поделишься задачкой, наконец? А то все говорите, говорите...


IT>Хочешь я поделюсь? Последние года четыре у меня без кодогенерации не обходится ни одни проект. А ты оценишь и скажешь нужно это или нет.


Конечно хочу. Только сразу предупреждаю — если ты макросами перформанс наигрываешь, то без профайлера я не смогу сказать, нужно оно или нет. Сам понимаешь. А вот если ты приведешь нечто, результирующее в заметном сокращении кода... Вот тут будет интересно.
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 31.07.07 16:34
Оценка:
Здравствуйте, Gaperton, Вы писали:

IT>>Хочешь я поделюсь? Последние года четыре у меня без кодогенерации не обходится ни одни проект. А ты оценишь и скажешь нужно это или нет.


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


Перформанс, конечно, тоже. Как же без этого? В частности для обхода тормозов рефлекшина. Но это действительно не самое интересное.

Гораздо более интересный пример можно найти здесь. Общая идея состоит в том, что для выполнения наиболее "интеллектуальной" работы достаточно описать сигнатуру метода:

public List<Customer> GetCustomerListByName(string @firstName, string @lastName);

Далее начинается в чистом виде monkey's job. В моём случае в качестве обезъянки выступает генератор, которому это с одной стороны не надоедает, с другой он не ошибается.

В дополнение к этому, я могу одним движением закешировать вызов этого метода:

[Cache(MaxMinutes = 10)]
public List<Customer> GetCustomerListByName(string @firstName, string @lastName);

и залогировать:

[Log, Cache(MaxMinutes = 10)]
public List<Customer> GetCustomerListByName(string @firstName, string @lastName);

Аспекты тоже будут догенертрованы в метод.

Ещё одно частое применение:

public abstract class Customer : EditableObject
{
    public abstract string FirstName { get; set; }
    public abstract string LastName  { get; set; }
}

Подробности здесь
Автор: IT
Дата: 07.02.06
. Этот вопрос я задавал немерлистам, гыгыгы, миллион сообщений назад. Кстати, похожая проблема возникает при использовании WPF.

Есть и другие случаи применения кодогенерации, но они скорее относятся к экзотическим. Здесь я перечислил лишь то, что используется повседневно.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 01.08.07 08:15
Оценка:
BZ>у меня в одной программе 48 вариантов кода генерятся именно на шаблонах. вот небольшой кусочек кодогенератора:

наверно, я не совсем ясно написал: приведённый кусок генерит 2*2*3=12 вариантов кода, плюс ещё одна функция с 4-мя вариантами выбора Coder — вот и выходят 48 вариантов. при этом MatchFinder в приведённом примере определяется многократным применением шаблонов, трансформирующих один из базовых MatchFinder — вот и получается, что комбинаторная сложность достигается линейным размером кода
Люди, я люблю вас! Будьте бдительны!!!
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 01.08.07 10:59
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>а темплейты не подойдут?

Много что у меня генерится темплейтами.
Но вот как ими сгенерить оптимальные цепочки для преобразования цветов (так чтобы у компилятора были шансы не сдохнуть от нехватки памяти) я не придумал.
В любом случае генератор гораздо проще и быстрее.

BZ>язык-то хоть C++?

Да.

BZ>у меня в одной программе 48 вариантов кода генерятся именно на шаблонах. вот небольшой кусочек кодогенератора:

Я так тоже умею.
Но в данной задаче не получилось.
Ибо O(N^4) для шаблонов С++ смерть.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 15:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Но это не главная засада.

WH>Проблема в том что мне в любой момент может понадобится преобразовать из одного цветового пространства в другое.
WH>И писать N^2 преобразований мне мягко говоря не хочется.
WH>Тем болие что большинство из них сводятся к преобразованию через цепочку пространств.
WH>Вот я и задал основные преобразования, назначил им веса и остальное сгенерил.

Насколько я не разбираюсь в обработке изображений, преобразование из одного цветового пространства в другое сводится к простому линейному преобразованию в 3 или 4-х мерном пространстве. у = Ах. По крайней мере для RGB <-> YCrCb это так.

Если все преобразования являются линейными операторами, их композиция делается тривиально. Надо матрицы перемножить. Нет?
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 01.08.07 15:41
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Если все преобразования являются линейными операторами, их композиция делается тривиально. Надо матрицы перемножить. Нет?

Нет. Есть не линейные преобразования. Например возведение в степень 2.2 и обратно.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 16:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


G>>Если все преобразования являются линейными операторами, их композиция делается тривиально. Надо матрицы перемножить. Нет?

WH>Нет. Есть не линейные преобразования. Например возведение в степень 2.2 и обратно.

И много таких — нелинейных? Кстати, с нелинейными — я что-то не понимаю — простая композиция инлайн-функций для описания преобразования почему не работает?
Re[24]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 01.08.07 16:17
Оценка:
Здравствуйте, IT, Вы писали:

IT>У run-time кодогенерации тоже есть свои козявки. Приходится использовать абстрактные классы, которые к тому же всегда должны быть публичные. Классы, которые не генерируются, но для которых что-то генерируется тоже должны обязательно быть публичными. Мелочь, а неприятно.

?? Для чего нужны абстрактные классы?

Мой любимый Tapestry в Java, например, использует кодогенерацию для работы с POJO (Plain Old Java Objects) — причем не требует никаких абстрактных классов (хотя в первых версиях библиотеки требовал из-за несовершенства кодогенератора).

А еще есть runtime bytecode instrumentation.
Sapienti sat!
Re[23]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 01.08.07 16:37
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>И много таких — нелинейных?

Хватает.

G>Кстати, с нелинейными — я что-то не понимаю — простая композиция инлайн-функций для описания преобразования почему не работает?

Работает. И именно ее я и использую. Вот только написать и поддерживать несколько сотен этих самых композиций ручками мне мягко говоря влом.
Задача тупая, объемная, требует большого внимания к мелочам и легко алгоритмизируемая. И именно на таких задачах компы по сравнению с людьми рулят.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: Иванков Дмитрий Россия  
Дата: 01.08.07 16:40
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Алгоритм Флойда — Уоршела О(N^3) если нужны только растояния. Мне же нужны сами пути. И если я не разучился считать то изменения которые запоминают пути делают алгоритм О(N^4).


Как N^4?

0) D(i, j) — Floyd
N^3
1) F(i, j) = k | exists E(k, j) & D(i, j) == D(i, k) + D(k, j)
(N^2) * N
2) P(i, j) = P(i, F(i, j)) append F(i, j)->j
(N^2) * N
Re[24]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 16:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

G>>И много таких — нелинейных?

WH>Хватает.

Хватает кому? Скажи плз в цифрах в сравнении с линейными.

G>>Кстати, с нелинейными — я что-то не понимаю — простая композиция инлайн-функций для описания преобразования почему не работает?

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

Пардон?

transform1( transform2( transform3( x ) ) )

Это писать и поддерживать — в лом? А можно поинтересоваться — почему?

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


И как ты ее алгоритмизируешь? В чем проблема-то — ты так и не описал самой задачи.
Re[24]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 16:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

Кажется, понятно.

У тебя каждое преобразование работает в своем цветовом пространстве. (класс со свойством "пространство")

У тебя есть картинка, которая тоже находится в своем цветовом пространстве. (класс со свойством "пространство")

Тебе надо наложить на картинку серию преобразований.

Цветовое пространство описываем классом с двумя функциями — преобразования в и из одного базового цветового пространства. Которое всегда одно и то же, например, RGB.

Функция преобразования из произвольного в произвольное пространство конструируется как композиция двух таких преобразований — "в" и "из".

Собственно, все. Можно сделать чтобы работало как в статике, так и в динамике. Без макросов. Где у нас подвох?
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 01.08.07 16:59
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


Пример пожалуйста.

G>>валяйте, давайте сюда пример, и я покажу, как его сделать без макросов и паттернов. Мне хватит паттерн-матчинга, атомов, и первоклассных функций.


VD>Хватит, или сможешь решать задачи компактнее, быстрее и порождая более производительный код? Если говорить о "хватит" в общем-то С для любой задачи хватит. Вот только паттерны от этого не исчезнут. Они просто будут строиться на базе ФВП и паттернматчинга.


Приведи мне пример паттерна, который будет строиться на базе ФВП и паттернматчинга, и покажи, как ты его макросом обернешь.
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 01.08.07 17:13
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Хватает кому? Скажи плз в цифрах в сравнении с линейными.

Примерно 50/50.
Но в любом случае необходим контроль компилятора над типами цветов.
Иначе в случае опечатки артефакты ловить задолбаешься.

G>Это писать и поддерживать — в лом? А можно поинтересоваться — почему?

По тому что таких цепочек СОТНИ. Я нарвался на комбинаторный взрыв с которым справится не получается.
И при добавлении нового пространства и/или преобразования есть не нулевая вероятность что гдето можно срезать углы.
Те нужно просмотреть все цепочки и поправить их.
Это занимает очень много времени.
А мне хитромудровывернутые алгоритмамы писать надо, а не обезьяней работой заниматься.

G>И как ты ее алгоритмизируешь?

Написал поиск кратчайших путей из каждого пространства до каждого.

G>В чем проблема-то —

В тонне ручной работы.

G>ты так и не описал самой задачи.

Гм. Вроде тут
Автор: WolfHound
Дата: 31.07.07
описал.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 01.08.07 17:22
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Собственно, все. Можно сделать чтобы работало как в статике, так и в динамике. Без макросов. Где у нас подвох?

Подвох в том что базового пространства нет.
И завести его без потери точности и эффективности невозможно.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 01.08.07 17:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>?? Для чего нужны абстрактные классы?


Если ты определяешь абстрактное свойство или метод, которое собираешься сгенерировать в рантайм, то класс должен быть абстрактным. По крайней мере в .NET.

C>А еще есть runtime bytecode instrumentation.


Это аналог emit'a?
Если нам не помогут, то мы тоже никого не пощадим.
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 01.08.07 17:59
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Индустрия имела макросы в далеких 70-х.


Ну-ка, поподробнее об этом. Первый раз такое слышу.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 01.08.07 18:40
Оценка:
Здравствуйте, Gaperton, Вы писали:

IT>>В этом смысле да. Но в том же немерле синтаксис атрибутов является лишь одним из форм макросов.


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


Давай. Итого, ты не против макросов, если синтаксически они выглядят как атрибуты или обычные методы. Но ты категорически против синтаксических макросов. Я правильно понимаю?

G>Я тоже никак не могу понять, почему ты думаешь, что я любое захардкоженное языковое расширение считаю хорошим, а любое сделанное на макросах — плохим. Мне как, его пользователю, вообще пофигу, на чем оно сделано. Мне главное, чтобы 1) их было поменьше, и 2) они были хорошо документированы.


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

G>Я не хочу иметь дело с языком класса PL/1, который умел делать все, и поддерживал абсолютно все на уровне языка, да еще быть лишенным мануала. А если вы не хотите городить второго PL/1, и его лавры дают, так сказать, покой, — так объясните еще раз — зачем нужны меняющие синтаксис макросы?


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

Вообще, я пока не разделяю твоих опасений по поводу PL/1. Всё это пока не более чем домысла. Насколько это будет или не будет реальной проблемой покажет только время и практика.

G>Пользователю языка, и языкового расширения — части языка все равно, как они сделаны, на макросах, или нет. Дело в другом — реальная необходимость писать языковые расширения настолько редка (при нормальном языке), что мне лично пофигу, имеет язык макросистему или нет.


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

G>Это последнее, на что я обращу внимание при выборе языка.


Дело конечно твоё. Я использую много генерируемого кода, поэтому для меня довольно важно насколько язык/платформа поддерживает средства метапрограммирования и насколько эти средства высокоуровневы.

G>Что пользователю не все равно — так это встречать недокументированные языковые расширения самоделкиных, сделанные на каждый чих. Это — плохо. Это — убивает maintainability.


Maintainability в большей степени убивается не плоходокументированными макросами или методами, а развесистой и запутанной логикой, в которой немешано всё в одну кучу. Особенно, если метод, сохраняющий что-либо где-либо назвать LoadSomething. Макросы же наоборот делают код чище за счёт повышения декларативности. К тому же, сегодня нет средств для создания библиотек паттернов. Библиотеку классов создать можно, а вот паттерны можно описать только в книжке. Макросы позволяют наконец-то разрабатывать библиотеки паттернов.

G>А для редких случаев вполне сгодятся тулы вроде яка с лексом.


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

G>Индустрия имела макросы в далеких 70-х. И отказалась от них вместе с ассемблерами и языками-монстрами вроде PL/1 — с появлением простых и понятных языков высокого уровня.


Я не уверен в том, что макросы имела именно индустрия. Отдельные исследовательские проекты возможно. Но насчёт всей индустрии я бы не стал утверждать. Вообще, востребованность инструмента напрямую зависит от сложности вхождения в него. Если сложность вхождения в те макросы была запредельной, то результат вполне закономерный.
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 01.08.07 20:46
Оценка:
Здравствуйте, IT, Вы писали:

C>>?? Для чего нужны абстрактные классы?

IT>Если ты определяешь абстрактное свойство или метод, которое собираешься сгенерировать в рантайм, то класс должен быть абстрактным. По крайней мере в .NET.
Так определяй конкретное свойство — а в рантайме генерируй классы-аксессоры (вместо тупого использования reflection'а).

C>>А еще есть runtime bytecode instrumentation.

IT>Это аналог emit'a?
Нет. Это ты загружаешь класс, и прямо при его загрузке происходит его инструментация. Например, у меня прямо так в рантайме вставляются хуки для системы безопасности. В JBoss в JBossCache инструментация используется для прозрачного кэширования сложных объектов (http://www.onjava.com/pub/a/onjava/2005/11/09/jboss-pojo-cache.html?page=3).

В Java для этого полно инструментов, в .NET знаю только: http://rail.dei.uc.pt/project_overview.htm
Sapienti sat!
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 01.08.07 21:28
Оценка:
Здравствуйте, Cyberax, Вы писали:

IT>>Если ты определяешь абстрактное свойство или метод, которое собираешься сгенерировать в рантайм, то класс должен быть абстрактным. По крайней мере в .NET.

C>Так определяй конкретное свойство — а в рантайме генерируй классы-аксессоры (вместо тупого использования reflection'а).

Ты не внимательно читал. Такое тоже делается, но в данном случае речь о другом. А именно, имея декларацию свойства или метода необходимо сгенерировать его тело. Т.е. в датааксессоре мне достаточно просто объявить метода, а генератор доделает остальное. Такой метод должен быть абстрактным.

C>В Java для этого полно инструментов, в .NET знаю только: http://rail.dei.uc.pt/project_overview.htm


Понятно. Судя по ссылки для .NET у них пока тоже ничего нет. Чем-то подобным занимаются в MS Research в проекте феникс, но пака это только рисёч.

В принципе, это всё можно делать и без инструментации. Достаточно объявлять нужные методы виртуальными и создавать объекты специальными методами, которые будут генерировать всё что нужно. В BLToolkit такое поддерживается (см. аспекты Log, Cache), но класс всё же должен быть абстрактным. Хотя это ограничение введено чисто искуственно, т.к. смысла в неабстрактном классе просто нет, а ошибки могут возникать.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 02.08.07 02:26
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>Если ты определяешь абстрактное свойство или метод, которое собираешься сгенерировать в рантайм, то класс должен быть абстрактным. По крайней мере в .NET.

C>>Так определяй конкретное свойство — а в рантайме генерируй классы-аксессоры (вместо тупого использования reflection'а).
IT>Ты не внимательно читал. Такое тоже делается, но в данном случае речь о другом. А именно, имея декларацию свойства или метода необходимо сгенерировать его тело. Т.е. в датааксессоре мне достаточно просто объявить метода, а генератор доделает остальное. Такой метод должен быть абстрактным.
Я понял. В Java это делается так — объявляешь обычные get/set-методы, а в рантайме он их тебе или строит наследника с переопределенными методами (они виртуальные) или прямо инструментируют сам класс, добавляя нужную функциональность в get/set.

C>>В Java для этого полно инструментов, в .NET знаю только: http://rail.dei.uc.pt/project_overview.htm

IT>Понятно. Судя по ссылки для .NET у них пока тоже ничего нет. Чем-то подобным занимаются в MS Research в проекте феникс, но пака это только рисёч.
IT>В принципе, это всё можно делать и без инструментации. Достаточно объявлять нужные методы виртуальными и создавать объекты специальными методами, которые будут генерировать всё что нужно. В BLToolkit такое поддерживается (см. аспекты Log, Cache), но класс всё же должен быть абстрактным. Хотя это ограничение введено чисто искуственно, т.к. смысла в неабстрактном классе просто нет, а ошибки могут возникать.
В Java стараются сейчас все делать конкретными классами — их можно легко использовать при тестировании (mock objects и все такое...).
Sapienti sat!
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 02.08.07 02:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В Java стараются сейчас все делать конкретными классами...

Java — суксь Немерля — the dest
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.08.07 02:42
Оценка:
Здравствуйте, IT, Вы писали:

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


C>>В Java стараются сейчас все делать конкретными классами...

IT>Java — суксь Немерля — the dest

От destiny?
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 02.08.07 02:49
Оценка:
Здравствуйте, IT, Вы писали:

C>>В Java стараются сейчас все делать конкретными классами...

IT>Java — суксь Немерля — the dest
Для Немерля есть IDEA?

Нет? Значит в сад!
Sapienti sat!
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: jazzer Россия Skype: enerjazzer
Дата: 02.08.07 02:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>В Java стараются сейчас все делать конкретными классами...

IT>>Java — суксь Немерля — the dest
C>Для Немерля есть IDEA?

Ты же был поклонником CodeBlocks & XRef, no?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 02.08.07 03:19
Оценка:
Здравствуйте, Курилка, Вы писали:

IT>>Java — суксь Немерля — the dest


К>От destiny?


Очепятался
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.08.07 05:11
Оценка:
Здравствуйте, IT, Вы писали:
IT>Очепятался
Нееет. Это не может быть случайным совпадением. Это новый термин
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 02.08.07 05:14
Оценка:
Здравствуйте, jazzer, Вы писали:

C>>>>В Java стараются сейчас все делать конкретными классами...

IT>>>Java — суксь Немерля — the dest
C>>Для Немерля есть IDEA?
J>Ты же был поклонником CodeBlocks & XRef, no?
Я вообще на всем пишу (С, С++, Java, C#, Python, Nemerle ). Просто лучшей IDE, чем IDEA я пока просто еще не видел.
Sapienti sat!
Re[26]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 02.08.07 10:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


G>>Собственно, все. Можно сделать чтобы работало как в статике, так и в динамике. Без макросов. Где у нас подвох?

WH>Подвох в том что базового пространства нет.
WH>И завести его без потери точности и эффективности невозможно.
В классе пространств, которые приводятся линейным преобразованием друг к другу (а это, как ты сказал, половина твоих преобразований), такое пространство, через которое ты будешь гнать цвет, в явном виде не нужно. Ты всегда получаешь прямое преобразование перемножением матриц, и потери эфективности и точности здесь не будет. А если ты воспользуешься оптимизированной библиотекой BLAS от Intel, и применишь 32-х битные float для компонент цвета (чего вполне достаточно) то у тебя будет чистый выигрышь в производительности (будет задействовано SSE). Это делается чисто и понятно — без макросов.

Для пространств, которые преобразовыватся нелинейно, достаточно описать одно преобразование в любое "линейное" цветовое пространство. Позволь мне усомниться в том, что у тебя сильно упадет точность при использовании линейного пространства как переходного и применении плавающей арифметики хорошей разрядности — ты можешь в конце концов задействовать и double — SSE замечаетельно работает и с ними.

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

Необходимости в макросах я тут не вижу. Почему должна просесть точность и производительность — тоже не понимаю. А вот то, что применение макросов — это переусложнение — это понятно.
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 02.08.07 14:02
Оценка:
G>Генерация — потому что ось представляла собой колоссальное количество макросов. Генерация состояла в том, что создавался пакет макровызовов с конкретными параметрами макросов. Для этого на компьютере была предустановлена минимальная система с транслятором-ассемблером (макроассемблером). Процесс генерации занимал несколько часов, потом ситему проверяли на работоспособность — та еще работа... Часто оказывалось, что параметры заданы не те или не так — не стыковались у некоторых макросов сочетания... И приходилось перегенерировать систему. Поэтому в системные программисты (а они как раз и занимались такой работой) старались брать людей, уже имевших опыт

это не синтаксические макросы (используемые для упрощения программирования), а система типа нынешнего configure
Люди, я люблю вас! Будьте бдительны!!!
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 02.08.07 14:56
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

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


BZ>это не синтаксические макросы (используемые для упрощения программирования), а система типа нынешнего configure


Это как раз синтаксические макросы. Речь идет о макроассемблере ЕС ЭВМ — великом и ужасном. Его "компилятор" с библиотеками занимал раза в полтора больше места, чем PL/1 (а это самый навороченный язык был). Про "С" в свое время говорили — это такая штука типа макроассемблера OS/360 — только переносимая?
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.08.07 08:20
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Если преобразования описываются матрицей (а если я не совсем позабыл соотв. раздел прикладной математики, то матрицей можно описать очень широкий класс аналоговых функций), то что мешает не преобразования делать в несколько шагов, а просто перемножить матрицы преобразований? При этом сами матрицы можно представлять на этапе перемножения со сколь угодно высокой точностью, это не скажется на производительности самих преобразований.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: . Великобритания  
Дата: 03.08.07 12:15
Оценка:
AndrewVK wrote:

> Учить, разумеется. ИМХО объяснить, что если в начале файла написано

> autogenerated, do not touch, то ни в коем случае этот файл не трогать
> совсем не сложно. В особо запущенных случаях можно для SVN скрипт
> написать, который запретит коммитить генерируемые файлы.
Обычно достаточно их в svn:ignore засунуть.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.08.07 12:27
Оценка:
Здравствуйте, ., Вы писали:

.>Обычно достаточно их в svn:ignore засунуть.


Ну, судя по всему, IT сгенерированные файлы таки в репозиторий запихал.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 03.08.07 14:20
Оценка:
Здравствуйте, AndrewVK, Вы писали:

.>>Обычно достаточно их в svn:ignore засунуть.


AVK>Ну, судя по всему, IT сгенерированные файлы таки в репозиторий запихал.


IT ничего никуда не пихал. У IT была студия, которая занималась этим как ей хотелось.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.08.07 22:00
Оценка:
Здравствуйте, IT, Вы писали:

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


А AVK всегда говорил, что студийная поддержка VCS — кака.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 03.08.07 23:12
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>А AVK всегда говорил, что студийная поддержка VCS — кака.


Какую MS туда воткнул, такая и была. Бывает ещё хуже. Например, p4.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 04.08.07 00:13
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Это так. У меня нет никакого желания что то тебе доказывать. Если тебе интересно мое мнение — я могу его пояснить, если интересно поспорить — я в этом участвовать не хочу. А то вон ваши молодые орлы уже подтянулись, только и ждут.


Мнение всегда интересно. А выводы скорее нет, чем да.

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


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

AVK>Ага. И в этом, как обычно, еще и главная пакость. И кодогенерацией, и макросами я увлекался намного раньше, чем вы начали махать флагом с буквой N.


Интересно какими же ты макросами увлекался намного раньше?

AVK>Только вот на моих задачах я вдоволь наелся и побочных эффектов. И эти эффекты совсем не в том, что кто то где то автогенеренный код поправил.


А в чём?

IT>> Особенно учитывая, что индустрии больше некуда расширяться "шире возможности'


AVK>Это ты зря. Возможностей масса. Мозгов не хватает. И в прямом и в переносном смысле.


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

IT>>Too big gun это только для Хэйлсберга. Ну и его последователей, конечно.


AVK>Ну а для последователей N, очевидно, нет. Ты что сказать то хотел?


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

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


AVK>Паттерн-матчинг в мейнстриме присутствует, но не в шарпе.


А где?

AVK>Лямбды в том же шарпе есть уже давно.


Лямб пока нет. Есть убожество, называемое анонимными делегатами. Но хотя бы это. Да и оно не сразу появилось. Но вот что радует, так это то, что всё таки появилось. Есть надежда, что может тому же Хейлсбергу придёт в голову ещё какая-нибудь идея вроде линка и в качестве побочного эффекта мы получим в языке паттерн-матчинг или те же макросы.

AVK>Ну а прочие полезные вещи ... Gaperton не зря на PL/1 намекал. Мейнстрим на нем весьма обжегся в свое время. Возможно, сейчас дуют на воду конечно, но тем не менее.


Думаю, ни тебе, ни Гапертону на PL/1 писать не приходилось. А мне немного довелось. PL/1 был редкостным говном сам по себе. Например, в нём, чтобы объявить рекурсивный метод нужно было слегка пошаманить. Бред, блин. Это в то время, когда уже во всю свирепствовал C, да и C++ с Паскалем были не самыми распоследними языками. Я как раз тогда, сравнивая PL/1 с Паскалем и C, долго удивлялся по поводу рекурсий и не мог понять в чём прикол, что тут такого сложного. PL/1 кроме кучи фич впитал в себя ещё и всю языковую дремучесть предков. Такое ощущение, что его делали не смотря в будущее, а постоянно оглядываясь, пока в конце концов у создателей не заклинило башку в положении 180 градусов глядя назад.

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

IT>>В 2002-2003-м, когда это происходило ещё сами учителя учились.

AVK>Ну а теперь?

А теперь учителя предали pre-compile time генерацию анафеме и живут в счастье со своими учениками и учениками учеников с run-time кодогенерацией, мечтая при этом о compile-time кодогенерации.

IT>> Мы пользовались VSS и студия сама решала что запрешать, а что нет.

AVK>Ну а теперь?

А теперь я пользуюсь хренью, которая на порядок хуже VSS. Называется перфорс.

IT>>Да ни фига. LCG появилось только в 2.0. Я тебе как специалист говорю.

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

Такое ощущение, что ты никогда не поддерживал кода, который может быть скомпилирован только одной версией единственного компилятора.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 04.08.07 00:29
Оценка:
Здравствуйте, IT, Вы писали:

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


Можно поподробней о преимуществах расширяемых парсеров?
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 04.08.07 01:04
Оценка:
Здравствуйте, mkizub, Вы писали:

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


M>Можно поподробней о преимуществах расширяемых парсеров?


Не совсем понял вопрос. Я не говорил о парсерах. Речь о расширяемых компиляторах. В частности, Немерле умеет в процессе парсинга расширять лишь список ключевых слов. И то, это скорее вопрос имплементации, чем идеологии. Расширение компилятора подразумевает не только и не столько парсинг, а скорее взаимодействие с компилятором во время всевозможных изврашений с AST.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 04.08.07 08:07
Оценка:
Здравствуйте, IT, Вы писали:

IT>Не совсем понял вопрос. Я не говорил о парсерах. Речь о расширяемых компиляторах. В частности, Немерле умеет в процессе парсинга расширять лишь список ключевых слов. И то, это скорее вопрос имплементации, чем идеологии. Расширение компилятора подразумевает не только и не столько парсинг, а скорее взаимодействие с компилятором во время всевозможных изврашений с AST.


Да, виноват, почему-то прочитал слово "парсер", хотя там было написано "компилятор".
Осталось только уточнить — речь идёт именно о компиляторах? Если да — то почему вы остановились именно на них, а не продолжили эту же идею на остальные инструменты разработки и исполнения программ?
Если у нас будет только компилятор расширяемый — то прости-прощай IDE, который превратится из ненешнего продвинутого инструмента в обычный редактор. А если мы включаем IDE в понятие "компилятор", то достаточно быстро приходим к тому, что расширения языка должны комплексно описывать изменения — и то, как его компилировать (извращаться с AST), и то, как его должен понимать IDE.
Далее, понятие компилятора в последнее время размывается, поскольку между исходным кодом и скомпилированными инструкциями CPU всё больше встаёт тень виртуальной машины, с её JIT компилятором или компиляцией при установке на конкретное железо, ОС и т.д. В сторону расширения VM вы как смотрите? Было-бы логично (по крайней мере — последовательно) иметь расширяемую VM, и по видимому, расширения VM могут описываться так-же, как и расширения компилятора (поскольку VM — это рантайм + компиляция из инструкций псевдо-процессора в инструкции hardware процессора). Там на горизонте виднеется ещё и расширяемость железа, но пока не будем трогать.

Так как вы считаете — расширять только компилятор, или весь набор средств разработки и исполнения программ?

PS Вопрос про расширяемые парсеры предполагал, что сам по себе парсер — это не очень-то большая часть компилятора (языка программирования), и его расширяемость не даёт больших бонусов, зато даёт ощутимые потери (вроде той-же проблемы с IDE). Расширяемость компилятора — даёт намного больше плюсов, но суть проблемы не меняется.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 04.08.07 11:40
Оценка:
Здравствуйте, IT, Вы писали:

IT>А теперь я пользуюсь хренью, которая на порядок хуже VSS. Называется перфорс.


А чем он не угодил? По мне так на порядок лучше VSS'а.
now playing: Misanthrop — Centrifuge
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 04.08.07 15:41
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Осталось только уточнить — речь идёт именно о компиляторах? Если да — то почему вы остановились именно на них, а не продолжили эту же идею на остальные инструменты разработки и исполнения программ?


Потому что речь идёт именно о языковых средствах. Если интересно пообсуждать IDE или VM, то это тоже можно сделать, но этот топик не об этом.

M>Если у нас будет только компилятор расширяемый — то прости-прощай IDE, который превратится из ненешнего продвинутого инструмента в обычный редактор. А если мы включаем IDE в понятие "компилятор", то достаточно быстро приходим к тому, что расширения языка должны комплексно описывать изменения — и то, как его компилировать (извращаться с AST), и то, как его должен понимать IDE.


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

M>Далее, понятие компилятора в последнее время размывается, поскольку между исходным кодом и скомпилированными инструкциями CPU всё больше встаёт тень виртуальной машины, с её JIT компилятором или компиляцией при установке на конкретное железо, ОС и т.д. В сторону расширения VM вы как смотрите? Было-бы логично (по крайней мере — последовательно) иметь расширяемую VM, и по видимому, расширения VM могут описываться так-же, как и расширения компилятора (поскольку VM — это рантайм + компиляция из инструкций псевдо-процессора в инструкции hardware процессора). Там на горизонте виднеется ещё и расширяемость железа, но пока не будем трогать.


Если я понимаю как можно сделать расширение компилятора, то как сделать расширяумую VM я без понятия. Если есть идеи, то можно обсудить.

M>Так как вы считаете — расширять только компилятор, или весь набор средств разработки и исполнения программ?


Пока мы говорим только о компиляторе.

M>PS Вопрос про расширяемые парсеры предполагал, что сам по себе парсер — это не очень-то большая часть компилятора (языка программирования), и его расширяемость не даёт больших бонусов, зато даёт ощутимые потери (вроде той-же проблемы с IDE). Расширяемость компилятора — даёт намного больше плюсов, но суть проблемы не меняется.


Это неверное утверждение. Как я уже сказал, интеграция Немерле со студией автоматически подхватывает все расширения. Есть определённые технические проблемы, которые решаемы, но принципиальных проблем нет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 04.08.07 15:41
Оценка:
Здравствуйте, EvilChild, Вы писали:

IT>>А теперь я пользуюсь хренью, которая на порядок хуже VSS. Называется перфорс.


EC>А чем он не угодил? По мне так на порядок лучше VSS'а.


Глючным плагином к студии.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.08.07 15:54
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>А теперь я пользуюсь хренью, которая на порядок хуже VSS. Называется перфорс.


EC>>А чем он не угодил? По мне так на порядок лучше VSS'а.


IT>Глючным плагином к студии.


Вот ведь, из-за какого-то там плагина обгадить приличную вещь.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 04.08.07 16:22
Оценка:
Здравствуйте, eao197, Вы писали:

IT>>Глючным плагином к студии.

E>Вот ведь, из-за какого-то там плагина обгадить приличную вещь.

Более пакостной поделки я не видел. При этом приличная или не приличная вещь сам перфорс меня уже не интересует. Плагин, кстати, той же конторы

И ещё, кстати. Смешно читать рекомендации разработчиков перфорса по эмуляции shared folders VSS. Типа, мы это не будем делать, т.к. считаем принципиально неправильным использовать shared folders, но если вам надо, то делайте так и так. Почему просто не сказать, мы это не будем делать, т.к. наша архитектура не рассчитана на такую фичу, но если вам надо, то делайте так и так
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 04.08.07 16:58
Оценка:
Здравствуйте, mkizub, Вы писали:

IT>>Потому что речь идёт именно о языковых средствах. Если интересно пообсуждать IDE или VM, то это тоже можно сделать, но этот топик не об этом.


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


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

M>VM имеет непосредственное отношение к языковым средствам, так как для того и была создана — как промежуточный уровень абстракции между языком и железом.


VM без разницы на каком языке был сгенертрован байт-код и с помощью каких расширений. Это как бы одна из основополагающих идей.

M>IDE и VM были упомянуты не для перевода стрелок и отвлечения внимания. Они имеют непосредственное отношение к макросам, о чём я и написал достаточно подробно. Если вы этого не видите и не хотите видеть — так бы и сказали, мол обсуждать не хочу.


Давай обсуждать, если очень хочется. Why not?
По-моему мнению VM не имеет никакого отношения к расширению компилятора. Т.е. вообще никакого. Продукт компиляции — это байт-код. Как он был получен это не важно. Я генертрую байт код вручную с помошью emit'а без всякой компиляции. Тем не менее VM на меня за это вовсе не в обиде.
Об IDE ниже.

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


M>Конечно это невозможно. Или мы о разных IDE.




M>Скажем, у нас есть "расшитрение" для enum типов, и их использования в выражениях и switch/case. Для case value мы бы хотели в IDE иметь автодополнение, которое предлагало бы список перечислымых значений из декларации enum.


Что такое "расширение" для enum типов? Это новый тип типов или новый enum?

M>Так вот, никаким образом этот тип автодополнения не появится автоматически из правил преобразования enum->class на уровне AST.

M>IDE уровня Eclipse или IntelliJ Idea понимает код, работает с ним на уровне семантики. Поэтому и является настолько удобным инструментом. А вы под IDE подразумеваете редактор+обработчик сообщений компилятора?

Я понимаю это как редактор + компилятор. Не секрет, что тот же Resharper включает в себя большую часть самописного компилятора C#. Фактически для IDE не нужна лишь последняя фаза кодогенерации. Остальное в ней присутствует в полный рост. Не думаю, что Idea и Eclipse в этом сильно отличаются. Что касается Немерле, то его интеграция с VS использует непосредственно сам компилятор. Соотвественно, если макрос, например, сгенертровал новый тип или метод в существующем типе, то он автоматически появится в списке интелисенс. Тоже самое касается новых ключевых слов.

IT>>Если я понимаю как можно сделать расширение компилятора, то как сделать расширяумую VM я без понятия. Если есть идеи, то можно обсудить.


M>Так я же написал — VM это рантайм плюс компилятор.


VM и компилятор напрямую никак не связаны.

M>Собственно говоря, после того как исходный код разобран (parsed & resolved), проверен на отсутствие ошибок — дальнейшая работа компилятора полностью автоматизирована (и представляет собой трансформацию дерева/графа), и может быть спокойно перемещена из source-to-bytecode компилятора в bytecode-to-native компилятор. Конечно, это самый первый уровень расширяемости VM, но у вас уже есть повод поразмышлять, если интересно.


Пофантазировать можно конечно. MS research работает над проектом Феникс, возможно это из этой серии.

IT>>Это неверное утверждение. Как я уже сказал, интеграция Немерле со студией автоматически подхватывает все расширения. Есть определённые технические проблемы, которые решаемы, но принципиальных проблем нет.


M>Расскажите мне о решении принципиальной проблемы изложенной выше. Как будет происходить пониание кода средой разработки на основании одних только правил преобразования AST, не говоря уже о расширениях вроде изменения системы типов.


Интеграция с VS использует сам компилятор. Т.е. исходный код проекта банально пропускается через компилятор и в результате IDE получает в своё распоряжение AST. В процессе компиляции выполняются в том числе и макросы. Соответственно, все сделанные ими изменения попадают в результирующее AST.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 04.08.07 19:04
Оценка:
Здравствуйте, mkizub, Вы писали:

IT>>VM без разницы на каком языке был сгенертрован байт-код и с помощью каких расширений. Это как бы одна из основополагающих идей.


M>Между языком и VM тоже нет принципиальной разницы. Можешь рассматривать байткод как некий язык программирования со специфическим синтаксисом.


Можно и так. Но в такой постановке это уже точно не относится к теме топика. Не то чтобы мне это было совсем не интересно, но намешав всё в одну кучу мы точно не придём ни к какому результату.

M>Этот процесс ничем не отличается от компиляции исходников OCaml в C. Они могут компилировать свои исходники в байткод для своей VM, а могут в исходный код на С.


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

M>Новый тип типов. Мне его удобно для примера пользовать, так как в Java изначально небыло enum-ов, и они реализуются сравнительно просто в виде "расширения", как трансформация AST (кодогенерация).


Понятно. Т.е. если я правильно понял, то enum в джаве представляет собой просто синтаксический сахар.

M>Теперь внимание — вопрос.

M>Каким образом из правил кодогенерации (трансформации AST) IDE сможет понять, что red, green, blue — это константы,

То что это константы следует из final. Правильно?

M>что автодополнение кода в case value должно выдавать список из red,green,blue, каким образом IDE узнает, что существуют только 3 варианта значения Color и что switch может иметь максимум эти 3 case-а и так далее.


В классе Color есть только эти три константы, соответственно показать мы можем только их.

M>Эти правила (что есть enum как понятие) — присутствуют в мозгах программиста. Трансформация AST — это применение этих правил, а не определение этих правил.


Для данного конкретного случая достаточно обучить IDE выдавать список констант определённых в классе. Вся информация для этого у нас есть в AST. То, что это именно enum знать совершенно не обязательно. В результате это будет работать не только для enum, а для любых вариантов данного паттерна.

M>Idea и Eclipse построены именно на понимании явовского кода, а не его формальном AST представлении.


И это очень плохо.

M>Кроме самого AST туда ещё много чего напихано. Именно поэтом миграция на Java 1.5 (в которой эти enum-ы появились, а так-же generics, autoboxing и прочее) заняла пару лет для IDE, уже после того, как компилятор был выпущен.


Не удивительно.

IT>>Пофантазировать можно конечно. MS research работает над проектом Феникс, возможно это из этой серии.


M>Приблизительно то-же говорят те, кто считает ненужным расширяемые компиляторы. Типа, "пофантазировать можно кончено". Вы их спрашиваете — как же они не видят полезности расширяемых компиляторов,


Нет, совсем не так. Они не просто не видят полезности, они яро протестуют. Большая разница.

M>а я так-же удивлён, почему ваша фантазия заканчивается на компиляторе.


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

IT>>Интеграция с VS использует сам компилятор. Т.е. исходный код проекта банально пропускается через компилятор и в результате IDE получает в своё распоряжение AST. В процессе компиляции выполняются в том числе и макросы. Соответственно, все сделанные ими изменения попадают в результирующее AST.


M>Как я написал выше, результирующее AST нам даёт очень мало, для понимания сути написанного. А если IDE не понимает сути написанного, то она превращается просто в редактор.


AST нам даёт всё что нужно. Возможно мы просто понимаем под AST разные вещи. Таже Idea наверняка производит некоторую трансляцию исходного кода в свои внутренние структуры. В Немерле исходный код преобразуется сначала в parsed tree, а затем в typed tree. Два этих дерева дают нам полную картину о структуре кода. Где, что, какие типы и т.п. Например, расположив курсор на ключевым словом while, которое является макросом, мы сможем наблюдать во что он раскрывается:

... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 04.08.07 20:45
Оценка:
Здравствуйте, AndrewVK, Вы писали:

IT>>Базовый уровень не изменяется. Мы не меняем компилятор, мы его расширяем.

AVK>Расширение это тоже изменение. Не меняем, это когда мы действительно не меняем грамматику языка.

Т.е. получается, что изменение грамматики плохо, потому что мы меняем базовый уровень. А базовый уровень плохо, потому что мы меняем грамматику языка. Понял.

AVK>Я крайне отрицательно отношусь к макросам, которые меняют синтаксис, и очень настороженно к макросам, которые пользуются синтаксисом существующим.


Т.е. негативно к макросам вообще.

IT>>Не вижу никаких проблем.

AVK>IT, еще раз — мне не интересно спорить. Поэтому мне все равно, что считаешь ты. Я высказываю свою точку зрения, ничего сверх того.
AVK>Я считаю иначе.

AVK, мне все равно, что считаешь ты. Мне интересны мотивы. В общем, похоже это и есть основной лейтмотив нашей беседы. Пора завязывать.

IT>> Не нужно было. Почему вы считаете, что наличие макросов в языке приведёт к тотальному увлечению ими я не понимаю

AVK>Потому что я вижу, что происходит с шаблонами на С++.

В самих по себе шаблонах C++ нет ничего плохого. Проблема в том, что для метапрограммирования в C++ используются побочные эффекты компилятора. Как следствие, маловразумительный, запутанный код. Код макросов Немерле представляет собой самый обычный стандартный код. Никаких побочных эффектов компилятора не используется. Всё в пределах дизайна языка.

AVK>>>Да были всякие разные типа Open C++. Но, как я предполагал, разговор скатывается во флейм.

IT>>Это не флейм.
AVK>Это именно он и есть. И чем дальше, тем его больше.

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

IT>>Это принципиальный вопрос. Одно дело, если ты с ними поигрался да и бросил. Другое — если ты использовал Open C++ в серьёзном проекте и твои утверждения о вреде макросов основываются не на домыслах, а на реальном опыте их применения.


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


Да тут нечего мерять. Если бы у тебя был реальный опыт использования Open C++, то нашлись бы и ответы. А так только одни намёки на всезнание. В общем, всё ясно.

IT>>Так это как раз и есть наша главная цель. Убрать частоповторяющуюся логику подальше,


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


О любой цене никто не говорит. Я тебе ещё раз могу повторить. За год я не написал ни одного макроса. Ещё раз повторить?

IT>> а в прикладном коде оставить максимум декларации. Почему тебя не пугает, например, что за вызовом метода Rsdn.Janus.Synchronizer.SyncForums остаётся много логики за кадром?


AVK>Потому что эта логика жестко ограничивается контрактом, причем контрактом явным. Могут быть, конечно, побочные эффекты. Но в случае макросов и с контрактом неясно, и с побочными эффектами может быть все очень непросто.


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

IT>>Это не проблема.

AVK>Это реальная проблема, которую я почувствовал на своей шкуре, когда возился с кодогенерацией.

Т.е. получается что ты вообще против кодогенерации. Я правильно понимаю?

IT>>А твоим обезъянкам так вообще по барабану.

AVK>Нет, и обезьянкам не по барабану. Но foreach — часть языка, и обезьянка не имеет права не разбираться хотя бы в базовых моментах foreach. Грубо говоря, обезьянка будет изучать foreach за свой счет, чтобы потом устроится на работу в качестве C# developer.

Обезъянкам по барабану. Им скажут foreach будут писать foreach, скажут forall будут писать forall. Впрочем, обезъянки меня интересуют в последнюю очередь. Слава богу, пока с ними плотно работать приходилось не часто.

AVK>>>SQL например. Или XSLT.

IT>>А... ну да. Нам как раз здесь не хватает именно такого замеса.
AVK>Тем не менее паттерн-матчинг в мейнстриме есть.

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

IT>>Начинается терминологический булшит?

AVK>Нет, просто поправил, уж больно глаза режет.

Ну тогда и я тебя поправлю. В спецификации языка это называется анонимными функциями.

IT>>И как ощущение от пережитого? Что тебя большего всего угнетало: обилие фич или дремучесть вообще?


AVK>Больше всего угнетало то, что крайне тяжело было читать чужой код, причем большей частью из-за обилия фич, которые мне неизвестны или известны плохо. Может, если бы я пописал на нем лет несколько, мне бы было все просто, но я столько не писал.


Да, нужно было почитать спецификацию языка. Это же по твоим словам очень помогает обезъянкам находить потом работу.

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


Короче, всё ясно. Обоснованных причин нелюбви тобой макросов мы похоже никогда не услышим. Как всегда, всё свелось к обвинению собеседника в разведении флейма вместо прямых ответов
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 04.08.07 21:03
Оценка:
Здравствуйте, mkizub, Вы писали:

M>final — это sealed, неизменяемая ссылка или значение.


readonly в C#.

M>А константы в яве — это числа, символы и прочее. В switch можно было использовать только int/char, а теперь и enum (но не в перемешку с int!!!) — константность эта семантическая, а с точки зрения JVM они не являются константами.


Я ещё раз хочу подчеркнуть. Я предпочитаю отделять мух от котлет, а языкы от VM.

M>enum-ы я привёл в качестве простого примера. Легко привести и более "продвинутые" примеры. Взять тот-же embedded SQL или GUI designer-ы.


Это не имеет отношения к языку. Точнее, IDE может использовать некий интерфейс с языком для генерации кода (CodeDOM в VS), но прямого отношения к языку эти фичи IDE не имеют.

M>В IDE, которая понимает SQL можно встроить дизайнер базы данных, auto-completition для embedded SQL.

M>В IDE, которая понимает GUI можно визуально строить диалоги, привязывать их к обработчикам событий и пр.
M>Наглядный пример — продукты Борланда. Дельфи и JBuilder имеют интегрированную поддержку SQL и GUI на уровне недоступном Nemerle как компилятору отдельному от IDE.
M>Аналогично MS Access и Visual Basic.
M>При этом дизайнер таблиц в Дельфи или Access — это полноценный язык программирования, только "визуальный", а не текстовый.

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

M>Вот именно. Надо обучить IDE. Обучим мы его конкретно enum-ам или целому классу подобных расширений — не суть важно. Я именно и говорю о необходимости обучения IDE тем расширениям, которые мы добавляем в компилятор. Тогда обученный IDE может интегрировать в единое целое и embedded SQL, и GUI designer, и редактировать комментарии в виде HTML/XML кода, и генерировать конфигурационные файлы (в формате XML, например) из настроек проекта и т.д. и т.п.


Ну и что тут не так? IDE нужно обучать взаимодействию со всеми этими вещами. С этим я не спорю. В частности IDE нужно будет обучить понимать расширения конкретного языка. Что не так?

IT>>Нет, совсем не так. Они не просто не видят полезности, они яро протестуют. Большая разница.


M>Они бы протестовали значительно меньше, если бы имели реальный опыт работы, и этот опыт показал полезность расширяемости компилятора. Плюс, эта полезность должна превышать потери. Возможно, их представления о потерях другие — для кого-то утрата GUI designer-а не представляет проблем, а для кого-то это ключевая фича инструмента. Полезность включает в себя много аспектов, вроде лёгкости освоения, типичных задач которые решал (и собирается решать) в своей жизни программист, качество поддержки и широта community и так далее.


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

IT>>AST нам даёт всё что нужно. Возможно мы просто понимаем под AST разные вещи.

M>Я не говорю о сегодняшнем дне, я говорю о завтрашнем.

Ну так с этого нужно было и начинать

M>Вы говорите о Nemerle, который работает только в рамках фиксированного набора AST узлов (и расширения компилятора строятся на композиции узлов) — это день сегодняшний.

M>А я говорю о расширяемом AST, где узел дополнительно описывает свою семантику, которая и служит как компилятору, так и IDE и VM, для работы с данным типом узлов — это день завтрашний.

Пока что это фантазии. Я бы даже сказал фантазёрство.

M>Мне кажется — это попытка перепрыгнуть пропасть в два прыжка.


Да хоть в три. Главное, что другая сторона отчётливо видна. То, о чём говоришь ты — это прыжок в туман, за которым может оказаться пустота.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 04.08.07 22:29
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>У тебя какая то странная спецификация.

AVK>C# Version 2.0 Specification, July 2005, page 6
AVK>

19.2 Anonymous methods


А, ну да, точно. Анонимный метод это:

delegate (int x) { return x + 1; }

а анонимная функция это:

x => x + 1



А что же тогда такое лямбда? Ты же говорил что это одна хрень.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 05:19
Оценка:
Здравствуйте, FR, Вы писали:

IT>>О любой цене никто не говорит. Я тебе ещё раз могу повторить. За год я не написал ни одного макроса. Ещё раз повторить?


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


Нет, это совсем другая мысль. Макросы мне не нужны для тех задач, которые я в данный момент решаю, потому что для этих задач всё что нужно уже есть. Будут новые задачи, будет новый необходимый набор решений. Но макросов на каждый чих (чего больше всего боятся мои оппоненты) не будет. Именно эту мысль я озвучил.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 09:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Нет, и обезьянкам не по барабану. Но foreach — часть языка, и обезьянка не имеет права не разбираться хотя бы в базовых моментах foreach. Грубо говоря, обезьянка будет изучать foreach за свой счет, чтобы потом устроится на работу в качестве C# developer.


Выделенное утверждение просто супер!
Зная этот базовый набор можно изучить любую библиотеку.
В случае макросов обезьянка не может их изучить за свой счёт. Следовательно издержки растут.
Я правильно понимаю твою позицию?
now playing: Extrawelt — Soopertrack
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 10:16
Оценка:
Здравствуйте, mkizub, Вы писали:

EC>>Я правильно понимаю, что для того, чтобы понять что делает макрос нужно довольно подробно представлять как устроено AST,

EC>>какие есть фазы компиляции, как AST может трансформироваться на каждой из них?
EC>>Т.е. при применении макроса с моим кодом может произойти практически любая трансформация?
EC>>Если так, то именно это людей и настораживает.
EC>>Потому как я применяя yield return точно знаю, что сделает компилятор и как это всё локализовано.

M>Свобода действий устрицы ограничена двумя состояними — открытой или закрытой раковиной. Именно это деалет поведение устриц столь понятным и надёжным. Увы, пока эти значительные преимущества не превратились в доминирование устриц как биологического вида, но природа работает над этим.


Расшифровываю свою мысль специально для юмористов: макросы повышают порог вхождения -> увеличивают стоимость разработки.
Если для более традиционных способов написания кода есть куча техник и практик, то с макросами всё не так радужно.
На данный момент это больше похоже на чёрную магию.
Безусловно, что в прямых руках и при наличии адекватной задачи это может быть лучшее средство.

P.S. Если состоянием устрицы можно управлять извне, то с помощью некоторого количества устриц можно производить вычисления.
now playing: Minilogue — The Leopard (Roel H Remix)
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 13:06
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Расшифровываю свою мысль специально для вас.


Расшифровка поскипана т.к. это понятно и без неё.
Можете привести какие-то из задач, которые вы решаете где макросы самое оно?
now playing: Calyx & Teebee — The Divide
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 13:24
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Можете привести какие-то из задач, которые вы решаете где макросы самое оно?


Чем сложнее программа, тем проще привести пример.
Вот я пишу компилятор (http://www.symade.org), я использую дерево узлов. Это дерево поддерживает версионность (одновременное существование нескольких версий дерева, возможность откатить изменения и т.д.), у него есть constraints (вроде того, что узел может иметь только одного родителя), мне нужен механизм интроспектирования дерева (вроде reflection — какие узлы обладают какими аттрибутами) и многое другое. Я написал систему трансформации AST, которая мне генерирует все необходимые дополнительные классы и методы. Объём сгенерированного кода в разы превышает объём вручную написанного кода, модификация алгоритмов (версионности, интроспекции) практически не требует изменения кода и так далее. Без этой системы генерации кода потребовалось бы раз в 100 больше man-month, я один этот код в принципе не смог бы написать и продолжать развивать. Объём "генератора" всего около 1000 строк, и объём дополнительного низкоуровневого кода (базовых классов) лишь около 2000 строк.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 14:19
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Зная этот базовый набор можно изучить любую библиотеку.


Теоретически — да. На практике — нет. Вот только если изучить любую библиотеку — не проблема, то тогда и с макросами проблем нет, потому, что макрос — это библиотечный класс, написанный на том-же языке что и любой другой библиотечный класс.
... << 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[34]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.08.07 16:04
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>В случае макросов обезьянка не может их изучить за свой счёт. Следовательно издержки растут.

EC>Я правильно понимаю твою позицию?

Вроде того. Только не "не может", а "не будет". Единственный шанс — если будет библиотека макросов очень широко используемая, типа boost.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.08.07 16:04
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Поскольку тогда таких средств композиции/декомпозиции кода как квазицитирование и паттерн-матчинг не существовало


http://en.wikipedia.org/wiki/Pattern_matching#History

History

The first computer programs to use pattern matching were text editors. At Bell Labs, Ken Thompson extended the seeking and replacing features of the QED editor to accept regular expressions. Early programming languages with pattern matching constructs include SNOBOL from 1962, NPL from 1977, and KRC from 1981. The first programming language with tree-based pattern matching features was Fred McBride's extension of LISP, in 1970.

... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 05.08.07 16:09
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>На самом деле макросов, как преобразований над AST, индустрия не имела никогда.

???????
LISP!

Я точно знаю, что квазицитирование в нем точно использовалось. А еще были кучи Лисп-подобных языков.
Sapienti sat!
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 16:14
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Доказательство по аналогии есть голая демагогия.


Это не доказательство, а повод для размышления.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 16:18
Оценка:
Здравствуйте, Klapaucius, Вы писали:

EC>>Зная этот базовый набор можно изучить любую библиотеку.


K>Теоретически — да. На практике — нет. Вот только если изучить любую библиотеку — не проблема, то тогда и с макросами проблем нет, потому, что макрос — это библиотечный класс, написанный на том-же языке что и любой другой библиотечный класс.


Если речь о том, что макрос чисто технически это просто класс, то это никак дело не менят.
Речь о другом.
Мне пока не встречались библиотеки, модифицирующие код, который я пишу (или может я просто не в курсе).
Макрос же совсем другое дело.
now playing: Extrawelt — Weich8
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 05.08.07 16:30
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Мне пока не встречались библиотеки, модифицирующие код, который я пишу (или может я просто не в курсе).

EC>Макрос же совсем другое дело.
В Java-мире такие библиотеки — достаточно распространенное явление. Только они работают обычно уже над байт-кодом скомпилированых классов.

Большинство Java-программистов стараются использовать такие библиотеки как можно меньше, так как ошибки в них находить и исправлять на порядок сложнее, чем в обычном коде.
Sapienti sat!
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 16:48
Оценка:
Здравствуйте, Cyberax, Вы писали:

EC>>Мне пока не встречались библиотеки, модифицирующие код, который я пишу (или может я просто не в курсе).

EC>>Макрос же совсем другое дело.
C>В Java-мире такие библиотеки — достаточно распространенное явление. Только они работают обычно уже над байт-кодом скомпилированых классов.

Ты говоришь об инструментировании байт кода?
Это всё-таки работает уровнем ниже — соответственно эффект не настолько значительный.
Насколько я знаю таким образом решаются очень узкие классы задач.
Видимо потому как куча семантической информации уже потеряна к моменту инструментирования.

C>Большинство Java-программистов стараются использовать такие библиотеки как можно меньше, так как ошибки в них находить и исправлять на порядок сложнее, чем в обычном коде.


Я их очень понимаю. Я бы использовал такие средства в самую последнюю очередь.
now playing: Jade — Bitch
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 17:52
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>http://en.wikipedia.org/wiki/Pattern_matching#History


А первым компьютерным (вычислительным) устройством были счёты.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 17:54
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Вы определитесь. А то ведь Nemerle и Haskell тоже к индустрии отношения не имеет.


Любезнейший, Вы меня с кем-то путаете. Где я говорил, что они опробированы индустрией?

M>А Dylan куда забыли? IMHO, по идеологии очень мало от него Nemerle ушло.


Dylan с Nemerle имеет очень мало общего. Начнем с того, что он динамически-типизированный, так что он на Схему больше похож (не синтаксически, конечно) чем на Немерле.
... << 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]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 05.08.07 17:54
Оценка:
Здравствуйте, AndrewVK, Вы писали:

K>>Поскольку тогда таких средств композиции/декомпозиции кода как квазицитирование и паттерн-матчинг не существовало

AVK>The first computer programs to use pattern matching were text editors. At Bell Labs, Ken Thompson extended the seeking and replacing features of the QED editor to accept regular expressions. Early programming languages with pattern matching constructs include SNOBOL from 1962, NPL from 1977, and KRC from 1981. The first programming language with tree-based pattern matching features was Fred McBride's extension of LISP, in 1970.[/q]

См. выделенное. Я говорил не про pattern-matching вообще — а про pattern-matching, как средство декомпозиции AST в макросистеме.
... << 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[36]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 18:33
Оценка:
Здравствуйте, IT, Вы писали:

IT>Тогда как ты можешь использовать библиотечные классы и их методы, если ты не знаешь точно, что они делают?

Думаю ты понимаешь о чём я, но делаешь вид, что нет: библиотечные классы и их методы ничего не делают с написанным мной кодом.

IT>Вообще, есть одна простая мысль, которую я уже неоднократно высказывал.

С поскипаной мыслью согласен.

Можешь привести примеры задач, стоящих перед тобой, которые требуют применения макросов?
Помимо приведённого ранее примера про DAL — там выглядит естественно.
Правда в свете LINQ необходимость этой фичи мне кажется менее востребованной.
now playing: Dom & Klute — Maximus
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 18:42
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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

Думаю в этой библиотеке самое сложное будет метод решения и возможно трики ускоряющие код.

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

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

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

Можно перефразировать это предложение? а то так и не понял его смысл.
now playing: Dom & Roland — Sanity
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 18:49
Оценка:
Здравствуйте, IT, Вы писали:

C>>Так ведь такой макрос почти бесполезен. А сложные макросы уровня реализации LINQ'а писать будет нааамного сложнее.


IT>Я разве утверждал обратное? Я лишь ответил на вопрос. Может быть не достаточно ясно? Но ты — молодец, безжалостно эту неясность искоренил


Ты считаешь, что реализовать LINQ на макросах было бы идеологически более правильно, чем хардкодить в язык?
Если да, то озвучь плюсы и минусы.
now playing: Dom & Roland — Sanity
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.08.07 18:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>А сложные макросы уровня реализации LINQ'а писать будет нааамного сложнее.


Как оказалось, LINQ макросами Nemerle вобще не реализуем без коррекции компилятора.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 19:01
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Как оказалось, LINQ макросами Nemerle вобще не реализуем без коррекции компилятора.


Что надо было докрутить в компиляторе?
now playing: Calyx & Ill.Skillz — Thru Your Eyes
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 19:09
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Как оказалось, LINQ макросами Nemerle вобще не реализуем без коррекции компилятора.


Это пока ещё не 100% факт. Но даже если это так, то изменения в компиляторе потребуются минимальные, чего не скажешь о реализации LINQ для C#.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.08.07 19:13
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Что надо было докрутить в компиляторе?


LINQ подразумевает неявное представление лямбды ввиде expression tree или генерации кода в зависимости от ожидаемого типа делегата, а немерлевые макросы вызываются только явно, по атрибуту, псевдофункции или ключевому слову. Все это осложняется extension methods.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 19:50
Оценка:
Здравствуйте, EvilChild, Вы писали:

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

EC>При использовании макросов эта библиотека сможет воздействовать на клиентский код гораздо более непредсказуемым способом, чем без них.

Библиотека не может воздействовать на пользовательский код, да. Но она может воздействовать на пользовательские данные и состояние системы в целом (для чего она и была написана). И это воздействие имеет всю полноту непредсказуемости. Например — библиотека работы с TCP/IP, вполне может поставить раком всё приложение, вроде его неработоспособности по причине таймаута в DNS, или как место через которое проникает злобный хакер и т.п.

Не думаю, что можно сравнить степень воздействия на программу библиотек и макросов. Библиотеки бывают большие и сложные, а макросы простые. Макросы обычно не пишут так, чтоб они воздействовали на произвольный код, а только на тот, который специально для них отмечен — ключевыми словами, аннотациями и пр. Вот AOP — это да, это полная диверсия. А нормальные макросы почти не отличимы от встроенных в язык средств.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 05.08.07 20:04
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Вот AOP — это да, это полная диверсия. А нормальные макросы почти не отличимы от встроенных в язык средств.


Мне казалось, что реализация AOP на макросах это самый прямой вариант. Это не так?
now playing: Posthuman — Lagrange Point
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 05.08.07 20:04
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Библиотека не может воздействовать на пользовательский код, да. Но она может воздействовать на пользовательские данные и состояние системы в целом (для чего она и была написана). И это воздействие имеет всю полноту непредсказуемости. Например — библиотека работы с TCP/IP, вполне может поставить раком всё приложение, вроде его неработоспособности по причине таймаута в DNS, или как место через которое проникает злобный хакер и т.п.

Вот только это все достаточно просто отлаживается многочисленными существующими инструментами. А вот для макросов у нас отладчиков пока нормальных нет.
Sapienti sat!
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 20:22
Оценка:
Здравствуйте, EvilChild, Вы писали:

M>>Вот AOP — это да, это полная диверсия. А нормальные макросы почти не отличимы от встроенных в язык средств.


EC>Мне казалось, что реализация AOP на макросах это самый прямой вариант. Это не так?


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

С появлением мета-данных (аннотаций) AOP может использоваться значительно более конструктивно. Его можно "натравить" только на операции со специально помеченными данными (полями, классами). С появлением определяемых пользователем операций (операторов в выражениях, statements, инициализаций и пр.) AOP мог бы совсем войти в конструктивное русло. Стать аналогом макроса, альтернативным способом определения как трансформировать дерево. Ему бы ещё отрезать возможность переопределять уже определённые операции (а стандартные мы считаем уже определёнными), и чтоб воздействие пойнткатов было явно отмечено (аннотациями, а не регэкспами имён функций и полей) — станет нормальным инструментом.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 05.08.07 20:29
Оценка:
Здравствуйте, mkizub, Вы писали:

M>чтоб воздействие пойнткатов было явно отмечено (аннотациями, а не регэкспами имён функций и полей) — станет нормальным инструментом.

Эээ.. AspectJ это уже давно умеет. В Spring'е и EJB3 это вообще везде используется.
Sapienti sat!
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 20:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Вот только это все достаточно просто отлаживается многочисленными существующими инструментами. А вот для макросов у нас отладчиков пока нормальных нет.


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

По моему опыту — разницы практически никакой. Зато есть большое сходство между отладкой "закрытой" библиотеки (от которой нет исходников) и "закрытого" компилятора — в обоих случаях остаётся только материться
Опыт отладки макросов может дать, например, такая среда разработки как Eclipse. Только там плагины к IDE отлаживаются, а не макросы, но суть процесса та-же самая. Не пробовали к Eclipse плагины писать?
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 05.08.07 20:36
Оценка:
Здравствуйте, IT, Вы писали:

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

Какие проблемы с reflection'ом, что у него такие "вытекающие последтсвия"?

Для таблицы в 100x100 (а больше — уже будем на лимиты браузера натыкаться) нужно всего порядка 10000 рефлективных вызовов. Это даже упоминания не стоит. Не говоря уж о возможности оптимизации рефлексии через динамически формируемые классы-аксессоры.

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

Кэшируем подготовленные запросы.

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

Эээ... А кэшировать на уровне провайдера нельзя?

IT>В-шестых. Предположим, что ко всему прочему в моём приложении используется система ограничения доступа к контенту. При использовании линк я вынужне буду добавлять фильтрацию контента к каждому запросу. Вопрос, справятся ли с этим обезъянки.

А на уровне провайдера нельзя?

Hibernate решает, например, все твои проблемы (что характерно, без макросов). При этом для NHibernate будет LINQ-интерфейс.

Хотя мне LINQ не нравится по другим причинам, но он не оправдание макросам.
Sapienti sat!
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 05.08.07 20:47
Оценка:
Здравствуйте, Cyberax, Вы писали:

M>>чтоб воздействие пойнткатов было явно отмечено (аннотациями, а не регэкспами имён функций и полей) — станет нормальным инструментом.

C>Эээ.. AspectJ это уже давно умеет. В Spring'е и EJB3 это вообще везде используется.

"Давно" не получится. Аннотации в яве появились считай что вчера
Собственно, именно AspectJ и аннотации я и имел в виду. Просто когда я 6 лет назад работал в AspectJ — аннотаций и в помине не было, и я им говорил, что "надо добавить пользовательские модификаторы/метки, иначе это хак чистой воды". На что мне ответили, что нихрена я не понимаю в крутизне AspectJ. Поэтому у меня очень специфическое отношение к AspectJ вообще, и интеллекту его создателя в частности. Когда они с Чарльзом Симони сделали фирму для продвижения Intentional Programming — я подумал "ну вот, наконец AOP будут применять в качестве определения операций, а не запутывания кода, и станет нормальной технологией". А потом Gregor ушёл из IP — я понял, что он полный даун, вместе с его AspectJ.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 05.08.07 20:56
Оценка:
Здравствуйте, mkizub, Вы писали:

M>>>чтоб воздействие пойнткатов было явно отмечено (аннотациями, а не регэкспами имён функций и полей) — станет нормальным инструментом.

C>>Эээ.. AspectJ это уже давно умеет. В Spring'е и EJB3 это вообще везде используется.
M>"Давно" не получится. Аннотации в яве появились считай что вчера
JDK5 вышла в 2004 году. Уже три года скоро будет.

M>Собственно, именно AspectJ и аннотации я и имел в виду. Просто когда я 6 лет назад работал в AspectJ — аннотаций и в помине не было, и я им говорил, что "надо добавить пользовательские модификаторы/метки, иначе это хак чистой воды".

Лично помню, что прикручивал атрибуты из JavaDoc'а к AspectJ в 2003 году. Так что при желании все было.

M>На что мне ответили, что нихрена я не понимаю в крутизне AspectJ. Поэтому у меня очень специфическое отношение к AspectJ вообще, и интеллекту его создателя в частности. Когда они с Чарльзом Симони сделали фирму для продвижения Intentional Programming — я подумал "ну вот, наконец AOP будут применять в качестве определения операций, а не запутывания кода, и станет нормальной технологией". А потом Gregor ушёл из IP — я понял, что он полный даун, вместе с его AspectJ.

Аспекты замечательно использовать для некоторых вещей — PojoCache из JBoss, например. Ну или классические logger'ы и security.
Sapienti sat!
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 05.08.07 21:12
Оценка:
>Динамические языки индустрия вообще не приняла.

бейсик. неужели ты не играл в donkey?

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


препроцессор pl/1 имел синтаксис, аналогичный самому pl/1
Люди, я люблю вас! Будьте бдительны!!!
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 05.08.07 21:15
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Какие проблемы с reflection'ом, что у него такие "вытекающие последтсвия"?


Тормоза.

C>Для таблицы в 100x100 (а больше — уже будем на лимиты браузера натыкаться) нужно всего порядка 10000 рефлективных вызовов. Это даже упоминания не стоит. Не говоря уж о возможности оптимизации рефлексии через динамически формируемые классы-аксессоры.


10000 нужно ещё умножать на фактор, зависящий от количества посетителей.

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

C>Кэшируем подготовленные запросы.

И возвращаемся к тому, от чего так старательно уходили. Видел запрос в 3 строчки? Вот это наша цель. Понятное дело, что сделать можно всё, что угодно. Но зачем тогда всё это? Зачем нужен линк, если можно обойтись и без него?

C>Эээ... А кэшировать на уровне провайдера нельзя?


MS SQL?

IT>>В-шестых. Предположим, что ко всему прочему в моём приложении используется система ограничения доступа к контенту. При использовании линк я вынужне буду добавлять фильтрацию контента к каждому запросу. Вопрос, справятся ли с этим обезъянки.

C>А на уровне провайдера нельзя?

Какого провайдера?

C>Hibernate решает, например, все твои проблемы (что характерно, без макросов). При этом для NHibernate будет LINQ-интерфейс.


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

C>Хотя мне LINQ не нравится по другим причинам, но он не оправдание макросам.


Хибернейт мне тоже не нравится по многим причинам, поэтому я даже не хочу о нём в этом топике говорить.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 05.08.07 22:06
Оценка:
Здравствуйте, IT, Вы писали:

C>>Какие проблемы с reflection'ом, что у него такие "вытекающие последтсвия"?

IT>Тормоза.
Premature optimization... — ну ты дальше сам знаешь.

C>>Для таблицы в 100x100 (а больше — уже будем на лимиты браузера натыкаться) нужно всего порядка 10000 рефлективных вызовов. Это даже упоминания не стоит. Не говоря уж о возможности оптимизации рефлексии через динамически формируемые классы-аксессоры.

IT>10000 нужно ещё умножать на фактор, зависящий от количества посетителей.
Для 100 запросов в секунду — будет всего миллион рефлексий. Кроме того, оптимизатор рефлексии вообще сведет оверхед к минимуму (по моим тестам в Java, генерируемые accessor'ы примерно в 10 раз быстрее стандартной рефлексии, которая примерно в 200 раз медленнее прямого вызова).

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

C>>Кэшируем подготовленные запросы.
IT>И возвращаемся к тому, от чего так старательно уходили. Видел запрос в 3 строчки? Вот это наша цель. Понятное дело, что сделать можно всё, что угодно. Но зачем тогда всё это? Зачем нужен линк, если можно обойтись и без него?
Дык без проблем. Вот живой код:
List<Need> needs=(List<Need>)sess.createQuery("from Need f inner join fetch f.position"
    "where f.date > :date and f.status='OPEN'")
    .setDate("date",needDate).setCacheable(true).list();

(в строке запроса работает автокомплит, просмотр генерируемого SQL и т.п. — injected languages в IDEA, однако).

А дальше байнди этот список куда тебе угодно.

C>>Эээ... А кэшировать на уровне провайдера нельзя?

IT>MS SQL?
Ну не знаю, Hibernate держит свой кэш на любом провайдере. Есть обертка (C-JDBC), которая делает то же самое для любой базы.

IT>>>В-шестых. Предположим, что ко всему прочему в моём приложении используется система ограничения доступа к контенту. При использовании линк я вынужне буду добавлять фильтрацию контента к каждому запросу. Вопрос, справятся ли с этим обезъянки.

C>>А на уровне провайдера нельзя?
IT>Какого провайдера?
Провайдера данных, к которому обращается LINQ.

C>>Hibernate решает, например, все твои проблемы (что характерно, без макросов). При этом для NHibernate будет LINQ-интерфейс.

IT>Я тоже все такие проблемы решаю и без макросов и, что характерно, без хибернейта. Но хочется абсолютного совершенства, а не подпорок и затычек.
Так может стоит посмотреть? А то все твои проблемы — высосаны из пальца, что называется.
Sapienti sat!
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 06.08.07 07:40
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>10000 нужно ещё умножать на фактор, зависящий от количества посетителей.

C>>Для 100 запросов в секунду — будет всего миллион рефлексий. Кроме того, оптимизатор рефлексии
IT>Кто такой, почему не знаю?
Например, здесь: http://andersnoras.com/blogs/anoras/archive/2007/06/13/blazing-fast-reflection.aspx и http://andersnoras.com/blogs/anoras/archive/2007/06/14/blazing-fast-reflection-for-java.aspx

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?


C>>вообще сведет оверхед к минимуму (по моим тестам в Java, генерируемые accessor'ы примерно в 10 раз быстрее стандартной рефлексии, которая примерно в 200 раз медленнее прямого вызова).

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

C>>
C>>List<Need> needs=(List<Need>)sess.createQuery("from Need f inner join fetch f.position"
C>>    "where f.date > :date and f.status='OPEN'")
C>>    .setDate("date",needDate).setCacheable(true).list();
C>>

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

C>>Ну не знаю, Hibernate держит свой кэш на любом провайдере.

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

C>>Так может стоит посмотреть? А то все твои проблемы — высосаны из пальца, что называется.

IT>Боюсь, что из пальца как раз высосан твой ынхибернейт. Извини, но этот пост не о монстриках, этот пост о макросах, задача которых убрать из кода тексуальщину и заменить её на проверяемую компилятором декларативность.
Эта текстуальность замечательно проверяется современными IDE и не создает проблем в 99% случаев.

Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.
Sapienti sat!
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 06.08.07 08:31
Оценка:
Здравствуйте, FR, Вы писали:

IT>>За год я не написал ни одного макроса. Ещё раз повторить?

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

Не обязательно. Макросами, которые написали другие он точно пользовался.
... << 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[37]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 06.08.07 09:35
Оценка:
Здравствуйте, FR, Вы писали:

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

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

Слово "затруднительно" не имеет объективного значения. Я думаю, что на Nemerle можно писать, не пользуясь макросами. Но зачем?
... << 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]: Являются ли макросы свидетельством недостаточной выр
От: Kisloid Мухосранск  
Дата: 06.08.07 09:38
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Я за то, чтобы оружие все-таки было. И я таки за то, чтобы это оружие было как можно более умным, так что если я нечаянно буду целиться в своего, оно б заблокировало ствол. Потому что мало ли что.

S>И вот немерлевые макросы пока что выглядят достаточно
S>а) сложными для использования, так что новичок скорее всего вообще не сможет это снарядить
S>б) умными, так что новичок не сможет использовать готовый макрос неправильно — компилятор надает ему по рукам (ср. с макросами С/С++)
S>в) мощными, так что можно решать офигительно сложные задачи офигительно изящно

По моему ты только что описал макросы Немерле. Но я бы тут еще один пункт добавил:

г) нормальная возможность отладки макросов

В немерле с этим щас не очень хорошо.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: Kisloid Мухосранск  
Дата: 06.08.07 10:02
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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

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

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


А я вот по другому думаю, зачем пользоваться макросами, если не понимаешь зачем их надо использовать, в Немерле можно писать вообще не имея представления о том, что такое макрос.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: Kisloid Мухосранск  
Дата: 06.08.07 10:24
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Зато в С элементарно

J>Скрипт, который будет выводить результат действия макроса, пишется за 3 минуты: вызов компилятора в режиме "только препроцессор" (в gcc это ключ -E), отсечение по какой-нть метке всякой ненужной фигни, которая придет с многочисленными include (проще всего через awk) и напускание какой-нть утилиты типа indent или astyle для приведения результата в читабельный вид.

J>Хотя это, конечно, смотря что понимать под отладкой макроса.

J>Если то, какой в результате текст он генерит — такого простого скрипта достаточно с головой.
J>Если надо — могу привести текст.

Нет, немного не то. То какой в результате текст генерится можно в студийной интеграции посмотреть простым наведением мышки на макрос. Я имел ввиду полноценную отладку, такую как если бы это был обычный код. Т.е. поставить в каком либо месте брейкпойнт, пройтись через F10-F11 по коду, смотреть какие значения переменных в данный момент, следить за калл стеком, условные брейкпойнты итд итп
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 06.08.07 10:37
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.


[OFFTOP] А у Эклипса есть что-нибудь на эту тему? Не в курсе?
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: jazzer Россия Skype: enerjazzer
Дата: 06.08.07 10:40
Оценка:
Здравствуйте, Kisloid, Вы писали:

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


Понятно. Да, если это встроено — это здорово.

В принципе, это можно сделать и в нормальной среде/отладчике, которая/ый допускает вменяемое программирование себя (т.е. скидывать сгенеренный текст во временный файл, автоматом проставить там все брейкпоинты и заинклудить его куда надо). В принципе, это же я делаю вручную, когда отлаживаю макросы — просто ставлю в нужном месте #include "generated.h", где generated.h — это результат работы препроцессора, и в нем уже расставляю брейкпоинты. Правда, я сомневаюсь, что в студии можно такую автоматику навернуть.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 06.08.07 10:44
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>LINQ подразумевает неявное представление лямбды ввиде expression tree или генерации кода в зависимости от ожидаемого типа делегата, а немерлевые макросы вызываются только явно, по атрибуту, псевдофункции или ключевому слову. Все это осложняется extension methods.


Влад утверждал, что возможен вызов макроса не по имени. Правда, не берусь утверждать, что я его верно понял. Ответа я не получил (может позже). Хотя мне кажется, что имелось в виду что то вроде вызова макроса на самом-пресамом-верхнем уровне что то вроде boo{...}, либо атрибута на верхнем уровне, который будет перелопачивать потроха нужным образом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 06.08.07 10:57
Оценка:
Здравствуйте, Курилка, Вы писали:

C>>Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.

К>[OFFTOP] А у Эклипса есть что-нибудь на эту тему? Не в курсе?
Пока нет. У них архитектура для этого плохо подходит. Хотя начинают шевелится в эту сторону.

Вот тут более подробно про эту фичу в IDEA: http://www.jetbrains.net/confluence/display/CONTEST/IntelliLang
Sapienti sat!
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 06.08.07 11:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Курилка, Вы писали:


C>>>Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.

К>>[OFFTOP] А у Эклипса есть что-нибудь на эту тему? Не в курсе?
C>Пока нет. У них архитектура для этого плохо подходит. Хотя начинают шевелится в эту сторону.
А на эту тему ссылок нет под рукой?
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 06.08.07 11:04
Оценка:
Здравствуйте, Курилка, Вы писали:

C>>>>Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.

К>>>[OFFTOP] А у Эклипса есть что-нибудь на эту тему? Не в курсе?
C>>Пока нет. У них архитектура для этого плохо подходит. Хотя начинают шевелится в эту сторону.
К>А на эту тему ссылок нет под рукой?
Я это где-то на TheServerSide видел, сейчас найти быстро не могу.

Или тебе ссылки на архитектуру Eclipse нужны?
Sapienti sat!
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 06.08.07 11:07
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Курилка, Вы писали:


C>>>>>Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.

К>>>>[OFFTOP] А у Эклипса есть что-нибудь на эту тему? Не в курсе?
C>>>Пока нет. У них архитектура для этого плохо подходит. Хотя начинают шевелится в эту сторону.
К>>А на эту тему ссылок нет под рукой?
C>Я это где-то на TheServerSide видел, сейчас найти быстро не могу.
Ну поверю на слово тогда

C>Или тебе ссылки на архитектуру Eclipse нужны?


Да не, спасибо, пока туда лезть не хочу
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.08.07 11:59
Оценка:
Здравствуйте, IT, Вы писали:

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


Здесь можно поподробнее?
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: GlebZ Россия  
Дата: 06.08.07 12:07
Оценка:
Здравствуйте, IT, Вы писали:


IT>Давай возьмём для примера тот же линк и попробуем его применить, допустим, для веб-приложения. У linq есть следующие весьма привлекательные возможности:


IT>- устранение одноразовых структур для ad-hoc запросов;

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

IT>Учитывая, что в большинстве случаев логика веб-приложения диктуется именно UI, у нас вместо трёх слоёв и дополнительной структуры может получится вот такая простая вещь из 3-х строк:


IT>
IT>grid.Source = from c in customers   
IT>              join o in orders on c equals o.Customer into oo   
IT>              select new { c.CompanyName, OrderCount = oo.Count() 
IT>

IT>Пока всё просто замечательно.
Не согласен. То что ты здесь написал — это есть "встроенный макрос". Мне вообще непонятно зафигом его ввели. Говорить о том, что визуальность по сравнению с функциональной записью кардинально увеличилось — не приходится. А вот ограничения введеные данным макросом — налицо.


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

На фоне генерации грида и работы с бд — выигрыш будет очень незначительным.

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

Это нормально. Провайдер может быть подменен.

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

Кэширование запросов или результатов?

IT>Поехали дальше.


IT>В-третьих. Обрати внимание вот на этот
Автор: fuurin
Дата: 04.08.07
знаковый топик и особенно на ответ.


IT>

IT>Нет, потому что штатно LINQ2SQL этого не поддерживает, а расширять генерацию SQL можно будет только в следующей версии.


IT>Учитывая, что разница между версиями у нас 2005 — 2008, то как говорится обещанного три года ждут.

Это особенности провайдера LINQ2SQL. К макросам отношение имеет мало.

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

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

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

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

IT>В-шестых. Предположим, что ко всему прочему в моём приложении используется система ограничения доступа к контенту. При использовании линк я вынужне буду добавлять фильтрацию контента к каждому запросу. Вопрос, справятся ли с этим обезъянки.

Аналогично. Отказ от pass-throught и встроенного макроса.

IT>Что можно было бы сделать на макросах?

Не убедил.


IT> И уж точно не придётся править компилятор для того, чтобы повторить возможности линка, т.к. никуда не надо будет проталкивать expression tree. Всё можно будет посчитать в компайл-тайм.

Так и не понял, а нужно ли?

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

С уважением, Gleb.
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 12:32
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Basic — статически типизированный язык.


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

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

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

BZ>>препроцессор pl/1 имел синтаксис, аналогичный самому pl/1


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


Балшыт. Макросистема не обязана уметь получать информацию о типах. Дело в том, что ее вообще может не быть, этой информации, так же как и типов. К примеру, макросистема в любом чисто динамическом языке без аннотаций типов этой информации получить не может в принципе. Взять хотя бы тикль. А в ряде приложений, где возможно применение макросистем, типов вообще в природе не существует как понятия — например при обработке текстов или в случае макроассемблера, или языка FORTH.
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.08.07 12:40
Оценка:
Здравствуйте, Gaperton, Вы писали:

VD>>Вообще-то уже через жопу и уже автогеном. Ты ведь с автоматами вручную копаться стал. Понятно, что паттерн-матчинг тут хоршее подспорье, но я бы предпочел работать с EBNF или другим ДСЛ-ем.


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


Полностью согласен. Только я нигде не сказал, что КА == EBNF или что-то подобное. Так что можно было этого всего и не говорить.

G>Есть масса самых разных задач, где встречается КА


Ага. И для каждой такой задачи всегда есть (или можно легко создать) DSL описывающий решаемые задачи очевидным образом. Ну, а уже по текстам на этом языке автоматически генерировать КА.

G>- например, связанных с реализацией сетевых протоколов.


Хороший пример. Вот тот же твой любимый Эрланг включает фактически встроенный DSL для разбора битовых полей. ОК, Эрлангу повезло в этой области. Он разрабатывался людям которым такой ДСЛ был нужен. Но для другой задачи Эрланг будет уже непреспособлен. И только его авторы смогут расширить язык должным образом. А что делать универсальным языкам в которых по их статусу неположено иметь специаилизированных решений? Вот тут МП получается отличным решением.

G> Так что не через жопу и не автогеном.


Да, нет... Как раз именно через жопу и именно неподходящим для этого органа инструментом.

G> Программеру, который под каждый случай разработки КА будет свое языковое расширение или ДСЛ писать, довольно быстро коллеги отстрелят то, что ему танцевать мешает.


Это если коллеги дауны. Уверен, что разумные коллеги сами понимают, что ручное программирование КА, а уж темболее ручная их оптимизация (устранение лишних путей, преобразование НКА в ДКА и т.п.) — это работа для машины. А выполнять вручную работу машины — это и есть первый признак ламерстава. Оставим копипэст для секритарш.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Являются ли макросы - аналогия
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.08.07 12:40
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Макросы — это не колдовство, а способ избавиться от заката солнца вручную. Способ представить решение задачи в наиболее интуитивно-понятном для человека виде, а решение генерировать автоматически с использованием очень правильных, но чересчур низкоуровневых "заковнов физики".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.08.07 12:40
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

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


Мне кажется, что достоточно. А вот ты явно недостаточно понял задачу и твои фантазии далеки от реальности.

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


BZ>data Salary = Salary Double


BZ>то это делается одной строчкой:


BZ>gmap (\Salary x -> Salary (x*1.1))


BZ>в общем и целом, generic программирование обеспечивает автоматическую навигацию по любым контейнерам с организацией обработки только интересующих нас частей информации. основные алгоритмы — gmap, отображающий структуру данных в изоморфную ей, gfold, собирающий информацию (скажем, сумму всех зарплат или список номеров кабинетов), gunfold, конструирующий структуру данных (скажем, при десериализации), gzip, обрабатывающий параллельно два объекта с одинаковой структурой


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

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

BZ>а наиболее известная статья в этой области — "Scrap your boilerpate!", т.е. "выкиньте ваш шаблонный код!" — как будто написана специально для тебя


Вряд ли. Я конечно люблю помечтать. Но мои мечты обязательно должны материализовываться. А вот в то, что Хаскель это материалистический язык я как-то поверить не могу. Уж больно он далек от реальной жизни.

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


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

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

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

BZ>скаждем, хорошо известно, что многие фичи, которые в раннем С реализовывались с помощьтю макросов (от определеняи констант до полиморфного кода), в C++ стали частью языка. и наверно, никто не будет спорить с тем, что это упростило разработку программ


Ну и что? Язык был не полноценным. С++ и сейчас таковым остается. Мы же ведем речь не о таких случаях?

Возмем тот же gmap. gmap и есть та самая магия. Почему магия? А его нельзя объяснитьв термирах основного языка (если я правильно понял). Скажем в Ява/дотнете его аналог можно создать на базе рефлексии. Работать будет на ура, но медленно, а значит не всегда приемлемо. Возможно в каких-то языках его аналог можно будет создат не базе компайлтайм-рефлексии. Но без подобных средств создать gmap мне не представляется возможным. А многие нуждаются в создании подобных магических фунций. И не телько. Кому-то просто хочется сделать синтаксис именно таким как он видит. А кто-то хочет интегрировать в свои программы некий фрэймворк. В общем, бесспорно, что если имеется отлично подходящие средства встроенные в язык, то лучше выбирать их, а не заниматься самодеятельностью и клепать макросы. Но макросы иметь тоже нужно. Иначе рано или поздно прийдется идти на компромисы и довольствоваться огрызками с барского стола.

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


Согласен.

BZ>хорошо, что эти проблемы можно решить хотя бы так, но ещё лучше, если бы макросы совсем не были нужны.


Это утопия.

BZ> особенно кстати это относится к хаскелю, где TH реализован только в одном компиляторе и крайне неудобен в использовании — имо это главным образом инструмент защиты диссертаций, а не реального порграммирования


А это проблемы Хаскеля и его сообщества. Примеры где макросы на очень высоком уровне интегрированы в язык и является частью его спецификации нам известны — Лисп и Немерле.

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


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

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


Я не очень понял что значит "управляющие стурктуры". Посему не могу об этом рассуждать. С точки зрения манипуляции функциями Хаскель мало чем отличается от Немерле.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: GlebZ Россия  
Дата: 06.08.07 12:41
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Если нужна кодогенерация, то лучше макросов ничего нет.

Не совсем верно. Написание макросов значительно легче чем кодогенерация, но в классе задач когда нужна кодогенерация у клиента в зависимости от внешних условий — макросы бесполезны.
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 06.08.07 12:58
Оценка:
Здравствуйте, GlebZ, Вы писали:

L>>Если нужна кодогенерация, то лучше макросов ничего нет.

GZ>Не совсем верно.

Ну, в общем да. Это было сказано в контексте разговора.

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


Это не понял. Пример?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 06.08.07 13:05
Оценка:
Здравствуйте, IT, Вы писали:

C>>А вот для макросов у нас отладчиков пока нормальных нет.

IT>Макрос отлаживается тем же отладчиком что и любой другой код.
Угу. Во время компиляции.

Я пробовал Nemerle'евые макросы отлаживать — нет, спасибо.
Sapienti sat!
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 06.08.07 13:07
Оценка:
Здравствуйте, mkizub, Вы писали:

C>>Вот только это все достаточно просто отлаживается многочисленными существующими инструментами. А вот для макросов у нас отладчиков пока нормальных нет.

M>А библиотеки как отлаживают? Cверяют ожидаемый выход данных с фактическим.
А еще отладчиком ставят брейкпоинты, watch'и добавляют, дампят stacktrace'ы и т.п.

M>Так и макросы отлаживают. Сверяют ожидаемый сгенерированный код с фактически сгенерированным. Инструменты для анализа сгенерированого кода — есть. Они появляются вместе с компилятором, поскольку компиляторы отлаживать тоже надо.

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

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

Пробовал. Не понравилось.
Sapienti sat!
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 13:26
Оценка:
Здравствуйте, 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 лет назад.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 06.08.07 13:30
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>Пробовал. Не понравилось.

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

Я пробовал писать плагины к Эклипсе, и мне их отладка понравилась. Видимо, тут речь идёт просто об опыте и знании инструмента. Безусловно, отлаживать компилятор — намного сложнее, чем выучить язык. Но если вы этот компилятор уже выучили вдоль и поперёк — то его отладка ничем не отличается от отладки обычного кода. Впрочем, это справедливо для любого большого проекта — пока его не выучишь, хрен поймёшь что происходит. В этом отношении IDE сильно рулит, так как по ходу отладки можно заодно и выучить проект.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 13:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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


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

Когда нам требуется построить запрос динамически, то синтаксис линка идёт в сад. Например, у нас есть несколько полей для задания фильтра. Если поле пустое, то мы по нему не фильтруем, если в нём есть какое-то значение, то мы его включаем в фильтр.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 06.08.07 13:42
Оценка:
Здравствуйте, IT, Вы писали:

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

MS переизобретает Hibernate

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

Единственного чего не хватает — ссылок на свойства, тогда вообще без строковых констант все можно было бы делать.
Sapienti sat!
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 06.08.07 13:45
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


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

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

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


Угу зачем ведь тяжело не использовать даже if for и т. п. уж лучше на лиспе.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.08.07 13:54
Оценка:
Здравствуйте, IT, Вы писали:

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


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

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


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

Но можно и промежуточный провайдер написать, который будет автоматом сворачивать ET, а потом передавать его Linq2SQL. Тогда можно будет просто декларативно писать полный запрос, а он потом свернется до необходимого.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 13:58
Оценка:
Здравствуйте, 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 пунктов, ты хочешь заменить слои на АОП с помощью макросов.


АОП тут вообще не причём.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 13:58
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


Это мы уже обсуждали. Нужно ввести в язык конструкцию nameof и всем будет счастье. Кстати, добавить макрос nameof в Немереле как... ну ты понял
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 13:58
Оценка:
Здравствуйте, Константин Л., Вы писали:

IT>>Для написания более сложных вещей желательно иметь полное представление.

КЛ>Для изучения которого нужно потратить полгода.

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

IT>>- обезъянкам будет трудно;

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

Именно. Те, кто нас с тобой считают обезъянками именно так и думают.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 14:04
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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


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


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

Вторая половина приводится к гражданским пространствам типа RGB нелинейно, т.е. в терминах матричного линейного преобразования не описывается. Что тоже не проблема — при нашем с тобой подходе любое преобразование делается в два хода — из нелинейного в линейное, потом обратно в нелинейное. Это устраняет необходимость в макроанализе страшного графа допустимых переходов между пространствами. Что-то намудрил WH на ровном месте, мне кажется.
Re[38]: В-седьмых
От: IT Россия linq2db.com
Дата: 06.08.07 14:05
Оценка:
Вот тут ещё подумалось.

Когда требуется использование сохранённых процедур (например, из-за требований безопасности), то у нас вводится ещё один слой и на каждый запрос пишется SQL скрипт с процедурой. С макросами можно оставаться в тем же самым кодом как и без сохранённых процедур, только вместо SQL генерировать саму сохранённую процедуру во время компиляции. Т.е. издержки на написание СП можно полностью устранить.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 06.08.07 14:05
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


Ну давай это назовём "обычной императивщиной и функциональщиной". Какая разница?

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


Вариант. Кстати, насколько просто/сложно расширить существующий провайдер?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 06.08.07 14:11
Оценка:
Здравствуйте, 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]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 14:20
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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

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

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

Однако, что такое динамическая и статическая типизация я помню хорошо. Отличие между ними, мой хорошо эрудированный и плохо знающий матчасть коллега, состоит не в полиморфизме, а в том, в какой момент проверяются типы. До выполнения (статически) или во время выполнения (динамически). Все бейсики, как интерпретируемые языки, кроме некоторых исключений-компиляторов, проверяли типы в динамике... И это соврешенно не важно, что переменная $String не полиморфна. Это уже второй вопрос — ответ на который также прост — нет в бейсике составных данных и сложных структур данных — как в фортране, потому и от полиморфных переменных толку немного.
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 06.08.07 14:29
Оценка:
Здравствуйте, lomeo, Вы писали:

M>>Самым мощным средством является непосредственная трансформация AST. Это что-то вроде ассемблера для расширяемого языка/компилятора.


L>Чем макрос отличается? Он же тоже работает с AST, нет?


Макрос — это "декларативное" описание изменений, а ещё AST можно трансформировать императивно, напрямую создавая и меняя узлы.
А ещё есть AOP, тоже декларативное описание изменений, но в другом виде.

M>>Нет, нельзя, ибо генерируемый код и правила генерации являются чисто project-specific.

M>>Если же под "более мощным" понимать язык, в который пихают всякий специфический мусор — то PL/1 покажется стройным и простым

L>Так трудно спорить. Почвы нет. Не можешь привести примеры project-specific генерируемого кода, т.е. вот столько нагенерили, отличия у них вот такие то?


Вот тут немного об этом написал
http://www.rsdn.ru/Forum/message/2611455.aspx
Автор: lomeo
Дата: 06.08.07
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.08.07 14:35
Оценка:
Здравствуйте, IT, Вы писали:

IT>Вариант. Кстати, насколько просто/сложно расширить существующий провайдер?


Реализуешь LINQ pattern и все. Сам я этого не делал, но не думаю, что пробрасывание ET это сверхсложная операция.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.08.07 15:32
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Процедурный подход безусловно мощнее, поскольку декларативный ограничен набором известных ему операций.


Какое то у тебя узкое понимание декларативности. ФП это тоже декларативный подход.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 06.08.07 15:43
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Вот только все "индустриальные" Бэйсики, которые позиционировались как языки общего назначения были компиляторами.
... << 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[36]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 06.08.07 15:43
Оценка:
Здравствуйте, FR, Вы писали:

FR>Если это так то и мой список состоит из статически типизированных языков.


Уверен, это будет сенсация. Если удасться доказать, конечно. Собственно, я и ожидаю от Вас обоснований своей точки зрения. Мои здесь
Автор: Klapaucius
Дата: 06.08.07


Впрочем, мне не особенно интересно участвовать во флейме по 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]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 06.08.07 15:43
Оценка:
Здравствуйте, 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[40]: Являются ли макросы свидетельством недостаточной выр
От: GlebZ Россия  
Дата: 06.08.07 15:47
Оценка:
Здравствуйте, IT, Вы писали:

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

GZ>>Я испуган...
IT>Не боись, прорвёмся.

- А что это за шаги такие на лестнице? — спросил Коровьев, поигрывая
ложечкой в чашке с черным кофе.
— А это нас арестовывать идут, — ответил Азазелло и выпил стопочку
коньяку.
— А, ну-ну, — ответил на это Коровьев.

(с)Булгаков

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[36]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 06.08.07 16:02
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Это не "эрудиция", это плохая память, коллега . Все-таки, в 31 год тяжело вспомнить детали угребищного языка, на котором писал много, но в школе. Я с тех пор настолько много чему научился, что мне не стыдно забыть $ перед строковой переменной, а смешно .


Завидую. А мне вот становиться невыносимо стыдно всякий раз, как я что-нибудь забываю.

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


Все верно.

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


А с чего Вы взяли, что Basic — интерпретируемый язык? Интерпретируемый язык или нет — зависит от его дизайна. Язык, который проектировали как статически типизированный можно компилировать и интерпретировать — но при интерпретации пользоваться бенефитами динамической типизации практически нельзя — дизайном не предусмотрена-с. Язык, который проектируется как язык с динамической типизацией — можно интерпретировать со всеми бенефитами динамики, но компилировать практически невозможно. Опять-таки дизайн.
Basic — язык, который относится к первым, а не ко вторым. Так что правильнее сказать Все бейсики, как компилируемые языки, проверяли типы при компиляции, за исключением скриптов-диалектов. От того, что есть интерпретатор Haskell и OCaml, они ведь динамическими не становяться?
Речь шла об индустриальных динамических языках. Я вспомнил Smalltalk и незаслуженно забыл про Erlang. Но уж бейсик то точно из другой оперы. Все индустриальные GP бейсики — компиляторы.
... << 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[47]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 06.08.07 16:03
Оценка:
Здравствуйте, AndrewVK, Вы писали:

M>>Процедурный подход безусловно мощнее, поскольку декларативный ограничен набором известных ему операций.


AVK>Какое то у тебя узкое понимание декларативности. ФП это тоже декларативный подход.


Не вижу противоречий. Мое понимание включает в себя FP, пока ты определяешь функцию — ты в рамках декларативности.
Когда компилятор, на основе твоих определений, строит последовательность действий, необходимых для вычисления значения этой функции — это уже императив.
Разумеется, последовательность действий для вычисления значения функции может быть разной (в зависимости от алгоритма используемого компилятором),
в этом смысле ФП декларативен.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 06.08.07 16:08
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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

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

K>Позвольте несогласиться с Вами. Возможность опробировать методику за треть столетия до появления первых научных работ, в которых она разрабатывается это серьезный вызов скорее физике, а не computer science.


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

G>>и не генерируют код, как они делали в далеких 70-х, да?

K>Зло не в том, что код генерируется. Это как раз добро. Зло в том, какой код генерируется и как он генерируется. А зависит это от гигиеничности, метаязыка, доступности информации о типах, et cetera.

Зло не в том, какой код генерируется, ине в том, как он генерируется. Предлагаю вам прежде чем со мной спорить, ознакомится с моей позицией. Это — вежливо. Вы по крайней мере будете понимать, что я говорю, почему и о чем.

K>Вы лучше вот что скажите, я так понимаю, что Вам не нравится в основном изменения синтаксиса? Если так, то как Вы относитесь к тому, что в некоторых языках есть штатные средства вроде определения произвольных операторов (Prolog, Haskell, Scala...) и неявного создания замыканий как в Scala (по понятным причинам в Haskell можно и без этого обойтись)? Такие средства позволяют изменять синтаксис также как и макросы — но "гражданскими" средствами, никак особо не выделенными.


Вот эту ветку прочтите пожалуйста, там все написано. Это сообщение, и ниже по треду.
http://rsdn.ru/forum/message/2604188.1.aspx
Автор: Gaperton
Дата: 30.07.07
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 06.08.07 17:02
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Были там целочисленные значения у переменных, были. Плавающая запятая эмулировалась программно, и работала крайне медленно. Поэтому, интерпретатор различал целые числа и плавающие в динамике, несмотря на то, что этих постфиксов-префиксов (не помню уже) там не было. Так вел себя любой бейсик для слабых процов без аппаратной плавающей запятой, таких как Z80.


Я прекрасно знаю архитектуру Z80. Там любая перменная описывалась 5 байтами и все операции с ней делались через калькулятор (который по сути набор функций для расчётов с floating point). Был там способ закодировать целочисленное число, с которым калькулятор работал быстрее (кажется, для этого было специальное значение экспонены, которая, кстати, была целиком в 1-м байте). Этот калькулятор умел делать неявное приведение при необходимости. Так вот, всё это было именно на уровне калькулятора. С точки зрения бэйсика это был один "численный" тип. Кстати, учитывая то, что строки так же обрабатывались через калькулятор, то можно сказать, что в спектрумовском бэйсике был всего один базовый тип. Но это, конечно, не серьёзно.

K>>Таким же макаром я могу доказать, что и Хаскель — динамически типизированный. А всего-то и нужно, что написать интерпретатор, который не проверяет типы заранее, а добавляет метки типов ко всем объектам. Ах да, забыл, это даст нехороший побочный эффект! Все функции станут обладать свойством "type polymorphism"! Ну ничего, можно и этот недостаток залатать, если подумать как.


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


Я могу написать интерпретатор Хаскелля, который типы вычисляет в рантайме, а не в компайлтайме, но при этом целиком соотв. семантике языка. Согласно твоей терминологии, Хаскелль будет динамически-типизированным. А вот, например, с Python, Perl, Ruby или PHP ничего подобного не выйдет. Так вот, внимание! Для старомодного бэйсика МОЖНО написать компилятор, выполняющим статические проверки типов! Вот отсюда я и делаю вывод, что на самом деле, бэйсик является стат. типизированным. Хотя, в случае бэйсика тяжело говорить о какой-либо типизации, как и в случае Лиспа.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 06.08.07 17:02
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Впрочем, мне не особенно интересно участвовать во флейме по BASIC. Того что он начнется я вообще не ожидал. А вот еще один индустриальный динамический язык я все же забыл упомянуть. Erlang.


Кажется, мы говорили про индустрию 70-х. Так что всё в порядке, Erlang не в счёт.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 06.08.07 17:03
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Гут. Ты все почти разрюхал.

Да ничего вы не разрюхали.

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

У меня есть несколько кластеров с линейными преобразованиями внутри кластера.

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

По другому НЕЛЬЗЯ.

G>Вторая половина приводится к гражданским пространствам типа RGB нелинейно,

К сведеню: RGB бывают разные.
И очень важно использовать именно тот RGB который нужен.
Иначе полезут артефакты.
Причем хорошо видно их только на специально подготовленных изображениях.
А на обычных фотографиях просто видно что что-то не так но вот что именно хз.

G>т.е. в терминах матричного линейного преобразования не описывается. Что тоже не проблема — при нашем с тобой подходе любое преобразование делается в два хода — из нелинейного в линейное, потом обратно в нелинейное.

Угу... с потерями эффективности, а иногда и точности.

G>Это устраняет необходимость в макроанализе страшного графа допустимых переходов между пространствами.

Не устраняет.
Ибо у меня есть много мест где можно срезать углы.
Причем искать руками все эти "срезы" у меня нет ни малейшего жилания. Да и времени это занимает много.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: Константин Л. Франция  
Дата: 06.08.07 19:10
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>>>Для написания более сложных вещей желательно иметь полное представление.

КЛ>>Для изучения которого нужно потратить полгода.

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


дык, посмотри на VladD2. Народ реально с ними парится.

IT>>>- обезъянкам будет трудно;

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

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


Только тут мы с тобой по разные стороны
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 05:46
Оценка:
Здравствуйте, IT, Вы писали:

IT>
IT>class UI
IT>{
IT>  void OnLoad()
IT>  {
IT>    binder.List = from c in Customer select c;
IT>  }
IT>}
IT>

IT>Можно для лучшей наглядности замешать сюда ещё и ad-hoc запрос.
Так кто мешает-то?

class UI
{
  void OnLoad()
  {
    binder.List = myMapper.select("from c in Customer select c").list();
  }
}

Нужно только сделать соответствующий mapper.
Sapienti sat!
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: night beast СССР  
Дата: 07.08.07 06:29
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>>>Правильно ли я понял, что предлагается писать вручную реализации для всех возможных выражений.

E>>Нет. Не правильно. Но вы, я вижу, больше математик, чем программист. Может быть, что-то и не допоняли.

K>Что Вы! Я не просто "больше математик, чем программист" — я вообще не программист, а физик. Образования программиста я не получал.

K>И хотя некоторые физики не любят, когда их называют математиками, мне все равно очень приятно, спасибо.

Дорогой друг.
Мы очень рады что вы вообще не программист, но раз уж влезли в дискуссию, то потрудитесь изучить инструмент о котором рассуждаете.

Задачи на expression templates уже много лет не являются проблемой для С++ кодеров.
Если у вас с этим сложности, то почитайте документацию. Ссылки были озвучены.

Реализовывать в 1001 раз линейную алгебру для вас никто не будет.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.08.07 06:40
Оценка:
Здравствуйте, IT, Вы писали:
IT>Когда нам требуется построить запрос динамически, то синтаксис линка идёт в сад.
Как это в сад?
IT>Например, у нас есть несколько полей для задания фильтра. Если поле пустое, то мы по нему не фильтруем, если в нём есть какое-то значение, то мы его включаем в фильтр.
if (StartDate != null)
  q = q.where(p => p.StartDate >= StartDate)

Поэтому то линк и рулит.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: GlebZ Россия  
Дата: 07.08.07 07:56
Оценка:
Здравствуйте, IT, Вы писали:

GZ>>вторая запись не менее визуальна чем первая. И в такой записи, запросы вполне можно собирать.

IT>К Хейлсбергу и Коробкину.
Нет. В контексте предыдущего обсуждения, я привел это как макрос который ограничивает функциональность.

GZ>>>>На фоне генерации грида и работы с бд — выигрыш будет очень незначительным.

IT>>>Точно? Проверял или сам догадался?
GZ>>Нет. Догадался.
IT>Я так и знал.

Факты в виде цифр есть?

GZ>>Опять. Трансформация OQL-подобных запросов в SQL — не является ресурсоемкой задачей.(если конечно в Microsoft не напортачили )

IT>Линк не шустр. Думаю, проблема не только в генерации SQL. Скорее всего проблема комплексная. Здесь посчитали задачу нересурсоёмкой, там догадались, что выигрыш будет незначительным и вот тебе результат. А потом мы удивляемся, почему 4 гига памяти и 4 ядра в процессоре не могут справиться с нашими задачами.
Искренне надеюсь что они внемлют твоему мнению и проведут нагрузочное тестирование. Пока что мы имеем только бету.

IT>В общем, я твою точку зрения понял. Я её не разделяю.

А по моему, нет. Я против такого термина как pass-through как плюса подхода LINQ2SQL. Также, я не особо верю что макросы, как аналогичный функционал, спасут мир и будут концептуально лучше чем LINQ2SQL.

IT>ООП не может быть преимуществом сам по себе. Это тоже самое что сказать, что преимущество гвоздя в том, что он забивается молотком.

ООП — это преимущество перед гипотетическими макросами. Его подводные камни — известны. И как писать сопровождаемый код вполне известно.

GZ>>LINQ2SQL — можно считать заменителем или хелпером для DAL.

IT>Ты вообще в курсе для чего нужен DAL?
Получение(изменение) данных, и трансформация из модели источника к логической модели и наоборот.

IT>
IT>class UI
IT>{
IT>  void OnLoad()
IT>  {
IT>    binder.List = from c in Customer select c;
IT>  }
IT>}
IT>

Пример достойный example или простейшего проекта.
IT>Можно для лучшей наглядности замешать сюда ещё и ad-hoc запрос.
Можешь показать как?

IT>Теперь сформулируем вопрос по-другому. Что тебе реально даст оставление двух таких pass-through методов в данном случае, учитывая что вся логика здесь диктуется UI?

Логика по любому диктуется UI. Если пользователь не чуствует работу той, или иной функции — то эта функция не нужна.
IT>Только пожалуйста без ООП и прочей чуши. Лучше давай оперировать такими понятиями как сопровождаемость.
OK. Кое что, ты уже описал. Нужно вставлять кэширование, секьюрити, логгирование и e.t.c. И желательно, чтобы вызовы были в одном слое, а посему — даже во избежание бардака стоит делать pass-thought когда оных функциональностей нет. Одни и те-же вызовы могут использоваться в различных прецедентах, в том числе которые могут быть написаны после оной итерации. В ситуации бардака, стоимость внесения изменений увеличивается. Ежели оные объекты еще публикуются через API (то есть должны быть отчуждаемы), то все совсем плохо. Но что совсем плохо — проект без выделенного слоя становится не тестируемым. А посему — LINQ2SQL может быть заменой(хедпером) DAL, но не более того. В остальном он сопровождаемых решений не дает.
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.08.07 08:39
Оценка:
Здравствуйте, mkizub, Вы писали:

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


M>>>Процедурный подход безусловно мощнее, поскольку декларативный ограничен набором известных ему операций.


AVK>>Какое то у тебя узкое понимание декларативности. ФП это тоже декларативный подход.


M>Не вижу противоречий. Мое понимание включает в себя FP, пока ты определяешь функцию — ты в рамках декларативности.

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

Ну и что? Исходный то код декларативен.

M>Разумеется, последовательность действий для вычисления значения функции может быть разной (в зависимости от алгоритма используемого компилятором),

M>в этом смысле ФП декларативен.

ФП декларативен в любых смыслах.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: deniok Россия  
Дата: 07.08.07 08:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Умный программист напишет сразу фильтр с обоими предикатами, и обойдется одним проходом и без временного объекта.

S>Умный компилятор/рантайм сведет цепочку к оптимальному преобразованию.

S>Ты говоришь ровно о том же: если у нас есть цепочка мапперов DataReader->DTO->BO->XML->HTML, то самым оптимальным будет свернуть это всё в один маппер, который проджитится, заоптимизируется, и будет работать практически без выделения мусора и оптимально по кэшу. Сие и есть наша самая заветная мечта.


Отлично пояснил!

Если бы все шаги DataReader->DTO->BO->XML->HTML были чистыми и ленивыми, то указание (в любой форме!) фильтрации на HTML стороне автоматически доехало бы до DataReader'а.
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.08.07 09:00
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Я могу написать интерпретатор Хаскелля, который типы вычисляет в рантайме, а не в компайлтайме, но при этом целиком соотв. семантике языка. Согласно твоей терминологии, Хаскелль будет динамически-типизированным.


Будет. Вот, к примеру, сиквел (возьмем SQL'92 для определенности) — динамически типизированный язык (это не значит что в нем типов нет!). Но совсем небольшой коррекции семантики и соответствующего компилятора хватает, чтобы сделать его статически типизированным. Сам язык при этом практически не меняется.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 09:16
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Нужно только сделать соответствующий mapper.

S>
S>Это мне напоминает Единую Теорию Поля. Скорее всего, Уравнение Всего имеет вот такой вид:
S>
S>#A = 0;
S>

S>где A — это некоторый вектор-потенциал, а # — какой-то дифференциальный оператор.
S>Осталось узнать, что за вектор и что за оператор. И этой фигней народ мается уже восемьдесят лет.
S>Так же и с маппером — примерно года с 95 если не раньше, народ пытается сделать маппер. Только они всё больше выходят какие-то на диво несоответствующие.
Почему-то, .NET-программисты страдают "туннельным видением" — все не-MS-технологии они просто не замечают. Удобные mapper'ы в виде iBatis'а и Hibernate работают в Java уже который год. И ничего, никакой LINQ не нужен.
Sapienti sat!
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.08.07 09:28
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Почему-то, .NET-программисты страдают "туннельным видением" — все не-MS-технологии они просто не замечают. Удобные mapper'ы в виде iBatis'а и Hibernate работают в Java уже который год. И ничего, никакой LINQ не нужен.


Сейчас тебе скажут, что Linq это никакой не мапер, потому что.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: IB Австрия http://rsdn.ru
Дата: 07.08.07 09:42
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Почему-то, .NET-программисты страдают "туннельным видением" — все не-MS-технологии они просто не замечают.

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

C> Удобные mapper'ы в виде iBatis'а и Hibernate работают в Java уже который год.

Фигово только работают, а так ниче, красивенько.

C>И ничего, никакой LINQ не нужен.

Если для вашего частного проекта не нужен — это не значит, что никому не нужен... У вас есть решение, для того чтобы это решение более менее адекватно заработало, вам пришлось потратить кучу усилий, потому как у данного решения очень высокий порог вхождения и куча побочных эффектов, не всегда очевидных. Прогресс на месте не стоит, появляются, очевидно, гораздо более удачные механизмы, но та как вам просто жалко потраченных усилий вы и пытаетесь пропихнуть морально устаревший подход во все проекты, даже не дав себе труд задуматься над его недостатками и возможными альтернативами.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 12:15
Оценка:
Здравствуйте, IB, Вы писали:

C>>Почему-то, .NET-программисты страдают "туннельным видением" — все не-MS-технологии они просто не замечают.

IB>Наоборот, это Java-исты ничего кругом не замечают, зациклились на морально устаревших решениях и никак не могут с них слезть.
Можешь назвать технологию MS, которой нет в Java?

C>> Удобные mapper'ы в виде iBatis'а и Hibernate работают в Java уже который год.

IB>Фигово только работают, а так ниче, красивенько.
Нормально работают. Который проект уже лично запустил на них.

C>>И ничего, никакой LINQ не нужен.

IB>Если для вашего частного проекта не нужен — это не значит, что никому не нужен... У вас есть решение, для того чтобы это решение более менее адекватно заработало, вам пришлось потратить кучу усилий, потому как у данного решения очень высокий порог вхождения и куча побочных эффектов, не всегда очевидных. Прогресс на месте не стоит, появляются, очевидно, гораздо более удачные механизмы, но та как вам просто жалко потраченных усилий вы и пытаетесь пропихнуть морально устаревший подход во все проекты, даже не дав себе труд задуматься над его недостатками и возможными альтернативами.
Даже и не говори. Посмотри только на всех этих DBA, пихающих реляционные БД — вообще морально устаревшую на 10 лет технологию.
Sapienti sat!
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: IB Австрия http://rsdn.ru
Дата: 07.08.07 12:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Можешь назвать технологию MS, которой нет в Java?

Синклер тебе уже все расписал про явовские технологии.

C>Нормально работают.

Нормально они работают только для тех, кто ничего другого не замечает.

C> Который проект уже лично запустил на них.

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

C>Посмотри только на всех этих DBA,

DBA-то здесь причем? DBA администрированием занимаются, а не разработкой.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 12:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Почему-то, .NET-программисты страдают "туннельным видением" — все не-MS-технологии они просто не замечают.

S>Гм.
C>> Удобные mapper'ы в виде iBatis'а и Hibernate работают в Java уже который год. И ничего, никакой LINQ не нужен.
S>Почему-то, Java-программисты страдают "туннельным видением" — все технологии за пределами Java они просто не замечают.
Назови мне технологию MS, которой нет в Java (кроме десктопно-гуевых, разве что). Все там есть — и dataset'ы, и тесная интеграция с серверами БД, и даже были аналоги LINQ'а (SQLJ — там была и автоматическая проверка запроса компилятором, и интеграция с языком, только анонимных типов не было).

S>Любые нововведения они объявляют изначально ненужными. Но как только эти или аналогичные нововведения таки внедряются в Java, они тут же становятся нужными и верными.

Не совсем. Генерики в Java просили еще с 97 года (http://jcp.org/en/jsr/detail?id=14), только Sun очень консервативно к языку относился (к этому руку MS приложил, кстати). Почти всем было понятно, что они нужны. Я помню, что тестировал первые draft-реализации в 2002 году. В IDEA поддержка draft'ов появилась, кажется, в 2003 (?).

S>Поэтому енумы в жаве нужны, а проперти — нет; анонимные методы — ересь, а анонимные классы — благо; делегаты — извращение, а классы, вложенные в объект — руль и мастхэв. Ну и так далее. Генерики были не нужны вплоть до какой джавы? Вроде бы 1.5, да? Автобоксинг был вреден до какой джавы?

Генерики были зарелизены в 2004 году (вместе с enum'ами, автобоксингом и прочим). Причем до релиза NET2.0, если мне не изменяет память.

Насчет делегатов — вложенные классы (которые могут быть анонимными с 96 года, когда у нас там анонимные делегаты появились в .NET?) обеспечивают абсолютно такой же функционал, только с небольшим синтаксическим оверхедом.

Проперти — уже поздно вводить, все стандартизовались на getter'ах.

S>Не надо сравнивать частные решения с общим подходом.

А это хорошо. В Java все современные популярные у разработчиков технологии (Spring, Hibernate, iBatis, Ant, Maven и т.д.) появились и эволюционировали под влиянием и для решения нужд разработчиков. И в ходе естественного отбора (да-да, эволюция против Intelligent Design) остались только самые удобные и фичастые инструменты.

Причем появились совершенно уникальные продукты, просто невозможные в мире MS.
Sapienti sat!
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 12:54
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Поэтому то линк и рулит.


Это понятно, но это уже не декларативно Не проще было бы обойтись вообще без ифоф? Если у меня пять таких полей, то нужно будет наприсать 10 строчек такого кода. А можно просто перечислить все пять полей в одной. Опять же повторю. Такой паттерн имеет смысл унифицировать, если он действительно часто повторяется. Ради одного-двух раз париться не стоит.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 12:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

Знаешь чего не хватает в твоём примере?

class UI
{
  void OnLoad()
  {
    binder.List = myMapper.select("from c in " + ReadCustomerTableNameFromXml() + " select c").list();
  }
}

Так будет вообще зашибись.

Я уже у Глеба спрашивал, могу тебе задать тот же вопрос. Ты вообще в курсе зачем нужен DAL?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 13:02
Оценка:
Здравствуйте, IT, Вы писали:

IT>
IT>class UI
IT>{
IT>  void OnLoad()
IT>  {
IT>    binder.List = myMapper.select("from c in " + ReadCustomerTableNameFromXml() + " select c").list();
IT>  }
IT>}
IT>

IT>Так будет вообще зашибись.
За такое я в своих проектах делаю строгое пинание — чистое поле для SQL-injection. А вообще — какие проблемы? Я вообще не могу вспомнить когда мне такое могло быть нужно.

IT>Я уже у Глеба спрашивал, могу тебе задать тот же вопрос. Ты вообще в курсе зачем нужен DAL?

Вообще-то да. Поэтому у меня он сведен к минимуму
Sapienti sat!
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 13:07
Оценка:
Здравствуйте, IB, Вы писали:

C>>Можешь назвать технологию MS, которой нет в Java?

IB>Синклер тебе уже все расписал про явовские технологии.
А я ему расписал в чем он не прав.

C>>Нормально работают.

IB>Нормально они работают только для тех, кто ничего другого не замечает.
Что другое? Dataset'ы (The True Way From Microsoft(tm)(r)(c) ) ? В морг их. А больше у нас ничего для работы с данными от MS и нет.

LINQ пока даже не появился.

C>> Который проект уже лично запустил на них.

IB>Успешность проекта — не аргумент. Успешным может быть проект на любой технологии, хоть целиком на ассемблере со вставками из бэйсика для пущего перфоманса и брэйнфака для обфускации — вопрос затраченных усилий и стоимости поддержки.
Ок. Успешные крупные проекты. Blogger.com, например, или Google Adwords.

C>>Посмотри только на всех этих DBA,

IB>DBA-то здесь причем? DBA администрированием занимаются, а не разработкой.
А по сути есть что ответить? Почему Hibernate — морально устарел, а еще более древние РБД — все еще круть?
Sapienti sat!
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: . Великобритания  
Дата: 07.08.07 13:26
Оценка:
IT wrote:

> Знаешь чего не хватает в твоём примере?

> binder.List = myMapper.select("from c in " + ReadCustomerTableNameFromXml() + " select c").list();
А зачем? Ведь hibernate использует не таблицы, а entity, которые уже привязываются к таблицам бд с помощью orm из
.hbm.xml, вот там и описывай привязку, нафиг это в каждый запрос пихать? Надо мух отделять от котлет. Так что
ReadCustomerTableNameFromXml в принципе кривость, и нафиг не нужна.
А в совсем плохих случаях запрос можно собирать объектно.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[50]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 07.08.07 13:29
Оценка:
Здравствуйте, IB, Вы писали:

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


C>>Ок. Успешные крупные проекты. Blogger.com, например, или Google Adwords.

IB>А без разницы, от крупноты тоже ничего не зависит.

Так в чём же сила, брат? (ц)
Или снова про пресловутого Джо?
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.08.07 13:29
Оценка:
Здравствуйте, IT, Вы писали:

IT> Не проще было бы обойтись вообще без ифоф?


Напиши несложный хелпер, будет так:
q = q.ApplyFilter(startDate, (p, x) => p.StartDate >= x);
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.08.07 13:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Назови мне технологию MS, которой нет в Java (кроме десктопно-гуевых, разве что)


CAS, transparent proxy, WCF

C>Насчет делегатов — вложенные классы (которые могут быть анонимными с 96 года, когда у нас там анонимные делегаты появились в .NET?)


Еще один. Анонимные МЕТОДЫ. И анонимные методы это совсем не то же самое, что анонимные классы.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 14:05
Оценка:
Здравствуйте, AndrewVK, Вы писали:

C>>Назови мне технологию MS, которой нет в Java (кроме десктопно-гуевых, разве что)

AVK>CAS, transparent proxy, WCF
CAS — это Code Access Security?

Transparent proxy — это, я так полагаю, то что описано здесь. Рекомендую прочитать первые строчки:

The Java community has had the joy of dynamic proxies since JDK 1.3 and .NET has had its counterpart, the TransparentProxy, since .NET version 1.0. However, the .NET TransparentProxy isn't as easy to use as its Java counterpart. This is why DynamicProxy.NET was made.


WCF — это вот это?

Вторая попытка.

C>>Насчет делегатов — вложенные классы (которые могут быть анонимными с 96 года, когда у нас там анонимные делегаты появились в .NET?)

AVK>Еще один. Анонимные МЕТОДЫ. И анонимные методы это совсем не то же самое, что анонимные классы.
Это философский вопрос. Делаешь интерфейс с одним методом "public <T> T execute(Object ...params)" и все. Да, в .NET меньше синтаксического оверхеда, но это чистый сахар. А в JDK7 вообще очень вероятно появление лямбд и настоящих замыканий.
Sapienti sat!
Re[50]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 14:12
Оценка:
Здравствуйте, IB, Вы писали:

C>>А я ему расписал в чем он не прав.

IB>Он-то как раз прав. А вот явисты уже конкретно задрали, напоминает анекдот про студента, который выучил только про блох, а ему достался билет про лягушку — "Ну что лягушка, четыре лапы, квакает, шерсти нет, а вот если бы была, то вней водились бы блохи, а вот блохи..."
IB>Так и вы со своим гибернейтом.
Я просто не могу упустить случая посмеяться над .NET-итстами.

C>> А больше у нас ничего для работы с данными от MS и нет.

IB>Для работы с данными нужен примитивный маппер, коих навалом.
Примитивный mapper — это будет iBatis. Но это же морально устаревшая технология. Почему же ты их продвигаешь?

C>>LINQ пока даже не появился.

IB>LINQ не для БД.
Ага. А Hibernate — не ORM, а универсальная система работы с данными. Не веришь?

C>>Ок. Успешные крупные проекты. Blogger.com, например, или Google Adwords.

IB>А без разницы, от крупноты тоже ничего не зависит.
Ага. Тогда в качестве антипримера можно взять RSDN — сколько он у нас глючит?

C>> Почему Hibernate — морально устарел,

IB>Потому что изначально тупиковое направление.
Почему тогда RDB — не тупиковое направление?
Sapienti sat!
Re[50]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 14:19
Оценка:
Здравствуйте, EvilChild, Вы писали:

AVK>>>Еще один. Анонимные МЕТОДЫ. И анонимные методы это совсем не то же самое, что анонимные классы.

C>>Это философский вопрос. Делаешь интерфейс с одним методом "public <T> T execute(Object ...params)" и все.
EC>Type safety тебя не заботит?
Ну тогда делаем типизированые интерфейсы. Какие проблемы-то?

К примеру, из моего кода:
JList needsList;
...
        //Focus listener - show info when we're focused
        needsList.addFocusListener(new FocusListener()
        {
            public void focusGained(FocusEvent e)
            {
                infoPanel.add(InfoUtils.createInfoPanel(curEmployee));
            }

            public void focusLost(FocusEvent e)
            {
                infoPanel.removeAll();
            }
        });


Все красиво и типобезопасно.
Sapienti sat!
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.08.07 14:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>CAS — это Code Access Security?


Да.

C>Transparent proxy — это, я так полагаю, то что описано здесь.


Нет.

C> Рекомендую прочитать первые строчки:

C>

C>The Java community has had the joy of dynamic proxies since JDK 1.3 and .NET has had its counterpart, the TransparentProxy, since .NET version 1.0. However, the .NET TransparentProxy isn't as easy to use as its Java counterpart. This is why DynamicProxy.NET was made.


Нет, dynamic proxy это другое. TP возможно реализовать только с помощью рантайма.

C>WCF — это вот это?


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

C>Это философский вопрос. Делаешь интерфейс с одним методом "public <T> T execute(Object ...params)" и все. Да, в .NET меньше синтаксического оверхеда, но это чистый сахар.


Нет, не сахар. Делегаты поддерживаются на уровне рантайма, а в джаве делегатов нет. И в свете ковариантности делегатов и вывода типов анонимные классы выглядят далеко не полноценным заменителем.

C> А в JDK7 вообще очень вероятно появление лямбд и настоящих замыканий.


Если уж LINQ нет, хотя beta 2 уже feature complete, то и лямбд с замыканиями в джаве тоже нет.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: GlebZ Россия  
Дата: 07.08.07 14:40
Оценка:
Здравствуйте, deniok, Вы писали:

D>Отлично пояснил!


D>Если бы все шаги DataReader->DTO->BO->XML->HTML были чистыми и ленивыми, то указание (в любой форме!) фильтрации на HTML стороне автоматически доехало бы до DataReader'а.

Ты знаешь, а такой язык есть. Называется XQuery. Чистый, функциональный язык. Только он не является языком общего назначения, со всеми вытекающими последствиями.

Что касается ленивости, то тут несколько неприятных проблем. Подобные прикладные системы имеют понятия транзакционности(притом и кэша и бд и файлов и многого еще чего). Из чего следует что многие действия должны выполняться в строгой последовательности. А для этого придется иметь императив.
Re[51]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 14:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

EC>>Type safety тебя не заботит?

C>Ну тогда делаем типизированые интерфейсы. Какие проблемы-то?
А как будет решаться следующая проблема с помощью интерфейсов:
в классе есть 2 метода с одинковой сигнатурой и в зависимости от условий надо звать то один, то второй, при наличии извне ссылки на интерфейс.
now playing: Phones — Sharpen The Knives
Re[51]: Являются ли макросы свидетельством недостаточной выр
От: IB Австрия http://rsdn.ru
Дата: 07.08.07 14:59
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я просто не могу упустить случая посмеяться над .NET-итстами.

Поговорку про смех без причины знаешь? Могу напомнить.

C>Примитивный mapper — это будет iBatis.

Он-то как раз не очень примитивный.

C>Ага. А Hibernate — не ORM, а универсальная система работы с данными. Не веришь?

Не верю. Или ты хочешь сказать это в оправдание его кривизны?.. =)

C>Ага. Тогда в качестве антипримера можно взять RSDN — сколько он у нас глючит?

На RSDN глючит железо. А если бы RSDN был написан на яве с гибернейтом, то железа бы требовалось в два раза больше.

C>Почему тогда RDB — не тупиковое направление?

Потому что пока ничего лучше не придумали.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[50]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 15:08
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Нет, dynamic proxy это другое. TP возможно реализовать только с помощью рантайма.

Я не вижу чем это отличается от java.lang.reflect.Proxy или Javassist.

Вообще, .NET и рядом не стоит по библиотекам манипуляции байт-кодами с Java.

C>>WCF — это вот это?

AVK>Релиз уже есть? И, что характерно, там явно указывается что ноги растут из WCF .
Так это просто пакеты с реализацией WS'ов. У JBoss'а тоже что-то есть на эту тему. Честно говоря, я вообще не интересуюсь ими. Так что не слежу совершенно что там и как.

А вообще, в Java есть http://java.sun.com/developer/products/jini/index.jsp — вроде бы функциональный аналог WCF (и появился, что характерно, раньше всего hype'а с WebServices).

C>>Это философский вопрос. Делаешь интерфейс с одним методом "public <T> T execute(Object ...params)" и все. Да, в .NET меньше синтаксического оверхеда, но это чистый сахар.

AVK>Нет, не сахар. Делегаты поддерживаются на уровне рантайма, а в джаве делегатов нет. И в свете ковариантности делегатов и вывода типов анонимные классы выглядят далеко не полноценным заменителем.
Пока сахар. Ковариантность для методоа в Java есть.

Вывода типов пока действительно нет — но Scala это исправляет

C>> А в JDK7 вообще очень вероятно появление лямбд и настоящих замыканий.

AVK>Если уж LINQ нет, хотя beta 2 уже feature complete, то и лямбд с замыканиями в джаве тоже нет.
Ну да, в Java есть Hibernate и его поддержка в IDEA — что еще для счастья нужно?
Sapienti sat!
Re[52]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 15:17
Оценка:
Здравствуйте, IB, Вы писали:

C>>Я просто не могу упустить случая посмеяться над .NET-итстами.

IB>Поговорку про смех без причины знаешь? Могу напомнить.


C>>Ага. А Hibernate — не ORM, а универсальная система работы с данными. Не веришь?

IB>Не верю. Или ты хочешь сказать это в оправдание его кривизны?.. =)
Почему? В Hibernate подключаешь любой провайдер — и работаешь с любым источником данных. Вот, для XML, например: http://www.hibernate.org/hib_docs/reference/en/html/xml.html

C>>Ага. Тогда в качестве антипримера можно взять RSDN — сколько он у нас глючит?

IB>На RSDN глючит железо. А если бы RSDN был написан на яве с гибернейтом, то железа бы требовалось в два раза больше.
Зато бы работало

У меня вот тоже в кластере железо пару раз подглючивало (RAID-карты оказались кривыми). И ничего, все работало — клинеты даже ничего не замечали, все прозрачно делало failover.

C>>Почему тогда RDB — не тупиковое направление?

IB>Потому что пока ничего лучше не придумали.
Объектные и гибридные базы, например.
Sapienti sat!
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: deniok Россия  
Дата: 07.08.07 15:22
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Ты знаешь, а такой язык есть. Называется XQuery. Чистый, функциональный язык. Только он не является языком общего назначения, со всеми вытекающими последствиями.


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


Не уверен. Мы можем описывать только ожидаемый результат. А последовательностью исполнения пускай занимается оптимизатор. Ты же не указываешь порядок JOIN'ов в SQL, когда их несколько?

А с транзакционностью можно тоже работать чисто и лениво — см. Software Transactional Memory (STM), и, в частности, Beautiful concurrency (уже вроде обсуждали в Философии).
Re[52]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 15:22
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>>>Type safety тебя не заботит?

C>>Ну тогда делаем типизированые интерфейсы. Какие проблемы-то?
EC>А как будет решаться следующая проблема с помощью интерфейсов:
EC>в классе есть 2 метода с одинковой сигнатурой и в зависимости от условий надо звать то один, то второй, при наличии извне ссылки на интерфейс.
Можно пример на делегатах?
Sapienti sat!
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 15:36
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


EC>>>>Type safety тебя не заботит?

C>>>Ну тогда делаем типизированые интерфейсы. Какие проблемы-то?
EC>>А как будет решаться следующая проблема с помощью интерфейсов:
EC>>в классе есть 2 метода с одинковой сигнатурой и в зависимости от условий надо звать то один, то второй, при наличии извне ссылки на интерфейс.
C>Можно пример на делегатах?
Давай по-другому. Я на джаве не пишу и могу что-то путать. Поэтому прошу уточнения.
Чтобы позвать метод некого объекта в джаве, не зная точный тип объекта ты что делаешь?
Объявляешь интерфейс с одним методом с подходящей сигнатурой и реализуешь его в отдельном классе или в классе, метод которого надо позвать?
now playing: Kavinsky — Testarossa (Sebastian Remix)
Re[54]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 15:39
Оценка:
Здравствуйте, EvilChild, Вы писали:

C>>Можно пример на делегатах?

EC>Давай по-другому. Я на джаве не пишу и могу что-то путать. Поэтому прошу уточнения.
EC>Чтобы позвать метод некого объекта в джаве, не зная точный тип объекта ты что делаешь?
То есть? Используешь обычный полиморфизм.

EC>Объявляешь интерфейс с одним методом с подходящей сигнатурой и реализуешь его в отдельном классе или в классе, метод которого надо позвать?

Я уже совсем запутался. Можешь все-таки пример привести? Хотя бы на псевдокоде.
Sapienti sat!
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 15:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

IT>>Я уже у Глеба спрашивал, могу тебе задать тот же вопрос. Ты вообще в курсе зачем нужен DAL?

C>Вообще-то да. Поэтому у меня он сведен к минимуму

Если ты его сводишь к минимуму, продемонстрированными выше способами, то это собственного говоря то, откуда 10 лет назад начали бежать и в результате прибежали к такому понятию как DAL.
Если нам не помогут, то мы тоже никого не пощадим.
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 15:58
Оценка:
Здравствуйте, ., Вы писали:

>> binder.List = myMapper.select("from c in " + ReadCustomerTableNameFromXml() + " select c").list();

.>А зачем?

Затем, что никто не сможет удержать разработчика сделать не только такое, но такое от чего потом волосы будут стоять дыбом не только на голове.
Если нам не помогут, то мы тоже никого не пощадим.
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.08.07 16:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

EC>>в классе есть 2 метода с одинковой сигнатурой и в зависимости от условий надо звать то один, то второй, при наличии извне ссылки на интерфейс.

C>Можно пример на делегатах?

class A
{
    private bool Foo() {...}
    private bool Bar() {...}
    
    static void Main()
    {
        bool flag = ...;
        var x = "abcdef".Find(flag ? Foo : Bar);
    }
}
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[55]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 16:05
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я уже совсем запутался. Можешь все-таки пример привести? Хотя бы на псевдокоде.

Ты таки заставил меня запустить Visual Studio
Типа так:
using System;

namespace Cyberax
{
    class Program
    {
        static void Main(string[] args)
        {
            Test2 t = new Test2();
            t.Action(1);
        }
    }

    class Test
    {
        public void Method1(int i)
        {
        }

        public void Method2(int i)
        {
        }
    }

    class Test2
    {
        private readonly Test _t = new Test();

        public Action<int> Action
        {
            get { return DateTime.Now.Second > 10 ? new Action<int>(_t.Method1) : new Action<int>(_t.Method2); }
        }
    }
}


Где Action это:
public delegate void Action<T>(T obj);
now playing: My My — Butterflies & Zebras
Re[51]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.08.07 16:14
Оценка:
Здравствуйте, Cyberax, Вы писали:

AVK>>Нет, dynamic proxy это другое. TP возможно реализовать только с помощью рантайма.

C>Я не вижу чем это отличается от java.lang.reflect.Proxy или Javassist.

Если ты не видишь, это не значит что проблем нет. Вот тебе псевдокод:
var x = GetProxy(...);
var y = x as Y;
Console.WriteLine(y == null); // false
y.AppendContract(typeof (Y));
var y = x as Y;
Console.WriteLine(y == null); // true

Такое ни на каких отдельно сгенеренных проксях ты не сделаешь.

C>Вообще, .NET и рядом не стоит по библиотекам манипуляции байт-кодами с Java.


TransparentProxy это не манипуляция байткодами, это CLR, сколько можно повторять?

AVK>>Релиз уже есть? И, что характерно, там явно указывается что ноги растут из WCF .

C>Так это просто пакеты с реализацией WS'ов. У JBoss'а тоже что-то есть на эту тему. Честно говоря, я вообще не интересуюсь ими.

Это и видно.
C>А вообще, в Java есть http://java.sun.com/developer/products/jini/index.jsp — вроде бы функциональный аналог WCF (и появился, что характерно, раньше всего hype'а с WebServices).

Если это функциональный аналог, зачем тогда Tango Project?

C>Вывода типов пока действительно нет — но Scala это исправляет


А при чем тут Scala?
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 07.08.07 16:21
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Плохо объясняешь? Если ты словами задачу и проблему объяснить понятным образом не можешь,

А может просто ты не хочешь принять то что нет способа объехать данный комбинаторный взрыв?
Нужно же как-то доказать самому себе что макросы не нужны.

G>то каково то по твоему коду будет разбирать, интересно? С мега-макросами и всем прочим.

А мой код очень простой.
Причем он простой именно благодоря макросам.
Хотя не только. Я еще использовал визитеры, замыкания и немного зашаблонил.

Обязьянка конечно не поймет но их к разработке это либы и близко не подпустят.
А при использовании этой либы есть просто класс Image и набор свободных функций который этот Image плющат. И никаких макросов и прочего.

В любом случае понять почему альгоритмы (при реализации которых напрямую макросы не использованы) реализованны именно так, а не иначе будет во много раз сложнее чем понять как работают макросы снижающие сложность обвязки.
Те человек без опыта работы с изображениями разбирется с макрами за пол дня максимум, а на алгоритмы будет еще как минимум пол года смотреть непонимающими глазами.
Некоторые алгоритмы я и сам не понимаю я их просто скопипастил и причесал под мою обвязку.

G>Почему их несколько, а не один?

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

G>Не может такого быть, чтобы по другому было нельзя.

С потерей эффективности и точности можно. Но это не мой путь.

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

Работаю я в основном с плавучкой.
Но:
1)Я не в вакууме работаю
2)Некоторым алгоритмам пофигу с каким именно цветовым пространством они работают.
Те я могу загрузить картинку, повернуть ее на 90 градусов, увеличить в 2 раза (point sampler'ом) и сохранить.
При этом ни разу не приведя картинку в пространство с плавающей точкой.
Причем если дело дойдет до плавучки то придется не только приводить к плавучке но и производить нелениейные коррекции, а если есть альфа то еще и домножать каналы на занчение альфы..., а потом обратно...
3)Некоторым алгоритмам нужны битмапы с низкой разрядностью.
...

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

Тогда теряется контроль компилятора.
А это критично. Ибо если использовать цвета которые скоректированны не так то полезут артефакты.
А делать коррекции на каждый чих это очень дорого.
Я пробовал.
Это просадило библиотеку и по скорости и по объему и по запутанности кода.

G>Приведи пример двух разных RGB, если тебя не затруднит.

Линейное и прецептурно линейное. Отличаются грубо говоря гамма-коррекцией (реально там болие сложная зависимость но гамма-коррекция дает неплохое приближение).
Путать их нельзя. Иначе полезут артефакты.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[56]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 16:26
Оценка:
Здравствуйте, EvilChild, Вы писали:


C>>Я уже совсем запутался. Можешь все-таки пример привести? Хотя бы на псевдокоде.

EC>Ты таки заставил меня запустить Visual Studio
EC>Типа так:
EC>
EC>using System;
EC>namespace Cyberax
EC>{
EC>    class Program
EC>    {
EC>        static void Main(string[] args)
EC>        {
EC>            Test2 t = new Test2();
EC>            t.Action(1);
EC>        }
EC>    }

EC>    class Test
EC>    {
EC>        public void Method1(int i)
EC>        {
EC>        }

EC>        public void Method2(int i)
EC>        {
EC>        }
EC>    }

EC>    class Test2
EC>    {
EC>        private readonly Test _t = new Test();

EC>        public Action<int> Action
EC>        {
EC>            get { return DateTime.Now.Second > 10 ? new Action<int>(_t.Method1) : new Action<int>(_t.Method2); }
EC>        }
EC>    }
EC>}
EC>

Пишу без IDE (Винду переустановил, блин), так что могут быть мелкие синтаксические ошибки:
public class Main
{
    public static void main(String []args)
    {
        Test2 t=new Test2();
        t.getAction(1).act();
    }

}

class Test
{

    public void method1(int i)
    {
    }

    public void method2(int i)
    {
    }
}

interface Action<T>
{
    void act(T param);
}

class Test2
{
    private final Test t = new Test();

    public Action<T> getAction()
    {
        if ((System.currentTimeMillis() % 10)==0)
            return new Action<Integer>(){int act(){t.method1(param);}};
        else
            return new Action<Integer>(){int act(){t.method2(param);}};
    }
}
Sapienti sat!
Re[54]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 16:28
Оценка:
Здравствуйте, AndrewVK, Вы писали:

C>>У меня вот тоже в кластере железо пару раз подглючивало (RAID-карты оказались кривыми). И ничего, все работало — клинеты даже ничего не замечали, все прозрачно делало failover.

AVK>Так мы тоже можем failover сделать. Оплатишь?
Если вам нужно сделать failover — без проблем, мы вам готовы переписать сервер Только платить вы должны.

Кстати, какое отношение имеет железо к постоянным проблемам типа: "не могу подсоединиться к SQL-серверу" или "сборка не найдена"?
Sapienti sat!
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 16:30
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>Я уже у Глеба спрашивал, могу тебе задать тот же вопрос. Ты вообще в курсе зачем нужен DAL?

C>>Вообще-то да. Поэтому у меня он сведен к минимуму
IT>Если ты его сводишь к минимуму, продемонстрированными выше способами, то это собственного говоря то, откуда 10 лет назад начали бежать и в результате прибежали к такому понятию как DAL.
Фига.

Двухуровневые системы были плохими из-за прямой работы с данными в коде UI. У меня идет прямая работа с бизнес-объектами, а mapping'ом их на базу данных занимается Hibernate. Всякие security и прочее обеспечиваются с помощью interceptor'ов, тоже подключаемых к Hibernate.
Sapienti sat!
Re[55]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.08.07 16:45
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Если вам нужно сделать failover — без проблем, мы вам готовы переписать сервер Только платить вы должны.


Мы и сами перепишем. Если намек не понят, поясню: RSDN проект некоммерческий, поэтому никакого файловера на нем нет и не будет.

C>Кстати, какое отношение имеет железо к постоянным проблемам типа: "не могу подсоединиться к SQL-серверу" или "сборка не найдена"?


Прямое. Рвется постоянно связь между серверами из-за глюков сетевой карты на одном из них.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[57]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 16:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

    return new Action<Integer>(){int act(){t.method2(param);}};


Можешь эту строку пояснить? Особенно интересует выделенное.
Я правильно понял, что экземпляр интерфейса по new создать можно или это что-то другое?
now playing: B-Movie — Nowhere Girl (Adam Freeland Mix)
Re[56]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 16:55
Оценка:
Здравствуйте, AndrewVK, Вы писали:

C>>Если вам нужно сделать failover — без проблем, мы вам готовы переписать сервер Только платить вы должны.

AVK>Мы и сами перепишем. Если намек не понят, поясню: RSDN проект некоммерческий, поэтому никакого файловера на нем нет и не будет.
А как это связано? Slashdot вот тоже некоммерческий, а failover на нем есть. Если надо новый сервер — я думаю, что уж пара десятков человек скинется по $100.

C>>Кстати, какое отношение имеет железо к постоянным проблемам типа: "не могу подсоединиться к SQL-серверу" или "сборка не найдена"?

AVK>Прямое. Рвется постоянно связь между серверами из-за глюков сетевой карты на одном из них.
Так поставьте SQL-сервер на одну машину с сайтом.
Sapienti sat!
Re[59]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 17:17
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет, ты создаешь анонимный класс, реализующий интерфейс Action.


Я просто не в курсе был, что есть такой приятный сахар. Здорово.
Но с делегатами всё равно код короче. В большинстве случаев тип делегата можно не указывать.
Но в твоём случае нет платы за мультикастовость (которая есть в делегатах), что лучше.
Так, что, то на то.
now playing: Swayzak — Leisure Centre
Re[54]: Являются ли макросы свидетельством недостаточной выр
От: . Великобритания  
Дата: 07.08.07 17:21
Оценка:
AndrewVK wrote:

> C>Можно пример на делегатах?

> class A
> {
>     private bool Foo() {...}
>     private bool Bar() {...}
>     
>     static void Main()
>     {
>         bool flag = ...;
>         var x = "abcdef".Find(flag ? Foo : Bar);
>     }
> }


А это рабочий пример??? Для какого экземляра A будут вызываться Foo/Bar из Find?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[60]: Являются ли макросы свидетельством недостаточной выр
От: . Великобритания  
Дата: 07.08.07 17:26
Оценка:
EvilChild wrote:

> C>Нет, ты создаешь *анонимный класс*, реализующий интерфейс Action.

> Я просто не в курсе был, что есть такой приятный сахар. Здорово.
Не совсем уж и сахар. Главное — возможность определять классы внутри методов, притом с локальным конекстом. Как такое
делается в c#?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[60]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 17:30
Оценка:
Здравствуйте, EvilChild, Вы писали:

C>>Нет, ты создаешь анонимный класс, реализующий интерфейс Action.

EC>Я просто не в курсе был, что есть такой приятный сахар. Здорово.
EC>Но с делегатами всё равно код короче. В большинстве случаев тип делегата можно не указывать.
Тут по-хорошему, нужен вывод типов.

Overhead, кстати, не так напрягает — IDE помогает. В IDEA это пишется так new Action()-ctrl-shift-space, выбрать implement methods. И пишешь реализацию.

EC>Но в твоём случае нет платы за мультикастовость (которая есть в делегатах), что лучше.

EC>Так, что, то на то.
Мультикастовость, кстати, в Java обычно тупо реализуют в вызывающем контейнере с помощью множества обработчиков.
Sapienti sat!
Re[52]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 17:42
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Если ты не видишь, это не значит что проблем нет. Вот тебе псевдокод:

AVK>
AVK>var x = GetProxy(...);
AVK>var y = x as Y;
AVK>Console.WriteLine(y == null); // false
AVK>y.AppendContract(typeof (Y));
AVK>var y = x as Y;
AVK>Console.WriteLine(y == null); // true
AVK>

AVK>Такое ни на каких отдельно сгенеренных проксях ты не сделаешь.
Классно. А где об этом можно почитать? В документации к RealProxy я не вижу возможности динамически добавлять реализуемые типы.

C>>А вообще, в Java есть http://java.sun.com/developer/products/jini/index.jsp — вроде бы функциональный аналог WCF (и появился, что характерно, раньше всего hype'а с WebServices).

AVK>Если это функциональный аналог, зачем тогда Tango Project?
Для интероперабельности, у них же написано.

JINI, кстати, не особо популярен. Видимо, разработчики усвоили главное правило распределенного программирования: "Do not distribute".

C>>Вывода типов пока действительно нет — но Scala это исправляет

AVK>А при чем тут Scala?
Есть мнение, что она может стать официальным продолжателям Java. Кстати, еще и JavaFX подкатывается.
Sapienti sat!
Re[61]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 17:44
Оценка:
Здравствуйте, ., Вы писали:

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

.>делается в c#?
Методы можно. Мне кажется этого достаточно, если знаешь когда нет, то приведи пример.
now playing: Etienne De Crecy — Fuck
Re[61]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 17:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Тут по-хорошему, нужен вывод типов.

Он в каком-то виде присутствует, просто в том случае компилятор почему-то не может.

C>Мультикастовость, кстати, в Java обычно тупо реализуют в вызывающем контейнере с помощью множества обработчиков.

А можешь привести минимальный пример реализации мультикастового события? Там контейнер обработчиков вручную ведётся?
now playing: Adam Freeland — Silverlake Pills
Re[61]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 17:51
Оценка:
Здравствуйте, ., Вы писали:

.>Не совсем уж и сахар.

Насколько я знаю, компилятор создаст скрытый класс для твоего анонимного класса.
Если это так, то это сахар в чистом виде.
now playing: Kim — By The Time They Reach You (Bagraiders Mix)
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 17:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

AVK>>А при чем тут Scala?

C>Есть мнение, что она может стать официальным продолжателям Java. Кстати, еще и JavaFX подкатывается.
Т.е. санки всерьёз ею заинтересовались?
now playing: Kim — By The Time They Reach You (Bagraiders Mix)
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 18:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Двухуровневые системы были плохими из-за прямой работы с данными в коде UI.


Ещё раз специально для самых одарённых. Проблемы работы с данными в коде UI нет, так же как и нет проблемы при чтении этих данных, например, из коллекции сериализованных объектов. Проблема в том, что работа ведётся с нетипизированными данными. В этом случае у нас пропадает контроль со стороны компилятора. Постарайся понять эту разницу и не путать причину и следствие.

C>У меня идет прямая работа с бизнес-объектами, а mapping'ом их на базу данных занимается Hibernate. Всякие security и прочее обеспечиваются с помощью interceptor'ов, тоже подключаемых к Hibernate.


В твоём примере ты делаешь точно тоже, что делалось 10 лет назад — ты используешь нетипизированную работу с данными.
Если нам не помогут, то мы тоже никого не пощадим.
Re[62]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 18:03
Оценка:
Здравствуйте, EvilChild, Вы писали:

.>>Не совсем уж и сахар.

EC>Насколько я знаю, компилятор создаст скрытый класс для твоего анонимного класса.
EC>Если это так, то это сахар в чистом виде.
Не совсем, там еще пара хаков в JVM есть для того, чтобы это все работало

А так да, по большей части сахар.
Sapienti sat!
Re[54]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 18:05
Оценка:
Здравствуйте, EvilChild, Вы писали:

AVK>>>А при чем тут Scala?

C>>Есть мнение, что она может стать официальным продолжателям Java. Кстати, еще и JavaFX подкатывается.
EC>Т.е. санки всерьёз ею заинтересовались?
Намного лучше: IDEA'вцы http://plugins.intellij.net/preview/popup/?sid=370&amp;pid=1347

Исторически так сложилось, что от сантехники следуют за Java community, откуда и приходят все интересные идеи.
Sapienti sat!
Re[63]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 18:11
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Не совсем, там еще пара хаков в JVM есть для того, чтобы это все работало

Можешь ссылку дать или сам рассказать в 2х словах?
now playing: Oliver Huntermann — 37 Degrees
Re[62]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 18:13
Оценка:
Здравствуйте, EvilChild, Вы писали:

C>>Мультикастовость, кстати, в Java обычно тупо реализуют в вызывающем контейнере с помощью множества обработчиков.

EC>А можешь привести минимальный пример реализации мультикастового события? Там контейнер обработчиков вручную ведётся?
Да. Тупо делаются методы addBlahBlahListener и removeBlahBlahListener. Неэстетично, зато дешево, надежно и практично.
Sapienti sat!
Re[63]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 18:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Да. Тупо делаются методы addBlahBlahListener и removeBlahBlahListener. Неэстетично, зато дешево, надежно и практично.

С этим понятно: аналоги += и -=. Хотя всё равно лишняя возня, которую за тебя может компилятор сделать.
Контейнер, где хранятся подписчики сам создаёшь и рулишь им?
now playing: Phones — Sharpen The Knives
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 18:23
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я уже привел пример с Hibernate. Почти весь DAL концентрируется в отдельной библиотеке, в результате в основном коде можно не волноваться о мелочах. Статическая проверка тоже в большинстве случаев нормально делается.


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

C>Ужжжас, а не пример.

C>Откуда мы берем соединение для работы с Cusomer'ом?

Можно подумать для работы с хибернейт нужно каждый раз по месту читать конфиги и открывать соединения с БД.

C>Что будет при навигации по связям от него?


Зачем мне куда-то нафигировать?

C>Вернется ли нам disconnected dataset?


Для веба можно вообще не возвращать никаких данных, а отмапить датаридер непосредственно в http response. У меня такой фигнёй занимается один контрол, рисующий отчёты. Мегобайты хэтэмээля отлетают со свистом абсолютно не нагружая при этом сервер. А вот экспорт в excel, который требует построения определённой структуры данных в памяти уже заметно просаживает сервер как по памяти, так и по CPU.

Отчёт, кстати, динамический. Пользователи сами определяют его вид, бродят по нему и дрилдаунят во все стороны. Потом строится SQL и результат рендерится в response. Прошу обратить внимание, никакого хибернейта при этом не используется.

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

private void Map<T>(IEnumerable list)
{
    BLToolkit.Mapping.Map.SourceListToDestinationList(
        new EnumeratorMapper(list.GetEnumerator()),
        new TextDataListMapper(new TextDataWriter(Response.Output, typeof(T))));

    Response.Output.Flush();
}

Тип объекта здесь нужен исключительно для того, чтобы обеспечить маппер метаданными. Если вместо EnumeratorMapper у нас будет DataReaderMapper, то опять же данные из ридера будут не задерживаясь уезжать в сеть. EnumeratorMapper используется лишь по причине того, что данные нужно кешировать.

C>Какой пользователь используется для работы с данными?


Я не знаю как там у вас в хибернейте, но у нас в дотнете пользователя всегда можно вытащить из текущего контекста без всяких проблем.
Если нам не помогут, то мы тоже никого не пощадим.
Re[61]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 18:28
Оценка:
Здравствуйте, ., Вы писали:

.>Не совсем уж и сахар. Главное — возможность определять классы внутри методов, притом с локальным конекстом. Как такое

.>делается в c#?

В C# замыкания выглядят так, как к ним давно привыкли функциональщики во всём мире. При это никто специально не хакал CLR, чтобы обеспечить возможность захвата контекста.
Если нам не помогут, то мы тоже никого не пощадим.
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 18:28
Оценка:
Здравствуйте, IT, Вы писали:

IT>А вот экспорт в excel, который требует построения определённой структуры данных в памяти уже заметно просаживает сервер как по памяти, так и по CPU.


Документ как создаёшь? Через XML?
now playing: Kavinsky — Testarossa (Sebastian Remix)
Re[63]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 07.08.07 18:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Не совсем, там еще пара хаков в JVM есть для того, чтобы это все работало


Расскажи про хаки.
Единственное упоминание об inner и anonymouse классах — это пара необязательных аттрибутов в классе (исключительно для дебаггера), и методы в Class (isInner() и т.п.) возвращающие результат на основании имени класса (гы).
Ты знаешь что-то ещё?
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[64]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 18:34
Оценка:
Здравствуйте, mkizub, Вы писали:

C>>Не совсем, там еще пара хаков в JVM есть для того, чтобы это все работало

M>Расскажи про хаки.
В ru.java было обсуждение (в котором ты, AFAIR, принимал участие ) — поля в проксиках инициализируются раньше вызова суперконструктора, для этого им хак в верификатор пришлось поставить. И еще один подобный хак есть, но я его не могу вспомнить.
Sapienti sat!
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 18:35
Оценка:
Здравствуйте, EvilChild, Вы писали:

IT>>А вот экспорт в excel, который требует построения определённой структуры данных в памяти уже заметно просаживает сервер как по памяти, так и по CPU.


EC>Документ как создаёшь? Через XML?


Нет. Используется какая-то платная библиотечка. Через XML тоже создавал, но результат был много хуже. Один процессор на сервере стабильно зашкаливал за 100%.
Если нам не помогут, то мы тоже никого не пощадим.
Re[64]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 18:51
Оценка:
Здравствуйте, EvilChild, Вы писали:

C>>Да. Тупо делаются методы addBlahBlahListener и removeBlahBlahListener. Неэстетично, зато дешево, надежно и практично.

EC>С этим понятно: аналоги += и -=. Хотя всё равно лишняя возня, которую за тебя может компилятор сделать.
EC>Контейнер, где хранятся подписчики сам создаёшь и рулишь им?
Ага. Обычно так и пищут:
Set<SomeListener> listeners=new HashSet<SomeListener>();
void addSomeListener(SomeListener listener)
{
   listeners.add(listener);
}
...


Это просто очень нечасто нужно бывает.
Sapienti sat!
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 18:53
Оценка:
Здравствуйте, IT, Вы писали:

C>>Двухуровневые системы были плохими из-за прямой работы с данными в коде UI.

IT>Ещё раз специально для самых одарённых. Проблемы работы с данными в коде UI нет, так же как и нет проблемы при чтении этих данных, например, из коллекции сериализованных объектов. Проблема в том, что работа ведётся с нетипизированными данными. В этом случае у нас пропадает контроль со стороны компилятора. Постарайся понять эту разницу и не путать причину и следствие.
Я тебе в который (пятый?) раз говорю, что можно для большинства запросов Hibernate сделать контроль типов с помощью плугина к IDE. И это уже сделано. И это уже работает.

Для байндинга так вообще типизированность обычно пофиг — grid'у все равно что отображать, главное чтобы порядок правильный был.

C>>У меня идет прямая работа с бизнес-объектами, а mapping'ом их на базу данных занимается Hibernate. Всякие security и прочее обеспечиваются с помощью interceptor'ов, тоже подключаемых к Hibernate.

IT>В твоём примере ты делаешь точно тоже, что делалось 10 лет назад — ты используешь нетипизированную работу с данными.
У меня возвращается List<BusinessObject>, который вполне типизирован.
Sapienti sat!
Re[63]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 19:02
Оценка:
Здравствуйте, ., Вы писали:

.>Разница есть на уровне детализации. Интерфейс может содержать несколько методов, их удобнее переопределять пачкой,

.>скажем событие FocusObserver имеет два метода — onFocus/onBlur. Ну и класс может содержать собственное состояние.
.>Скажем:
.>
.>...
.>FocusObserver fo = new FocusObserver()
.>{
.>    int howMuch = 0;
.>    onFocus(){++howMuch;}
.>    onBlur(){killUser();}
.>};
.>control.setObserver(fo);
.>control.kick();
.>if(fo.howMuch...)
.>...
.>

В таком случае можно и неанонимный приватный класс завести. В чём преимущество анонимности в данном случае?
В C# можно объявить анонимные методы, причём там можно захватывать лексический контекст,
что устраняет необходимость делать эти методы членами одного класса.
now playing: Swayzak — Kensai Rising
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 07.08.07 19:06
Оценка:
Здравствуйте, IT, Вы писали:

C>>Я уже привел пример с Hibernate. Почти весь DAL концентрируется в отдельной библиотеке, в результате в основном коде можно не волноваться о мелочах. Статическая проверка тоже в большинстве случаев нормально делается.

IT>Ты привёл пример, использующий строковые константы. Какая нафиг статическая проверка? Или ты думаешь, что достаточно замазать в одном месте и точно такие же ошибки в другом месте не вызовут проблем?
ИНСПЕКЦИИ IDE! У меня даже строковые регэкспы инспекциями проверяются.

C>>Ужжжас, а не пример.

C>>Откуда мы берем соединение для работы с Cusomer'ом?
IT>Можно подумать для работы с хибернейт нужно каждый раз по месту читать конфиги и открывать соединения с БД.
Нет. У меня есть четко выраженая сессия, с которой я явно работаю.

C>>Что будет при навигации по связям от него?

IT>Зачем мне куда-то нафигировать?
Просто так...

C>>Вернется ли нам disconnected dataset?

IT>Для веба можно вообще не возвращать никаких данных, а отмапить датаридер непосредственно в http response. У меня такой фигнёй занимается один контрол, рисующий отчёты. Мегобайты хэтэмээля отлетают со свистом абсолютно не нагружая при этом сервер. А вот экспорт в excel, который требует построения определённой структуры данных в памяти уже заметно просаживает сервер как по памяти, так и по CPU.
Это все понятно, тут никаких проблем нет. Используй StatelessSession — у нас она для синхронизации гигабайтовых баз используется.

IT>Отчёт, кстати, динамический. Пользователи сами определяют его вид, бродят по нему и дрилдаунят во все стороны. Потом строится SQL и результат рендерится в response. Прошу обратить внимание, никакого хибернейта при этом не используется.

А у нас точно такое же, но при этом в отчете идет сложная аналитика, которая на SQL просто не реализуется нормально (поиск лучшего расписания, например).

IT>
IT>private void Map<T>(IEnumerable list)
IT>{
IT>    BLToolkit.Mapping.Map.SourceListToDestinationList(
IT>        new EnumeratorMapper(list.GetEnumerator()),
IT>        new TextDataListMapper(new TextDataWriter(Response.Output, typeof(T))));
IT>    Response.Output.Flush();
IT>}
IT>

IT>Тип объекта здесь нужен исключительно для того, чтобы обеспечить маппер метаданными. Если вместо EnumeratorMapper у нас будет DataReaderMapper, то опять же данные из ридера будут не задерживаясь уезжать в сеть. EnumeratorMapper используется лишь по причине того, что данные нужно кешировать.
Это все мелочи, не вижу тут никаких проблем. Для меня многомегабайтные отчеты — далеко не самый интересный частный случай, это все рутина.

Другое дело сложные алгоритмы или, например, система со сложными взаимосвязями (сейчас их задаем с помощью движка правил) — без ORM можно повеситься.

C>>Какой пользователь используется для работы с данными?

IT>Я не знаю как там у вас в хибернейте, но у нас в дотнете пользователя всегда можно вытащить из текущего контекста без всяких проблем.
"Контекст" — это ЗЛО. Мы используем глобальную/thread-local переменную. А если я захочу с двумя источниками данных работать?
Sapienti sat!
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 07.08.07 19:11
Оценка:
Здравствуйте, awson, Вы писали:

A>Я линком никогда не пользовался, но знаю, что он вырос из embedded dsls типа haskelldb. Еще я вижу код Sinclair. Из всего этого я заключаю, что queries в linq являются composable, т.е., попросту говоря, first-class.

Ага, Erik Meijer даже как-то объяснял что ноги у него растут из монад.
now playing: Swayzak — Kensai Rising
Re[64]: Являются ли макросы свидетельством недостаточной выр
От: . Великобритания  
Дата: 07.08.07 19:23
Оценка:
EvilChild wrote:

> В таком случае можно и неанонимный приватный класс завести. В чём

> преимущество анонимности в данном случае?
Тем что оно анонимно , т.е. имя не надо придумывать. Если тебе нужно переопределить фокусы у пяти контролов, тебе
придётся придумать имена для каждого именованного класса. И если этот класс используется только в одном блоке, то
неоправданно расширяется область видимости класса.

> В C# можно объявить анонимные методы, причём там можно захватывать

> лексический контекст,
> что устраняет необходимость делать эти методы членами одного класса.
Но со структурной т.з. всё-таки поудобнее, имхо. Контекст изменяемый сразу виден — то что внутри класса. Можно
группировать события, скажем, события от клавиатуры (keyup/down/press), от мыши (mouseup/down/hover) и т.п.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 20:14
Оценка:
Здравствуйте, awson, Вы писали:

A>Я линком никогда не пользовался, но... все (может быть, почти все — точно не проверял) Ваши высказывания на эту тему идут лесом. Привет.


Спасибо, друг! Повеселил!
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: GlebZ Россия  
Дата: 07.08.07 20:33
Оценка:
Здравствуйте, IT, Вы писали:

GZ>>Факты в виде цифр есть?

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

IT>pass-through как термин существует вне зависимости от линка. Это объективная реальность, присутствующая в большинтсве правильно спроектированных проектах, в которых логика диктуется UI.

У меня не присутвует. Всегда есть какие-то довески. Что я делаю неправильно?

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

IT>Макросы как альтернативу линку я привёл лишь в качестве примера. Мысль состоит в том, что на макросах можно было бы сделать такой же линк и даже лучше, но ещё вчера.
На сегодня нет ни релиза Nemerle, ни Go Live лицензии линки. Поэтому можно говорить только о завтра.

IT>И ООП и макросы — это иструменты. Сравнивать нужно не их, а результаты их применения. А уж известность подводных камней как преимущество — это вообще здорово. Ты никогда не пробовал решать проблемы, а не коллекционировать их, описывать и классифицировать?

Соберем все грабли и посчитаем шишки? Очень не хотелось бы на коммерч. проектах пользоваться этим советом.

GZ>>>>LINQ2SQL — можно считать заменителем или хелпером для DAL.

IT>>>Ты вообще в курсе для чего нужен DAL?
GZ>>Получение(изменение) данных, и трансформация из модели источника к логической модели и наоборот.
IT>Ответ неверный. DAL нужен для изоляции кода, работающего с БД от остальных частей приложения. Ключевое слово здесь изоляция.
Ответ как раз верный. Изоляция — это уже средство.

IT>При этом DAL не решает проблему полностью. С помощью DAL мы загоняем её в дальний угол, где её можно лучше контролировать. Но не более того. Проблема всё ещё существует.


IT>Что делает линк. Линк позволяет работать с БД в терминах основного языка, компилятор которого теперь может на 100% контролировать правильность кода работы с БД ещё в компайлтайм.

Не точно так. Правильность кода на соответсвие метаданным.
IT>Это происходит потому, что линк не оперирует строками, а исключительно строготипизированными метаданными. Кстати, на макросах можно было бы пойти ещё дальше — автоматически синхронизировать эти метаданные с БД во время компайл-тайм.
Уже лучше. Только полностью синхронизировать не удастся. Реляционные метаданные недостаточны. Можно только проверить соответсвие. И это можно сделать вполне внешними средствами.

IT>Так вот, теперь подумай, если проблема, которую раньше решал DAL исчезла, то зачем нужен сам DAL?

IT>>>
IT>>>class UI
IT>>>{
IT>>>  void OnLoad()
IT>>>  {
IT>>>    binder.List = from c in Customer select c;
IT>>>  }
IT>>>}
IT>>>

GZ>>Пример достойный example или простейшего проекта.

IT>О! Видишь что с людями делает декларативщина? Тебе этот код кажется примитивным? Правильно. А почему? Да потому что в нём нет ничего лишнего. Ни одного лишнего элемента. Учитывая, что в обычном коде мусора как правило больше половины, то смотря на такой код хочется зажмурится, как когда смотришь на яркий свет. Что-то тут не так, где-то нас обманывают. Только с декларативностью можно добиться такого примитивизма.

Чудный примитивизм. А если вспомнить что еще есть кластерный транзакционный кэш, то примитив улетучивается.

IT>Я уже показывал выше. Впрочем, вот копипейст:


IT>
IT>grid.Source = from c in customers   
IT>              join o in orders on c equals o.Customer into oo   
IT>              select new { c.CompanyName, OrderCount = oo.Count()
IT>

IT>Идея в том, что структура возращаемая запросом является одноразовой. Используя слои ты вынужден объявлять такие структуры в публичном интерфейсе. Но для публичного интерфейса такие структуры не более чем мусор.
Это не есть то, что я спрашивал. Например, для администратора нужен фильтр один фильтр, а для простого пользователя другой фильтр.

IT>>>Теперь сформулируем вопрос по-другому. Что тебе реально даст оставление двух таких pass-through методов в данном случае, учитывая что вся логика здесь диктуется UI?

GZ>>Логика по любому диктуется UI. Если пользователь не чуствует работу той, или иной функции — то эта функция не нужна.

IT>И как тебе в этом случае поможет наличие pass-through методов?

GZ>>OK. Кое что, ты уже описал. Нужно вставлять кэширование, секьюрити, логгирование и e.t.c. И желательно, чтобы вызовы были в одном слое,
IT>Зачем? Какую проблему мы решаем располагая все вызовы в одном слое?
В одном раздельном слое? Этот слой называется бизнес-логикой, и он не зависит от UI.

GZ>>а посему — даже во избежание бардака стоит делать pass-thought когда оных функциональностей нет. Одни и те-же вызовы могут использоваться в различных прецедентах, в том числе которые могут быть написаны после оной итерации.

IT>А после следующей итерации у нас появятся методы, которые вообще никем не используются. И так и будут висеть по жизни рудиментами и атавизмами.
А что, их так сложно поубивать? Если слой тестируемый, то контролировать его легко. Хотя можно иногда оставить рудименты пока компилятор не заругается.

GZ>>В ситуации бардака, стоимость внесения изменений увеличивается.

IT>Если ты бардаком называешь линк, то попробуй представить что нужно сделать для того, чтобы добавить в запрос выше ещё одну колонку CompanyAddress. А теперь представь что нужно сделать для того, чтобы добавить её же в случае с логикой, размазанной по слоям.
Не очень много. Измени поле в entity и где и какие изменения проверяются компилятором. Чаще всего, они инкапсулированы в отдельном компоненте(ежели разработчик дружит с головой). А вот лазить по UI (который чаще сложнее чем все остальное) не очень хочется.

GZ>>Ежели оные объекты еще публикуются через API (то есть должны быть отчуждаемы), то все совсем плохо. Но что совсем плохо — проект без выделенного слоя становится не тестируемым.

IT>Что именно ты собираешься тестировать? Соответствие имён полей структур и полей таблиц в БД? Так это за тебя уже сделал компилятор.
Нет. Именно то, что называют чудовишным и непонятным словом бизнес-логика. Действия и возможности которые предоставлены клиентам бизнес-логики.

GZ>>А посему — LINQ2SQL может быть заменой(хедпером) DAL, но не более того. В остальном он сопровождаемых решений не дает.

IT>Это заблуждение. Точнее, нежелание отказываться от старых привычек.
Нет. Может я устарел, но в UI я никогда не буду делать действий не связанных с интерфейсом пользователя. Там своей сложности всегда хватит.
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 07.08.07 20:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>ИНСПЕКЦИИ IDE! У меня даже строковые регэкспы инспекциями проверяются.

Строковые регексы не зависят от изменений в других частях приложения. А запросы зависят. И когда эти запросы задаются строковыми константами, то никакая инспекция IDE не поможет. Поможет только тотальная проверка компилятором.

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

C>Нет. У меня есть четко выраженая сессия, с которой я явно работаю.

А если у тебя сессия одна на всё приложение, то ты тоже её везде за собой таскаешь?

C>Это все мелочи, не вижу тут никаких проблем. Для меня многомегабайтные отчеты — далеко не самый интересный частный случай...


Понимаю. Особенно, если проблемы производительности затыкать наращиванием железа, то это вообще никак не интересно.

C>Другое дело сложные алгоритмы или, например, система со сложными взаимосвязями (сейчас их задаем с помощью движка правил) — без ORM можно повеситься.


Задача ORM — перелить данные из пустого в порожнее. Затем уже к полученному результату можно применять любые алгоритмы. Или у вас смысл алгоритмов заключается в постоянном переливании данных туда сюда?

C>"Контекст" — это ЗЛО. Мы используем глобальную/thread-local переменную.


Я сейчас умру со смеху. Как по-твоему устроен контекст?

C>А если я захочу с двумя источниками данных работать?


Источник данных можно спокойно задать метаданными. Типа таблица A принадлежит источнику B. Далее между источником B и конкретной базой данных можно легко организовать нужное соответствие. Именно так я у себя и делаю. Иначе при указании пользователем колонки для просмотра мне пришлось бы у него ещё запрашивать и таблицу, которой она принадлежит, имя БД, имя сервера и порт.
Если нам не помогут, то мы тоже никого не пощадим.
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 02:27
Оценка:
Здравствуйте, GlebZ, Вы писали:

IT>>Вообще-то, это мой вопрос.

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

Ыгыгыгы!

IT>>pass-through как термин существует вне зависимости от линка. Это объективная реальность, присутствующая в большинтсве правильно спроектированных проектах, в которых логика диктуется UI.

GZ>У меня не присутвует. Всегда есть какие-то довески. Что я делаю неправильно?

Давай сюда код, я тебе расскажу что у тебя неправильно.

GZ>На сегодня нет ни релиза Nemerle, ни Go Live лицензии линки. Поэтому можно говорить только о завтра.


А мы о завтра и говорим.

IT>>И ООП и макросы — это иструменты. Сравнивать нужно не их, а результаты их применения. А уж известность подводных камней как преимущество — это вообще здорово. Ты никогда не пробовал решать проблемы, а не коллекционировать их, описывать и классифицировать?

GZ>Соберем все грабли и посчитаем шишки? Очень не хотелось бы на коммерч. проектах пользоваться этим советом.

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

GZ>>>Получение(изменение) данных, и трансформация из модели источника к логической модели и наоборот.

IT>>Ответ неверный. DAL нужен для изоляции кода, работающего с БД от остальных частей приложения. Ключевое слово здесь изоляция.
GZ>Ответ как раз верный. Изоляция — это уже средство.

Следствие из чего? Из получения или трансформации? Впрочем это не важно. Ни то ни другое не даёт столько проблем, чтобы это выносить в отдельный слой.

GZ>Уже лучше. Только полностью синхронизировать не удастся. Реляционные метаданные недостаточны.


Почему?

GZ>Можно только проверить соответсвие. И это можно сделать вполне внешними средствами.


Можно, но почему-то никто не делает и я даже знаю почему.

IT>>О! Видишь что с людями делает декларативщина? Тебе этот код кажется примитивным? Правильно. А почему? Да потому что в нём нет ничего лишнего. Ни одного лишнего элемента. Учитывая, что в обычном коде мусора как правило больше половины, то смотря на такой код хочется зажмурится, как когда смотришь на яркий свет. Что-то тут не так, где-то нас обманывают. Только с декларативностью можно добиться такого примитивизма.

GZ>Чудный примитивизм. А если вспомнить что еще есть кластерный транзакционный кэш, то примитив улетучивается.

Как твой кешь повлияет на запрос вида "SELECT * FROM Customer", если он будет в DAL?

GZ>Это не есть то, что я спрашивал. Например, для администратора нужен фильтр один фильтр, а для простого пользователя другой фильтр.


Ты спрашивал про ad-hoc запрос, я тебе привёл пример.

IT>>И как тебе в этом случае поможет наличие pass-through методов?

GZ>>>OK. Кое что, ты уже описал. Нужно вставлять кэширование, секьюрити, логгирование и e.t.c. И желательно, чтобы вызовы были в одном слое,
IT>>Зачем? Какую проблему мы решаем располагая все вызовы в одном слое?
GZ>В одном раздельном слое? Этот слой называется бизнес-логикой, и он не зависит от UI.

Бизнес логика диктуемая UI зависит от UI на 150%. Причём завист в худшем смысле этого слова.

IT>>А после следующей итерации у нас появятся методы, которые вообще никем не используются. И так и будут висеть по жизни рудиментами и атавизмами.

GZ>А что, их так сложно поубивать?

Если ты один в команде, то не сложно. Если не один и этот метод писал не ты, то, думаю, ты его даже пальцем не тронешь.

GZ>Не очень много. Измени поле в entity и где и какие изменения проверяются компилятором. Чаще всего, они инкапсулированы в отдельном компоненте(ежели разработчик дружит с головой). А вот лазить по UI (который чаще сложнее чем все остальное) не очень хочется.


Никуда лазить не надо. В случае линка этим будет заниматься компилятор. Собственно говоря, о чём весь сыр-бор.

IT>>Что именно ты собираешься тестировать? Соответствие имён полей структур и полей таблиц в БД? Так это за тебя уже сделал компилятор.

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

Ещё раз. Действия и возможности которые предоставлены клиентам бизнес-логики в случае бизнес логики диктуемой UI нужны только тому UI, который диктует эту логику. В результате у тебя будет бизнес-слой, состоящий из pass-through методов, которые вызываются только одним методом UI. Повторное использование в таких приложениях стремительно стремится к нулю.

Если мы устраняем DAL за ненадобностью, то у нас остаётся один метод, который представляет собой запрос, полностью, т.е. абсолютно полностью, на 100% подчиняющийся логике UI. Какой смысл в таком запросе, если от него только проблемы при сопровождении?

GZ>Нет. Может я устарел, но в UI я никогда не буду делать действий не связанных с интерфейсом пользователя. Там своей сложности всегда хватит.


Не хочешь в UI, не надо. Сегодня в моде всякие MVP и прочие умные слова.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.08.07 02:43
Оценка:
Привет, IT, спрашиваешь:
IT>Это понятно, но это уже не декларативно Не проще было бы обойтись вообще без ифоф?
Это ты уже докопался до совсем другого.
Пока что мы говорим о том, что в отличе от текстуальных генераторов запросов, linq позволяет тебе динамически компоновать запросы, при этом
— не нужно анализировать, какие там еще были предикаты, и были ли они вообще (ср. с. if (sqlWhere != "") sqlWhere += "AND "; sqlWhere += "startDate >= @startDate)
— не нужно анализировать, сколько параметров в итоге получилось у запроса
— нет риска совершить досадную опечатку (банальный пробел в тексте пропустить очень легко, и никто тебе не поможет)

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

IT>Если у меня пять таких полей, то нужно будет наприсать 10 строчек такого кода. А можно просто перечислить все пять полей в одной. Опять же повторю. Такой паттерн имеет смысл унифицировать, если он действительно часто повторяется. Ради одного-двух раз париться не стоит.

Вот это место я, честно говоря, не понял. Что, есть какой-то более совершенный подход к условной генерации запросов?
Покажи.
Если ты имеешь в виду ситуацию, когда сам запрос собирается 100% динамически, то тут, действительно, линку будет несколько тяжело. Потому что это, грубо говоря, reflection, а линк — это нормальный компайл-тайм. Впрочем, там, где запрос собирался 100% динамически, всё уже написано, и привлекать линк смысла почти нету.
Почти — это потому, что всё же есть у меня подозрение, что манипулировать Expression Trees должно быть всё же удобнее и надежнее, чем текстом. Ну и плюс возможность генерировать диалектно-зависимый SQL забесплатно.

Но такие тулзы уже были и есть. А вот чтобы прямо синтаксис, да прямо в языке, да статически проверяемый... Гибернейтовый плагин для эклипса глотает слезы ревности.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.08.07 03:00
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>Назови мне технологию MS, которой нет в Java (кроме десктопно-гуевых, разве что).
Ладно, это была шутка. Напомню, что мы в ФП, а не в КСВ. Поэтому меряться пиписьками у меня намерения нет. Я и на Java работал, и без нее, и на чем я только не писал.
А уж маппингом данных я начал заниматься практически не выпуская из рук маминой юбки, лет в 12. Нормальные дети ломали спектрумы, а у меня спектрума не было, поэтому я помогал писать систему экономического анализа сначала на РЕБУС, потом на Clipper.

В результате, против Java я ничего не имею, как и против других технологий. А вот точка зрения типа "вы такие, потому что вы дотнетчики" — бред и предубеждение.
Hibernate — вполне хорошее решение для своего окружения. Также как версант, который использовал собственный компилятор для разбора исходников и генерации по ним метаданных, тоже вполне адекватен для C++. Но молиться ни на то ни на другое я не собираюсь, и прекрасно вижу те возможности, которые есть в linq.

Я не собираюсь также молиться на шарп и MS, хотя у них действительно есть классные черты. Я, к примеру, вижу преимущества Nemerle перед C# во многих областях. Равно как я понимаю (как мне кажется) мотивацию отсутствия этих вещей в шарпе. Я также понимаю, почему в джаве сделаны по-другому некоторые вещи, чем в шарпе.

Так что не надо за меня оценивать угол моего обзора.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[57]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.08.07 03:00
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>Если вам нужно сделать failover — без проблем, мы вам готовы переписать сервер Только платить вы должны.

AVK>>Мы и сами перепишем. Если намек не понят, поясню: RSDN проект некоммерческий, поэтому никакого файловера на нем нет и не будет.
C>А как это связано? Slashdot вот тоже некоммерческий, а failover на нем есть. Если надо новый сервер — я думаю, что уж пара десятков человек скинется по $100.
Ну, во-первых, за $2000 приличный сервер собрать затруднительно.
Во-вторых, на практике дать даже $10 на благое дело желают отнюдь не все.
В итоге, мы имеем то, что мы имеем — у нас хотя бы это железо есть.
C>Так поставьте SQL-сервер на одну машину с сайтом.
Так уже тоже было. Ты себе нагрузку представляешь?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 03:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

IT>>Если у меня пять таких полей, то нужно будет наприсать 10 строчек такого кода. А можно просто перечислить все пять полей в одной. Опять же повторю. Такой паттерн имеет смысл унифицировать, если он действительно часто повторяется. Ради одного-двух раз париться не стоит.

S>Вот это место я, честно говоря, не понял. Что, есть какой-то более совершенный подход к условной генерации запросов?
S>Покажи.

Давай ещё раз вот с этого места:

if (StartDate != null)
  q = q.where(p => p.StartDate >= StartDate)

Поэтому то линк и рулит.


Это всё здорово за исключением одного — это уже не query expressions. Если мне нужно 5 проверок, то это будет выглядеть так:

if (StartDate1 != null)
  q = q.where(p => p.StartDate1 >= StartDate1)
if (StartDate2 != null)
  q = q.where(p => p.StartDate2 >= StartDate2)
if (StartDate3 != null)
  q = q.where(p => p.StartDate2 >= StartDate3)
if (StartDate4 != null)
  q = q.where(p => p.StartDate4 >= StartDate4)
if (StartDate5 != null)
  q = q.where(p => p.StartDate5 >= StartDate5)

Вместо этого хотелось бы иметь что-то типа:

grid.Source = from c in customers   
              join o in orders on c equals o.Customer into oo   
              filterby StartDate1, StartDate2, StartDate3, StartDate4, StartDate5
              select new { c.CompanyName, OrderCount = oo.Count()

Я понимаю, что в линк этого нет и я даже не собираюсь это просить, т.к. это логика специфичная исключительно для моей задачи. По-этому, я отнёс это к преимуществу макросов, т.к. в тех случаях, когда у меня вырисовывается вполне чёткий паттерн я могу совершенно спокойно добавить его в свой набор и иметь возможность заменять 10 императивных строк одной декларативной.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: awson  
Дата: 08.08.07 05:30
Оценка:
Здравствуйте, IT, Вы писали:

IT>Спасибо, друг! Повеселил!


Ну, с "почти все" я, наверное, погорячился — темы такой чудовищной длины целиком читать невозможно, однако в данном конкретном треде Вы пишете уже совсем странные вещи, например
Автор: IT
Дата: 08.08.07
:
IT>
IT>if (StartDate1 != null)
IT>  q = q.where(p => p.StartDate1 >= StartDate1)
IT>if (StartDate2 != null)
IT>  q = q.where(p => p.StartDate2 >= StartDate2)
IT>if (StartDate3 != null)
IT>  q = q.where(p => p.StartDate2 >= StartDate3)
IT>if (StartDate4 != null)
IT>  q = q.where(p => p.StartDate4 >= StartDate4)
IT>if (StartDate5 != null)
IT>  q = q.where(p => p.StartDate5 >= StartDate5)
IT>


Неужели в контексте использования в линке нельзя построить first-class составной предикат из списка полей ??? Еще раз — я линком не пользовался, поэтому интуицию черпаю из знакомства с его прародителем (haskelldb) — там бы это решительно не составило никакой проблемы безо всяких макросов.
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: no4  
Дата: 08.08.07 06:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>Почему-то, .NET-программисты страдают "туннельным видением" — все не-MS-технологии они просто не замечают.

IB>>Наоборот, это Java-исты ничего кругом не замечают, зациклились на морально устаревших решениях и никак не могут с них слезть.
C>Можешь назвать технологию MS, которой нет в Java?

C++/CLI -- т.е. язык, который одинкаково зорошо понимает как объекты фреймфорка, так и низкоурованевые структуры.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 08.08.07 07:56
Оценка:
Здравствуйте, IT, Вы писали:

C>>ИНСПЕКЦИИ IDE! У меня даже строковые регэкспы инспекциями проверяются.

IT>Строковые регексы не зависят от изменений в других частях приложения. А запросы зависят. И когда эти запросы задаются строковыми константами, то никакая инспекция IDE не поможет. Поможет только тотальная проверка компилятором.
Ты вообще IDEA когда-нибудь видел? Вот так выглядит диалог Analyze->Inspect code...:


Специально для тебя — посмотри на пункт "Whole Project".

Естественно, при рефакторингах IDE тоже автоматически исправляет запросы. Да, и можно поднять для inspection'а уровень предупреждения до "error", тогда он будет выполняться при компиляции.

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

C>>Нет. У меня есть четко выраженая сессия, с которой я явно работаю.
IT>А если у тебя сессия одна на всё приложение, то ты тоже её везде за собой таскаешь?
Ага. Я даже ссылку на главное окно передаю везде явно. Не люблю синглтоны и неявные контексты.

C>>Это все мелочи, не вижу тут никаких проблем. Для меня многомегабайтные отчеты — далеко не самый интересный частный случай...

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

C>>Другое дело сложные алгоритмы или, например, система со сложными взаимосвязями (сейчас их задаем с помощью движка правил) — без ORM можно повеситься.

IT>Задача ORM — перелить данные из пустого в порожнее. Затем уже к полученному результату можно применять любые алгоритмы. Или у вас смысл алгоритмов заключается в постоянном переливании данных туда сюда?
Нет. Просто на SQL нет нормальных способов работы не с отдельными рядами, а с их набором. Тупой Java-код получается намного приятнее.

А еще есть сложные структуры и логика. Я пишу системы работы с персоналом, связаные с биллингом. Например, при добавлении человеку в его расписание нового shift'а, мне нужно проверять не получился ли у него overtime, если overtime получился — то проверить разрешен ли он ему (это включает в себя проверку его истории работы), потом еще надо проверить контрактные условия (например, один человек не может более одного раза в неделю работать на одном месте) и т.п. В общей сложности срабатывает 156 правил (и это еще далеко не предел, сейчас еще консультанты туда их добавляют по десятку в день).

На SQL это все делать — получится огромное количество мелких (и не очень) запросов. На Hibernate мы используем, в основном, навигационный доступ к данным. Причем обычно у нас в кэше находятся ВСЕ нужные данные, и у нас не делается вообще ни одного запроса к базе (кроме update'ов, естественно).

C>>"Контекст" — это ЗЛО. Мы используем глобальную/thread-local переменную.

IT>Я сейчас умру со смеху. Как по-твоему устроен контекст?
В виде thread-local переменной.

C>>А если я захочу с двумя источниками данных работать?

IT>Источник данных можно спокойно задать метаданными. Типа таблица A принадлежит источнику B.
Представь, что ты синхронизируешь несколько баз данных с одинаковой структурой. Твои действия?
Sapienti sat!
Re[51]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.08.07 07:58
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>LINQ пока даже не появился.

IB>>LINQ не для БД.
C>Ага. А Hibernate — не ORM, а универсальная система работы с данными. Не веришь?

afair, "универсальная система" это JDO, но похоже оно нафиг никому не упало.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.08.07 08:15
Оценка:
Здравствуйте, IT, Вы писали:

IT>
IT>class UI
IT>{
IT>  void OnLoad()
IT>  {
IT>    binder.List = from c in Customer select c;
IT>  }
IT>}
IT>

IT>Можно для лучшей наглядности замешать сюда ещё и ad-hoc запрос.

btw, вопрос к тебе как к знатоку. Где то в этом форуме, я видел утверждения, что типы генерируемые Linq-ом не доступны в других сборках. Означает ли это, что Linq-запросы можно использовать только in-place? И что, вообще, то утверждение означает ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[50]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 08.08.07 08:44
Оценка:
Здравствуйте, IT, Вы писали:

C>>Я тебе в который (пятый?) раз говорю, что можно для большинства запросов Hibernate сделать контроль типов с помощью плугина к IDE. И это уже сделано. И это уже работает.

IT>Ты понимаешь какую чушь ты говоришь? А если файл, которые затронули мои изменения не открыт в IDE? Всё, не шмагла?
Зачем файл открывать? IDEA замечательно умеет ловить изменения на лету и проверять все файлы. А еще есть TeamCity, который вообще позволяет запускать инспекции на билд-сервере.

IT>>>В твоём примере ты делаешь точно тоже, что делалось 10 лет назад — ты используешь нетипизированную работу с данными.

C>>У меня возвращается List<BusinessObject>, который вполне типизирован.
IT>Ты строкой задаёшь запрос, в котором используются строковые имена таблиц и полей. Дальнейшее уже не важно.
Это НЕ имена таблиц и полей. Это имена entity, для которых поддерживается рефакторинг и проверка. Тебе screencast что ли снять?
Sapienti sat!
Re[57]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.08.07 08:45
Оценка:
Здравствуйте, Cyberax, Вы писали:

AVK>>Мы и сами перепишем. Если намек не понят, поясню: RSDN проект некоммерческий, поэтому никакого файловера на нем нет и не будет.

C>А как это связано?

Связано.

C> Slashdot вот тоже некоммерческий, а failover на нем есть.


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

C> Если надо новый сервер — я думаю, что уж пара десятков человек скинется по $100.


Смешно. Последний сервер RSDN стоил в районе 7К. И я бы не сказал, что он сейчас нагружен слабо.

AVK>>Прямое. Рвется постоянно связь между серверами из-за глюков сетевой карты на одном из них.

C>Так поставьте SQL-сервер на одну машину с сайтом.

Периодически приходится. Тормозит-с.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[55]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.08.07 08:45
Оценка:
Здравствуйте, ., Вы писали:

.>А это рабочий пример???


Нет конечно, оператора ... в шарпе еще нет.

.> Для какого экземляра A будут вызываться Foo/Bar из Find?


У Foo и Bar надо дописать static.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.08.07 08:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

AVK>>Такое ни на каких отдельно сгенеренных проксях ты не сделаешь.

C>Классно. А где об этом можно почитать?

Хороший вопрос. Ответа не знаю.

C> В документации к RealProxy я не вижу возможности динамически добавлять реализуемые типы.


Курить ObjRef.TypeInfo.CanCastTo(). Этот метод вызывается при каждом кастинге TP.

AVK>>Если это функциональный аналог, зачем тогда Tango Project?

C>Для интероперабельности, у них же написано.

А что там интероперировать, если WCF поддерживает все стандарты WS? Jini нельзя добавить поддержку веб-сервисов в полном объеме?

AVK>>А при чем тут Scala?

C>Есть мнение, что она может стать официальным продолжателям Java.

Вот когда станет, тогда и поговорим.

C> Кстати, еще и JavaFX подкатывается.


И LINQ
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: GlebZ Россия  
Дата: 08.08.07 09:39
Оценка:
Здравствуйте, IT, Вы писали:

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

IT>Ыгыгыгы!
Понял.

GZ>>>>Получение(изменение) данных, и трансформация из модели источника к логической модели и наоборот.

IT>>>Ответ неверный. DAL нужен для изоляции кода, работающего с БД от остальных частей приложения. Ключевое слово здесь изоляция.
GZ>>Ответ как раз верный. Изоляция — это уже средство.
IT>Следствие из чего? Из получения или трансформации? Впрочем это не важно. Ни то ни другое не даёт столько проблем, чтобы это выносить в отдельный слой.

GZ>>Уже лучше. Только полностью синхронизировать не удастся. Реляционные метаданные недостаточны.

IT>Почему?
Потому что есть разница. Например, есть readonly агрегационные поля формируемые только триггерами. FK — это всего лишь констреинт который зачастую отсутсвует поскольку логика более сложна и проверяется либо триггерами либо процедурами. Потому что должны ли две таблицы инстанцироваться всегда в один неделимый объект или нет. Потому что например в Oracle нет понятие guid а это можно сохранять в строку или в raw. Потому что объект может быть получен через набор вьюх и функций а закачен через таблицы. И т.д. и т.п.

GZ>>Можно только проверить соответсвие. И это можно сделать вполне внешними средствами.

IT>Можно, но почему-то никто не делает и я даже знаю почему.
Так почему?

IT>Как твой кешь повлияет на запрос вида "SELECT * FROM Customer", если он будет в DAL?

Подобный почти никак. А вот "select * from customer where id=?" до DAL — запрос может и не дойти и вообще не сгенерен. Хотя в случае транзакционности кэша все несколько усложняется.

IT>>>И как тебе в этом случае поможет наличие pass-through методов?

GZ>>>>OK. Кое что, ты уже описал. Нужно вставлять кэширование, секьюрити, логгирование и e.t.c. И желательно, чтобы вызовы были в одном слое,
IT>>>Зачем? Какую проблему мы решаем располагая все вызовы в одном слое?
GZ>>В одном раздельном слое? Этот слой называется бизнес-логикой, и он не зависит от UI.

IT>Бизнес логика диктуемая UI зависит от UI на 150%. Причём завист в худшем смысле этого слова.

Я не очень понимаю что такое бизнес-логика диктуемая UI. Я знаю что логика зависит от вариантов использования. А UI, БД и BL — средства.

IT>>>А после следующей итерации у нас появятся методы, которые вообще никем не используются. И так и будут висеть по жизни рудиментами и атавизмами.

GZ>>А что, их так сложно поубивать?
IT>Если ты один в команде, то не сложно. Если не один и этот метод писал не ты, то, думаю, ты его даже пальцем не тронешь.
В случае нормальной тестируемости — трону.

GZ>>Не очень много. Измени поле в entity и где и какие изменения проверяются компилятором. Чаще всего, они инкапсулированы в отдельном компоненте(ежели разработчик дружит с головой). А вот лазить по UI (который чаще сложнее чем все остальное) не очень хочется.

IT>Никуда лазить не надо. В случае линка этим будет заниматься компилятор. Собственно говоря, о чём весь сыр-бор.
В случае типизированных бизнес объектов — то же самое.

IT>Ещё раз. Действия и возможности которые предоставлены клиентам бизнес-логики в случае бизнес логики диктуемой UI нужны только тому UI, который диктует эту логику. В результате у тебя будет бизнес-слой, состоящий из pass-through методов, которые вызываются только одним методом UI. Повторное использование в таких приложениях стремительно стремится к нулю.

Ну вот я и говорю. Пример достойный экзампла или простого проекта.
Re[54]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 08.08.07 10:17
Оценка:
Здравствуйте, AndrewVK, Вы писали:

C>> В документации к RealProxy я не вижу возможности динамически добавлять реализуемые типы.

AVK>Курить ObjRef.TypeInfo.CanCastTo(). Этот метод вызывается при каждом кастинге TP.
А... А я думал, что что-то действительно серьезное. Берем и переписываем байт-код в Java так, чтобы касты объекта типа Proxy превращались в вызовы специального метода. Спокойно делается в рантайме.

AVK>>>Если это функциональный аналог, зачем тогда Tango Project?

C>>Для интероперабельности, у них же написано.
AVK>А что там интероперировать, если WCF поддерживает все стандарты WS?
Так Tango и есть просто реализация всех стандартов WS.

AVK>Jini нельзя добавить поддержку веб-сервисов в полном объеме?

В Jini можно добавить все что угодно, там архитектура гибкая. Я точно помню, что там еще в 2001 году были распределенные транзакции по типу WS-AtomicTransaction.
Sapienti sat!
Re[58]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.08.07 11:36
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Периодически приходится. Тормозит-с.


Выбросте вы этот дотНет
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.08.07 11:41
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ANS>>btw, вопрос к тебе как к знатоку. Где то в этом форуме, я видел утверждения, что типы генерируемые Linq-ом не доступны в других сборках. Означает ли это, что Linq-запросы можно использовать только in-place? И что, вообще, то утверждение означает ?


AVK>Ты все перепутал.


Я ниче не мог перепутать, потому как я спрашивал как именно оно работает.

AVK>Анонимные типы недоступны компилятору за пределами метода.


То есть возвращаемое Linq-ом значение нельзя вернуть из метода (кроме как Object)?

AVK>С точки зрения рантайма (а биндинг работает только в рантайме) никаких анонимных типов нет, есть обычные классы.


Дык тем фактом, что Linq всё во время компиляции проверяет, а не в ран-тайм. Или ты о чем?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: Являются ли макросы свидетельством недостаточной выра
От: cl-user  
Дата: 08.08.07 12:44
Оценка:
Здравствуйте, Gaperton, Вы писали:

G> Форт (есть такой жутко гибкий макроязык для встраиваемых систем — по гибкости не уступает LISP, по близости к железу — ассемблеру и С).


"Твои слова да богу в уши"

Есть реализация (многоплатформенная и многопроцессорная), оптимально использующая при "шитье" все регистры используемых процессоров и/или умеющая оптимизировать свой "шитый" код?

Гибкость — да, скорость — нет.
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 12:51
Оценка:
Здравствуйте, awson, Вы писали:

A>Неужели в контексте использования в линке нельзя построить first-class составной предикат из списка полей ???


Декларативная часть linq (query extensions) — это гвоздями прибитое расширение к компилятору. Само это расширение расширять нельзя. Но можно расширять то, во что это расширение трансформируется, как это тут уже неоднократно демонстрировал AVK. Проблема лишь в том, что после трансформации у нас заканчивается декларативность и начинается чистый императив c элементами функциональщины.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 13:02
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ты вообще IDEA когда-нибудь видел? Вот так выглядит диалог Analyze->Inspect code...:

C>http://files.rsdn.ru/37054/Inspections.PNG

Что я тебе могу сказать? Мрачное зрелище. Ты пробовал этот whole project запускать на больших проектах? Нормально, не торомзит?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: . Великобритания  
Дата: 08.08.07 13:09
Оценка:
IT wrote:

>> > binder.List = myMapper.select("from c in " +

> ReadCustomerTableNameFromXml() + " select c").list();
> .>А зачем?
> Затем, что никто не сможет удержать разработчика сделать не только
> такое, но такое от чего потом волосы будут стоять дыбом не только на голове.
Никто не сможет удержать разработчика приводить всё к void*. И что?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: FR  
Дата: 08.08.07 13:20
Оценка:
Здравствуйте, cl-user, Вы писали:

G>> Форт (есть такой жутко гибкий макроязык для встраиваемых систем — по гибкости не уступает LISP, по близости к железу — ассемблеру и С).


CU>"Твои слова да богу в уши"


CU>Есть реализация (многоплатформенная и многопроцессорная), оптимально использующая при "шитье" все регистры используемых процессоров и/или умеющая оптимизировать свой "шитый" код?


CU>Гибкость — да, скорость — нет.


Скорость и близость к железу не всегда совпадают
Re[51]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 13:59
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Зачем файл открывать? IDEA замечательно умеет ловить изменения на лету и проверять все файлы. А еще есть TeamCity, который вообще позволяет запускать инспекции на билд-сервере.


Мне не понятно только одно, зачем тогда вообще нужен компилятор?

C>Это НЕ имена таблиц и полей.


Не важно. Главное, что это строки.

C>Это имена entity, для которых поддерживается рефакторинг и проверка. Тебе screencast что ли снять?


Решарпер тоже пытается научится рефакторить в строках. Но у меня банально может не стоять решарпера или IDEA, либо оно может глюкнуть, либо кто-то в тиме поменяет что-то и зальёт врепозиторий, а я уже это заиспользовал и т.п. Случиться может что угодно. Поэтому я доверяю только компилятору. Если он сказал OK, то всё в прорядке. Но на строковые идентификаторы он всегда скажет OK.

Кстати, в этом топике я уже называл решение. Оно очень простое и решит не все, но большинство проблем. Это языковая конструкция nameof.
Если нам не помогут, то мы тоже никого не пощадим.
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 14:04
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>btw, вопрос к тебе как к знатоку. Где то в этом форуме, я видел утверждения, что типы генерируемые Linq-ом не доступны в других сборках. Означает ли это, что Linq-запросы можно использовать только in-place? И что, вообще, то утверждение означает ?


Означает, что за пределы метода такой тип можно вернуть только как object. Косяк, конечно. Обещали поправить, когда будут править CLR, т.е. ещё года через три.

Радует лишь то, что для ad-hoc запросов всё же не нужно создавать типы, используемые между лэйерами и замусоривающие публичный интерфейс. Такие типы можно локализовать в пределах использующего их класса.
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.08.07 14:15
Оценка:
Здравствуйте, IT, Вы писали:

IT>Означает, что за пределы метода такой тип можно вернуть только как object. Косяк, конечно. Обещали поправить, когда будут править CLR, т.е. ещё года через три.


хм. начал думать причем тут clr. Так и не понял. Но зато додумался до того, то не понимаю, что они с компилятором будут делать
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 08.08.07 14:16
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Заменить текст деревом.


Деревом-деревом!.. В виде списка... в текстовом файле
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.08.07 14:17
Оценка:
Здравствуйте, IT, Вы писали:

IT>Радует лишь то, что для ad-hoc запросов всё же не нужно создавать типы, используемые между лэйерами и замусоривающие публичный интерфейс. Такие типы можно локализовать в пределах использующего их класса.


Как обычно, всё свелось к пользовательскому интерфейсу
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[50]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 08.08.07 14:22
Оценка:
Здравствуйте, IT, Вы писали:

C>>Ты вообще IDEA когда-нибудь видел? Вот так выглядит диалог Analyze->Inspect code...:

C>>http://files.rsdn.ru/37054/Inspections.PNG
IT>Что я тебе могу сказать? Мрачное зрелище. Ты пробовал этот whole project запускать на больших проектах? Нормально, не торомзит?
Со ВСЕМИ инспекциями — тормозит. Для определенных наборов инспекций (типа косяков с сериализацией) запускаю регулярно — работает быстро.

Ну и про билд-сервер я не зря сказал. Ему пофиг сколько там оно будет инспектироваться.
Sapienti sat!
Re[52]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 08.08.07 14:31
Оценка:
Здравствуйте, IT, Вы писали:

C>>Зачем файл открывать? IDEA замечательно умеет ловить изменения на лету и проверять все файлы. А еще есть TeamCity, который вообще позволяет запускать инспекции на билд-сервере.

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

C>>Это НЕ имена таблиц и полей.

IT>Не важно. Главное, что это строки.
И что?

C>>Это имена entity, для которых поддерживается рефакторинг и проверка. Тебе screencast что ли снять?

IT>Решарпер тоже пытается научится рефакторить в строках. Но у меня банально может не стоять решарпера или IDEA, либо оно может глюкнуть, либо кто-то в тиме поменяет что-то и зальёт врепозиторий, а я уже это заиспользовал и т.п. Случиться может что угодно. Поэтому я доверяю только компилятору. Если он сказал OK, то всё в прорядке. Но на строковые идентификаторы он всегда скажет OK.
Добавь к "компилятору" еще и "инспектор" (который можно запускать отдельно от IDE, кстати).

IT>Кстати, в этом топике я уже называл решение. Оно очень простое и решит не все, но большинство проблем. Это языковая конструкция nameof.

Так никто не мешает и ее использовать в Hibernate.
Sapienti sat!
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 14:33
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>>>Уже лучше. Только полностью синхронизировать не удастся. Реляционные метаданные недостаточны.

IT>>Почему?
GZ>Потому что есть разница. Например, есть readonly агрегационные поля формируемые только триггерами. FK — это всего лишь констреинт который зачастую отсутсвует поскольку логика более сложна и проверяется либо триггерами либо процедурами. Потому что должны ли две таблицы инстанцироваться всегда в один неделимый объект или нет. Потому что например в Oracle нет понятие guid а это можно сохранять в строку или в raw. Потому что объект может быть получен через набор вьюх и функций а закачен через таблицы. И т.д. и т.п.

Все эти проблемы решаемы. Было бы желание. Технических препятствий нет никаких.

GZ>Так почему?




IT>>Как твой кешь повлияет на запрос вида "SELECT * FROM Customer", если он будет в DAL?

GZ>Подобный почти никак. А вот "select * from customer where id=?" до DAL — запрос может и не дойти и вообще не сгенерен. Хотя в случае транзакционности кэша все несколько усложняется.

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

IT>>Бизнес логика диктуемая UI зависит от UI на 150%. Причём завист в худшем смысле этого слова.

GZ>Я не очень понимаю что такое бизнес-логика диктуемая UI. Я знаю что логика зависит от вариантов использования. А UI, БД и BL — средства.

Я бы сказал, что UI ближе к результату и напрямую связан с функциональными требованиями. Так я никогда в жизни не видел в ФТ требования к БД, а для UI видел уже даже готовые мокапы.

IT>>Если ты один в команде, то не сложно. Если не один и этот метод писал не ты, то, думаю, ты его даже пальцем не тронешь.

GZ>В случае нормальной тестируемости — трону.

Откуда ты узнаешь, что этот метод нужно трогать?

IT>>Никуда лазить не надо. В случае линка этим будет заниматься компилятор. Собственно говоря, о чём весь сыр-бор.

GZ>В случае типизированных бизнес объектов — то же самое.

Про DAL мы уже успели забыть.

IT>>Ещё раз. Действия и возможности которые предоставлены клиентам бизнес-логики в случае бизнес логики диктуемой UI нужны только тому UI, который диктует эту логику. В результате у тебя будет бизнес-слой, состоящий из pass-through методов, которые вызываются только одним методом UI. Повторное использование в таких приложениях стремительно стремится к нулю.

GZ>Ну вот я и говорю. Пример достойный экзампла или простого проекта.

Я правильно догадываюсь, что ты под этим понимаешь отсутствие в таких методах логики, занимающейся транзакционными кешами и прочей ортогональной бизнес логики фигнёй? У меня методы действительно простые, т.к. кеширование и другие подобные вещи выполнениы в виде аспектов.
Если нам не помогут, то мы тоже никого не пощадим.
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 14:34
Оценка:
Здравствуйте, ., Вы писали:

>> Затем, что никто не сможет удержать разработчика сделать не только

>> такое, но такое от чего потом волосы будут стоять дыбом не только на голове.
.>Никто не сможет удержать разработчика приводить всё к void*. И что?

И глюки.
Если нам не помогут, то мы тоже никого не пощадим.
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 08.08.07 14:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Добавь к "компилятору" еще и "инспектор" (который можно запускать отдельно от IDE, кстати).


А почему к компилятору просто не добавить нормальную систему расширения? Ведь твой инспектор как раз и занимается тем, что пытается расширяет возможности компилятора на свой лад, делает за него какие-то дополнительные проверки и т.п. Но по сути это же просто обыкновенная затычка. Теперь оказывается нужно не только компилятор запускать, но ещё перед ним не забыть запустить инспектор. А кто будет инспектировать инспектора?
Если нам не помогут, то мы тоже никого не пощадим.
Re[54]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 08.08.07 14:49
Оценка:
Здравствуйте, IT, Вы писали:

C>>Добавь к "компилятору" еще и "инспектор" (который можно запускать отдельно от IDE, кстати).

IT>А почему к компилятору просто не добавить нормальную систему расширения? Ведь твой инспектор как раз и занимается тем, что пытается расширяет возможности компилятора на свой лад, делает за него какие-то дополнительные проверки и т.п.
Потому как я не хочу разбираться с тем, что наделали индусы, дорвавшиеся до макросов. Если им захочется написать свою инспекцию — пожалуйста, нет проблем. Я ее просто у себя отключу, если мне захочется.

IT>Но по сути это же просто обыкновенная затычка. Теперь оказывается нужно не только компилятор запускать, но ещё перед ним не забыть запустить инспектор.

А ты не забываешь запустить компиляцию перед запуском приложения?

IT>А кто будет инспектировать инспектора?

Инспектор
Sapienti sat!
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: cl-user  
Дата: 08.08.07 15:27
Оценка:
Здравствуйте, FR, Вы писали:

CU>>Гибкость — да, скорость — нет.


FR>Скорость и близость к железу не всегда совпадают


А нафиг "близость к железу", если она не даёт скорость? Для самоудовлетворения?
Re[55]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 08.08.07 15:40
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


А в чём принципиальная разница с индусской библиотекой?
Кстати, ты себе представляешь сколько в стандартной явовской библиотеке индусского кода?
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: mkizub Литва http://symade.tigris.org
Дата: 08.08.07 15:45
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>>>Гибкость — да, скорость — нет.


FR>>Скорость и близость к железу не всегда совпадают


CU>А нафиг "близость к железу", если она не даёт скорость? Для самоудовлетворения?


Думай, голова, думай — не только кушать дана.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[56]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 08.08.07 17:27
Оценка:
Здравствуйте, mkizub, Вы писали:

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

M>А в чём принципиальная разница с индусской библиотекой?
В ее влиянии на приложение. Влияние библиотеки более-менее ограничено (особенно в Java, где нет проблем С++) — так что ее не так страшно использовать.

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

M>Кстати, ты себе представляешь сколько в стандартной явовской библиотеке индусского кода?

На JRE мне пофиг — ее используют миллионы человек и большая часть багов находится и исправляется быстро. Если это не баги в дизайне.
Sapienti sat!
Re[56]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 08.08.07 17:31
Оценка:
Здравствуйте, IT, Вы писали:

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

IT>Так просто не используй макрос, написанный индусами
А ты просто не используй Windows. Какие проблемы-то?

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

C>>А ты не забываешь запустить компиляцию перед запуском приложения?

IT>Нет, это необходимый минимум, чтобы получить запускаемый код. Компилятор + инспектор не минимальный набор, следовательно всегда существует возможность использовать минимальный, чем твои индусы обязательно воспользуются.
Пусть. Ошибки в запросах обнаружаться в виде исключений при тестировании. Да, это не приятно, но прекрасно локализуемо и легкоисправимо. Кроме того, Я САМ буду запускать инспекции — и найду эти ошибки (у нас в процедуре релиза, кстати, предусмотрена автоматическая проверка).

А вот индусские макросы — это намного хуже. Они мне затрудняют поддержку кода и поиск ошибок (которые будут).
Sapienti sat!
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.08.07 17:54
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

VD>>А насколко это универсальное решение?


BZ>уточни вопрос


Как я понял — это хардкодинг для конкретных случаев. Правильно?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.08.07 17:54
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

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


BZ>вопрос был в том, почему опыт в реализации "стандарный и универсальный скриптовый язык" делает ошибочными утверждения относящиеся к DSL.


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

BZ> кроме того, по-моему, DSL вовсе не обязан быть узким языком.


Обязаьельно. Причем, ты не поверишь! Прямо из определения:
http://en.wikipedia.org/wiki/Domain-specific_programming_language

BZ> скажем, Lua используемый в игре для скриптования ботов — вполне себе пример DSL.


Не скажем. Лучше скажем, что Lua является типичнейшим представителем GPL.

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


Ты просто невладеешь терминалогией.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.08.07 17:54
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Нет, компилятор неоднозначности не найдёт. Ты же о компиляторе Хаскеля? Не думаю, что он умеет определять, что в строках "public", "private" и "protected" все слова начинаются на одну букву


L>Сам же парсер выдаёт либо сообщение о несработавшем комбинаторе (если поставить явный <?>). Либо говорит о том, что ожидается то-то, а найдено то-то.


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

Как я понял в случае с Парсеком мы просто получим некорректный парсер. Так?

L>Так у С# грамматика должна быть не маленькая верно?


Дык она уже есть. Если задача просто ко контексту символы заменить, то это работа на 10-20 минут.

L>Ясно. Я думал, тебя производительность интересовала в первую очередь.


Она мне нитересна, конечно. Но это только один вопрос. А их несколько. Вот в начале этого собщения мы говорим о логике постраителя парсера. Это мне тоже очень интересно. Потом интересна отладка. Да и просто поглядеть на то во что выльется грамматика интересно.

А то абстрано у всех все здорово и красиво. А вот на прктике что-то проблемы вылезают.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.08.07 17:54
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

VD>>"Byte" означает то о чем я подумал, и Юникод Хаскелю незнаком?


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


А что встренные строки Хаскеля поддерживают Юникод?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.08.07 17:54
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


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


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

Вон в том же С++ пока Александреску не придумал как приспособить систему типов для нужд метапрограммирования тоже мало кто внешние мета-решения городил. Но после того как эти идеи оформили в Бусте многие стали применять их на право и на лево.

G> Это глупость. Я лучше в том редком случае, когда надо что-то сложное разобрать, воспользуюсь flex/byson или подобными.


Дык и убьёшь море времени. Плюс сузишь количество случаев когда ты решишся на разработку нового языка. Ну, и последним гвоздем в крышку гроба водруженной над этой идей будет, то что ты не сможешь легко интегрировать этот язык в свой основной ЯП. А без этого многие ДСЛ будут неудобны. В итоге для тебя DSL как дизайнерское решение является исключительной экзотикой. А я вот на сегодя рассматриваю его как вполне себе реальное решение. Легко создать. Легко воспользоваться. Легко отладить. Легко внердить...

G>А вот если я провожу масштабные исследования в области языков и компиляторов, то тогда да.


Эта другая область. Довольн узкая. Мы все же говорил о ДСЛ-ях, а не о полноценных языках.

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


Вообще-то он довольно гораничен в этом лане. Там толко лексический препроцессор. По крайней мере особых преимущество по срвнению с макросам, и темболее по сравнению с файтически встренным flex-ом (да еще и с человеческим лицом) нет. В прочем, это все равно будет проще чем возня с flex-ом.

G> Это свойство мне существенно съекономит время. Тем более, что есть замечательная книга — Compilers Construction with ML с примерами, которую можно почитать и новичкам потом дать.


О, да. Книга несомненно позволит скоротать вечерок другой .

В общем, не о том речь.

G>Только я в своей работе не провожу исследований в области языков и компиляторов.


Я, как не странно, тоже. Я просто хочу сделать свою среду разработку более высокоуровневой.

G> Поэтому я в крайней и редкой ситуации — когда припрет — воспользуюсь flex и bison. Чем офигенно обрадую тех людей, кто будет потом разбираться в моем коде — они его поймут.


Тем самым ты понизишь уровень разработки и накажешь тех самых людей.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.08.07 17:54
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Приведи мне пример паттерна, который будет строиться на базе ФВП и паттернматчинга, и покажи, как ты его макросом обернешь.


Возможно неплохим примером будет оператор foreach из Nemerle. О его возможностях можно прочесть тут
Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.
.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.08.07 17:54
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

VD>>Оба недостатка будут у любого средства ДСЛ-естроения.


BZ>похоже, ты путаешь DSL и eDSL. DSL — это просто любой язык, интерепретатор/компилятор которого ты реализуешь. embedded DSL — это DSL, реализованный как расширение твоего ЯП.


Нет. DSL — это ограниченный язык решающий узкий список проблем предметной области.

BZ> через доп. функции, классы, макросы и т.д. т.е. библиотека матричных операций — это уже eDSL. а скажем, любой язык, реализуемый с помощью ParseC — это DSL, но при этом сам ParseC реализует eDSL для описания грамматик


Нет. Не любой. Думаю, что Парсек может справиться и с С++ (скажем). От этого С++ DSL-ем не становится. Он по прежнему останется GPL.

BZ>ещё примеры: всякие boost::lambda — это eDSL функционального программирования внутри C++, а byson или regexps — это средства создания DSL


"eDSL функционального программирования" — это оксюморон. ФП — это уже General Purpose...

boost::lambda — это пример эмуляции полезной фичи на базе бесполезной. В прочем, если я не ошибаюсь, то boost::lambda даже примером метапрограммирования не является. Это чистый пример обобщенного программирования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.08.07 17:54
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Да лёгкая замена xml-ю. JavaScript Object Notation


Да, пожалуй, пойдет.

VD>>Грамматика была в виде глобального метаатрибута. Что-то типа:


L>Прикольное решение. А в виде чего тогда приходит на макрос BNF параметр после lexer/parser внутри фигурных скобок?


Это главная фича. "Кода в скобках" попросту нет! На выходе мы получаем список/поток вариантов описывающих грамматические конструкции. Ну, а далее мы прсото анализируем их средствами паттерн-матчинга. В итоге получаем полное отделение описания грамматики от действий предпринимаемых при распозновании тех или иных конструкций.

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


VD>>При этом изменение грамматики автоматически перестраивает генерируемые алгеброические типы, так что сразу доступен комплит-ворд и диагностика ошибок (без какой либо добполниетльной роботы по этому поводу).


L>Не понял, как он ловит ambiguity?


Выдает сообщения об ошибках — вестимо. Это же настоящий генератор парсеров завуалированный под DSEL.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.08.07 17:54
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Так! Парсер написал.


Здорво!

L>Думал дольше времени уйдёт, наверное, рука набита


Вот и я о том же. Больше споров...

L>Если у тебя есть установленный Haskell, то это сообщение можешь просто скопировать в файл, обозвать его, дав ему расширение lhs, и запустить.


К сожалению, нет. Но готов поставить если будут четки инструкции "чего и скока?". За одно многие другие смогут приобщиться.

L>...


А можно увидить все это в целом? Ну, чтобы с оригиналом сравнить?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[59]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.08.07 19:11
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

AVK>>Периодически приходится. Тормозит-с.


ANS>Выбросте вы этот дотНет


И что, сиквел сразу быстрее работать станет?
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[55]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.08.07 19:11
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>А... А я думал, что что-то действительно серьезное. Берем и переписываем байт-код в Java так, чтобы касты объекта типа Proxy превращались в вызовы специального метода. Спокойно делается в рантайме.


object o = GetProxy();
var x = o as X;

Чего будем переписывать? Все касты во всем коде включая библиотеки?

AVK>>А что там интероперировать, если WCF поддерживает все стандарты WS?

C>Так Tango и есть просто реализация всех стандартов WS.

Почему не ввиде расширения Jini? Может потому что последний заметно проще чем WCF и в его архитектуру все потребные фичи просто не укладываются? Как в Jini с поддержкой messaging, streaming, notifications, reliable messaging, p2p, metadata exchange? Есть ли в jini реализация аутентификации kerberos, x509, cardspace, ws-federation, ntlm? Что там насчет поддержки авторизации?

AVK>>Jini нельзя добавить поддержку веб-сервисов в полном объеме?

C>В Jini можно добавить все что угодно, там архитектура гибкая.

Зачем тогда Tango?
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.08.07 19:33
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

AVK>>Ты все перепутал.


ANS>Я ниче не мог перепутать, потому как я спрашивал как именно оно работает.


Значит перепутал тот, кто тебе отвечал.

AVK>>Анонимные типы недоступны компилятору за пределами метода.


ANS>То есть возвращаемое Linq-ом значение нельзя вернуть из метода (кроме как Object)?


Да.

AVK>>С точки зрения рантайма (а биндинг работает только в рантайме) никаких анонимных типов нет, есть обычные классы.


ANS>Дык тем фактом, что Linq всё во время компиляции проверяет, а не в ран-тайм. Или ты о чем?


Ты чего, совсем не читаешь тред, на который отвечаешь?

class UI
{
  void OnLoad()
  {
    binder.List = from c in Customer select c;
  }
}

Это биндинг. Вот он с анонимными типами будет работать без проблем, несмотря на то, что реализован в сборках FCL.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.08.07 19:33
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>хм. начал думать причем тут clr. Так и не понял.


Во-первых:
var x = new {Customer.Name, Customer.Description};
var y = new {Person.Name, Person.Description};
Console.WriteLine(x.GetType() == y.GetType()); // true

Во-вторых, как только анонимный тип станет доступен за пределами метода (а значит и за пределами сборки), это, в условиях .NET, автоматом означает, что генерацию анонимных типов должен делать уже не компилятор, как сейчас, а JIT, потому что только JIT обладает полной информацией о всех загруженных сборках.
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[58]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 08.08.07 19:48
Оценка:
Здравствуйте, IT, Вы писали:

C>>А ты просто не используй Windows. Какие проблемы-то?

IT>Всё, я больше не могу Кто-нибудь там поближе, киньте в этого маньяка чем-нибудь тяжёлым!
Отскочит и обратно прилетит

Я для чего сравнение делал — не всегда возможно просто так отказаться от индусокода.
Sapienti sat!
Re[56]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 08.08.07 19:55
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>
AVK>object o = GetProxy();
AVK>var x = o as X;
AVK>

AVK>Чего будем переписывать? Все касты во всем коде включая библиотеки?
Как оно тогда работает? Неужто поставили хак прямо в JIT?

C>>Так Tango и есть просто реализация всех стандартов WS.

AVK>Почему не ввиде расширения Jini? Может потому что последний заметно проще чем WCF и в его архитектуру все потребные фичи просто не укладываются?
Потому как в Java предпочитают разнообразие. Гораздо проще сделать Tango без дополнительного слоя поверх существующей инфраструктуры сервлетов — так что так и сделали.

AVK>Как в Jini с поддержкой messaging, streaming, notifications, reliable messaging, p2p, metadata exchange? Есть ли в jini реализация аутентификации kerberos, x509, cardspace, ws-federation, ntlm? Что там насчет поддержки авторизации?

Messaging, notifications точно есть. Reliable messaging — это JMS. Аутентификация+авторизация — это занятия для протокола передачи.

AVK>>>Jini нельзя добавить поддержку веб-сервисов в полном объеме?

C>>В Jini можно добавить все что угодно, там архитектура гибкая.
AVK>Зачем тогда Tango?
Для совместимости
Sapienti sat!
Re[57]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.08.07 20:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

AVK>>Чего будем переписывать? Все касты во всем коде включая библиотеки?

C>Как оно тогда работает? Неужто поставили хак прямо в JIT?

Именно так. Я тебе об этом с самого начала говорил.

AVK>>Почему не ввиде расширения Jini? Может потому что последний заметно проще чем WCF и в его архитектуру все потребные фичи просто не укладываются?

C>Потому как в Java предпочитают разнообразие.

Перевожу на русский — любят изобретать велосипеды.

C> Гораздо проще сделать Tango без дополнительного слоя поверх существующей инфраструктуры сервлетов


А Jini работает поверх сервлетов?

C>Аутентификация+авторизация — это занятия для протокола передачи.


С чего бы это?
... << RSDN@Home 1.2.0 alpha rev. 693 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[58]: Являются ли макросы свидетельством недостаточной выр
От: . Великобритания  
Дата: 08.08.07 20:53
Оценка:
IT wrote:

> C>А ты просто не используй Windows. Какие проблемы-то?

>
> Всё, я больше не могу Кто-нибудь там поближе, киньте в этого маньяка
> чем-нибудь тяжёлым!
Дело он говорит. Иногда бывает очень трудно объяснить, почему нужно писать так, а не иначе. Притом "мои инспекции
показывают..." не прокатывает — компилируется и ладно. Вот люди не знают про bind-параметры, не понимают объяснений, что
такое sql-injection — ради бога, пусть дальше мучаются, свои правила навязывать не всегда возможно.
Так что считай, что инспекции — типа вонингов в С++ (но не отнимающих время при компиляции), они проверяются,
показываются, но запустить и поиграться с кривым кодом возможно. И инспекции служат для проверки качества кода, а не его
работоспособности.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[59]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 09.08.07 00:55
Оценка:
Здравствуйте, ., Вы писали:

.>Иногда бывает очень трудно объяснить, почему нужно писать так, а не иначе.


Макросами можно сделать любые инспекции и выдавать во время компиляции хоть ворнинги, хоть ошибки компиляции. В самом компиляторе, например, нельзя объявить член любого класса типа Location не mutable. Ты такое можешь со своими инспекциями?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: FR  
Дата: 09.08.07 03:33
Оценка:
Здравствуйте, cl-user, Вы писали:


FR>>Скорость и близость к железу не всегда совпадают


CU>А нафиг "близость к железу", если она не даёт скорость? Для самоудовлетворения?


У форта для близких к железу решений есть два железных преимущества, легкость портирования (аппаратно зависимые части ядра всего килобайты) и компактность получаемого кода (обгоняет многие ассемблеры). Поэтому для встраиваемых устройств очень хороший выбор. Кроме того по параметру размер реализации / высокоуровневость кода, форт рекордсмен до сих пор.
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: FR  
Дата: 09.08.07 03:48
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Руби, Питон и ЯваСкрипт — это скрипыт. Скрпты до мозга костей. Их методы метапрограммирования на прочь убивают любые потуги в лпане повышения производительности (компиляции), надежности (статические проверки) и поддерживаемости.


Влад тебе уже наверно десятки раз здесь показывали как работает метапрогроаммирование в том же питоне или Smalltalk'е, но ты все равно как попугай повторяешь свои любимые мантры.
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 09.08.07 06:59
Оценка:
Здравствуйте, mkizub, Вы писали:

CU>>>>Гибкость — да, скорость — нет.


FR>>>Скорость и близость к железу не всегда совпадают


CU>>А нафиг "близость к железу", если она не даёт скорость? Для самоудовлетворения?


M>Думай, голова, думай — не только кушать дана.


"Памяти мало, на скорость положить" — слишком узкий спектр задач. Даже в мобилку не пойдёт. Вот и остаётся только что засовывать в медленные но хитрые контроллеры да в бутромы всякие — скорость загрузки не критична.
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 09.08.07 07:05
Оценка:
Здравствуйте, FR, Вы писали:

FR>У форта для близких к железу решений есть два железных преимущества, легкость портирования (аппаратно зависимые части ядра всего килобайты) и компактность получаемого кода (обгоняет многие ассемблеры). Поэтому для встраиваемых устройств очень хороший выбор. Кроме того по параметру размер реализации / высокоуровневость кода, форт рекордсмен до сих пор.


Так я и не спорил с применением во всяких контроллерах и прочей "ембедщине". Но тут его вроде как GPL предлагали?..
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.08.07 07:43
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>
AVK>class UI
AVK>{
AVK>  void OnLoad()
AVK>  {
AVK>    binder.List = from c in Customer select c;
AVK>  }
AVK>}
AVK>

AVK>Это биндинг. Вот он с анонимными типами будет работать без проблем, несмотря на то, что реализован в сборках FCL.

А какого типа List? (В примере будет Customer, как я понимаю, но меня интересует "вообще"). Там же не Object, который разгребается рефлексией?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 09.08.07 08:28
Оценка:
Здравствуйте, cl-user, Вы писали:

M>>Пробовали — херня получается , Lisp называется.


CU>1. "ниасилил"?

CU>2. Вы просто не умеете его готовить.

Спасибо за предложенный список, но у меня есть свой вариант.
Лисп в качестве языка мета-программирования — это вроде ассемблера для императивных языков.
На ассемблере можно многое сделать, но почему-то делают мало, а много предпочитают делать на ЯВУ.
У меня к Лиспу нежное отношение, поскольку они на пару с Фортом демонстрируют всю мощь мета-программирования. Как говорится, "и сжёг он то, чему поклонялся; и поклонился тому, что сжёг". Так я и сделал — реализовал систему мета-программироварния, которая так-же относится к Лиспу, как ЯВУ к ассемблеру. И поклонился дедушке Лиспу, сказав ему последнее прости-прощай.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 09.08.07 08:38
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Спасибо за предложенный список, но у меня есть свой вариант.

M>Лисп в качестве языка мета-программирования — это вроде ассемблера для императивных языков.
M>На ассемблере можно многое сделать, но почему-то делают мало, а много предпочитают делать на ЯВУ.
M>У меня к Лиспу нежное отношение, поскольку они на пару с Фортом демонстрируют всю мощь мета-программирования. Как говорится, "и сжёг он то, чему поклонялся; и поклонился тому, что сжёг". Так я и сделал — реализовал систему мета-программироварния, которая так-же относится к Лиспу, как ЯВУ к ассемблеру. И поклонился дедушке Лиспу, сказав ему последнее прости-прощай.

Спасибо. Очень заинтересовало.

Что есть ЯВУ в мета-программировании? (N не вспоминать )
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 09.08.07 08:48
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>"Памяти мало, на скорость положить" — слишком узкий спектр задач. Даже в мобилку не пойдёт. Вот и остаётся только что засовывать в медленные но хитрые контроллеры да в бутромы всякие — скорость загрузки не критична.


— Скорость работы специализированной железяки определяется в первую очередь этой железячностью.
— Никому, как правило, нафиг не нужно исполнять программы общего назначения на специализированной железяке, и писать под неё компилятор для С — нафиг не нужно, а нередко и просто невозможно.
— Компилятор на С врядли обеспечит значительный прирост скорости, поскольку специализированные вещи делаются на ассемблере, а связка между функциями занимает 5% времени исполнения, оптимизировать эти 5% такой ценой — безумие.
— Несмотря на всю низкоуровневость С или аналогичных языков — у них есть неприятное свойство в виде наличия call conventions, которые сильно затрудняют их работу с ассемблерными методами.

Учитывая всё это (а может что-то и позабыл) — реализация кода на Форте в 99% случаев (т.е. кроме крайне массовых продуктов, вроде специлизированного GPU) будет быстрее, дешевле, надёжней, мощнее. Мизерные потери на скорость на этом фоне никого не волнуют. Я тебе больше скажу — на 9 телефонах из 10 (с ARM CPU), с которыми я работал — код компилируется в Thumb режиме. Да, это медленее на 30%, но на эти же 30% сокращает размер кода — и производители выбирают размер, и это не для специализированной железяки, а для девайса общего назначения.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 09.08.07 09:06
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>Что есть ЯВУ в мета-программировании? (N не вспоминать )


Что есть ЯВУ вообще? Удобный синтаксис (отображение, восприятие кода), программирование в более высокоуровневых абстрациях (врочем, этого к Лиспу тяжело добавить больше, чем у него уже есть) и оптимизация опираясь на эти абстракции, а так-же переносимость (вот этого у Лиспа не очень). Есть ещё несколько полезных средств разработки, ассоциированных с ЯВУ (вроде IDE), которые менее удобны для "ассемблеров" в виду отсутствия у них конструкций со сложной семантикой. У Лиспа семантика расширяемая, но нет средств "сообщить/описать" эти расширения в IDE, поэтому последний так-же слабо поможет в написании мета-программ. Или в декларацию новых семантических конструкций необходимо добавлять описание для их понимания IDE — что-то вроде мета-протокола, как CLOS описывает ОО, так и какой-нибудь CLIDE будет описывать интеграцию с IDE.

Вот тут статья, которую всё никак не собирутся опубликовать на RSDN.
http://www.symade.org/SOP_and_SymADE.doc
Я пишу новую и побольше, но это ещё не один день займёт.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[58]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 09.08.07 10:16
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Чего будем переписывать? Все касты во всем коде включая библиотеки?

C>>Как оно тогда работает? Неужто поставили хак прямо в JIT?
AVK>Именно так. Я тебе об этом с самого начала говорил.
Добавить, что ли, на досуге в JRE такой же хак? Кстати, тоже самое МОЖНО сделать переписывание байт-кодов. Только нужно будет переписывать ВСЕ касты.

Это возможно, но достаточно дорого по времени получится (ага, теперь понятно, почему портированое на Java приложение работало на 20% быстрее).

AVK>>>Почему не ввиде расширения Jini? Может потому что последний заметно проще чем WCF и в его архитектуру все потребные фичи просто не укладываются?

C>>Потому как в Java предпочитают разнообразие.
AVK>Перевожу на русский — любят изобретать велосипеды.
Именно. И в итоге выживает наиболее приспособленый, простой и удобный велосипед.

C>> Гораздо проще сделать Tango без дополнительного слоя поверх существующей инфраструктуры сервлетов

AVK>А Jini работает поверх сервлетов?
Опционально, при использовании HTTP в качестве транспорта.

C>>Аутентификация+авторизация — это занятия для протокола передачи.

AVK>С чего бы это?
А с чего бы это должно быть проблемой самого JINI?
Sapienti sat!
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.08.07 10:33
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>1. "ниасилил"?


В следующий раз будет бан.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 09.08.07 10:37
Оценка:
Здравствуйте, mkizub, Вы писали:

M>- Скорость работы специализированной железяки определяется в первую очередь этой железячностью.

M>- Никому, как правило, нафиг не нужно исполнять программы общего назначения на специализированной железяке, и писать под неё компилятор для С — нафиг не нужно, а нередко и просто невозможно.
M>- Компилятор на С врядли обеспечит значительный прирост скорости, поскольку специализированные вещи делаются на ассемблере, а связка между функциями занимает 5% времени исполнения, оптимизировать эти 5% такой ценой — безумие.
M>- Несмотря на всю низкоуровневость С или аналогичных языков — у них есть неприятное свойство в виде наличия call conventions, которые сильно затрудняют их работу с ассемблерными методами.

M>Учитывая всё это (а может что-то и позабыл) — реализация кода на Форте в 99% случаев (т.е. кроме крайне массовых продуктов, вроде специлизированного GPU) будет быстрее, дешевле, надёжней, мощнее. Мизерные потери на скорость на этом фоне никого не волнуют. Я тебе больше скажу — на 9 телефонах из 10 (с ARM CPU), с которыми я работал — код компилируется в Thumb режиме. Да, это медленее на 30%, но на эти же 30% сокращает размер кода — и производители выбирают размер, и это не для специализированной железяки, а для девайса общего назначения.


Я уже писал — ничего не имею против форта как языка для "ембедщины" и т.п.
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 09.08.07 10:45
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, cl-user, Вы писали:


CU>>Что есть ЯВУ в мета-программировании? (N не вспоминать )


M>Что есть ЯВУ вообще? Удобный синтаксис (отображение, восприятие кода),


субъективно

M> программирование в более высокоуровневых абстрациях (врочем, этого к Лиспу тяжело добавить больше, чем у него уже есть)


угу

M> и оптимизация опираясь на эти абстракции, а так-же переносимость (вот этого у Лиспа не очень).


С чем "не очень"? С переносимостью между чем и чем?

M> Есть ещё несколько полезных средств разработки, ассоциированных с ЯВУ (вроде IDE), которые менее удобны для "ассемблеров" в виду отсутствия у них конструкций со сложной семантикой. У Лиспа семантика расширяемая, но нет средств "сообщить/описать" эти расширения в IDE, поэтому последний так-же слабо поможет в написании мета-программ.


Не понял... SLIME прекрасно подсказывает количество и характер (для некоторых реализаций — и имена параметров) при вызове функций/макр. Типов — да, о них ничего не говорит. Но мог-бы (для тех реализаций, которые поддерживают эту "метаинформацию").

M> Или в декларацию новых семантических конструкций необходимо добавлять описание для их понимания IDE — что-то вроде мета-протокола, как CLOS описывает ОО, так и какой-нибудь CLIDE будет описывать интеграцию с IDE.


SLIME использует средства инспектирования каждой отдельной реализации.

M>Вот тут статья, которую всё никак не собирутся опубликовать на RSDN.

M>http://www.symade.org/SOP_and_SymADE.doc
M>Я пишу новую и побольше, но это ещё не один день займёт.

Ок, почитаем.

Так, это, более ВУ Я нет?
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.08.07 11:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Как я понял в случае с Парсеком мы просто получим некорректный парсер. Так?


Да.
Но хочу заметить, что это не ограничение того, что не используются макросы. Просто это решение конкретной библиотеки. То же самое решение можно построить на комбинаторах. Делаем для них возможность instance Eq, а потом для <|> просто сравниваем начало левого и правого комбинатора. Если равны — выводим соответствующую ошибку. Будет работать в компайлтайме.

VD>Она мне нитересна, конечно. Но это только один вопрос. А их несколько. Вот в начале этого собщения мы говорим о логике постраителя парсера. Это мне тоже очень интересно. Потом интересна отладка. Да и просто поглядеть на то во что выльется грамматика интересно.


Отладка — в смысле пошаговый дебаггер?

VD>А то абстрано у всех все здорово и красиво. А вот на прктике что-то проблемы вылезают.


Не, я не абстрактно говорю, редко, но применяю Parsec на практике. Конечно, у меня задачи по разбору не такие критичные к производительности, как у тебя, поэтому мне хватает даже простого [Char]. Но это только то, что касается производительности. Что касается описания грамматики, то парсек для меня удобнее чистого EBNF — из-за возможности дополнять своими комбинаторами.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 09.08.07 11:15
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>>>Что есть ЯВУ в мета-программировании? (N не вспоминать )


M>>Что есть ЯВУ вообще? Удобный синтаксис (отображение, восприятие кода),


CU>субъективно


Безусловно. Плюс — привычка. Исследования показывают, что человек читает буквенный текст (слова) так-же, как иероглифы — как целое. Высокоуровневые конструкции языка человек тоже воспринимает целиком, а не разбивает их на кусочки — конечно, после определённой практики. Степень автоматизма доходит до того, что даже индентация/пробелы влияют на распознавания "образа" и читаемость кода, не говоря уже о различиях С и Паскаль-подобного синтаксиса, и уж тем более синтаксиса Лиспа и Форта.

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

Далее. Возможность отображать дерево не целиком, а многоуровнево, скрывая несущественные детали — это объективный показатель. В качестве примера можно привести бесконечные пальцы веером у ФП программистов по поводу выводимости типов. А фактически вся эта выводимость сводится к тому, что часть кода не нужно писать/отображать. Очень небольшую часть кода — всего лишь типы. На фоне возможности, скажем, визуальных редакторов GUI, которые показывают как будет выглядеть диалог, скрывая детали вроде обработчиков событий и настроек layout manager-а — возможности сокрытия ненужной информации при выводе типов — это детский лепет.

M>> и оптимизация опираясь на эти абстракции, а так-же переносимость (вот этого у Лиспа не очень).


CU>С чем "не очень"? С переносимостью между чем и чем?


Лисп задаёт не только новую семантику узлов дерева, но и её реализацию. Она у него неотрывно привязана к декларации макроса. Соотвественно и трансформация дерева макросом предполагается только одна. А если отделить декларацию семантики от транформации, то можно преобразовывать одну абстракцию в разные реализации для разных платформ, или разные реализации в зависимости от настроек компилятора и проекта. Это даст как большую модульность, так и большую переносимость кода.

M>> Есть ещё несколько полезных средств разработки, ассоциированных с ЯВУ (вроде IDE), которые менее удобны для "ассемблеров" в виду отсутствия у них конструкций со сложной семантикой. У Лиспа семантика расширяемая, но нет средств "сообщить/описать" эти расширения в IDE, поэтому последний так-же слабо поможет в написании мета-программ.


CU>Не понял... SLIME прекрасно подсказывает количество и характер (для некоторых реализаций — и имена параметров) при вызове функций/макр. Типов — да, о них ничего не говорит. Но мог-бы (для тех реализаций, которые поддерживают эту "метаинформацию").


Людей мало интересуют имена параметров — это детали внутренней реализации. Людей больше заботит семантика и удобство отображения. Скажем, как это сделано для автоматической генерации кода в IDE — набираем слово for жмём Ctrl-Enter и нам генерят и показывают код

for ( <init> ; <check> ; <iterate> ) <statement>


После чего <поля> заполняются как поля ввода, а не редактирование текста. При этом внутренняя реализация узла для for loop может иметь много других полей, являющихся деталью реализации — скажем, labels для break и continue и т.п., не говоря уже о именах слотов для хранения под-узлов, которые совсем не обязаны быть init, check, iterate.

M>> Или в декларацию новых семантических конструкций необходимо добавлять описание для их понимания IDE — что-то вроде мета-протокола, как CLOS описывает ОО, так и какой-нибудь CLIDE будет описывать интеграцию с IDE.


CU>SLIME использует средства инспектирования каждой отдельной реализации.


А он есть для Eclipse? А то я Emacs не осилил, в силу особенностей реализации своего мозга, который принципиально больше 5 шорткатов запоминать отказывается.

M>>http://www.symade.org/SOP_and_SymADE.doc


CU>Так, это, более ВУ Я нет?


Это вообще не язык. Это концепция (парадигма) программирования (с упором на мета-программирование) и его реализация.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.08.07 11:20
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это главная фича. "Кода в скобках" попросту нет! На выходе мы получаем список/поток вариантов описывающих грамматические конструкции. Ну, а далее мы прсото анализируем их средствами паттерн-матчинга. В итоге получаем полное отделение описания грамматики от действий предпринимаемых при распозновании тех или иных конструкций.


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

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


konsoletyper говорил, что свои комбинаторы нельзя писать. только те, что есть в EBNF — *, | и т.д.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.08.07 11:21
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>К сожалению, нет. Но готов поставить если будут четки инструкции "чего и скока?". За одно многие другие смогут приобщиться.


К сожалению, побился indent, а как тут файл залить можно?

Поставить можно GHC:

http://haskell.org/ghc/download.html

Качаешь, ставишь. Настраиваешь пути

Можно запускать сразу в режиме интерпретации

> runhaskell JSON.lhs test.js


Или сначала скомпилировать, а потом запустить

> ghc --make -O2 JSON.lhs

> JSON.exe test.js

VD>А можно увидить все это в целом? Ну, чтобы с оригиналом сравнить?


Э-э-э.. Что то я туплю с утра. Что увидеть?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.08.07 13:16
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>А что встренные строки Хаскеля поддерживают Юникод?


Вообще должны, но поддерживаются не везде, насколько я знаю. GHC, например, поддерживает, но при выводе в stdout обрезает символ до последних 8 бит

Разумеется, есть решения, но я никогда этим не интересовался.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 09.08.07 15:07
Оценка:
Здравствуйте, cl-user, Вы писали:

M>>Это вообще не язык. Это концепция (парадигма) программирования (с упором на мета-программирование) и его реализация.


CU>Это пока ещё только концепция и ничего больше.

CU>Так и запишем: "Лисп — ассемблер в МП. Но С ещё не придумали..."

По первых — реализация, пусть и в стадии prrof-of-concept.
Во вторых — уже придумали.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 09.08.07 15:57
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>"Памяти мало, на скорость положить" — слишком узкий спектр задач. Даже в мобилку не пойдёт. Вот и остаётся только что засовывать в медленные но хитрые контроллеры да в бутромы всякие — скорость загрузки не критична.


По сравнению с той же явой которую суют сейчас в мобилки форт будет очень шустрым, он медленен только относительно достаточно хорошего си компилятора.
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 09.08.07 16:52
Оценка:
Здравствуйте, FR, Вы писали:

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


Не будет. Совать форт, написанный непонятно кем, в свой телефон нормальный человек не будет. Потому как фортовских программ с встроенным вирусом образуется больше, чем сейчас спама образовалось из e-mail-а.
Явовский код — это такой же стек, как и фортовский, плюс проверки на нулевой указатель, выход за границы массивов, проверки типов и прочее. Явовскому интерпретатору просто не от чего быть медленее, кроме проверок — а без них левый код на мобилку не загрузишь.
Больше того, нынешние мобилки прекрасно позволяют компилировать яву в нэйтивный код, памяти у них хватает. И для распространённых на мобилках CPU эти компиляторы написаны и работают. Интепретатор форта не сдюжит против компилятора в нэйтивный код никаким местом.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: Andrei F.  
Дата: 10.08.07 03:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В Java для этого полно инструментов, в .NET знаю только: http://rail.dei.uc.pt/project_overview.htm


http://rsdn.ru/Forum/message/2564849.1.aspx
Автор: AndreiF
Дата: 29.06.07

еще можно использовать profiler API, чтобы модифицировать IL код перед выполнением JIT-a
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 10.08.07 03:16
Оценка:
Здравствуйте, mkizub, Вы писали:

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


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


M>Не будет. Совать форт, написанный непонятно кем, в свой телефон нормальный человек не будет. Потому как фортовских программ с встроенным вирусом образуется больше, чем сейчас спама образовалось из e-mail-а.


Не будет не из-за этого, а из-за того что место давно занято.

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

M>Больше того, нынешние мобилки прекрасно позволяют компилировать яву в нэйтивный код, памяти у них хватает. И для распространённых на мобилках CPU эти компиляторы написаны и работают. Интепретатор форта не сдюжит против компилятора в нэйтивный код никаким местом.

Угу то-то эта ява так страшно тормозит.
"Интерпретор" у форта как ты наверно знаешь, имеет некторые особенности которые позволяют ему по скорости мало уступать тупым плохо оптимизирующим компиляторам (а явовские в мобилках именно такие), правда эти же особенности мешают построить хороший оптимизирующий компилятор. Но компиляторы у форта есть и посоревноватся с той же явой вполне могут.
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 10.08.07 07:02
Оценка:
Здравствуйте, mkizub, Вы писали:

M>>>Это вообще не язык. Это концепция (парадигма) программирования (с упором на мета-программирование) и его реализация.


CU>>Это пока ещё только концепция и ничего больше.

CU>>Так и запишем: "Лисп — ассемблер в МП. Но С ещё не придумали..."

M>По первых — реализация, пусть и в стадии prrof-of-concept.


Хрен редьки не слаще. Ваш концепт только и доказывает что возможность частичной реализации Вашей-же идеи. Всё. С практической точки зрения — 0.

M>Во вторых — уже придумали.


"Имя, сестра, имя!"
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 10.08.07 07:06
Оценка:
Здравствуйте, FR, Вы писали:

CU>>"Памяти мало, на скорость положить" — слишком узкий спектр задач. Даже в мобилку не пойдёт. Вот и остаётся только что засовывать в медленные но хитрые контроллеры да в бутромы всякие — скорость загрузки не критична.


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


Он медленнее любых "прямых" компиляторов в натив. Даже SBCL его обгоняет. Так нафига? Только из-за памяти.
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 10.08.07 08:52
Оценка:
Здравствуйте, FR, Вы писали:

FR>Не будет не из-за этого, а из-за того что место давно занято.


Ага, а когда оно было свободным — помешал всемирный еврейский заговор.

FR>Угу то-то эта ява так страшно тормозит.


"Страшно" тормозящую яву я видел только одну — неоптимизированный C-шный main loop по байткоду, который поставляется фирмой Sun, для а) отладки, и б) пусть каждый оптимизирует под свой процессор как хочет.
Именно эту работу я делал для Samsung-овский телефонов и digital TV — переписывал main loop на асме, что за неделю работы дало ускорение в 2 раза. Ещё в два раза дало ускорение оптимизация вызова методов и выкидывание некоторых "дублирующих" инструкций (вроде op_null и op_const0) и использование освободившегося места для комбинированных инструкций.

FR>"Интерпретор" у форта как ты наверно знаешь, имеет некторые особенности которые позволяют ему по скорости мало уступать тупым плохо оптимизирующим компиляторам (а явовские в мобилках именно такие), правда эти же особенности мешают построить хороший оптимизирующий компилятор. Но компиляторы у форта есть и посоревноватся с той же явой вполне могут.


Этого не может быть, потому, что этого не может быть никогда.
Любой, самый тупой из тупых компиляторов разворачивает байткод в последовательность комманд процессора, экономя на каждой комманде чтение опкода и джамп на хэндлер. У ARM эти две операции совмещены, но джамп занимает больше такта. У MIPS их надо делать отдельно, но он выполняет ещё одну инструкцию, в течении джампа. Итого — минимальная прибыль от компилятора, даже если он тупо работает со стеком и не занимается регистрами — 2-3 такта на инстукцию. Если он ещё регистры использует (даже без оптимизации) — то это ещё раза в 2 ускорение.

Фсё, я тему быстродействия больше в этом топике не обсуждаю. Если есть что-то конкретное в виде бенчмарков — можно обсудить в новом топике.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 10.08.07 09:31
Оценка:
Здравствуйте, Andrei F., Вы писали:

C>>В Java для этого полно инструментов, в .NET знаю только: http://rail.dei.uc.pt/project_overview.htm

AF>http://rsdn.ru/Forum/message/2564849.1.aspx
Автор: AndreiF
Дата: 29.06.07

AF>еще можно использовать profiler API, чтобы модифицировать IL код перед выполнением JIT-a
Маловато будет, тут по большей части просто процессоры IL, Феникс вообще пока умер. Есть еще RAILS — но они тоже как-то присмерти.

В Java есть всякие: http://www.csg.is.titech.ac.jp/~chiba/javassist/
Sapienti sat!
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: FR  
Дата: 10.08.07 09:52
Оценка:
Здравствуйте, mkizub, Вы писали:


FR>>"Интерпретор" у форта как ты наверно знаешь, имеет некторые особенности которые позволяют ему по скорости мало уступать тупым плохо оптимизирующим компиляторам (а явовские в мобилках именно такие), правда эти же особенности мешают построить хороший оптимизирующий компилятор. Но компиляторы у форта есть и посоревноватся с той же явой вполне могут.


M>Этого не может быть, потому, что этого не может быть никогда.


Угу пока не ознокомишся как форт система работает.

M>Любой, самый тупой из тупых компиляторов разворачивает байткод в последовательность комманд процессора, экономя на каждой комманде чтение опкода и джамп на хэндлер. У ARM эти две операции совмещены, но джамп занимает больше такта. У MIPS их надо делать отдельно, но он выполняет ещё одну инструкцию, в течении джампа. Итого — минимальная прибыль от компилятора, даже если он тупо работает со стеком и не занимается регистрами — 2-3 такта на инстукцию. Если он ещё регистры использует (даже без оптимизации) — то это ещё раза в 2 ускорение.


"Интерпретатор" прямого шитого кода в форте состоит всего из нескольких ассемблерных команд, суть его работы в том что выбирает адрес слова и делает косвенный call. То есть добавляется на один косвенный вызов больше чем при непосредственном вызове подпрограммы. Компиляторы просто заменяют этот косвенный вызов на прямой call и инлайнят низкоуровневые слова.

M>Фсё, я тему быстродействия больше в этом топике не обсуждаю. Если есть что-то конкретное в виде бенчмарков — можно обсудить в новом топике.


Дя бенчмарков я форт слишком давно в руках не держал.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.08.07 13:53
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Мне кажется именно это решение возможно на чистых ФВП и ПМ:...


Это где угодно можно делать. Толкьо это не эффектвно и не гибко.

Макрос генерирует специализированный (оптимизированный) код для частных случаев. Так он обрабатывает ситуации в ктолрых речь идет о массивах и генерирует for-ы, обрабатывает ситуацию когда коллекция реализует интерфейс IDisposable и вызывает при этом Dispose(), генерирует оптимальный код для списков и (что очень важно) разворачивает генераторы последовательностей в циклы. В итоге получается гибкое и оптимальное с точки зрения производительности решение. Причем синтаксически оно такое как хочется, а не такое как получается (как в твоих примерах).

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

L>Аналогично (строку не буду собирать)


А зря, кстати. Строка тоже собирается макросом. Он тоже явно боеле выразителен чем то что можешь предложить Хаскель.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.08.07 13:53
Оценка:
Здравствуйте, lomeo, Вы писали:

L>К сожалению, побился indent, а как тут файл залить можно?


Входишь в своей профайл и там есть сслочка на твои файлы. Ну, а там кнопочка "Загрузить".

L>Поставить можно GHC:

L>http://haskell.org/ghc/download.html
L>Качаешь, ставишь.

ОК.

L>Настраиваешь пути


Ну, это как всегда у ученых и юнисойдов. Ни дня без траха.

L>Э-э-э.. Что то я туплю с утра. Что увидеть?


Код целиком.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.08.07 13:53
Оценка:
Здравствуйте, deniok, Вы писали:

Вопрос...

Все эти фунции работают в рантайме? Я все же могу породить спциализированный код во время компиляции или нет?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.08.07 13:53
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Но ведь изначально вопрос стоял так: являются ли макросы неким маркером, сигналящем о недостаточной выразительности языка в той области, в которой они в этом языке применяются.


Дык... Вот мой пример и демонстрирует несостоятельность такой постановки вопроса.

В том же дотнете (а занчит в любом поддерживающем его языке) подобные задачи можно решать с помощью рефлексии. Вот только я в реальной жизни выбрал генерацию кода в компайлатме на макросах. И сделал это не просто так. Дело в том, что я выбрал оптимальное (для моей задачи) решение. Мне ну нужны лишние вычисления в рантайме. Я не верю в нулевой оверхэд любой рантайм подсистемы использующей информацию о типах. К тому же делая выбор в пользу рантайма мы неменуемо откладываем мноиге проверки до рантайма. А это уже значит, что мы получаем менее надежное решение. Например, мое решение во время компиляции информировало программиста о том, что перменные типа Location обязательно должны быть изменямыми (объявлены с идентефикатором mutable). Если бы этого не было, то ошибка выявлялась бы толко в рантайме и только кода мой код начал бы модифицировать конкретное поле.

В общем, это разные решения хотя и решающие одну и ту же задачу. У них разные характеристики.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 12.08.07 14:51
Оценка:
L>>Поставить можно GHC:
L>>http://haskell.org/ghc/download.html
L>>Качаешь, ставишь.

VD>ОК.


L>>Настраиваешь пути


VD>Ну, это как всегда у ученых и юнисойдов. Ни дня без траха.


для мартышек там есть автоматический инсталлятор

(не обижайся, Влад, сам таким пользуюсь)
Люди, я люблю вас! Будьте бдительны!!!
Re[29]: Generic programming
От: BulatZiganshin  
Дата: 12.08.07 15:34
Оценка:
VD>>Она мне нитересна, конечно. Но это только один вопрос. А их несколько. Вот в начале этого собщения мы говорим о логике постраителя парсера. Это мне тоже очень интересно. Потом интересна отладка. Да и просто поглядеть на то во что выльется грамматика интересно.

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

кстати, был ещё и парсер, основанный на arrows. благодаря сойствам Arrow этот парсер действительнор генерил LR-таблицы разбора; насколько я понимаю, их подход дейстивтельно соответствовал BNF-описанию грамматики в виде eDSL с последующей генерацией кода, даром что это была библиотека:
Sometimes it's useful to restrict what you can do. Duponcheel and
Swierstra wrote a parser library as an Arrow; because it forced you to
decide the parsing structure ahead of time, their library had enough
information to build LR-type parsing tables, and thus to do yacc-style
error correction. (Nobody found it useful enough to use, but it still
makes a nice demonstration of why plain Arrow is sometimes better.)

кстати, вот здесь — haskell.org/haskellwiki/Blog_articles/Monads собрано 42 введение в монады. не может быть, чтобы среди них не нашлось ни одного, которого тебе удастся наконец понять


что касается generic programming. SYB, который вы здесь обсуждаете — лишь один из возможных подходов. я их в своё время насчитал десяток, а ведь я в этой области совсем не специалист. из них три поставляются с самим GHC — SYB, Template Haskell, [1]. В [2] даётся краткое описание всех подходов

[1] Derivable type classes [http://research.microsoft.com/~simonpj/Papers/derive.ps.gz]
[2] Comparing Approaches to Generic Programming in Haskell [http://www.cs.uu.nl/~johanj/publications/ComparingGP.pdf]


теперь о том, каким образом *библиотека* может в *compile-time* сгенерить код, специализированный для данного конкретного типа. на самом деле ты знаешь ответ темплейты в C++ устроены похоже на type classes в хаскеле. когда ты даёшь темплейту аргумент определённого типа, он генерит код именно для данного конкретного типа. в хаскеле type inference позволяет вообще не писать типов данных и тем не менее гшенерить типо-специфичный код

далее, для каждого контейнерного типа пишется (или генерится) несколько стандартных процедур обхода — перечисление элементов (fold), генерация (unfold) и т.д. generic-процедуры программируются через эти операции, проверки, которые можнор разрешить в compile-time, превращаются в константные выражения, в результате темплейто-подобная кодогенерация плюс стандартная оптимизация генерит эффективную type-specific процедуру

впрочем, это только один из возможных подходов. он используется в syb4 Олега Киселёва [3]. syb0 проихзводит поверки в run-time, т.е. он аналогичен использованию RTTI в ООП языках. другие же подходы (GH, [1]) просто используют специаольный язык для описания generic процедур. это можно считать специализированным языком, позволяющим компилятору сгенерить type-speciifc код как в макросистемах или RTTI-based код. отличие от макросистем в том, что во всех случаях пользователь думает в терминах одноуровневого языка, а не двух отдельных систем — прецпроцессинга и собственно выполнения

[3] Ищи "[Haskell] Smash your boiler-plate without class and Typeable"
и "[Haskell] Smash along your boilerplate; how to traverse a non-existent term"
http://okmij.org/ftp/Haskell/syb4.hs
http://darcs.haskell.org/generics/comparison/SmashA/
Люди, я люблю вас! Будьте бдительны!!!
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>для мартышек там есть автоматический инсталлятор


BZ>(не обижайся, Влад, сам таким пользуюсь)


Я и не обижаюсь. Просто неверная классификация. Только венец природы — половозрелый человек, может додуматься не делать лишней работы. А как раз мартышка с удовольствием полезет на дерево...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Generic programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

VD>>>Она мне нитересна, конечно. Но это только один вопрос. А их несколько. Вот в начале этого собщения мы говорим о логике постраителя парсера. Это мне тоже очень интересно. Потом интересна отладка. Да и просто поглядеть на то во что выльется грамматика интересно.


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


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

Макросы позволяют решать некоторые задачи (хорошим примером является построитель парсеров):
1. В компайлатайме.
2. С меньшими временными затратами в рантайме.
3. Обеспечивает большую гибкость (мы вольны вибирать алгоритмы и синтаксис не заморачиваясь на базовые фичи языка, ведь мы генерируем код).
4. Раньше выявлять ошибки.

В итоге тут просто нечго сравнивать. Несомненно если в задача с приемлемы качеством решается некой универсальной фунцией gmap, то лучше воспользоваться ею чем создавать специализированное решение на макросах. И наличие такой фунции, так же, несоменное пиремущество. Вот только это не доказательство крутости языка. Это доказательство прозорливости тех кто писал эту фунцию. Ее так же можно реализовать и с помощью макросов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Вообще должны, но поддерживаются не везде, насколько я знаю. GHC, например, поддерживает, но при выводе в stdout обрезает символ до последних 8 бит


Иначе и быть не может, так как большинство консолей воспринимает только 8 бит. Просто должен быть АПИ по управлению кодировками.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Generic programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>кстати, был ещё и парсер, основанный на arrows. благодаря сойствам Arrow этот парсер действительнор генерил LR-таблицы разбора; насколько я понимаю, их подход дейстивтельно соответствовал BNF-описанию грамматики в виде eDSL с последующей генерацией кода, даром что это была библиотека:

BZ>Sometimes it's useful to restrict what you can do. Duponcheel and
BZ>Swierstra wrote a parser library as an Arrow; because it forced you to
BZ>decide the parsing structure ahead of time, their library had enough
BZ>information to build LR-type parsing tables, and thus to do yacc-style
BZ>error correction. (Nobody found it useful enough to use, but it still
BZ>makes a nice demonstration of why plain Arrow is sometimes better.)


Здорово. Можно по продрбнее (на пальцах)?
Конкретно:
1. Что такое Arrow?
2. Как генерируется код? Т.е. какие средства МП используются?

BZ>кстати, вот здесь — haskell.org/haskellwiki/Blog_articles/Monads собрано 42 введение в монады. не может быть, чтобы среди них не нашлось ни одного, которого тебе удастся наконец понять


Пугает как раз то что их 42. Видимо это и есть то священное значение этого числа .

BZ>что касается generic programming. SYB, который вы здесь обсуждаете — лишь один из возможных подходов. я их в своё время насчитал десяток, а ведь я в этой области совсем не специалист. из них три поставляются с самим GHC — SYB, Template Haskell, [1]. В [2] даётся краткое описание всех подходов


Ты меня извини, но Template Haskell — это как раз в чистом виде макросы. Почти аналогичные Немерловым. Template Haskell было одним из прототипов Немерла.

BZ>теперь о том, каким образом *библиотека* может в *compile-time* сгенерить код, специализированный для данного конкретного типа. на самом деле ты знаешь ответ темплейты в C++ устроены похоже на type classes в хаскеле. когда ты даёшь темплейту аргумент определённого типа, он генерит код именно для данного конкретного типа. в хаскеле type inference позволяет вообще не писать типов данных и тем не менее гшенерить типо-специфичный код


BZ>далее, для каждого контейнерного типа пишется (или генерится) несколько стандартных процедур обхода — перечисление элементов (fold), генерация (unfold) и т.д. generic-процедуры программируются через эти операции, проверки, которые можнор разрешить в compile-time, превращаются в константные выражения, в результате темплейто-подобная кодогенерация плюс стандартная оптимизация генерит эффективную type-specific процедуру


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

Если мы просто создадим некий обобщенный код и создадим две специализции некой фунции, то это не будет генерацией. Того же самого можно добиться друними формами полиморфизма. Генерация же подразумевает порождение кода на базе условий и проверку этих условий во время компиляции. Заметь — это не тоже самое, что выбор специализации.

BZ>впрочем, это только один из возможных подходов. он используется в syb4 Олега Киселёва [3]. syb0 проихзводит поверки в run-time, т.е. он аналогичен использованию RTTI в ООП языках. другие же подходы (GH, [1]) просто используют специаольный язык для описания generic процедур. это можно считать специализированным языком, позволяющим компилятору сгенерить type-speciifc код как в макросистемах или RTTI-based код. отличие от макросистем в том, что во всех случаях пользователь думает в терминах одноуровневого языка, а не двух отдельных систем — прецпроцессинга и собственно выполнения


Вот уже дудки. Или мы генерируем код и думаем в терминах двух программ: метапрограммы и конечной программы (код которой и генерируется). Или у нас "одноуровневый язык". Если под "одноуровневостью" понимается исползование того же языка, то макросы пишутся на точтно таком же языке. Просто там есть пара примитивов позволяющих явно отделить генерирующий код и генерируемый.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Короче, макросы и раные там навороченные шаблоны конечно крутая штука для шифрования исходного кода и чесания левой пяткой за правым ухом, только на практике не нужная. Думаете, почему в большинстве современных языков нет макросов? В 70-х годах вот были популярны развитые макросистемы. Сейчас — нет, потому что нафиг не нужны. Рынок, так сказать, голосует.


Единственный язык в кором в 70-ые были полноценные макросы (а не уроды как в С) — это Лисп. В нем макросы есть и по сей день. Так что доказательство основывается на ложных предпосылках. Вообще очень много ложных выводов о макросах делается по схеме: "в С макросы ужасны... значит все макросы ужасны... значит маросы зло!"
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


На этом предлагаю тему и закрыть, так как ты сам признал как минимум, что в некторых случаях они все же нужны .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>1) У тебя там применяются атрибуты. Добавление кастомных атрибутов никак не меняет синтаксис языка, и не увеличивает indirection level языковых конструкций.


Ах вот даже так? Ну, тогда хочу отрыть одну забавную тайну. Один из видов макросво в том же Немерле — это метаатрибуты. Они точно так же не меняют синтаксис языка. Другой — это простые макросы. И они не меняют синтаксис (выглядят как вызов фунции).

Так что такие макросы допустимы?

Или, не уж то, рантайм-кодогенерация которую использует IT для реализации приведенной задачи, или стоэтажные навороты на монадах Хаскеля (с неминуемвм оверхэдом) лучше? Почему не применить прямые решения для решения задачи?

Вот в C# 3.0 VB.NET и 9.0 в язык ввели DSEL под хитрым потентованным названием. Не уж то это лучше нежели ввести в язык макросы и реализовать все это на них?

G> Применение их изолировано, и локализовано. Поэтому, моя аргументация к атрибутам не относится — кастомные атрибуты являются доброй, хорошей магией. От нее вреда практически нет. По своим свойствам, влияющим на процесс разработки и поддержки — это совсем не то же самое, что злые макросы. Это безопасная штука, и мы всеми руками голосуем за кастомные атрибуты.


То есть ты голосуешь за атрибуты и против лучшего средства задания семантики для них? Зашибись!

В C# самой большой проблемой является то, что атрибуты пассивны. Нужно писать какие-то рантайм-решения котоые будут их читать и что-то делать. Та же сериализация в ХМЛ, которая к слову, была довольно удобна, дико тормозила из-за того, что при загрузке генерировала по атрибутам работчий код. Если бы она это не делала, то тормозила бы уже сериализация. В МС не придумал ничего умнее как создать ехе-шник который студия вызвает после компиляции чтобы он сгенерировал по полученным сборкам код сериализации. При этом сама реализация этого ехе-шника крайне запутана и сложна. Тоже самое на макросах пишется за пару дней и работает во время компиляции прямо в компиляторе.

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


Ага. Как в прочем кому попало не стоит доверять проектирование архитектуры ПО и т.п. Только к котегориям зла и добра это не дложно относиться.

G>2) Удобный биндинг к БД — это даже более ходовая и популярная задача, чем создание парсеров. И для ее решения, так же как ex/yacc, вполне оправдано сделать внешний макропроцессор, совсем не обязательно иметь поддержку макросов в языке.


А зачем? Да и на результаты посмотри? Лучши датабиндер до появления LINQ от MS был Кибернэйт. Но это же полная задница с точки зрения как удобства работы (описания во внешем ХМЛ), так и с точки зрения надежности (большая часть проверок в рантайме), да и быстродействие сильно хромает. LINQ тупо интегрируют в ЯП.

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

G> Насколько я понимаю, в твоем тулките, на который ты ссылаешься, так и сделано — макросисиема там не применяется. Этой же цели, кажется, служит явский hybernate? Опять, обошлись без макросистемы. Что имеем в сухом остатке? Индустрия подверждает мой тезис о макросах, не так ли?


Ага. Вот и спроси у IT зачем от занимается отладчиком для Nemerle, а не осваивает Кибернэйм или не допиливает свое решение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


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

G>...так объясните еще раз — зачем нужны меняющие синтаксис макросы?


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

G>Что пользователю не все равно — так это встречать недокументированные языковые расширения самоделкиных, сделанные на каждый чих. Это — плохо. Это — убивает maintainability. А для редких случаев вполне сгодятся тулы вроде яка с лексом.


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

G>Индустрия имела макросы в далеких 70-х. И отказалась от них вместе с ассемблерами и языками-монстрами вроде PL/1 — с появлением простых и понятных языков высокого уровня.


Это не те макросы. Те были только в Лиспе. В нем они есть и по сей день.

ЗЫ

И вообще, забавно наблюдать как человек всего год-два пропагандировавший ОКамлоский препроцессор вдруг стал таким рьяным борцом с макросами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Есть. Почему они так и остались почти во всех ассемблерах?
Почему ты сравниваешь примитивные текстуальные макросы ранних ассемблеров с Лисп-подобными макросистемами?
Почему в том же Лиспе макросы не были отвергнуты?
Почему появились Темлэйт Хаскель, ОКамлосвский препроцессор и многие другие полноценные маросистемы?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>К LISP паттерн-матчинг в 70 году был, манипуляция AST в нем тоже была.


Гы. В Лиспе паттерн-матчинага, да и АСТ никогда небыло. АСТ ненужно так как код пишется в S-выражения, а паттерн-матчинг довольно неуклюже эмулируется на макросах.

Ну, да Лисп это первый язык в котором били макросы (полноценные) вообще. И именно потому что в нем нет синтаксиса (АСТ по вашему) или точнее код пишется напрямую в аналоге АСТ — этот язык не был воспринят не только индустрией, но и большей частью научного сообщества. Но 90-ых бытовало мнение, что Лисп — это эдакий ДСЛ для проблемной области искуственного интелекта.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Basic — статически типизированный язык.


Первый вроде был дикамикой. Если вообще его можно навзвать полноценным ЯП.

BZ>>препроцессор pl/1 имел синтаксис, аналогичный самому pl/1


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


А можно где-то почитать описание препроцессора pl/1? Чем он манипулировал?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Gaperton, Вы писали:


G>Балшыт. Макросистема не обязана уметь получать информацию о типах.


Ага. Как не обязана манипулировать АСТ, поддерживать квази-цитирование и паттерн-матчинг. Вот толькоо без всего этого она ничего не стоит, так как сделать с ее помощью на практике ничего нельзя. Хотя нет... можно. Можно угробить код, что часто и случалось в С (про pl/1 не скажу, я не так чтобы стар или суперстар, чтобы помнить этот язык).

G> Дело в том, что ее вообще может не быть, этой информации, так же как и типов.


В статически типизированном языке? Ого?

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


Хароший пример . Кстати, о Лиспе. Мне тут показывали как на Лиспе из макросов в рантайме типы вытаскивали и код на ходу генерили и исполняли. 10-и этажный наворот! И все потому, что язык динамический, а типы для решения задачи ой как хочется иметь.

G> без аннотаций типов этой информации получить не может в принципе.


О как? А не ты ли мне про вывод типов в ОКамле рассказывал?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Ну, как минимум Бэйски от МС вроде бы делали проверки при разборе текста.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Будет.


Блин, спор интелекутульнее не придумашь.

AVK> Вот, к примеру, сиквел (возьмем SQL'92 для определенности) — динамически типизированный язык (это не значит что в нем типов нет!). Но совсем небольшой коррекции семантики и соответствующего компилятора хватает, чтобы сделать его статически типизированным. Сам язык при этом практически не меняется.


С каких пор SQL динамически типизированный? В SQL-92 определеятся синтаксис объявления типизированных таблиц, а команды SELECT, UPDATE и т.п. работают уже с типизированными данными. Все известные мне СУБД вводя расширения SQL так же заставляли декларировать типы. Ну, а то что какой-нить там сервер позволяет складывать теплое с мягким (скажем, строки с целыми), так это особенности типобезопасности, точнее ее отсуствия. Динамические привдения типов есть во многих статически типизированных языках. В том числе С++ и C#.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Gaperton, Вы писали:

K>>Вот только все "индустриальные" Бэйсики, которые позиционировались как языки общего назначения были компиляторами.


G>Ага щаз. "Индустриальные" бейсики по началу все были интерпретаторами без исключения. Компиляторы из бейсиков стали делать уже сильно позже — и эти языки бейсиками можно уже с натяжкой было назвать — это уже сильно расширенные диалекты. И то, современные "индустриальные" бейсики днамические, например Visual Basic, не путать со скриптом VBScript и встраиваемым Visual Basic for applications.


Компилируемость действительно не в кассу. Кстати Visual Basic до версии 5.0 был чистым интерпретатором. А VBA и сейчас интерпретатор. Но вот типы в Visual Basic били еще в 1.0. И задавались символами. К 4.0 появился синтаксис "DIM имя as тип". Более того и сейчас если не указывать опции вроде стрикт в васике можно объявлять переменные типа Object (нанее Variant) работа с которыми по сути ведется с помощью интерпретации (компилятор генерирует вызовы универсальных фуцний вроде VARIANT_Add().

Вот только у меня один вопрос. Причем тут макросы? У вас тема уехала, господа, любезные.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Это не "эрудиция", это плохая память, коллега . Все-таки, в 31 год тяжело вспомнить детали угребищного языка, на котором писал много, но в школе. Я с тех пор настолько много чему научился, что мне не стыдно забыть $ перед строковой переменной, а смешно .


+1

G>Однако, что такое динамическая и статическая типизация я помню хорошо. Отличие между ними, мой хорошо эрудированный и плохо знающий матчасть коллега, состоит не в полиморфизме, а в том, в какой момент проверяются типы. До выполнения (статически) или во время выполнения (динамически). Все бейсики, как интерпретируемые языки, кроме некоторых исключений-компиляторов, проверяли типы в динамике... И это соврешенно не важно, что переменная $String не полиморфна. Это уже второй вопрос — ответ на который также прост — нет в бейсике составных данных и сложных структур данных — как в фортране, потому и от полиморфных переменных толку немного.


Вообще-то важно. Иначе дейсвтительно написав интерпретатор С++ или Хаскеля можно заявить, что язык динамический.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Klapaucius, Вы писали:

Орля! Спор выродился. Начался флэйм. Завязывайте вы с Васиком. Он точно до добра не доведет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Хотя к предмету спора это и имеет мало отношения.


К предмету не имеет, но информация полезная... как раз в контексте.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 19:58
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Ага. Но с очень разными последствиями. Более того. Того же добиваются и любые другие системы метапрограммирования. Даже Яки. Да и не только системы МП. Многие выкрутасы Хаскеля по стути меняют семантику языка. Язык волшебным образом начинат мимикрировать под процессор БД или генератор парсеров. Остается вопрос... плохо ли это? Полхо ли, то что задача описывается очевидным для не обрзом, а не на эзоповом языке?


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


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

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

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

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

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


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

К сожалению, на сегодня нет ни одной доделанной системы такого типа. Именно этим и объясняются фобии подобного рода.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 12.08.07 20:09
Оценка:
Здравствуйте, VladD2, Вы писали:

от тебя больше 10 сооющений и все датированы 23:58. помогают навыки профессиональной машинистки?
Люди, я люблю вас! Будьте бдительны!!!
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 12.08.07 20:26
Оценка:
G>>Однако, что такое динамическая и статическая типизация я помню хорошо. Отличие между ними, мой хорошо эрудированный и плохо знающий матчасть коллега, состоит не в полиморфизме, а в том, в какой момент проверяются типы. До выполнения (статически) или во время выполнения (динамически).

это вопрос реализации. были интерпретаторы даже для С, с другой стороны есть lint-подобные системы для динамичсеких языков. правильное же определение — в статических языках тип переменной определяется текстом программы, в динамических — процессом исполнения. кстати ООП — это динамическая типизация, даже когда она привнесена в статические языки
Люди, я люблю вас! Будьте бдительны!!!
Re[31]: Generic programming
От: BulatZiganshin  
Дата: 12.08.07 20:55
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>>Она мне нитересна, конечно. Но это только один вопрос. А их несколько. Вот в начале этого собщения мы говорим о логике постраителя парсера. Это мне тоже очень интересно. Потом интересна отладка. Да и просто поглядеть на то во что выльется грамматика интересно.


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


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


VD>Макросы позволяют решать некоторые задачи (хорошим примером является построитель парсеров):

VD>1. В компайлатайме.
VD>2. С меньшими временными затратами в рантайме.
VD>3. Обеспечивает большую гибкость (мы вольны вибирать алгоритмы и синтаксис не заморачиваясь на базовые фичи языка, ведь мы генерируем код).
VD>4. Раньше выявлять ошибки.

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


разумеется, одно другому не мешает. макросы — более универсальны, generic programming — лишь одно из их применений. речь у нас шла только о том, что некоторые задачи, которые в языках уровня C* можно решить только макросами, в хаскеле могут быть решены на языковом уровне

далее, ты упираешь на эффективность генерации кода во время компиляции. рднако опттимизировать скорость кода следует только в том случае, когда это критично для проекта в целом, в большинстве же случаев следует оптимизировать время ращработчика. и двухуровневая система язык+макросы усложняет его жизнь
Люди, я люблю вас! Будьте бдительны!!!
Re[31]: Generic programming
От: BulatZiganshin  
Дата: 12.08.07 21:27
Оценка:
VD>Здорово. Можно по продрбнее (на пальцах)?
VD>Конкретно:
VD>1. Что такое Arrow?
VD>2. Как генерируется код? Т.е. какие средства МП используются?

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

BZ>>кстати, вот здесь — haskell.org/haskellwiki/Blog_articles/Monads


BZ>>что касается generic programming. SYB, который вы здесь обсуждаете — лишь один из возможных подходов. я их в своё время насчитал десяток, а ведь я в этой области совсем не специалист. из них три поставляются с самим GHC — SYB, Template Haskell, [1]. В [2] даётся краткое описание всех подходов


VD>Ты меня извини, но Template Haskell — это как раз в чистом виде макросы. Почти аналогичные Немерловым. Template Haskell было одним из прототипов Немерла.


да. я хочу сказать, что generic программирование в хаскеле — очень уважаемая тема, и средств для его реализации придумано немеряно — на препроцессорах, type classes, расширения языка, rtti. в общем, поручик Ржевский был бааальшой выдумщик

BZ>>теперь о том, каким образом *библиотека* может в *compile-time* сгенерить код, специализированный для данного конкретного типа

VD>Если мы просто создадим некий обобщенный код и создадим две специализции некой фунции, то это не будет генерацией. Того же самого можно добиться друними формами полиморфизма. Генерация же подразумевает порождение кода на базе условий и проверку этих условий во время компиляции. Заметь — это не тоже самое, что выбор специализации.

фишка в том, что условия, записанные в коде, могут проверяться на этапе компиляции :

if TRUE=FALSE then print "Vlad прав"

поэтому макросы, явно срабатывающие на этапе компиляции, в определённой степени заменимы на код, содержащийся в templates/type classes. имхо, на хаскеле эти границы выше, чем на C* ввиду вывода типов и наличия higher-order funcs, поэтому то, что представляется нереальным для C++ (generic programming с помощью templates), в хаскеле всё же возможно

вот тебе для примера код, печатающий тип значения:

class Type a where
  typeof :: a -> String
instance Type String where
  typeof _ = "String"
instance Type Int where
  typeof _ = "Int"
instance (Type a) => Type [a] where
  typeof x = "["++typeof (head x)++"]"
instance (Type a, Type b) => Type (a,b) where
  typeof (x,y) = "("++typeof x++","++typeof y++")"
main = print$ typeof ("",("",[""]))



кстати, описываемый в [1] подход вообще весьма примечателен — фишка в том, что любой Algebraic Data Type можно построить из базовых примененим всего двух операций — выбора из двух альтернатив и декартова произведения. соответственно, если мы определим процедуру в терминах этих двух операций (и представим реализацию base cases), то её можно будет применить к любому типу! к примеру, сериализация:

{a :+: b} a = putBit 0 >> put a
{a :+: b} b = putBit 1 >> put b
{a :*: b} = put a >> put b



BZ>>впрочем, это только один из возможных подходов. он используется в syb4 Олега Киселёва [3]. syb0 проихзводит поверки в run-time, т.е. он аналогичен использованию RTTI в ООП языках. другие же подходы (GH, [1]) просто используют специаольный язык для описания generic процедур. это можно считать специализированным языком, позволяющим компилятору сгенерить type-speciifc код как в макросистемах или RTTI-based код. отличие от макросистем в том, что во всех случаях пользователь думает в терминах одноуровневого языка, а не двух отдельных систем — прецпроцессинга и собственно выполнения


VD>Вот уже дудки. Или мы генерируем код и думаем в терминах двух программ: метапрограммы и конечной программы (код которой и генерируется). Или у нас "одноуровневый язык". Если под "одноуровневостью" понимается исползование того же языка, то макросы пишутся на точтно таком же языке. Просто там есть пара примитивов позволяющих явно отделить генерирующий код и генерируемый.
Люди, я люблю вас! Будьте бдительны!!!
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: BulatZiganshin  
Дата: 12.08.07 21:40
Оценка:
VD>>А вот извороты вроде Хаскелевских всегда будут сопровождаться коментариями вроде (ну, вот все замечательно только А кривовато, а Б медленновато, а С зависит от компилятора и направления ветра). Реализация разны магических фунций вроде gmap опять же отличное поле для макросов. В итоге мы получим и там, и там фунцию gmap, которую внешне нельзя будет отличить. Но в одном случае ее смогут создать только создатели компилятора, а в друго любой смертный. Думаю не надо объяснять почему путь макросов лучше?

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


с интеллектом в 1000 миллиОлегов как раз syb4.hs, ссылку на который я давал — это реализаций generic программирования в compile time , которую не сможет понять ни один смертный
Люди, я люблю вас! Будьте бдительны!!!
Re[32]: Generic programming
От: BulatZiganshin  
Дата: 12.08.07 21:57
Оценка:
BZ>>>впрочем, это только один из возможных подходов. он используется в syb4 Олега Киселёва [3]. syb0 проихзводит поверки в run-time, т.е. он аналогичен использованию RTTI в ООП языках. другие же подходы (GH, [1]) просто используют специаольный язык для описания generic процедур. это можно считать специализированным языком, позволяющим компилятору сгенерить type-speciifc код как в макросистемах или RTTI-based код. отличие от макросистем в том, что во всех случаях пользователь думает в терминах одноуровневого языка, а не двух отдельных систем — прецпроцессинга и собственно выполнения

VD>>Вот уже дудки. Или мы генерируем код и думаем в терминах двух программ: метапрограммы и конечной программы (код которой и генерируется). Или у нас "одноуровневый язык". Если под "одноуровневостью" понимается исползование того же языка, то макросы пишутся на точтно таком же языке. Просто там есть пара примитивов позволяющих явно отделить генерирующий код и генерируемый.


блин, хотел ответить и на это, но уже запечатал конверт

так вот, описание констант или темплейтов в C++ тоже можно считать средставми макроподстановки и генерации кода. тем не менее это средства, которые сингтегрированы в сам язык, и никто их не отделяет от "обычной" порграммы. точно также и средства generic программирования — интерес состоит как раз в том, чтобы они являлись естественной составной частью языка наравне с остальными средствами, а не отдельным преобразованием, которое застваляет пользователя и разработчика держать в голове два уровня программы и отслеживать ошибки, которые можно понять только на уровне странслированного кода, а ля:

#define e 2.78 // основание натуральных логарифмов

в приведённом мною примере никакой метапрограммы нет. просто код написан так, что значение функции известно уже на этапе компиляции. в generic programming тем или иным путём производится обход структуры данных — никакиъ "метапорграмм"
Люди, я люблю вас! Будьте бдительны!!!
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 12.08.07 22:34
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>от тебя больше 10 сооющений и все датированы 23:58. помогают навыки профессиональной машинистки?


На выбор: либо ты неудачно пошутил, либо я тебя забаню.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 12.08.07 22:53
Оценка:
Здравствуйте, IT, Вы писали:

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


BZ>>от тебя больше 10 сооющений и все датированы 23:58. помогают навыки профессиональной машинистки?


я — само совершенство. можешь банить — как раз рабочая неделя начинается
Люди, я люблю вас! Будьте бдительны!!!
Re[25]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 22:58
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Потому что LINQ прописан в стандарте и его будет обязан знать каждый, претендующий на звание C# developer. И когда я уйду из одной команды и приду в другую, там будет все тот же самый LINQ.


Ага. А в спецификации Nemerle описан list-comprehention выполненый в виде макроса и макрос foreach и что это меняет? Что помешало ввести макросы, реализовать LINQ на них, а потом ввести их в стандарт?

Текущее положение дел ведет к тому, что Шарп является объективно значительно более слабым языком и фич подобных LINQ-у нужно ждать от МС десятилетиями.

Наличие макросов не позволило бы упростить работу самих разработчиков Шарпа и тем самым ускорить появление тех самых LINQ-ов.

IT>>Индустрия банально не имеет макросов, поэтому извращается как может.


AVK>Спорно. Идее ситаксических макросов 200 лет в обед. Однако ж не прижились пока что.


Можно источник? Насколько мне известно превый статически типизированный язык в котором реализованы макросы — это МетаМЛ. И то в нем они работают в рантайме. В общем, такие языки это конец 80-ых в лучшем случае.

К тому же, скажем идее фунционального типа еще болше лет (см. труды Чёрча по лямбдаисчислениям), но C# почему-то получил вместо него убогий делегат и только к версии 3.0 дорос до бледного подобия лябды и фуцкционального типа эмулируемого на обобщенных делегатах Fun<...>.

IT>> Проблемы pre-compile и run-time кодогенерации хорошо известны и, к сожалению, неразрешимы. Я, например, в своё время поимел много гемороя с pre-compile-time генерацей код. Народ по незнаю правил такой код вручную и когда это всплывало через несколько месяцев, то наступал полный паралич.


AVK>Это не проблема технических средств, это проблема организации процесса разработки.


Дык если эту проблему можно решить устранив техническую возможность править генерированный код, то и организационных проблем решать не прийдется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 22:58
Оценка:
Здравствуйте, AndrewVK, Вы писали:

IT>> Не потому ли, что это хоть что-то, что появилось в мейнстриме за последние 20 лет. А все те идеи о которых ты говоришь были всего лишь идеями и никогда к мейнстриму даже близко не относились?


AVK>Т.е. всемирный антимакросовый заговор? И Гейтс, поди, не последнюю роль в нем играет?

AVK>Должны же быть какие то причины отсуствия макросов в мейнстриме.

Вообще забвно. ИТ тебе говорит о том, что в С++ кривейший аналог макросов во всю исползуется программистами-практиками, а ты говришь, что отсуствуют.

Они присуствуют, но в сильно извращенной форме. И далеко не в самых удобных языках.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 22:58
Оценка:
Здравствуйте, mkizub, Вы писали:

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

M>VM имеет непосредственное отношение к языковым средствам, так как для того и была создана — как промежуточный уровень абстракции между языком и железом.

Обясняю про ВМ... Есть работы преполагающие преобразование/модификацию/инструментирование и т.п. для байткода/MSIL-а. Например Феникс (похоже загнулся, правда). Работать на уровне МСИЛ-а выгодно с некоторой точки зрения и для некоторых задач. Но это делать тяжело. Уровень очень низкий, а убийственной технологии вроде квази-цитирования пока что на горизонте нет. Грубо говоря не придуманы решения как преобразовывать мсил просто.

Меж тем в мсил-е много информации уже потеряно, да и программист не особо может влиять на него. Он же пишет код на прикладном языке (например, на Васике).

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

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

M>IDE и VM были упомянуты не для перевода стрелок и отвлечения внимания. Они имеют непосредственное отношение к макросам, о чём я и написал достаточно подробно. Если вы этого не видите и не хотите видеть — так бы и сказали, мол обсуждать не хочу.


Как уже сказал IT в том же немерле принципиальных проблем с макросами нет. Интеграция с IDE использует основной компилятор (который реально реализован в виде DLL-и) запускаемый в специальном Intellisese-режиме. Объем специализированного кода крайне мал, так что подавляющее большинство изменений в компиляторе без единого вмешательства становятся сразу же доступны и в интеграции. Причем, прошу заметить, это положение дел сложилось при том, что при разработке компилятора и даже саомго языка автры вообще не думали о совместимости с IDE. Если же разрабатывать язык и (в особенности) компилятор с расчетом на работу в IDE, то можно избежать и те мелкие проблемы, что вылезли у нас.

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


M>Конечно это невозможно. Или мы о разных IDE.


Что "нонечно невозможно"? Ты внимательно прочел что тебе написали? Это работает. Это не просто теоретически возможно. Это работает на практике. Все новые макросы я разрабатываю под управлением VS 2005. И тестирую в ней же.

M>Скажем, у нас есть "расшитрение" для enum типов, и их использования в выражениях и switch/case. Для case value мы бы хотели в IDE иметь автодополнение, которое предлагало бы список перечислымых значений из декларации enum.


Расширения не безграничны. У них есть рамки. В этих рамках они подхватываются IDE. Есть понятие макроса. У макроса есть синтаксис. Синтаксис включает ключевые слова. Комплит считывает эти слова и рпедоставляет программисту-пользователю. Далее кода макрос написан код метода в котором использован макрос или типа скармливается компилятору который произвоидит его проверку и динамически подсвечивает строки с ошибками. Ну, и так далее. При это основной язык нельзя заменить на 100%. Его можно толко расширить.

M>Так вот, никаким образом этот тип автодополнения не появится автоматически из правил преобразования enum->class на уровне AST.


Ненадо фантазировать. Скачай последнюю версию интеграции и попробуй.

M>IDE уровня Eclipse или IntelliJ Idea понимает код, работает с ним на уровне семантики.


Ошибашся. Они работают даже на более низком уровне. Они работают на уровен типизированного АСТ. Именно на этом уровне с кодом работаем и мы. Просто язык расширяемый. Расширения загружаются и становятся доступны компилятору. Мы кормим компилятор расширеным кодам и читаем полученое АСТ. Далее остаетя только сопоставлять положение курсора и положения веток АСТ отфильтровывая нужные ветки.

M> Поэтому и является настолько удобным инструментом. А вы под IDE подразумеваете редактор+обработчик сообщений компилятора?


Иди скачай интеграцию: http://rsdn.ru/forum/group/prj.nemerle.aspx
И почитай статьи о языке: http://rsdn.ru/forum/group/prj.nemerle.aspx

А то право разговор бесполежный. На твоем уровне представлений тебе вряд ли получится что-то объяснить. Вот когда ты будешь иметь представление о языке и том, что сделано в интеграции можно будет и попробовать рассказать как все это работает.

M>Так я же написал — VM это рантайм плюс компилятор.


Что за компилятор? Джит?

M>Собственно говоря, после того как исходный код разобран (parsed & resolved), проверен на отсутствие ошибок — дальнейшая работа компилятора полностью автоматизирована (и представляет собой трансформацию дерева/графа), и может быть спокойно перемещена из source-to-bytecode компилятора в bytecode-to-native компилятор.


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

Интересно? Начинай читать статьи оп языку с самого начала и пробовать на нем что-то делать. Нет, тогда просто забуть. Это слишком сложно чтобы объяснять это на пальцах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 22:58
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Между языком и VM тоже нет принципиальной разницы. Можешь рассматривать байткод как некий язык программирования со специфическим синтаксисом.


Подумай какую глупость ты только что сказал?
VM — это абстракное понятие. Язык есть язык. МСИЛ, скажем или байткод Явы — это конечно язык. Только это низкоуровневый язык — ассемблер для конкретной VM.

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

M>Этот процесс ничем не отличается от компиляции исходников OCaml в C. Они могут компилировать свои исходники в байткод для своей VM, а могут в исходный код на С.


Мгут. И менять С-код так же тяжело как менять мсил. В ОКамле есть паттерн-матчинг и алгеброические типы. В С это будет преобразовано в море низкоуровневого кода и структур. Понять что за код был в оригинале будет уже очень не просто. Это уже будет нехилый реверс-инжиниринг. А это само по себе задача не простая.

M>Когда я говорю о расширении VM, то имеется в виду что-то вроде расширяемого байткода.


Остется понять зачем это надо и что это даст?

M> Так же, как в Nemerle вы можете определять новые операторы, так и для такой расширяемой VM можно определять новые инструкции.


Но это не разумно! VM понимает один низкоуровневый и от того примитивный ЯП. VM это море кода единственная задача которого преобразовать этот универсальный ассемблер в реальный машинный код конкретной машины. Это абстракция от железа. Расширять инструкции мсила просто бессмысленно. Вель прийдется писать скажем их реобразователи в машинные кода разных процессоров. Плюс встает вопрос а на основании чего генерировать эти расширенные инструкции? Ведь компиляторы знают только тот их набор что стандартизован. В прочем при расширении мсила о стандартах можно будет сразу забыть.

В общем, это бредовешая идея.

Ну, а как было сказано преобразователи мсила есть. Тот же проект Феникс.


M> Самый простой пример — определение SIMD операций, ты их можешь определить в Nemerle для работы с 3D вычислениями.


Какие SIMD-инструкции? Это же VM? Ее код может быть скопилирован как на древних 486-ых, так и на экзотических процессорах у которых вообще может многого не быть.

Задача вырабатывания SIMD-инструкций — это задача опримизирующего JIT/PreJIT-компилятора. Вот в проекте Феникс предполагалось что можно будет делать плагины производящие те или иные оптимизации для конкретных процессоров.

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

M> Если это расширение компилятора — то эти операции должны будут скомпилироваться либо в вызовы библиотечных методов, либо развернуться в последовательность скалярных операций. Если это расширение VM, то эти операции будут скомпилированы либо в вызовы библиотечных методов, либо развёрнуты в последовательность скалярных операций, либо могут использоваться непосредственно аппаратные SIMD инструкции CPU.


Вот это и есть работа JIT-а. Пусть он думает как и что там делать. И не на базе каких-то там самопальных инструкций. А на базе самых что ни на есть универсальных. Более того низкоуровенвый код проще вообще запихнуть в нэйтив-библиотеки. Скажем библиотеку векторной или 3D-графики. Это дешевле и проще.


IT>>Что такое "расширение" для enum типов? Это новый тип типов или новый enum?


M>Новый тип типов. Мне его удобно для примера пользовать, так как в Java изначально небыло enum-ов, и они реализуются сравнительно просто в виде "расширения", как трансформация AST (кодогенерация).


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

M>Теперь внимание — вопрос.

M>Каким образом из правил кодогенерации (трансформации AST) IDE сможет понять, что red, green, blue — это константы, что автодополнение кода в case value должно выдавать список из red,green,blue, каким образом IDE узнает, что существуют только 3 варианта значения Color и что switch может иметь максимум эти 3 case-а и так далее. Эти правила (что есть enum как понятие) — присутствуют в мозгах программиста. Трансформация AST — это применение этих правил, а не определение этих правил.

Описанное решение повторить на 100% на Немерле просто неудастся. Если говорить гипотетически, то в принципе можно обеспечивать обработку всех методов и трансформировать код как нравится. В том числе и подменять его.

В общем, макросы не предназначены для введения в язык новых классов типов данных. Они могут создават экзепляры типов, менять код, генерировать новый код. В отличии от Явы в Немерел и так много встроеных типов. Скажем его Variant-ы намного мощьнее перечислений Явы. И писать для них подержку свитчей не надо. В прочем в Немерле нет и свитчей. Вместо этого есть мощьнейший оператор match который заменяет все остальные операторы ветвления (if-ы есть, но они реализованы в виде макросов).

Так что читай описание языка и все поймешь сам.

M>Idea и Eclipse построены именно на понимании явовского кода, а не его формальном AST представлении.


Нет. Idea, Eclipse, VS и любая другая интеллектуальная IDE оперирует именно АСТ. Снабженным информацией о типах, но все же АСТ. А код это всего лишь текст. АСТ же и есть его программное представление.

M> Кроме самого AST туда ещё много чего напихано. Именно поэтом миграция на Java 1.5 (в которой эти enum-ы появились, а так-же generics, autoboxing и прочее) заняла пару лет для IDE, уже после того, как компилятор был выпущен.


Пара лет ушла на то, чтобы попросту добавить поддержку этих фич в их копию компилятора. В Немреле (и об этом тебе сказали уже 20 раз) для целей поддержки интелисенса используется сам компилятор. Так что все что в него добавляется (или в нем исправляется) сразу же (после перекомпиляции компилятора и модулей интеграции) становится доступным как в компиляторе, так и в IDE.

IT>>Пофантазировать можно конечно. MS research работает над проектом Феникс, возможно это из этой серии.


M>Приблизительно то-же говорят те, кто считает ненужным расширяемые компиляторы. Типа, "пофантазировать можно кончено". Вы их спрашиваете — как же они не видят полезности расширяемых компиляторов, а я так-же удивлён, почему ваша фантазия заканчивается на компиляторе.


Да, как раз, нет. Они говорят о своих страхах. А зачем это нужно им понятно без объяснений. Вот АВК, например, сам использует пепроцессор созданный на базе XSLT для генерации классов по модели описываемой на XML-е. А Гапертон сам рекламировал препроцессор для ОКамла.

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

M>Как я написал выше, результирующее AST нам даёт очень мало, для понимания сути написанного. А если IDE не понимает сути написанного, то она превращается просто в редактор.


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

Не хочешь верить слвам? Не дано. Не хочешь качать работающий продукт? Опять же не проблема. Только тогда не стоит задавать вопросы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 12.08.07 23:17
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>я — само совершенство. можешь банить — как раз рабочая неделя начинается


Не поможет. Бан на чтение надо постараться чтобы заслужить
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 23:22
Оценка:
Здравствуйте, cl-user, Вы писали:

M>>Заменить текст деревом.


CU>Деревом-деревом!.. В виде списка... в текстовом файле


Уточню. Не прсто списка, а в виде S-выражения .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[51]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 23:22
Оценка:
Здравствуйте, mkizub, Вы писали:

CU>>"Имя, сестра, имя!"


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


Наверно мне тоже не интересно. Так как я так и не смог его разглядеть. Идея отказаться от текстового представления мне разумной не кажется. Других идея (которых я бы не видел ранее) я так и не увидел.

Может ты в своей статье не о концепции расскажешь, а о том, как на твоем прототипе хотя бы гипотетически программку написать?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[54]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.08.07 23:22
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>P.P.S. Можете банить — не считаю необходимым вести спор "в техническом русле" с оппонентами, шарахающимися тех. информации как чёрт ладана.


Да, на саомо деле, и не за что банить...

Жестко сказанная, но правда. Подпишусь под любым словом. Меня смаого раздражает когда на конкретную просьбу описать как оно и что получаешь расказы о прыжках в пропость в два прыжка и т.п.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 12.08.07 23:39
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>текстовым представлением программы. помесь макросов С со средствами управления самого pl/1. вот пример, генерящий 10 строк кода:


BZ>%do i=1 to 10 do

BZ>a(i)=0
BZ>%end

Куль. Однозачно, моя слеза будетв в два раза больше, когда я принесу букетик на могилу PL/1.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 12.08.07 23:50
Оценка:
Здравствуйте, IT, Вы писали:

BZ>>текстовым представлением программы. помесь макросов С со средствами управления самого pl/1. вот пример, генерящий 10 строк кода:

BZ>>%do i=1 to 10 do
BZ>>a(i)=0
BZ>>%end
IT>Куль. Однозачно, моя слеза будетв в два раза больше, когда я принесу букетик на могилу PL/1.
Причем, оно, AFAIR, еще и использовал для макросов арифметику неограниченой точности
Sapienti sat!
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.08.07 00:41
Оценка:
Здравствуйте, IT, Вы писали:

IT>Это не флейм. Это принципиальный вопрос. Одно дело, если ты с ними поигрался да и бросил. Другое — если ты использовал Open C++ в серьёзном проекте и твои утверждения о вреде макросов основываются не на домыслах, а на реальном опыте их применения.


Кстати, я как раз Open C++ пытался использоать. Он с макросами имеет столько же общего как R#. Это не макрос-система. Это система глобальной замены по коду. Причем без малешего разумного зерна. Никаких средств дкомпозиции нет в помине. Средства композиции примитивны. Информация о типах недоступна. Парсер неполноценный.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.08.07 00:41
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Понятно. Да, если это встроено — это здорово.


J>В принципе, это можно сделать и в нормальной среде/отладчике, которая/ый допускает вменяемое программирование себя (т.е. скидывать сгенеренный текст во временный файл, автоматом проставить там все брейкпоинты и заинклудить его куда надо). В принципе, это же я делаю вручную, когда отлаживаю макросы — просто ставлю в нужном месте #include "generated.h", где generated.h — это результат работы препроцессора, и в нем уже расставляю брейкпоинты. Правда, я сомневаюсь, что в студии можно такую автоматику навернуть.


Не сомневайся. Можно. Но это требует некоторого объема работ, а значит усилий и времени.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.08.07 00:41
Оценка:
Здравствуйте, Kisloid, Вы писали:

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


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


Дык при этом ты будешь постоянно пользоваться ими. Просто не будешь понимать этого. Тот же if или while — это макросы. Писать без них несомненно можно. Но, как верно заметил Klapaucius, зачем?!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.08.07 00:41
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Я правильно понимаю, что для того, чтобы понять что делает макрос нужно довольно подробно представлять как устроено AST,

EC>какие есть фазы компиляции, как AST может трансформироваться на каждой из них?

Да несомненно. Это один из спосбов узнать что делает макрос. Хорошим примером тут является макрос foreach. Вот его код:
  /**
   * The 'foreach' macro introduces a construction equivalent
   * to C#'s 'foreach' keyword, iterating over a collection.
   */
  macro @foreach (inexpr, body)
  syntax ("foreach", "(", inexpr, ")", body)
  {
    match (ListComprehensionHelper.ExpandRange (inexpr, body)) {
      | Some (expr) => Nemerle.Imperative.Return (expr)
      | None => {}
    }

    def (iter, collection) =
      match (inexpr) {
        | <[ $i in $c ]> => (i, c)
        | e =>
          Message.FatalError ($ "the syntax is 'foreach (x in collection)', "
                                "got $e");
      }
      
    def typer = Macros.ImplicitCTX ();
    def tcollection = typer.TypeExpr (collection);

    // build the body of loop (may contain additional matching)
    def build_definition (val) {
      match (body) {
        | <[ match ($(null)) { ..$cases } ]> =>
          match (iter) {
            | <[ $(x : name) ]> when char.IsLower (x.Id[0]) | <[ (..$_) ]> => ()
            | _ => Message.FatalError ("only simple names available in pattern"
                                       " of foreach with direct matching")
          }

          <[ def $iter = $val; 
             match ($iter) { ..$cases } 
          ]>

        | _ =>
          def mat =
            match (iter) {
              | <[ $pat :> $ty ]> =>
                <[ match ($val :> $ty) { | $pat => $body; () | _ => () } ]>
              | _ =>
                <[ match ($val) { | $iter => $body; () | _ => () } ]>  
            }
          mat.cases.Iter (fun (x : PT.MatchCase) { x.disable_warnings = true });
          mat
      }
    }

    // here we choose if we want to use enumerator pattern
    // of access GetEnumerator through IEnumarable
    // http://www.jaggersoft.com/csharp_standard/15.8.4.htm
    def decide_enumerator_pattern (tyinfo) {
      def all = tyinfo.LookupMember ("GetEnumerator");
      
      def choosen = List.Exists (all, fun (mem : IMember) {
        | meth is IMethod when !meth.IsStatic && meth.GetParameters ().IsEmpty =>
          match (meth.ReturnType.Fix ()) {
            // FIXME: do additional conservative checks              
            | MType.Class (tc, _) when
              !tc.LookupMember ("MoveNext").IsEmpty &&
              !tc.LookupMember ("Current").IsEmpty => true
              
            | _ => false
          }
        | _ => false
      });
      if (choosen)
        <[ $(tcollection : typed).GetEnumerator () ]>
      else
        <[ ($(tcollection : typed) : System.Collections.IEnumerable).GetEnumerator () ]>
    }

    typer.DelayMacro (fun (fail_loudly) {
      match (tcollection.Type.Hint) {
        | Some (MType.Class (tc, args)) =>
          if (tc.InternalType.Nemerle_list_tc != null 
              && tc.SuperType (tc.InternalType.Nemerle_list_tc).IsSome)
          {
            def arg = List.Head (args);
            def definition = build_definition (<[ x ]>);
            Some (<[
              // we explicitly set parameter type to list, because collection's type
              // can be more specific (list.Cons, etc.)
              ($("_N_break" : global) : {
                def foreach_loop (_ : list [$(arg : typed)]) {
                  | x :: xs =>
                    $("_N_continue" : global) : {
                      $definition;
                    }
                    foreach_loop (xs)
                  | _ => ()
                }
                foreach_loop ($(tcollection : typed))
              })
            ]>)
          }
          else {
            def init_body = decide_enumerator_pattern (tc);

            def is_disposable = 
              typer.JustTry (fun () {
                def expr = typer.TypeExpr (init_body);
                expr.Type.Require (<[ ttype: System.IDisposable ]>)
              });

            def finally_body = 
              if (is_disposable)
                <[ (enumerator : System.IDisposable).Dispose () ]>
              else
                <[
                  match (enumerator) {
                    | x is System.IDisposable => x.Dispose ();
                    | _ => ()
                  }
                ]>;

            def definition = build_definition (<[ enumerator.Current ]>);

            Some (<[ 
              def enumerator = $init_body;
              $("_N_break" : global) : {
                def loop () {
                  when (enumerator.MoveNext ()) {
                    $("_N_continue" : global) : {
                      $definition;
                    }
                    loop ();
                  }
                }
                try { loop () } 
                finally { $finally_body }
              }
            ]>)
          }

        | Some (MType.Array (_ , rank)) =>
          def indices  = array (rank);
          def lengths = array (rank);
          for (mutable i = 0; i < rank; ++i) {
            indices [i] = Macros.NewSymbol ();
            lengths [i] = Macros.NewSymbol ();
          }
          def indices_list = List.RevMap (List.FromArray (indices), fun (x) {
              <[ $(x : name) ]> 
          });
          def build_loops (depth)  {
            /// build expression defining iteration symbols
            | 0 => build_definition ( <[ cached_collection [..$indices_list] ]> )
            | n => 
              def idx = indices [n - 1];
              <[ for (mutable $(idx : name) = 0; 
                      $(idx : name) < $(lengths [n - 1] : name);
                      ++ $(idx : name) ) 
                   $(build_loops (n - 1)) 
              ]>
          }
          mutable sequence = [ <[ $(build_loops (rank)) ]> ];
          if (rank == 1) 
            sequence = <[ def $(lengths [0] : name) = cached_collection.Length ]> :: sequence;
          else
            for (mutable i = rank - 1; i >= 0; --i)
              sequence = <[ def $(lengths [(rank - 1) - i] : name) = cached_collection.GetLength ($(i : int)) ]>
                         :: sequence;

          sequence = <[ def cached_collection = $(tcollection : typed) ]> :: sequence;
          Some (<[ { .. $sequence } ]>)

        | t =>
          when (fail_loudly) {
            def guess =
              match (t) {
                | Some (t) => $ "current best guess about the type is $t"
                | None => "the compiler has no idea what the type might be"
              }
            Message.Error ($ "collection in foreach must be an array or "
                             "type implementing enumerator pattern, $guess");
            Message.Hint ("try specifing the type directly using 'expr : SomeType'");
          }
          None ()
      }
    })
  }


Мне кажется этот код очевиден. Но есть и другой, более сложный, на мой взгляд, способ познания того что же делает макрос — это прочтение документации или коментариев. Например,
foreach можно описать как аналог foreach из C# 2.0 который кроме всего прочего позволет фильтровать данные с помощь паттерн-матчинга.

EC>Т.е. при применении макроса с моим кодом может произойти практически любая трансформация?


Ага.

EC>Потому как я применяя yield return точно знаю, что сделает компилятор и как это всё локализовано.


На саомо деле ты не знашь что делает код отвечающий за реализацию yield return. Это гора С++-кода которую ты скорее всего даже не сможешь понять если увидишь. Но тебе спокойно так как индус писавший ее работает в МС.

В прочем, когда люди пишут на С++ или на Шарпе с применением небезопасного кода или интеропа, то с их кодом может произойти вообще все что угодно, так как от проходов по памяти их мало что защищает. Но это не останавливает почти никого.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.08.07 00:41
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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


И првда. Ведь запустить при развертывании генератор кода и потом компилятор C# — это в порядке вещей. А запустить скажем компилятор Немерле или интерпретатор Лиспа — это фу бяка ату эту идею.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.08.07 00:41
Оценка:
Здравствуйте, mkizub, Вы писали:

M>это императивщина, поскольку последовательность операций.

M>Процедурный подход безусловно мощнее, поскольку декларативный ограничен набором известных ему операций.

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

M> Но он же и более тяжёлый в написании и понимании.


Вот это правада. Особенно тежело думать в терминах лэйблов и готу.

M> Что-то более сложное на нём практически невозможно изобразить. Мне кажется, компилятор должен иметь оба этих интерфейса к преобразованию AST, точнее — декларативный можно изобразить как некий плагин к компилятору (если понимать под плагином некий пользовательский код, который делает трансформацию AST), тогда в компилятор можно вставить несколько разных систем описания трансформации (используя квотинг, или как это описывается в AOP, или это будет некий embedded DSL вроде logic engine в SymADE и так далее).



Знаешь... Немерловцы прежде чем сесть писать свой язык с макросами изучили имеющиеся образцы, написали научную работу по этому поводу, опубликовали ее и обсудили с общественностью. Потом долго (несколько лет) выслушивали пожелания и замечания от онлайн-комьюнити. А ты не изучив даже лежащих на поверхности примеров занялся, по твоим же словам, будущим программирования. Тебе не кажется это несерьезным?

Да... Что до обхода АСТ и т.п., то лучше бы ты взял язык с паттерн-матчингом и алгеброическими типами. Тода и тонн кода генерировать не пришлось бы. Так что это скорее пример в пользу автора темы.

M>Блин, это RSDN, который не меняет URL при клике на другой пост

M>http://rsdn.ru/forum/message/2610368.1.aspx
Автор: mkizub
Дата: 05.08.07
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 13.08.07 03:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Мне кажется этот код очевиден.

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

Я бы ещё заменил "collection in foreach must be an array or type implementing enumerator pattern" на
"collection in foreach must be an array or type implementing IEnumerable/IEnumerable<>"
потому как enumerator pattern как-то мутно звучит.

VD>На саомо деле ты не знашь что делает код отвечающий за реализацию yield return. Это гора С++-кода которую ты скорее всего даже не сможешь понять если увидишь. Но тебе спокойно так как индус писавший ее работает в МС.

Это тупо код на C# (хотя во что декомпилируешь), причём довольно примитивный в простых случаях.
Единственная сложность в понимании это кривые генерённые имена.

VD>В прочем, когда люди пишут на С++ или на Шарпе с применением небезопасного кода или интеропа, то с их кодом может произойти вообще все что угодно, так как от проходов по памяти их мало что защищает. Но это не останавливает почти никого.

Работа с памятью это проблема из совершенно другой плоскости.
now playing: Marc Antona — Fast Cats No Fat
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: Andrei F.  
Дата: 13.08.07 04:59
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Маловато будет, тут по большей части просто процессоры IL, Феникс вообще пока умер. Есть еще RAILS — но они тоже как-то присмерти.


Почему умер? Последний RDK вроде за март этого года.
А что за RAILS?
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: Andrei F.  
Дата: 13.08.07 05:13
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что же касается текста, то очень многие продукты использовавшие ранее бинарные форматы (МС Офис, Опен Офис) стримительно движутся к текстовым форматам (на базе стандартного ХМЛ-я). Правда есть над чем задуматься?


Действительно, есть над чем задуматься. Если API для доступа к хранилищу данных нормально проработано, то для разработчика нет вообще никакой разницы, что конкретно используется как конечное хранилище — текст или бинарная форма. Ну за исключением такой мелочи как производительность, конечно

Так что если они решили отказаться от STG и переходить на текстовый формат, то тут есть несколько возможных причин:
1. Следование моде
2. Разработчики команды STG положили большой болт на просьбы команд, которые пользуются их творением, и теперь тем приходится как-то выкручиваться
3. Нужно как-то использовать все эти огроменные мегагерцы и гигабайты, которые нагло выдают разработчики железа

А вообще самый правильный подход используют разработчики PNG (если не ошибаюсь). Там все данные хранятся в бинарной форме (естественно), но при желании поковыряться внутри можно сделать экспорт в текстовую форму.
Re[35]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 13.08.07 07:11
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Хароший пример . Кстати, о Лиспе. Мне тут показывали как на Лиспе из макросов в рантайме типы вытаскивали и код на ходу генерили и исполняли. 10-и этажный наворот! И все потому, что язык динамический, а типы для решения задачи ой как хочется иметь.


G>> без аннотаций типов этой информации получить не может в принципе.


VD>О как? А не ты ли мне про вывод типов в ОКамле рассказывал?


"О птичках"...

Я уже упоминал здесь Qi — предлагаю тем, кому это действительно может быть интересно. Это библиотека для CL, которая добавляет к "динамическому языку" и частичный вывод типов, и строгую типизацию, и паттерн-матчинг и многое другое. Естественно, что это уже получается не совсем "лисп", но! — одновременная работа и с чистым CL и с Qi возможна. Учитывая возможность в лиспе "горячей подмены" ридера — это не удивительно. Естественно, макросы там используются "в полный рост".

Конечно-же не "без минусов": учитывая врождённую динамику лиспа это всё даётся некоторой потерей производительности (но, хочу заметить, не большой, а учитывая хорошее качество двоичного кода, который генерит тот-же sbcl, на потери и вовсе можно не обращать внимания).
Re[36]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 13.08.07 07:26
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Влад, для многих здесь присутствующих это не "плюс", а "тяжкий смертный грех"

P.S. Само собой — я не о себе
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.08.07 07:39
Оценка:
Здравствуйте, EvilChild, Вы писали:
EC>Я бы ещё заменил "collection in foreach must be an array or type implementing enumerator pattern" на
EC>"collection in foreach must be an array or type implementing IEnumerable/IEnumerable<>"
EC>потому как enumerator pattern как-то мутно звучит.
Ну, в дотнетном мире Enumerator Pattern — это имя собственное. Я бы это подчеркнул в комментах капитализацией. А вот заменять всякий раз определяемое на определение, тем более в комментариях к исходникам — увольте. В очередной раз процитирую:

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: Kisloid Мухосранск  
Дата: 13.08.07 09:02
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Дык при этом ты будешь постоянно пользоваться ими. Просто не будешь понимать этого. Тот же if или while — это макросы. Писать без них несомненно можно. Но, как верно заметил Klapaucius, зачем?!


Да, я просто не совсем правильно выразился, конечно я имел ввиду под "пользоваться" написание макросов.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 13.08.07 09:36
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>в статических языках тип переменной определяется текстом программы, в динамических — процессом исполнения. кстати ООП — это динамическая типизация, даже когда она привнесена в статические языки


Нет, ООП не противоречит статической типизации. Тип — это набор констрайнтов, определяющих что можно сделать с объектом. Тип в Java ничем не хуже типа в C, это всё тот-же набор операций над объектом.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.08.07 11:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И првда. Ведь запустить при развертывании генератор кода и потом компилятор C# — это в порядке вещей. А запустить скажем компилятор Немерле или интерпретатор Лиспа — это фу бяка ату эту идею.


Да запустить то не проблема. Проблема в том, что бизнес-сущности на момент деплоймента уже скомпилированы. И чем при таком раскладе помогут макросы мне пока неясно. Упростят код генерируемых проксей? Так они и так примитивны как 3 копейки. Что то еще?
... << RSDN@Home 1.2.0 alpha rev. 710 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.08.07 11:22
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Я бы ещё заменил "collection in foreach must be an array or type implementing enumerator pattern" на

EC>"collection in foreach must be an array or type implementing IEnumerable/IEnumerable<>"

enumerator pattern это несколько большее, нежели просто реализация IEnumerable/IEnumerable<T>
... << RSDN@Home 1.2.0 alpha rev. 710 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.08.07 11:22
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Однако ж даже в извращенной форме они присутствуют куда в большем объеме, нежели их идеальная реализация в Nemerle.
... << RSDN@Home 1.2.0 alpha rev. 710 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: Andir Россия
Дата: 13.08.07 13:07
Оценка:
Здравствуйте, IT, Вы писали:

BZ>>от тебя больше 10 сооющений и все датированы 23:58. помогают навыки профессиональной машинистки?


Булат похоже просто не в курсе, что Янус сообщения скопом отправляет, а не по мере написания

С Уважением, Andir!
using( RSDN@Home 1.2.0 alpha rev. 703 ) { /* Работаем */ }
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 13.08.07 17:20
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>enumerator pattern это несколько большее, нежели просто реализация IEnumerable/IEnumerable<T>

Насколько мне известно для foreach необходима и достаточна реализация одного из этих интерфейсов.
Или что-то ещё в этот паттерн включается?
now playing: Deep-Dive-Corp — Walker (Ohm-G Rmx)
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>С таких. Во-первых CASE может возвращать разнотипные значения в зависимости от условия,


Что-то такого не встречал. Можно ссылочку на описание где об этом говорится? Может быть там все же приведение типво?

AVK> во-вторых типы параметров указываются только в момент выполнения запросов.


Какие еще параметры?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Действительно, есть над чем задуматься. Если API для доступа к хранилищу данных нормально проработано, то для разработчика нет вообще никакой разницы, что конкретно используется как конечное хранилище — текст или бинарная форма. Ну за исключением такой мелочи как производительность, конечно


Разница есть для пользователей. Да и стандартного АПИ мало. Нужн чтобы сами форматы были описаны. Описать их в ХМЛ проще простого. Описать бинарник = прибить его формат гвоздями к полу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>И првда. Ведь запустить при развертывании генератор кода и потом компилятор C# — это в порядке вещей. А запустить скажем компилятор Немерле или интерпретатор Лиспа — это фу бяка ату эту идею.


AVK>Да запустить то не проблема. Проблема в том, что бизнес-сущности на момент деплоймента уже скомпилированы. И чем при таком раскладе помогут макросы мне пока неясно. Упростят код генерируемых проксей?


Дык макросам фиолетово скомпилированы ли типы которые эти макросы анализируют или просто находятся в виде исходников. Для них это прозрачно.

AVK>Так они и так примитивны как 3 копейки. Что то еще?


Понимаю. Видимо примитивные системы очень тяжелы в разработке, раз вы их так долго пишите...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Он у меня давно есть, и работает на славу.

M>Но я не об этом. Я случайно увидел твой ответ, обычно я сообщения от тебя просто пропускаю — ты в игноре.
M>Спасибо за понимание.

А. Ясно. Тогда когда будешь случайно смореть это сообщение, то не расстраивайся от того факта, что твоя реализация в подметки немерловой не годится.

И вообще, не расстраивайся. А то ты похоже воспринимаешь любую критику твоих идей как личные оскорбления.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


VD>>Мне кажется этот код очевиден.

EC>Он более менее понятен, даже учитывая, что я не знаю Nemerle, но никак не очевиден.
EC>Видимо у меня парадигматический сдвиг ещё не произошёл

Вообще-то это была ирония, если кто не заметил...

VD>>На саомо деле ты не знашь что делает код отвечающий за реализацию yield return. Это гора С++-кода которую ты скорее всего даже не сможешь понять если увидишь. Но тебе спокойно так как индус писавший ее работает в МС.

EC>Это тупо код на C# (хотя во что декомпилируешь),

Я вообще-то вел речь о коде компилятора который пораждает код этого паттерна.

VD>>В прочем, когда люди пишут на С++ или на Шарпе с применением небезопасного кода или интеропа, то с их кодом может произойти вообще все что угодно, так как от проходов по памяти их мало что защищает. Но это не останавливает почти никого.

EC>Работа с памятью это проблема из совершенно другой плоскости.

То есть в макросах страшно само слово "макрос", а не какие-то там проблемы которые вызываются макросами?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>Мне кажется этот код очевиден.


ANS>"Очевидный" это когда пара строчек. А когда три экрана текста, которые нельзя охватить взглядом, то слово "очевидный" уже не в кассу.


Нда, часть мозга отвечающая за юмор (и соотвествнно за восприятие иронии) у многих программистов атрафировалсь на прочь.

Попробуй прочесть текст за кодом... Если не поможет, то попробуй почитать "12 стульев". Особенно часть про встречу с любителями шахмат.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Большинство Java-программистов стараются использовать такие библиотеки как можно меньше, так как ошибки в них находить и исправлять на порядок сложнее, чем в обычном коде.


Ошибки — это конечно. Рантайм есть рантайм. Но вот используют их часто, так как слишком большие бенефиты. Кибернэйты, струтсы, спринги и т.п. — это все проявление "магии".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Вот только это все достаточно просто отлаживается многочисленными существующими инструментами. А вот для макросов у нас отладчиков пока нормальных нет.


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

В любом, случае пробема отладки решаема.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, mkizub, Вы писали:

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


В декларативных конструкциях и отлаживать нечего. Квази-циртирование — это способ сформироать АСТ. Слово "квази" говорит о том, что кроме цитат могут содержаться и перменные. Сложный код формируется путем последовательного преобразования цитат. Делать это можно как в функциональном стиле, так и в императивном (АСТ — это по сути просто список).

M>Я пробовал писать плагины к Эклипсе, и мне их отладка понравилась.


Вот так же отлаживаются и макросы Немерле.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Угу. Во время компиляции.


Ага.

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


А в чем проблема? Я вот во всю отлаживаю.

Проблемы конечно есть, но не с отладкой макросов. Проблема в отладке сгенерированного кода. Пока что текстовое представление для него сгенерить можно далеко (очень далеко) не всегда. Без этого проблемы могут возникнуть не толко с отладкой сгенерированного кода, но даже с его компиляцией. Компилятор будет орать непонятные вещи указывая на вызов макроса, а что за ошибка понять нельзя. Но это тоже дело времени. Сделаем грамотную генерацию текста для генерируемого макросами кода и все будет ОК.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Generic programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>так вот, описание констант или темплейтов в C++ тоже можно считать средставми макроподстановки и генерации кода. тем не менее это средства, которые сингтегрированы в сам язык, и никто их не отделяет от "обычной" порграммы.


Шаблоны С++ не позволяют программировать генерацию. Они просто позволяют подставить праметры. Разумется, что это справедливо, если мы не ведем речь о метапрограммировании на шаблонах в стиле Александреску (с испоьзованием побочных эффектов при частичной специализации и рекурсивных шаблонах).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Generic programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.07 22:08
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>далее, ты упираешь на эффективность генерации кода во время компиляции.

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

Это все лирика. Для решения конкретных задач она непригодна. Я не из тех кто будет заниматься глупыми предварительными оптимизациями. Поверь, задача того трбовала.

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


Это прописные истины. Я с ними не спорю. Вот только они не отменяют того факта, что на Хаскеле получаетя другое решение. С другими характеристиками и с другими последствиями.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 14.08.07 22:20
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>А в чем проблема? Я вот во всю отлаживаю.
Неудобно. Особенно, если в макросах много логики.

VD>Проблемы конечно есть, но не с отладкой макросов. Проблема в отладке сгенерированного кода. Пока что текстовое представление для него сгенерить можно далеко (очень далеко) не всегда. Без этого проблемы могут возникнуть не толко с отладкой сгенерированного кода, но даже с его компиляцией. Компилятор будет орать непонятные вещи указывая на вызов макроса, а что за ошибка понять нельзя. Но это тоже дело времени. Сделаем грамотную генерацию текста для генерируемого макросами кода и все будет ОК.

Мне в макросах не нравится то, что мы отлаживаем не саму программу, а ее язык. Мне кажется, что нужны какие-то более глубокие средства интеграции с IDE. SymADE — это движение в этом направлении. Еще вспоминается Smalltalk'овские IDE.
Sapienti sat!
Re[42]: Являются ли макросы свидетельством недостаточной выр
От: Andrei F.  
Дата: 15.08.07 02:26
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Разница есть для пользователей. Да и стандартного АПИ мало. Нужн чтобы сами форматы были описаны. Описать их в ХМЛ проще простого.


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

VD>Описать бинарник = прибить его формат гвоздями к полу.


Обоснуй.
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.08.07 10:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что-то такого не встречал. Можно ссылочку на описание где об этом говорится? Может быть там все же приведение типво?


Тут я немножко наврал. Кое какие ограничения на типы в result expression имеются и описаны в п. 9.3 стандарта SQL'92.

AVK>> во-вторых типы параметров указываются только в момент выполнения запросов.


VD>Какие еще параметры?


Параметры запроса. Типы их нигде в самом запросе не декларируются (за исключением хранимок).
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.08.07 10:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Дык макросам фиолетово скомпилированы ли типы которые эти макросы анализируют или просто находятся в виде исходников. Для них это прозрачно.


Зачем мне для анализа скомпилированных типов макросы? И где эти макросы надо применять, если на момент деплоймента никаких исходников нет вобще?

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


А кто тебе сказал, что у нас проблемы с проксями? Их код черт знает сколько времени не трогался вобще.
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.08.07 12:02
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Тут я немножко наврал. Кое какие ограничения на типы в result expression имеются и описаны в п. 9.3 стандарта SQL'92.


У тебя он явно под рукой. Приведи, плиз, цитату.

AVK>>> во-вторых типы параметров указываются только в момент выполнения запросов.


VD>>Какие еще параметры?


AVK>Параметры запроса. Типы их нигде в самом запросе не декларируются (за исключением хранимок).


А ничего, что, скажем в C# в вызовах методов (и в LINQ-запросах) тоже не описываются типы параметров (да и возвращаемого значения тоже, начиная с 3.0)?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.08.07 12:02
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Для пользователей, насколько я понимаю, будет иметь значение только скорость работы и объем занятых данных. Или ты что-то другое имел в виду?


"Мы" это кто? Я имею в виду, что ХМЛ для ползователя удобнее, так как он сможет манипулировать с документом во первых как с обычным текстом (хранить его в системах контроля версий, мерджить и т.п.), а во вторых стандартное структурирование поможет выуживать из документов нужную информацию не прибегая к пропроитарным АПИ, а так же писать собственные редакторы для данных документов (например, резко упрощается создание генераторов отчетов выдающих на выходе воровские файлы). Что до скорости загрузки, то на современных компьютерах оверхэд от текстового формата будет небольшой (при качественной реализации), а зипование (применяемое в офисных пакетах) способно даже дать выигрышь по сравнению с бинарными форматами.

VD>>Описать бинарник = прибить его формат гвоздями к полу.


AF>Обоснуй.


Ты видил спецификации для воровского формата (бинарного)? Не STG, а того что в него пишет Ворд... Нет? Знаешь почему? Потому, что формат этот довольно гнусен и постоянно менялся МС-ом. Им проще было недокументировать данный формат оставляя отвественность за ручную модификацию (или чтение) данного формата на тех хакерах, что сами с ним смогли разобраться (и написали книжки посвященные этому). В вордоском документе запись идет не последовательно и отдельными блоками. Так проще реализовать быстрое сохранение. В купе с тем, что в отдельных блоках данные там хранятся в формате с прямой адресацией (не сериализованные) — это нехило усложняет создание собственных ридеров и райтеров для такого формата. А с ХМЛ проблем нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.08.07 12:31
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Тут я немножко наврал. Кое какие ограничения на типы в result expression имеются и описаны в п. 9.3 стандарта SQL'92.


VD>У тебя он явно под рукой. Приведи, плиз, цитату.


Там много.

AVK>>Параметры запроса. Типы их нигде в самом запросе не декларируются (за исключением хранимок).


VD>А ничего, что, скажем в C# в вызовах методов (и в LINQ-запросах) тоже не описываются типы параметров (да и возвращаемого значения тоже, начиная с 3.0)?


Типы параметров, в отличие от, вывести невозможно. Поэтому в рантайме их приходится задавать отдельно.
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.08.07 12:38
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>Дык макросам фиолетово скомпилированы ли типы которые эти макросы анализируют или просто находятся в виде исходников. Для них это прозрачно.


AVK>Зачем мне для анализа скомпилированных типов макросы? И где эти макросы надо применять, если на момент деплоймента никаких исходников нет вобще?


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

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


AVK>А кто тебе сказал, что у нас проблемы с проксями? Их код черт знает сколько времени не трогался вобще.


Да, я ничего и не говорю. Просто все просто, а конца и края не видно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.08.07 12:38
Оценка:
Здравствуйте, EvilChild, Вы писали:

VD>>Вообще-то это была ирония, если кто не заметил...

EC>Ты в таких сложных местах комментарии (смайлы) добавляй,
EC>потому как людям не использующим макросы такой юмор ещё не понятен

А людям не кажется странным, что термин "очевидно" употреблен к двум страницам кода?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.08.07 12:50
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Тут я немножко наврал. Кое какие ограничения на типы в result expression имеются и описаны в п. 9.3 стандарта SQL'92.


VD>>У тебя он явно под рукой. Приведи, плиз, цитату.


AVK>Там много.


А ты процитируй, то о чем ведешь речь.

AVK>Типы параметров, в отличие от, вывести невозможно. Поэтому в рантайме их приходится задавать отдельно.


1. Возможно.
2. Если в рантайме их задают, значит они есть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.08.07 12:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Кроме анализа еще есть стадия генерации кода. Вот она радикально упростится.


За счет чего?

VD> Кроме того руки будут развязаны и можно будет пользоваться не только скомпилированными сборками в качестве входных данных


Это просто не нужно.

AVK>>А кто тебе сказал, что у нас проблемы с проксями? Их код черт знает сколько времени не трогался вобще.


VD>Да, я ничего и не говорю. Просто все просто, а конца и края не видно.


Это демагогия.
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re[50]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.08.07 14:47
Оценка:
Здравствуйте, IT, Вы писали:

IT>Он принял архитектурное решение


Решение принял не я. Отсутствие исходников фигурирует в ТЗ.
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re[50]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 15.08.07 14:54
Оценка:
Здравствуйте, IT, Вы писали:

IT>макросы не могут проявить себя никак


Не "макросы" вообще, а "макросы N", btw
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[51]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 15.08.07 15:06
Оценка:
Здравствуйте, AndrewVK, Вы писали:

IT>>Он принял архитектурное решение


AVK>Решение принял не я. Отсутствие исходников фигурирует в ТЗ.


Какая связь между отсутствием исходников и генерацией проксей? Зачем вообще нужно генерировать прокси?
Если нам не помогут, то мы тоже никого не пощадим.
Re[52]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.08.07 15:17
Оценка:
Здравствуйте, IT, Вы писали:

AVK>>Решение принял не я. Отсутствие исходников фигурирует в ТЗ.


IT>Какая связь между отсутствием исходников и генерацией проксей? Зачем вообще нужно генерировать прокси?


Затем, что сервер должен перехватывать обращения к бизнес-классам. Сразу оговорюсь — написание бизнес-кода на Nemerle и наличие рантайма сервера при компиляции неприемлемо все по тому же ТЗ.
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 15.08.07 16:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А людям не кажется странным, что термин "очевидно" употреблен к двум страницам кода?

Может для тебя это и очевидно, мне почём знать?
now playing: Remute — Super Mario Was My Most Important Teacher (Red Kite's Magic Mushroom Remix)
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 15.08.07 17:14
Оценка:
Здравствуйте, cl-user, Вы писали:

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


FR>>У форта для близких к железу решений есть два железных преимущества, легкость портирования (аппаратно зависимые части ядра всего килобайты) и компактность получаемого кода (обгоняет многие ассемблеры). Поэтому для встраиваемых устройств очень хороший выбор. Кроме того по параметру размер реализации / высокоуровневость кода, форт рекордсмен до сих пор.


CU>Так я и не спорил с применением во всяких контроллерах и прочей "ембедщине". Но тут его вроде как GPL предлагали?..


А ты почитай внимательно, что и как предлагали. Меньше флейма будет. Речь идет исключительно об встраиваемой разработке. Я знаю, что Локотков занимается embedded разработкой — по-моему либо он либо я об этом явно сказали, и хорошо представляю, какой именно совет ему даю.
Re[7]: Являются ли макросы свидетельством недостаточной выра
От: Gaperton http://gaperton.livejournal.com
Дата: 15.08.07 17:34
Оценка:
Здравствуйте, cl-user, Вы писали:

G>> Форт (есть такой жутко гибкий макроязык для встраиваемых систем — по гибкости не уступает LISP, по близости к железу — ассемблеру и С).


CU>"Твои слова да богу в уши"


Спасибо, не надо. Ты бы читал внимательнее посты, спорил бы меньше.

CU>Есть реализация (многоплатформенная и многопроцессорная), оптимально использующая при "шитье" все регистры используемых процессоров и/или умеющая оптимизировать свой "шитый" код?


Многоплатформенную сделать труда не составит, конечно — я тебе могу на чистом С сделать замечательный кроссплатформенный форт. Я это уже делал один раз, кстати. Многопроцессорные реализации ФОРТ-а есть, проблем с этим никаких, но это не вперлость при ембеддед разработке никак, там обыкновенно одно управляющее ядро. Шитый код оптимизировать глупо — надо оптимизировать критичные куски целиком (их немного) переписыванием на С (на asm-е под MIPS особо не наоптимизишь — gcc совершенно ацки компилить умеет, накладывая аппаратное умножение на второе умножение через сдвиги-сложения, используя слот инструкции после джампов, и прочее). Форт-машина должна быть тупой, это ее основное преимущество. Задействовать все регистры при "шитье" тоже, гхм, не нужно, наоборот, надо по возможности задействовать минимум регистров.

Впрочем, голову стека данных я постарался бы хранить в отдельном регистре, как делают практически все аппаратные реализации форта — уж больно сильно это арифметику ускоряет — всего одно чтение памяти на операцию. Обеспечивается это буквально несколькими коротенькими вставками на ассемблере. Использовать два регистра под верхушку стека имеет смысл для суперскалярных процессоров, и навороченных процов, которые могут наложить обращение в память на вычисления. Это видишь ли не случай в embedded-разработке, так что смысла не имеет. Хотя, если говорить о сигнальных процах, типа блэкфина и прочих ацких сигнальниках... Или модных ядрах типа SH... То множно и задуматься.

CU>Гибкость — да, скорость — нет.


На эту тему тебе хорошо ответили ниже по ветке.
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: mkizub Литва http://symade.tigris.org
Дата: 15.08.07 18:03
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Шитый код оптимизировать глупо — надо оптимизировать критичные куски целиком (их немного) переписыванием на С (на asm-е под MIPS особо не наоптимизишь — gcc совершенно ацки компилить умеет, накладывая аппаратное умножение на второе умножение через сдвиги-сложения, используя слот инструкции после джампов, и прочее). Форт-машина должна быть тупой, это ее основное преимущество. Задействовать все регистры при "шитье" тоже, гхм, не нужно, наоборот, надо по возможности задействовать минимум регистров.


JFYI, я для Samsung-а переписал main loop явовского интерпретатора (KVM) на ассемблере (MIPS). Ускорение вышло в 2 раза. В основном за счёт правильного джамп-а при диспатчинге опкода (все хэндлеры имели по 16 или 32 комманды, не помню), расположения верхушки стека в регистре и т.п. Потом подрихтовал на ассемблере вызов методов, оптимизировал байткод при загрузке класса, оптимизнул несколько библиотечных методов и синхронизацию — и вышло ещё ускорение в 1.8 раз.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 15.08.07 18:07
Оценка:
Здравствуйте, mkizub, Вы писали:

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


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


M>Не будет. Совать форт, написанный непонятно кем, в свой телефон нормальный человек не будет. Потому как фортовских программ с встроенным вирусом образуется больше, чем сейчас спама образовалось из e-mail-а.


Ограничить доступ к ресурсам телефона для форт-машины — проблем нет никаких. Будет так же безопасно. Правда в форте есть адресная арифметика... Ну и то не беда — надо будет в каждой операции записи "!" маскировать адрес чтоб уписать его в сегмент, и всего делов. Совместимым на уровне байт-кода меж разными телефонами такой форт сделать тяжело — но можно, надо ввести переносимое промежуточное представление, либо прям в исходниках программу заливать.

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

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


Есть от чего. Там в байткоде на один уровень косвенности больше, байткод это не просто адреса, и если не применяется JIT, (а он не применяется в JVM которые реализуют CLDC, например, в KVM — том самом, который в мобильных телефонах), то явский байткод будет медленнее.

M>Больше того, нынешние мобилки прекрасно позволяют компилировать яву в нэйтивный код, памяти у них хватает. И для распространённых на мобилках CPU эти компиляторы написаны и работают. Интепретатор форта не сдюжит против компилятора в нэйтивный код никаким местом.


Мобилы реализуют CLDC и применяют в массе своей KVM в котором JIT не предусмотрен, поэтому ява для них ацки тормозит. Кроме случая, если в них как в смартфонах применяется ARM c Jazelle, тогда там ява должна быть быстра.
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 15.08.07 18:29
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


G>Есть от чего. Там в байткоде на один уровень косвенности больше, байткод это не просто адреса, и если не применяется JIT, (а он не применяется в JVM которые реализуют CLDC, например, в KVM — том самом, который в мобильных телефонах), то явский байткод будет медленнее.


О каком дополнительном уровне косвенности ты говоришь?

M>>Больше того, нынешние мобилки прекрасно позволяют компилировать яву в нэйтивный код, памяти у них хватает. И для распространённых на мобилках CPU эти компиляторы написаны и работают. Интепретатор форта не сдюжит против компилятора в нэйтивный код никаким местом.


G>Мобилы реализуют CLDC и применяют в массе своей KVM в котором JIT не предусмотрен, поэтому ява для них ацки тормозит. Кроме случая, если в них как в смартфонах применяется ARM c Jazelle, тогда там ява должна быть быстра.


Ща. Я больше трёх лет работал в Esmertec. Их продукт (Jbed) — это AOP компилятор явы. А библиотечные функции компилятся в нэйтивный код на хосте, и раборают (сюрприз!) быстрее С-шных (за счёт интеграции с GC и избегания алиасинга, в C надо лепить volatile указателям, а в явовском коде не надо, плюс unsafe хаки в компиляторе для библиотечного кода). Jazelle — мёртворождённая технология. В ней переключение между режимом java и arm/thumb слишком медленное. Следующая версия ARM-а уже будет иметь инструкции для аппаратной проверки нулевых указателей, границ массива и ещё нескольких шибко удобных вещей — код (нэйтивный) в который компилятется ява имеет размер меньше байткода, а скорость работы сам понимаешь — полная. Тут Jazelle вообще пипец настанет.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[33]: Generic programming
От: BulatZiganshin  
Дата: 15.08.07 18:59
Оценка:
Здравствуйте, VladD2, Вы писали:

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


BZ>>далее, ты упираешь на эффективность генерации кода во время компиляции.

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

VD>Это все лирика. Для решения конкретных задач она непригодна. Я не из тех кто будет заниматься глупыми предварительными оптимизациями. Поверь, задача того трбовала.


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


VD>Это прописные истины. Я с ними не спорю. Вот только они не отменяют того факта, что на Хаскеле получаетя другое решение. С другими характеристиками и с другими последствиями.


а причём тут ваша частная задача? про неё ты можешь говорить что угодно — это твоё право. в целом же generic программирование, как и программирование вообще, требует оптимизации не более чем в 20% случаев
Люди, я люблю вас! Будьте бдительны!!!
Re[39]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 15.08.07 19:02
Оценка:
Здравствуйте, mkizub, Вы писали:

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


BZ>>в статических языках тип переменной определяется текстом программы, в динамических — процессом исполнения. кстати ООП — это динамическая типизация, даже когда она привнесена в статические языки


M>Нет, ООП не противоречит статической типизации. Тип — это набор констрайнтов, определяющих что можно сделать с объектом. Тип в Java ничем не хуже типа в C, это всё тот-же набор операций над объектом.


вопрос на засывку — а зачем тогда понадобился RTTI?
Люди, я люблю вас! Будьте бдительны!!!
Re[40]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 15.08.07 19:14
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

M>>Нет, ООП не противоречит статической типизации. Тип — это набор констрайнтов, определяющих что можно сделать с объектом. Тип в Java ничем не хуже типа в C, это всё тот-же набор операций над объектом.


BZ>вопрос на засывку — а зачем тогда понадобился RTTI?


Не поверишь — просто удобно.
На C++ можно писать без RTTI, и на яве можно писать без рефлекшина. В частности, из J2ME эту библиотеку убрали — просто для экономии места.
Если тебя смущает instanceof — то почему тебя не смущает pattern mathcing в FP?
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 15.08.07 19:46
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>кстати, если бы в немерле были клозуры,


А кто сказал, что их там нет? Они даже в шарпе есть.
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 15.08.07 19:46
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>кстати, если бы в немерле были клозуры, то как я понимаю все эти управляющие структуры, которые ты приводишь (while, foreach) — можно было бы реализовать в виде обычных процедур, как это делается в руби, например


Или что обещают в 7-й яве после их добавления.
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 15.08.07 19:50
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>кстати, если бы в немерле были клозуры, то как я понимаю все эти управляющие структуры, которые ты приводишь (while, foreach) — можно было бы реализовать в виде обычных процедур, как это делается в руби, например


А mutable локальные переменные как апдейтить?
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 15.08.07 20:12
Оценка:
Здравствуйте, mkizub, Вы писали:

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


BZ>>кстати, если бы в немерле были клозуры, то как я понимаю все эти управляющие структуры, которые ты приводишь (while, foreach) — можно было бы реализовать в виде обычных процедур, как это делается в руби, например


M>А mutable локальные переменные как апдейтить?


Ммм, а может определение почитать чтоль?
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 15.08.07 20:15
Оценка:
Здравствуйте, mkizub, Вы писали:

BZ>>кстати, если бы в немерле были клозуры, то как я понимаю все эти управляющие структуры, которые ты приводишь (while, foreach) — можно было бы реализовать в виде обычных процедур, как это делается в руби, например

M>А mutable локальные переменные как апдейтить?
А какие проблемы с mutable-переменными, если есть настоящие замыкания?
Sapienti sat!
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 15.08.07 20:20
Оценка:
Здравствуйте, Курилка, Вы писали:

M>>А mutable локальные переменные как апдейтить?


К>Ммм, а может определение почитать чтоль?


И что? Что ты хотел сказать этим?
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 15.08.07 20:20
Оценка:
Здравствуйте, Cyberax, Вы писали:

M>>А mutable локальные переменные как апдейтить?

C>А какие проблемы с mutable-переменными, если есть настоящие замыкания?

Эффективность кода.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[30]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 15.08.07 20:23
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Курилка, Вы писали:


M>>>А mutable локальные переменные как апдейтить?


К>>Ммм, а может определение почитать чтоль?


M>И что? Что ты хотел сказать этим?


Несколько странно задавать вопрос про то, как локальные переменные апдейтить, если в этом основной смысл замыкания
Или это тоже непонятно?
Re[41]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 15.08.07 20:24
Оценка:
Здравствуйте, mkizub, Вы писали:

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


M>>>Нет, ООП не противоречит статической типизации. Тип — это набор констрайнтов, определяющих что можно сделать с объектом. Тип в Java ничем не хуже типа в C, это всё тот-же набор операций над объектом.


BZ>>вопрос на засывку — а зачем тогда понадобился RTTI?


M>Не поверишь — просто удобно.

M>На C++ можно писать без RTTI, и на яве можно писать без рефлекшина. В частности, из J2ME эту библиотеку убрали — просто для экономии места.

более того, C++ не ООП язык, поскольку на нём можно писать без классов RTTI — это как раз *следствие* частично-динамической типизации ООП. получая ссылку на A, ты не знаешь, какого на самом деле типа указуемый объект и RTTI сущетсвует как раз чтобы определить этот тип в случае использования техник, основанных на динамической типизации

>Если тебя смущает instanceof — то почему тебя не смущает pattern mathcing в FP?


это один тип. но в плане надёжности проблемы имхо точно такие же — обработка правильного варианта может быть просто не предусмотрена кодом
Люди, я люблю вас! Будьте бдительны!!!
Re[31]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 15.08.07 20:30
Оценка:
Здравствуйте, Курилка, Вы писали:

M>>>>А mutable локальные переменные как апдейтить?


К>>>Ммм, а может определение почитать чтоль?


M>>И что? Что ты хотел сказать этим?


К>Несколько странно задавать вопрос про то, как локальные переменные апдейтить, если в этом основной смысл замыкания

К>Или это тоже непонятно?

Смысл замыканий не в том, чтоб апдейтить локальные переменные.
Впрочем, речь не о том, что их нельзя поменять из замыкания, а о том — как ты это собираешься делать? Физически — как? Указатель на них сохранить в замыкании? И потом работать с локальной переменной по ссылке, а не в регистре/стеке?
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[51]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 16.08.07 00:54
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

IT>>макросы не могут проявить себя никак


ANS>Не "макросы" вообще, а "макросы N", btw


А мы о каких говорим? Или если больше сказать нечего, то нужно обязательно придолбаться к терминологии?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: Andrei F.  
Дата: 16.08.07 03:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>"Мы" это кто? Я имею в виду, что ХМЛ для ползователя удобнее, так как он сможет манипулировать с документом во первых как с обычным текстом (хранить его в системах контроля версий, мерджить и т.п.), а во вторых стандартное структурирование поможет выуживать из документов нужную информацию не прибегая к пропроитарным АПИ, а так же писать собственные редакторы для данных документов (например, резко упрощается создание генераторов отчетов выдающих на выходе воровские файлы).


и опять все сводится к legacy

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


не способно, если проектированием бинарного формата занимался не полный дебил. Хотел бы я посмотреть, как ты будешь сравнивать скорость работы зазипованного XML с database-in-file.

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


То есть главная и единственная проблема — в том, что MS не помогал разрабатывать 3d-party реализации либ для работы со своим форматом?
Re[43]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 16.08.07 05:39
Оценка:
Здравствуйте, mkizub, Вы писали:

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


BZ>>более того, C++ не ООП язык, поскольку на нём можно писать без классов RTTI — это как раз *следствие* частично-динамической типизации ООП. получая ссылку на A, ты не знаешь, какого на самом деле типа указуемый объект и RTTI сущетсвует как раз чтобы определить этот тип в случае использования техник, основанных на динамической типизации


M>RTTI не нужен для полиморфизма, для него нужен диспатчинг методов в зависимости от ран-тайм типа аргумента. Что никак не противоречит "набору операций, которые можно с данными произвести" — набор операций тот-же самый, вот только код выполнится разный. Не путай динамическую типизацию с полиморфизмом. Да, там унутри есть виртуальные таблици или ещё какая хрень, которая в рантайме предоставляет возможность определения типа. Но это внутренние детали, а проверка типов на этапе компиляции полная.


типы в ООП динамические. секрет успеха ООп именно в том, что он предложил наьбор операций, который похзволяет работать с динамическими, неизвестными в вомент компиляции типами в надёжной, compile-time checked манере. а RTTI — это чистая динамика, предоставляющая доступ к остальным операциям, которые в compile-time не проверишь
Люди, я люблю вас! Будьте бдительны!!!
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 16.08.07 05:41
Оценка:
M>Впрочем, речь не о том, что их нельзя поменять из замыкания, а о том — как ты это собираешься делать? Физически — как? Указатель на них сохранить в замыкании? И потом работать с локальной переменной по ссылке, а не в регистре/стеке?

это в терминах C мыслишь в GC-ed языках всё создаётся в куче — и локальные переменные, и замыкания, которые на них ссылаются. остальное — оптимизации, выполняемые по мере сил и способностей компилятора
Люди, я люблю вас! Будьте бдительны!!!
Re[52]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 16.08.07 06:44
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>макросы не могут проявить себя никак


ANS>>Не "макросы" вообще, а "макросы N", btw


IT>А мы о каких говорим?


В subj быквы N нетути.

IT>Или если больше сказать нечего, то нужно обязательно придолбаться к терминологии?


Спокойнее. Ты уже мог заметить, что решение ограниченное временем компиляции я считаю ущербным "по умолчанию". Так что мимо такой фразы я просто не смог пройти мимо
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: Курилка Россия http://kirya.narod.ru/
Дата: 16.08.07 06:52
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Спрашивается, нафига козе баян? Если в N уже есть макросы, более мощные чем инлайн-функции — нафига делать через инлайн, а не макросы?!


Ну да, зачем нам JIT, если есть более мощные макросы?
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 16.08.07 06:52
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>типы в ООП динамические.


Да не в ООП!!! В принципе полиморфизма это. Может ты не видишь разницы, но больше мне добавить нечего.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 16.08.07 06:56
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

M>>Впрочем, речь не о том, что их нельзя поменять из замыкания, а о том — как ты это собираешься делать? Физически — как? Указатель на них сохранить в замыкании? И потом работать с локальной переменной по ссылке, а не в регистре/стеке?


BZ>это в терминах C мыслишь в GC-ed языках всё создаётся в куче — и локальные переменные, и замыкания, которые на них ссылаются. остальное — оптимизации, выполняемые по мере сил и способностей компилятора


А к куче не через ссылки доступаются, да? Оптимизатор ничего не сможет наоптимизировать, он ссылки в хип на операции со стеком не заменит.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 16.08.07 07:01
Оценка:
Здравствуйте, Курилка, Вы писали:

M>>Спрашивается, нафига козе баян? Если в N уже есть макросы, более мощные чем инлайн-функции — нафига делать через инлайн, а не макросы?!


К>Ну да, зачем нам JIT, если есть более мощные макросы?


Наверное, ты что-то умное хотел сказать. Про то, что компиляторы (а не только JIT) умеют инлайнить инлайн методы я в курсе. Что-то ещё хочешь добавить?
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 16.08.07 07:48
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>А ты почитай внимательно, что и как предлагали.


Ок, раз речь идёт только об ембедщине — умолкаю
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 16.08.07 08:23
Оценка:
Здравствуйте, mkizub, Вы писали:

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


BZ>>типы в ООП динамические.


M>Да не в ООП!!! В принципе полиморфизма это. Может ты не видишь разницы, но больше мне добавить нечего.


я как раз вижу templates — это по твоему не полиморфизм?
Люди, я люблю вас! Будьте бдительны!!!
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 16.08.07 08:26
Оценка:
Здравствуйте, mkizub, Вы писали:

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


M>>>>>А mutable локальные переменные как апдейтить?

C>>>>А какие проблемы с mutable-переменными, если есть настоящие замыкания?

M>>>Эффективность кода.


BZ>>это проблема компилятора, который должен уметь их инлайнить


M>А вот и не угадал.

M>Если нам компилятор/язык гарантирует, что данный метод будет заинлайнен — то это те-же макросы, вид сбоку.
M>Спрашивается, нафига козе баян? Если в N уже есть макросы, более мощные чем инлайн-функции — нафига делать через инлайн, а не макросы?!

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

реимущесчтва в том, что это интегрированная часть языка, которую можно понять, не держа в голове дополнительный уровень трансляции. в том, что при отладке можно спокойно заходить внутрь клозур, в том что они могут реализовываться либо инлайнингом, либо ссылками в зависимости от настроек компилятора и своих размеров
Люди, я люблю вас! Будьте бдительны!!!
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 16.08.07 09:16
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>я как раз вижу templates — это по твоему не полиморфизм?


Из википедии (так себе источник, но для справки можно попользовать):

Полиморфизм (в языках программирования) — взаимозаменяемость объектов с одинаковым интерфейсом.

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


Никакий "различной реализации" для шаблонов я не вижу. Параметризация (что и служит для инстантиирования типа из шаблона) за полиморфизм, IMHO, не канает.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[33]: Являются ли макросы свидетельством недостаточной выр
От: mkizub Литва http://symade.tigris.org
Дата: 16.08.07 09:44
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>а зачем в С константы, если это по сути дела те же макросы — ты не догадываешься?


Ты опять не угадал. Мы же не о С-щных макросах говорим. В С++ const и inline ввели как type safe замену С-шных макросов.
А мы говорим об "умных" макросах. Которые сами по себе type safe.

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


Я же не против closures или inline. Иначе бы я не делал closures в своём компиляторе.
Речь зашла о том, что foreach в N можно сделать в виде closures, и инлайнинге метода foreach.
Можно, но есть такая вещь как сложность. Это фундаментальная проблема программирования, вокруг попыток упростить разработку программ вообще всё программирование вертится. Это в нём главное, иначе мы бы до сих пор в машинных кодах программировали бы.
Так вот. Силы разработчиков компилятора N ушли на макросы. У них пока руки не дошли обычный if оптимизировать (нормально скомпилировать, а не как http://rsdn.ru/forum/message/2618909.1.aspx
Автор: Othello
Дата: 13.08.07
), а ты говоришь об инлайнинге. Конечно, если N будет жить — то доделают и инлайнинг, и всё остальное. Но это ещё не скоро. А пока они взяли то, что у них сделано хорошо (макросы) и на них сделали foreach. И правильно сделали. А вот когда (и если) доделают инлайнинг — тогда кто-нибудь ради прикола напишет метод inline foreach(...) и будет приколисту щастье.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 16.08.07 12:00
Оценка:
Здравствуйте, mkizub, Вы писали:

M>А к куче не через ссылки доступаются, да? Оптимизатор ничего не сможет наоптимизировать, он ссылки в хип на операции со стеком не заменит.

Еще как заменит... некоторые реализации жабы давно заменяют... и то что они делают далеко не придел.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: WolfHound  
Дата: 16.08.07 12:00
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Так вот. Силы разработчиков компилятора N ушли на макросы. У них пока руки не дошли обычный if оптимизировать (нормально скомпилировать, а не как http://rsdn.ru/forum/message/2618909.1.aspx
Автор: Othello
Дата: 13.08.07
), а ты говоришь об инлайнинге.

Убирать такие ляпы фротенда дело виртуальной машины (и JIT .NET'а кстати убирает). Фронтенду и так есть чем заняться.
Болие того если этим будет заниматся фронтенд то эти оптимизации придется делать во всех фронендах. А если этим займется ВМ то эти оптимизации нужно сделать один раз.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: Gaperton http://gaperton.livejournal.com
Дата: 16.08.07 12:29
Оценка:
Здравствуйте, mkizub, Вы писали:

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


G>>Шитый код оптимизировать глупо — надо оптимизировать критичные куски целиком (их немного) переписыванием на С (на asm-е под MIPS особо не наоптимизишь — gcc совершенно ацки компилить умеет, накладывая аппаратное умножение на второе умножение через сдвиги-сложения, используя слот инструкции после джампов, и прочее). Форт-машина должна быть тупой, это ее основное преимущество. Задействовать все регистры при "шитье" тоже, гхм, не нужно, наоборот, надо по возможности задействовать минимум регистров.


M>JFYI, я для Samsung-а переписал main loop явовского интерпретатора (KVM) на ассемблере (MIPS). Ускорение вышло в 2 раза. В основном за счёт правильного джамп-а при диспатчинге опкода (все хэндлеры имели по 16 или 32 комманды, не помню),


Шитый код в отличии от байткода — это уже адрес, по которому надо делать переход (для прямого шитого кода) причем адрес строго фиксированного размера. Например, 32 бита, без вариантов. Его диспатчить правильно не надо — есть ровно один способ.

M>расположения верхушки стека в регистре и т.п.

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

M>Потом подрихтовал на ассемблере вызов методов, оптимизировал байткод при загрузке класса, оптимизнул несколько библиотечных методов и синхронизацию — и вышло ещё ускорение в 1.8 раз.


Этого всего в случае форт-машины делать просто не нужно, за отсутствием методов и классов, и исключительно простой процедуре вызова.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 16.08.07 12:38
Оценка:
Здравствуйте, mkizub, Вы писали:

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


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


G>>Есть от чего. Там в байткоде на один уровень косвенности больше, байткод это не просто адреса, и если не применяется JIT, (а он не применяется в JVM которые реализуют CLDC, например, в KVM — том самом, который в мобильных телефонах), то явский байткод будет медленнее.


M>О каком дополнительном уровне косвенности ты говоришь?


Я о том, что в фортовом шитом коде мне не надо дешифровать код операции — все коды фиксированной длины и представляют из себя адреса, по которым надо делать переход (для прямого кода JMP [PC++]) или слазить по адресу (для косвенного шитого кода JMP [PC++]]). В случае сишной переносимой встраиваемой реализации у меня байткод — это массив указателей на функции (которым верхушку стека я передам отдельным параметром, и она будет лежать в регистре). И все. По производительности такая переносимая реализация порвет тупенький KVM даже без "вставок на Клиппере для скорости".

M>>>Больше того, нынешние мобилки прекрасно позволяют компилировать яву в нэйтивный код, памяти у них хватает. И для распространённых на мобилках CPU эти компиляторы написаны и работают. Интепретатор форта не сдюжит против компилятора в нэйтивный код никаким местом.


G>>Мобилы реализуют CLDC и применяют в массе своей KVM в котором JIT не предусмотрен, поэтому ява для них ацки тормозит. Кроме случая, если в них как в смартфонах применяется ARM c Jazelle, тогда там ява должна быть быстра.


M>Ща. Я больше трёх лет работал в Esmertec. Их продукт (Jbed) — это AOP компилятор явы. А библиотечные функции компилятся в нэйтивный код на хосте, и раборают (сюрприз!) быстрее С-шных (за счёт интеграции с GC и избегания алиасинга, в C надо лепить volatile указателям, а в явовском коде не надо, плюс unsafe хаки в компиляторе для библиотечного кода).


Компилятор тут не причем. Речь о ява машинах для телефонов. Конкретнее, о том что CLDC-шный KVM популярный в мобилах не делает джит, и никакой компилятор не поможет тебе не то что обогнать, но даже близко к С подойти.

M>Jazelle — мёртворождённая технология. В ней переключение между режимом java и arm/thumb слишком медленное. Следующая версия ARM-а уже будет иметь инструкции для аппаратной проверки нулевых указателей, границ массива и ещё нескольких шибко удобных вещей — код (нэйтивный) в который компилятется ява имеет размер меньше байткода, а скорость работы сам понимаешь — полная. Тут Jazelle вообще пипец настанет.


Возможно.
Re[38]: Являются ли макросы свидетельством недостаточной выр
От: Gaperton http://gaperton.livejournal.com
Дата: 16.08.07 13:00
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

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


BZ>это вопрос реализации. были интерпретаторы даже для С, с другой стороны есть lint-подобные системы для динамичсеких языков. правильное же определение — в статических языках тип переменной определяется текстом программы, в динамических — процессом исполнения.


Не совсем так. Не текстом программы. Я и в динамическом языке могу во многих случаях тип вывести из контекста употребления. Разница в том, как семантика языка трактует ошибку типа — может ли она у меня во время выполнения выскочить, или это невозможно в принципе. Вот в вашем бейсике например семантика не обязываем меня употреблять % для целых чисел, и эту переменную я могу подставить в конструктор массива DIM. Что будет, если параметром DIM окажется число с плавающей запятой? Обязан ли компилятор выводить тип этой переменной и давать мне по рукам? Нет, не обязан — это должно упасть в рантайме. Потому, семантика динамическая. Просто система типов языка настолька убога, что пользы от этой динамической семантики нет никакой.

BZ>кстати ООП — это динамическая типизация, даже когда она привнесена в статические языки

Ну разумеется, нет. Это один из способов привнести в статические языки полиморфизм. Типизация остается статической — все ошибки типов гарантированно ловятся компилятором статически. Это если ты не пользуешься dynamic_cast и аналогами (даункасты в яве, QueryInterface в COM) — вот они как раз и есть "динамическая типизация" — могут и обломаться в рантайме запросто.
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 16.08.07 13:09
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


Так бы сразу и сказал, что макросы суксь.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Военный стиль руководства.
От: Gaperton http://gaperton.livejournal.com
Дата: 17.08.07 08:08
Оценка:
Здравствуйте, Вася, Вы писали:

BZ>типы в ООП динамические.


Вась, ты не мог бы дать определение термина "динамический тип", и чем он отличается от "статического типа"? Я всегда, понимаешь, держу руку на пульсе и открыт свежим веяниям в computer science. Есть у меня предположения, что ты говоришь о старых добрых "полиморфных переменных"

BZ> секрет успеха ООп именно в том, что он предложил наьбор операций, который похзволяет работать с динамическими, неизвестными в вомент компиляции типами в надёжной, compile-time checked манере.


Это, видимо, очень, очень большой секрет, знает который лишь узкий круг ограниченных лиц.

BZ>а RTTI — это чистая динамика, предоставляющая доступ к остальным операциям, которые в compile-time не проверишь


Да, RTTI — чистая динамика, не имеющая никакого отношения к ООП.
Re[54]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.08.07 09:25
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>Так бы сразу и сказал, что макросы суксь.


Я еще не определился

Кстати, в LISP есть макросы, но "время компиляции" может быть и во время выполнения. Такая система мне нравится. Но о пользе и вреде макросов я не говорю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[44]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.08.07 13:53
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Мне в макросах не нравится то, что мы отлаживаем не саму программу, а ее язык. Мне кажется, что нужны какие-то более глубокие средства интеграции с IDE.


Мета-программа есть мета-программа. Она манипулирвет кодом как данными. Тут дригого ничего ен придуемешь. Макросы просто упрощают эту манипуляцию и предоставляют инструменты декомпозиции кода.

C>SymADE — это движение в этом направлении.


С чего бы это? Из приводимых, разрозненных, примеров лично я вижу, что в SymADE вообще конь не валялся. Мета-программирование (МП) там используется во всю, но таких вещей как квази-цитирование и паттернм матчинг нет и в памине. В итоге приходится манипулировать галимым АСТ средствами Явы. В общем, мрак.

Ты явно не можешь поянть в чем фишка у автора SymADE.
Он во что бы то ни стало хочет отказаться от текста. Думает, что не будеть текста как базового формата хранения, как все стразу в жизни станет просто и красиво. А никаких идей по упрощению МП или заменяющих его в SymADE нет.

C>Еще вспоминается Smalltalk'овские IDE.


Давай. Начинай. Что же там такого чудестного?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.08.07 13:53
Оценка:
Здравствуйте, Andrei F., Вы писали:

VD>>"Мы" это кто? Я имею в виду, что ХМЛ для ползователя удобнее, так как он сможет манипулировать с документом во первых как с обычным текстом (хранить его в системах контроля версий, мерджить и т.п.), а во вторых стандартное структурирование поможет выуживать из документов нужную информацию не прибегая к пропроитарным АПИ, а так же писать собственные редакторы для данных документов (например, резко упрощается создание генераторов отчетов выдающих на выходе воровские файлы).


AF>и опять все сводится к legacy


Где ты увидил это свое "legacy"? А? Тебе же говорят "удбнее для пользователей". Точка.

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


AF>не способно, если проектированием бинарного формата занимался не полный дебил.


Значит занимались полные дебилы, потому как это факт. В прочем, у меня другая точка зрения. Просто кто-то говорит не разобравшись и это точно не я.

AF> Хотел бы я посмотреть, как ты будешь сравнивать скорость работы зазипованного XML с database-in-file.


А зачем мне БД если я хочу передать текстовый документ?

AF>То есть главная и единственная проблема — в том, что MS не помогал разрабатывать 3d-party реализации либ для работы со своим форматом?


Нет главная проблема в непрозрачности не текстовых форматов. И нужно иметь очень веские основания, чтобы предпочесть их текствым. В случае с СУБД — это основание есть. В случае с текстовым документом аля Вордовский — нет. В случае с исходниками такого основания нет и подавно. Ну, разве что сложность создания прасера. Но это проблемы разработчика. Пользовтель же выберет самое удобное для себя. И текстовый формат будет одним из приемуществ для него.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.08.07 13:53
Оценка:
Здравствуйте, AndrewVK, Вы писали:

...

Здорово. Ты привел правила приведения типов и конвертации данных. Из каких строк, по твоему, следует, что SQL динамически типизирован по определению?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.08.07 13:53
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>
AVK>SELECT @param
AVK>

AVK>Выводи.

Это некорректный запрос с точки зрения SQL92.

VD>>2. Если в рантайме их задают, значит они есть.


AVK>Выяснение типов в рантайме как раз и есть динамическая типизиция.


Вот только в SQL типы известны еще до выполнения запроса. А это и есть рантайм для SQL.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Generic programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.08.07 13:53
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

VD>>Это прописные истины. Я с ними не спорю. Вот только они не отменяют того факта, что на Хаскеле получаетя другое решение. С другими характеристиками и с другими последствиями.


BZ>а причём тут ваша частная задача? про неё ты можешь говорить что угодно — это твоё право. в целом же generic программирование, как и программирование вообще, требует оптимизации не более чем в 20% случаев


А я не абстрактные задачи решаю, а исключительно частные.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Generic programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.08.07 13:53
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>так вот, в то время как макросы обеспечивают доступ к AST генерируемого кода плюс обычные средства ЯП для манипуляции с ним — templates/generics предоставляют свой собственный набор операций, нацеленный именно на generic программирование,


Не скажу за Хаскель, но для С++ — это не правда. Там "язык" получился соврешенно случайно. Ни на что он не нацелен и решает задачи МП с горем пополам.

BZ> и в этой области они позволяют достигать того же эффекта затратой куда меньших усилий.


Это уже полнейшая лож. Если бы это было так, то никто бы и не стал возиться с макросами. На практике МП на шаблонах С++ выливается в кривейшие решения, изобилующие ужимками и хаками, то и дело преводящие к дичайшему оверхэду и геморою. По сравнению с ними добротная макросистема выглядит просто верхом совершенства и позволяет куда больше.

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


Ага. Только вот обобщенное программирование по любому будет меньше чем МП. Обобщенное программирование не подразумевает генерацию нового кода. Хаскель конечно преуспел в этой области. Его классы типов несомненно красивое решение, новыше головы не прыгнешь и именно поэтому есть Темплэйт Хаскель.

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


Тут не счем спорить. Если впихнуть в язык средства для чего-то то реализовывать это что-то вручную будет не надо (при условии достаточной универсальности и производительности встроенного решения). Но надеюсь никто в здравом уме не будет спорить с тем, что все в язык не впихнуть, с тем, что впихвание усложняет язык и с тем, что не все впихнутые решения оказываются приемлемыми на практике. Так вот макросы и есть средство гибко впихивать в язык то что нужно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.08.07 14:29
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>
AVK>>SELECT @param
AVK>>

AVK>>Выводи.

VD>Это некорректный запрос с точки зрения SQL92.


<direct select statement: multiple rows> ::=
              <query expression> [ <order by clause> ]

<query expression> ::=
                <non-join query expression>
              | <joined table>

<non-join query expression> ::=
                <non-join query term>
              | <query expression> UNION  [ ALL ] [ <corresponding spec> ] <query term>
              | <query expression> EXCEPT [ ALL ] [ <corresponding spec> ] <query term>

<non-join query term> ::=
                <non-join query primary>
              | <query term> INTERSECT [ ALL ] [ <corresponding spec> ] <query primary>

<non-join query primary> ::=
                <simple table>
              | <left paren> <non-join query expression> <right paren>

<simple table> ::=
                <query specification>
              | <table value constructor>
              | <explicit table>
              
<table value constructor> ::=
              VALUES <table value constructor list>

<table value constructor list> ::=
              <row value constructor> [ { <comma> <row value constructor> }... ]

<row value constructor> ::=
                <row value constructor element>
              | <left paren> <row value constructor list> <right paren>
              | <row subquery>

<row value constructor element> ::=
                <value expression>
              | <null specification>
              | <default specification>


Перепишем:
VALUES :param

Сильно полегчало? Можно и так:
SELECT :param FROM MyTable

А можно так:
SELECT X FROM Y WHERE :param1 = :param2
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: Andrei F.  
Дата: 20.08.07 15:27
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Где ты увидил это свое "legacy"? А? Тебе же говорят "удбнее для пользователей". Точка.


Там, где ты сказал про системы контроля версий и мерджилки.

AF>> Хотел бы я посмотреть, как ты будешь сравнивать скорость работы зазипованного XML с database-in-file.


VD>А зачем мне БД если я хочу передать текстовый документ?


А какая тебе разница, как пользователю, что там внутри? Берешь файл и передаешь.

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


Непрозрачность — это политика МС, а не особенность использованной ими технологии. Разработчиками PNG ничто не помешало сделать формат прозрачным.
Но мы же здесь не о политике говорим?

И вообще, давай перенесем дискуссию в одну ветку. Вот сюда
Re[9]: Грамотное развитие новых языков и средств программиро
Автор: VladD2
Дата: 20.08.07
Re[36]: Generic programming
От: BulatZiganshin  
Дата: 20.08.07 16:24
Оценка:
Здравствуйте, VladD2, Вы писали:

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


BZ>>так вот, в то время как макросы обеспечивают доступ к AST генерируемого кода плюс обычные средства ЯП для манипуляции с ним — templates/generics предоставляют свой собственный набор операций, нацеленный именно на generic программирование,


VD>Не скажу за Хаскель, но для С++ — это не правда. Там "язык" получился соврешенно случайно. Ни на что он не нацелен и решает задачи МП с горем пополам.


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

BZ>> и в этой области они позволяют достигать того же эффекта затратой куда меньших усилий.


VD>Это уже полнейшая лож. Если бы это было так, то никто бы и не стал возиться с макросами.


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

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


VD>Ага. Только вот обобщенное программирование по любому будет меньше чем МП. Обобщенное программирование не подразумевает генерацию нового кода. Хаскель конечно преуспел в этой области. Его классы типов несомненно красивое решение, новыше головы не прыгнешь и именно поэтому есть Темплэйт Хаскель.


type classes — это не generic, а polymorhic programming. я уже многоркатно говорил, что здесь ижёт терминологическая путаница. generic programming — это операции типа gmap или gfold, позволяющие сгенерить операции отображения или скажем сериализации для сколь угодно сложного типа
Люди, я люблю вас! Будьте бдительны!!!
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 21.08.07 02:36
Оценка:
VladD2 wrote:
> C>Мне в макросах не нравится то, что мы отлаживаем не саму программу, а
> ее язык. Мне кажется, что нужны какие-то более глубокие средства
> интеграции с IDE.
> Мета-программа есть мета-программа. Она манипулирвет кодом как данными.
Именно это мне и не нравится.

> Тут дригого ничего ен придуемешь. Макросы просто упрощают эту

> манипуляцию и предоставляют инструменты декомпозиции кода.
Мне почему-то кажется, что манипуляции с кодом должна делать IDE.

Проще всего на примере показать. В Java для организации событий
используется вот такой жуткий паттерн:
public class Something
{
   int anything;
   Set<PropertyChangeListener> listeners=new 
HashSet<PropertyChangeListener>();

   int getAnything()
   {
      return anything;
   }
   void setAnything(int anything)
   {
      if (this.anything!=anything)
      {
          fireEvents(listeners,new PropertyChangeEvent(...));
          this.anything=anything;
      }
   }
};

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

А можно решить эту проблему с помощью IDE, которая вместо этого жуткого
кода будет показывать что-нибудь типа "[+] PropertyWithEvents int
anything;" (при нажатии [+] — разворачиваем тело).

Еще один пример — regexp'ы в языке. Можно сделать кучу сложных макросов,
похожих по синтаксису на regexp'ы (причем полностью повторить синтаксис
скорее всего не получится), а можно просто научить IDE определять
литералы, в которых есть regexp'ы.

Такой подход, несомненно, менее мощный, чем полноценные макросы. Однако,
он намного более индус-friendly. Кроме того, нам для него не требуется
[большого] изменения языка (Java или C#), а достаточно изменения IDE.
Причем возможно эволюционное развитие.

Мне еще этот подход кажется более естественным, что ли. Но это мое
субъективное мнение.

> C>SymADE — это движение в этом направлении.

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

Надо как-то заставить IDE понимать больше в семантике кода.

> Ты явно не можешь поянть в чем фишка у автора SymADE.

> Он во что бы то ни стало хочет отказаться от текста.
Да это понятно тупиковая идея — лучше текста ничего не придумали для
работы с кодом (т.е. для написания кода).

> C>Еще вспоминается Smalltalk'овские IDE.

> Давай. Начинай. Что же там такого чудестного?
Программа по сути может представлять из себя "слепок" состояния
программы + IDE. Интерсный подход.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 21.08.07 10:37
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>Класс с кучей таких свойств — это жуткое, душераздирающее зрелище. Можно
C>банально решить эту проблему с помощью макроса, который будет
C>разворачиваться в нужный код.

А можно просто создать новый класс.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 21.08.07 14:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Мне еще этот подход кажется более естественным, что ли. Но это мое субъективное мнение.


Именно что индус-friendly. В чистом виде копипейст со всеми вытекающими. Что если выяснится, что код твоего паттерна, к примеру, не multithreaded? Выискивать и выправлять все места? А если индусы там уже своих козявок понадобавляли?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 21.08.07 15:01
Оценка:
IT wrote:
> C>Мне еще этот подход кажется более естественным, что ли. Но это мое
> субъективное мнение.
> Именно что индус-friendly. В чистом виде копипейст со всеми вытекающими.
> Что если выяснится, что код твоего паттерна, к примеру, не
> multithreaded?
Использовать средства рефакторинга IDE, с массовой заменой кода паттерна.

> Выискивать и выправлять все места? А если индусы там уже

> своих козявок понадобавляли?
А если выяснится, что твой макрос вынуждает клиента быть unthreadsafe?
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[37]: Generic programming
От: awson  
Дата: 21.08.07 15:12
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>type classes — это не generic, а polymorhic programming. я уже многоркатно говорил, что здесь ижёт терминологическая путаница. generic programming — это операции типа gmap или gfold, позволяющие сгенерить операции отображения или скажем сериализации для сколь угодно сложного типа

Только (пока) эти операции в Хаскелле целиком и полностью реализуются на классах типов, которые и обеспечивают "обход" типа.
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 21.08.07 15:38
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Использовать средства рефакторинга IDE, с массовой заменой кода паттерна.


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

C>А если выяснится, что твой макрос вынуждает клиента быть unthreadsafe?


Значит макрос будет заточен под конкретные нужды без переписывания остального кода.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 21.08.07 15:57
Оценка:
IT wrote:
> C>Использовать средства рефакторинга IDE, с массовой заменой кода паттерна.
> Простой заменой дело не обойдётся. Самое плохое в копи-пейсте, что он с
> каждой копией имеет тенденцию слегка мутировать.
В том-то и дело, что ты НЕ делаешь copy-paste. В простейшем варианте ты
пишешь: "[клавиша-модификатор]WithEvents[/клавиша-модификатор]int
anything;". IDE тебе сама все сгенерирует, зафолдит и вообще уберет с
глаз долой.

> C>А если выяснится, что твой макрос вынуждает клиента быть unthreadsafe?

> Значит макрос будет заточен под конкретные нужды без переписывания
> остального кода.
Что мешает заточить темплейт под нужды кода?
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[39]: Generic programming
От: awson  
Дата: 21.08.07 16:19
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>откуда у вас столь глубокие познания предмета? из моих же постов, где я объясняю как это можно сделать через type classes. однако это только одна из групп подходов, также используются макросистемы, спец. надстройки над хаскел, RTTI. читайте

BZ>Comparing Approaches to Generic Programming in Haskell [http://www.cs.uu.nl/~johanj/publications/ComparingGP.pdf]

1. Глубокие познания предмета у меня от изучения литературы, кода и использования всего этого в собственных разработках
2. Я не читал Ваших постов по этой теме
3. В своем посте я писал о Хаскелле, а не о "макросистемы, спец. надстройки над хаскел"
4. Без классов типов generic-programming невозможно по определению. Разве только в случае использования template haskell, доведенного до абсурда.

Привет.
Re[50]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 21.08.07 16:19
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В том-то и дело, что ты НЕ делаешь copy-paste. В простейшем варианте ты

C>пишешь: "[клавиша-модификатор]WithEvents[/клавиша-модификатор]int
C>anything;". IDE тебе сама все сгенерирует, зафолдит и вообще уберет с
C>глаз долой.
Я правильно понимаю, что этот подход работает только, если нагенерённый код руками не трогали?
now playing: Ada — Cool My Fire (Erlend Oye & Band)
Re[51]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 21.08.07 17:19
Оценка:
EvilChild wrote:
> C>В том-то и дело, что ты НЕ делаешь copy-paste. В простейшем варианте ты
> C>пишешь: "[клавиша-модификатор]WithEvents[/клавиша-модификатор]int
> C>anything;". IDE тебе сама все сгенерирует, зафолдит и вообще уберет с
> C>глаз долой.
> Я правильно понимаю, что этот подход работает только, если нагенерённый
> код руками не трогали?
Ага. А если тронешь код, помеченый паттерном — IDE инспекцией по голове
стукнет.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[52]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 21.08.07 17:20
Оценка:
IT wrote:
> EC>Я правильно понимаю, что этот подход работает только, если
> нагенерённый код руками не трогали?
> Правильно. Но его нельзя не трогать. Нужно как минимум поменять anything
> на something
Так меняй, какие проблемы? Ты при обычной работе на экране будешь видеть
вот такое:
+ WithEvens int anything;


Меняешь anything (с помощью рефакторинга или руками) — оно все само сделает.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 21.08.07 17:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Меняешь anything (с помощью рефакторинга или руками) — оно все само сделает.


И как потом "Использовать средства рефакторинга IDE, с массовой заменой кода паттерна."?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[52]: Являются ли макросы свидетельством недостаточной выр
От: IT Россия linq2db.com
Дата: 21.08.07 17:32
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ага. А если тронешь код, помеченый паттерном — IDE инспекцией по голове стукнет.


Ужас. Опять инспекция. Сначала нужно нагенерить всякого хлама, а потом усиленно следить, чтобы его никто не сломал.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[52]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 21.08.07 18:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ага. А если тронешь код, помеченый паттерном — IDE инспекцией по голове

C>стукнет.
А если кому-то лицензия на IDE ещё не пришла или человек приверженнец другой IDE, то пипец?
Убей себя Notepad'ом?
Мне вот странно слышать подобное именно от тебя, человека чей кругозор не ограничен Java,
закалённого C++ template metaprogramming'ом, такие вещи.
now playing: Misanthrop — Waste Express
Re[53]: Являются ли макросы свидетельством недостаточной выр
От: BulatZiganshin  
Дата: 22.08.07 07:12
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


C>>Ага. А если тронешь код, помеченый паттерном — IDE инспекцией по голове

C>>стукнет.
EC>А если кому-то лицензия на IDE ещё не пришла или человек приверженнец другой IDE, то пипец?

а если он приверженец другого языка? главный вопрос со всяким технологическим новшеством — подтвердить свои реальные преимущества над старыми технологиями: сократить время разработки, увеличить наджёжность, снизить требования к квалифиуации программистов
Люди, я люблю вас! Будьте бдительны!!!
Re[54]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 22.08.07 20:23
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Мне НЕ нравятся полностью неограниченые макросы. Эффекты С++-ных

C>темплейтов хотя бы локализованы.
Так я за них и не агитирую.
Мой поинт в том, что удобнее, когда какая-то вещь интегрирована в язык, чем реализация её на соглашениях.
now playing: Deep-Dive-Corp — Rising Sun (Flipside's Shine Rmx)
Re[55]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 22.08.07 22:59
Оценка:
EvilChild wrote:
> C>Мне НЕ нравятся полностью неограниченые макросы. Эффекты С++-ных
> C>темплейтов хотя бы локализованы.
> Так я за них и не агитирую.
> Мой поинт в том, что удобнее, когда какая-то вещь интегрирована в язык,
> чем реализация её на соглашениях.
Так достаточно стандартизовать соглашения

Просто я еще работаю на Java в IDEA — так эта IDE реально делает из Java
более "высокоуровневый" язык. В частности, проверяются вещи, которые
статической типизацией вообще не ловятся.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[55]: Являются ли макросы свидетельством недостаточной выр
От: Cyberax Марс  
Дата: 22.08.07 23:38
Оценка:
Здравствуйте, IT, Вы писали:

C>>Мне НЕ нравятся полностью неограниченые макросы.

IT>Дык, а макросы для чего? Ведь всегда можно ограничить неограниченные макросы с помощью неограниченных макросов!
И каким же образом ты это сделаешь в проекте, где ты пишешь только один интеграционный модуль (а ядро тебе никто не даст менять)?
Sapienti sat!
Re[48]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 23.08.07 17:10
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>> С другой стороны все те же симптому наблюдаются и у дотнетчиков./.../ похоже ничего поделать с ним нельзя. Это на уровне психологии.


ANS>Я точно читаю это у Влада?


Пора ник апгрейдить на VladD3, чтобы людей не путать
now playing: Typecell — Next Stage
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: jazzer Россия Skype: enerjazzer
Дата: 27.08.07 04:29
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Никакий "различной реализации" для шаблонов я не вижу. Параметризация (что и служит для инстантиирования типа из шаблона) за полиморфизм, IMHO, не канает.


Почитай что-нть про специализацию и про частичную специализацию.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.08.07 08:51
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

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


BZ>с интеллектом в 1000 миллиОлегов как раз syb4.hs, ссылку на который я давал — это реализаций generic программирования в compile time , которую не сможет понять ни один смертный


Оставь, пожалуйста syb4 может быть, а вот ту реализацию gmap что я давал — очень даже запросто.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.08.07 08:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это где угодно можно делать. Толкьо это не эффектвно и не гибко.


Не обязательно, см ниже.

VD>Макрос генерирует специализированный (оптимизированный) код для частных случаев. Так он обрабатывает ситуации в ктолрых речь идет о массивах и генерирует for-ы,


Например, полиморфный mapM так и будет делать.

VD>обрабатывает ситуацию когда коллекция реализует интерфейс IDisposable и вызывает при этом Dispose(),


По моему, для этого достаточно сделать foreach полиморфным. Необходимости в макросах не видно.

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


Насчёт списков опять полиморфизм, а что такое генераторы последовательностей?

VD>В итоге получается гибкое и оптимальное с точки зрения производительности решение. Причем синтаксически оно такое как хочется, а не такое как получается (как в твоих примерах).


Да. Синтаксис — сильная сторона макросов. Моё имхо в том, что в данном случае он не важен. Ну или не сильно важен.

VD>В итоге мы имеем два решения. Одно для матиматиков (оно в Немерле тоже достпно). Второе для повседневной жизни. Быстрое, удобное и практичное.


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

VD>А зря, кстати. Строка тоже собирается макросом. Он тоже явно боеле выразителен чем то что можешь предложить Хаскель.


Да. Но это как раз задача на синтаксис, тут макросы рулят.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.08.07 09:11
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Входишь в своей профайл и там есть сслочка на твои файлы. Ну, а там кнопочка "Загрузить".


Есть, пасиб.

L>>Настраиваешь пути


VD>Ну, это как всегда у ученых и юнисойдов. Ни дня без траха.


Я в смысле добавляешь в PATH путь к ghc/ghci

L>>Э-э-э.. Что то я туплю с утра. Что увидеть?


VD>Код целиком.


http://files.rsdn.ru/5682/JSON.lhs
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.09.07 11:41
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Как это сделать на макросах?


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

Примеры? Их посовывает сама жизнь: [Haskell] Метопрограммирование на типах
Автор: awson
Дата: 10.09.07
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.09.07 11:41
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>Влад, есть отличное введение в использование ParseC — http://www.cs.uu.nl/people/daan/download/parsec/parsec.html . для того, чтобы немного разобраться в возможностях, предоставляемых библиотекой, лучше всего почитать его


Спасибо, конечно, но это 35 страниц самым мелким шрифтом. А времени нет .

BZ>и разумеется, ты прав, что всё это делается с помощью монад. монады — это просто универсальный способ написания "фабрик кода", что-то типа поддержки создания паттернов в самом языке. монады, создаваемые для парсинга, весьма напоминают Прологовский механизм унификации с бэктрекингом. просто здесь он реализован в виде библиотеки, а монады обеспечивают необходимый сахар в лице 'do' плюс high-order functions


Дык, проблема в том, что это не меньшая магия чем макросы. Точнее даже куда большая.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[46]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.09.07 12:08
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

M>>Да не в ООП!!! В принципе полиморфизма это. Может ты не видишь разницы, но больше мне добавить нечего.


BZ>я как раз вижу templates — это по твоему не полиморфизм?


Плдиморфизм бывает разный. Бывает статически, бывает динамический, а бывает утиный. Так вот несомненно без динамики вообще жить нельзя. И несомнено на есть (не может не быть) и в ООП и в ФП. И так же несомненно, что статической типизации это не отменяет. Как несомненно, что динамический полиморфизм делает решения более гибкими.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Военный стиль руководства.
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.09.07 12:08
Оценка:
Здравствуйте, Gaperton, Вы писали:

BZ>>типы в ООП динамические.


G>Вась, ты не мог бы дать определение термина "динамический тип", и чем он отличается от "статического типа"? Я всегда, понимаешь, держу руку на пульсе и открыт свежим веяниям в computer science. Есть у меня предположения, что ты говоришь о старых добрых "полиморфных переменных"


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

При этом статическим типом можно считать этот интерфейс, а динамическим — фактический тип объекта. Это хорошо видно в отладчиках.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.09.07 12:08
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Почему-то, .NET-программисты страдают "туннельным видением" — все не-MS-технологии они просто не замечают. Удобные mapper'ы в виде iBatis'а и Hibernate работают в Java уже который год. И ничего, никакой LINQ не нужен.


А каким видением страдают ява-программисты, что незамечают, что море народу засовывает в задницу Кибернэйты и начинает использовать Руби на Рельсах, где мапер проще, но удобнее?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 12.09.07 09:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Зачем делать на макросах то для чего они не предназначены? Это так же глупо как делать не на макросах то, что проще или понятнее/логичнее делается на макросах.


VD>Примеры? Их посовывает сама жизнь: [Haskell] Метопрограммирование на типах
Автор: awson
Дата: 10.09.07


Зачем делать на макросах то, что проще делается без них и для чего они не предназначены?

Если же задача стоит делать это именно компайл-тайм, то почему макросы здесь подходят лучше, чем зависимые типы (вернее, очень близкие к ним)?

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

Во-вторых, если взять язык с зависимыми типами вроде Омеги, то это решение будет выглядеть очень близко к исходному (рантайм) варианту, но при этом работать в компайл тайм на проверке типов. Просто потому что в языке есть удобный сахар + нужная типизация, что делает его очень выразительным — например, функции над типами пишутся практически так же как и обычные. Т.е. в этом случае макросы не нужны — и данная задача лишь подтверждает гипотезу EvilChild'а.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[27]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 12.09.07 09:18
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Дык, проблема в том, что это не меньшая магия чем макросы. Точнее даже куда большая.


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

ФВП тебе как? Меньшая магия, чем макросы или большая?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.07 09:07
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Примеры? Их посовывает сама жизнь: [Haskell] Метопрограммирование на типах
Автор: awson
Дата: 10.09.07


L>Зачем делать на макросах то, что проще делается без них и для чего они не предназначены?


Незачем. Как незачем делать обратное. Вот пример обратного и находится по этой ссылке.

L>Если же задача стоит делать это именно компайл-тайм, то почему макросы здесь подходят лучше, чем зависимые типы (вернее, очень близкие к ним)?


Птому, что они позяоляют решать задачу, а не терять время почем зря.

Если кто-то этого не понимает, то пусть пребывает в своем заблуждении сколько угодно.

L>Тут есть два момента. Во-первых, сама по себе эта задача не очень то жизненная. Однако, её решение — наложение ограничений на типы и проверка этих ограничений — имеет смысл в практике.


Задача конечно бессмысленная. Но это банальное, не тривиальное вычисление в компайлтайме. А в этом смысл на практие сплошь и рядом.

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


Я не понял. И что? Это пример безграмотного подхода к решению проблемы — выбора не соответствующего интсрумента. То что этот инструмет к тому же сильно ограничен не более чем частности.

L>Во-вторых, если взять язык с зависимыми типами вроде Омеги, то это решение будет выглядеть очень близко к исходному (рантайм) варианту


А зачем нужно "очень близкое к исходному решение" если есть "полностью аналогичное"?

Зачем вставлять в зад горелку от автогена когда можно просто удалять гланды через рот?

Ладно. Это музыка будет вечна, если вдруг с дури заменить батерейки. Позиции всех участников дискуссии понятны. Мое мнение — попытки оправадать подобный подход не более чем фанатизм который не позволяет правильно оценить выбор интрумента. Обсуждать тут больше не чего. Прелдагаю закрыть дискуссию.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.07 09:50
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Ну представь, что это не монады — они тут нужны только для сахара, чтобы запись была красивее.

L>По большому счёту это ФВП — с помощью набора комбинаторов мы создаём одну длинную функцию — это и есть парсер.

По любому счету ФВП есть почти в любом языке. Так что не надо разводить софистику. Монады — это черная магия непонятная никому кроме тех кто влюблен в Хаскель. И аргументировать хаками с монадами отсуствие необходимости в прямых и понятных средствах, на мой взгляд, просто бессмысленно. Если достаточно ФВП и там скажем замыканий, то флаг вам в руки. Покажите примеры на C# 3.0, скажем, или на Скале.

L>Монады тут совершенно не важны — они служат лишь для удобной связки этих комбинаторов.


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

Это товарищи господа — обычная предвзятость.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 13.09.07 10:02
Оценка:
Здравствуйте, lomeo, Вы писали:

Разрешите встрять?

L>Зачем делать на макросах то, что проще делается без них и для чего они не предназначены?


1. Хаскелевская работа с типами (по пути обобщения а не по пути сужения) ещё более "специфична", нежели генерация кода макрами — её (систему типов) в любой язык не вопрёшь.

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

3. Если данную конкретную задачу в данном языке проще решить без макр — да, макры не нужны. Но мы же не будем из данного утверждения делать необоснованные обобщения?

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

L>Если же задача стоит делать это именно компайл-тайм, то почему макросы здесь подходят лучше, чем зависимые типы (вернее, очень близкие к ним)?


Макры "здесь" никак не подходят, ибо их нет в Хаскеле (стандартном).

L>Тут есть два момента. Во-первых, сама по себе эта задача не очень то жизненная. Однако, её решение — наложение ограничений на типы и проверка этих ограничений — имеет смысл в практике. Это перенос части работы по проверке в компайл тайм — написание типов, в которых невозможно читать из закрытого файла, например, в которых невозможно написать фунцию сортировки коллекции, возвращающую неверно отсортированную коллекцию и прочие примеры из моего предыдущего поста.


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

L>Во-вторых, если взять язык с зависимыми типами вроде Омеги, то это решение будет выглядеть очень близко к исходному (рантайм) варианту, но при этом работать в компайл тайм на проверке типов. Просто потому что в языке есть удобный сахар + нужная типизация, что делает его очень выразительным — например, функции над типами пишутся практически так же как и обычные. Т.е. в этом случае макросы не нужны — и данная задача лишь подтверждает гипотезу EvilChild'а.


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

P.S. Ответ тем, кто захочет ограничить пространство решаемых задач наиболее часто встречающимися / "мэйнстримом" / собственным кругозором — Java у вас никто и не отбирает.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.07 10:36
Оценка:
Здравствуйте, lomeo, Вы писали:

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


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

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


Да считай все что угодно. Только не надо на базе своего мнения какие-то выводы делать, и темболее, такие-то теории обосновывать (вроде сабжевой).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.09.07 10:46
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>Разрешите встрять?


Буду только рад.

L>>Зачем делать на макросах то, что проще делается без них и для чего они не предназначены?


CU>1. Хаскелевская работа с типами (по пути обобщения а не по пути сужения) ещё более "специфична", нежели генерация кода макрами — её (систему типов) в любой язык не вопрёшь.


+1, но мы говорим о техниках вообще, а не о языках. Макросов вот тоже не везде есть.

CU>2. Макры просто генерят код. Не только для наложения ограничений на типы. Т.е. менее ограничены (не привязаны к типам, хотя есть языки, где макры могут типами пользоваться )


Ну да, макросы же более универсальны.

CU>3. Если данную конкретную задачу в данном языке проще решить без макр — да, макры не нужны. Но мы же не будем из данного утверждения делать необоснованные обобщения?


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

CU>Ещё раз: макры нужны для генерации кода вкупе с использованием всех возможностей базового языка. Если вам это не надо — макры вам не нужны. Но о чём тогда спор? О том, что отдельные задачи проще решать специально заточенным для этого инструментом? Да, но, к сожалению, пока ещё нет инструментов для всех задач (тем более для ещё неизвестных задач). Да и язык, который будет обладать всеми такими инструментами (и средствами для их дальнейшего построения) — но не макрами , трудно себе представить.


М-м-м. Кажется я понял, в чём у нас недопонимание. Для меня сабж — "является ли использование макросов для такой то задачи маркером того, что язык не обладает для этой задачи достаточно выразительными средствами", а не "является ли наличие макросов в языке свидетельством недостаточной выразительности этого языка вообще". В Хаскеле, например, макросы есть, только их очень мало используют. Я не скажу, что я сторонник этой гипотезы, например, для кодогенерации средства лучше не найдёшь. Но я и не противник — а может быть в каком нибудь языке и не нужна эта кодогенерация (пример с gmap).

L>>Если же задача стоит делать это именно компайл-тайм, то почему макросы здесь подходят лучше, чем зависимые типы (вернее, очень близкие к ним)?


CU>Макры "здесь" никак не подходят, ибо их нет в Хаскеле (стандартном).


Ну, это же философия, мы тут "вообще" говорим

CU>Это очень "частная" задача по сравнению с ничем неограниченным количеством задач, которые можно успешно решать с помощью кодогенерации.


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

CU>Таки буду утверждать: языка, который будет обладать частными средствами решения для всех частных задач, в том числе и для построения новых "частных" средств для вновь открывшихся задач — и всё это во время компиляции проекта (а не путём пересборки самого компилятора под конкретный набор задач), но не использующего макросистему — _не будет никогда_ (по определению).


Ни с одним утверждением не могу поспорить, но речь не о всех частных задачах. Мы говорили о статье. Влад привёл эту задачу, как пример, который надо решать на макросах. Остальные средства он назвал автогенами.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[29]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.09.07 10:53
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Ну представь, что это не монады — они тут нужны только для сахара, чтобы запись была красивее.

L>>По большому счёту это ФВП — с помощью набора комбинаторов мы создаём одну длинную функцию — это и есть парсер.

VD>По любому счету ФВП есть почти в любом языке. Так что не надо разводить софистику. Монады — это черная магия непонятная никому кроме тех кто влюблен в Хаскель. И аргументировать хаками с монадами отсуствие необходимости в прямых и понятных средствах, на мой взгляд, просто бессмысленно. Если достаточно ФВП и там скажем замыканий, то флаг вам в руки. Покажите примеры на C# 3.0, скажем, или на Скале.


Примеры чего? Парсека? Зачем мне его показывать на шарпе не пойму — чтобы доказать, что монады в парсеке не нужны? Или что? Ты чего хочешь понять/узнать/прояснить?

L>>Монады тут совершенно не важны — они служат лишь для удобной связки этих комбинаторов.


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


VD>Это товарищи господа — обычная предвзятость.


Согласен.

Трехэтажная ахинея на системе типов — плохо
Загадочные манадные навороты приводящие к тормозам и тратам памяти — плохо
прямое и понятно решение на маросах — хорошо

С другой стороны

Грамотно спроектированное решение на системе типов — хорошо
Прозрачные монадные решения, не приводящие к тормозам и тратам памяти — хорошо
Кривое и невнятное решение на макросах — плохо

Как с тобой нелегко — ты говоришь, говоришь, вроде всё понятно, и спорить то не о чём, а что сказать то хотел — непонятно. Остаётся только пожать плечами.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.09.07 10:53
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

VD>Да считай все что угодно.


Симметрично.

VD>Только не надо на базе своего мнения какие-то выводы делать, и темболее, такие-то теории обосновывать (вроде сабжевой).


А то что?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.09.07 12:21
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Более мощная система типов позволяет вынести больше ошибок из рантайма в компиляцию.


VD>Это домыслы. А вто то, что с ее помощью можно сделать больше ошибок — это факт.


И чем ты можешь этот факт подтвердить?
Я вот смои домыслы могу подвердить отсылкой к dependent types, предназначенных именно для уже неоднократно перечисленных мной примеров.

L>> Что в этом ужасного, если она для этого и предназначается?


VD>Ужасно использование вещей не по назначению. Система типов предназначена для описания типов. А молоток для забивания гвоздей.


Что есть описание типов, как не расстановка ограничений на их значения? Если мы в функции, которая по сигнатуре должна приниматься тип A передаём тип B — компилятор бьёт нам по рукам. Или если в функции, которая должна принимать два списка одинаковой длины, принимает списки разной длины — компилятор тоже бьёт нам по рукам.

Чем одно ограничение отличается от другого? Почему первое можно, а второе нет?

Просто в некоторых системах можно задавать тип — "список длины n", "список длины m", "список длины n+m". А в некоторых — нет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.07 14:40
Оценка:
Здравствуйте, lomeo, Вы писали:

L>И чем ты можешь этот факт подтвердить?


А вот тут как раз есть форум по С++. Посмотри сколько траха с МП на шаблонах. Посмотри во что превратился Буст и т.п. А С++ действительно имеет более удобную для МП систему типов (допускающую целочисленные параметры в шаблонах).

L>Я вот смои домыслы могу подвердить отсылкой к dependent types, предназначенных именно для уже неоднократно перечисленных мной примеров.


Ты лучше сам этоти проповеди читай. Я как-то не проникаюсь.

VD>>Ужасно использование вещей не по назначению. Система типов предназначена для описания типов. А молоток для забивания гвоздей.


L>Что есть описание типов, как не расстановка ограничений на их значения? Если мы в функции, которая по сигнатуре должна приниматься тип A передаём тип B — компилятор бьёт нам по рукам. Или если в функции, которая должна принимать два списка одинаковой длины, принимает списки разной длины — компилятор тоже бьёт нам по рукам.


L>Чем одно ограничение отличается от другого? Почему первое можно, а второе нет?


L>Просто в некоторых системах можно задавать тип — "список длины n", "список длины m", "список длины n+m". А в некоторых — нет.


А причем тут это? Используй эти удивительные возможности по назначению и никто тебе ни слова не скажет. А вот когда ты начинашь на типах списки времени компиляции эмулировать и вывертывать фунции вроде MapAppend, то извини, но это уже не ограничение на типы, а исползование побочного эффекта. Ты перестаешь использовать систему типов для описания типов. Ты уже описываешь код на языке который родился как побочный эффект от усиления системы типов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.07 14:40
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Свершилось твоё превращение в сторонника динамической типизации?


Агащазблин. Читай внимательнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[56]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.07 14:40
Оценка:
Здравствуйте, AndrewVK, Вы писали:

.>> Для какого экземляра A будут вызываться Foo/Bar из Find?


AVK>У Foo и Bar надо дописать static.


И, наверно, еще this к первому параметру. Плюс сам первый параметр.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[55]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.09.07 14:40
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


Дык в чем проблема? Отключи макросы которые написали индусы.

IT>>Но по сути это же просто обыкновенная затычка. Теперь оказывается нужно не только компилятор запускать, но ещё перед ним не забыть запустить инспектор.

C>А ты не забываешь запустить компиляцию перед запуском приложения?

А, что, это возможно? Вот EDI возможно. Например, в ночной сборке...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 13.09.07 15:03
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>Ок, так конкретнее. Но даже в таком варианте всё зависит от характера задачи. И к тому-же в языках, имеющих встроенные макросистемы, различные "встроенные" инструкции создаются именно на макрах — ибо зачем для одного и того-же иметь два инструмента?

А реально имея относительно минимальный набор (АлТД, ФВП в общем то, что есть в Standard ML) в статически типизированном языке и макросы докурутить всё остальное — type classes, fundeps,...?
now playing: The Streets — It’s Too Late
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.09.07 15:25
Оценка:
Здравствуйте, EvilChild, Вы писали:

CU>>Ок, так конкретнее. Но даже в таком варианте всё зависит от характера задачи. И к тому-же в языках, имеющих встроенные макросистемы, различные "встроенные" инструкции создаются именно на макрах — ибо зачем для одного и того-же иметь два инструмента?


EC>А реально имея относительно минимальный набор (АлТД, ФВП в общем то, что есть в Standard ML) в статически типизированном языке и макросы докурутить всё остальное — type classes, fundeps,...?


С помощью макросов?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 13.09.07 15:27
Оценка:
Здравствуйте, lomeo, Вы писали:

L>С помощью макросов?

Ага. Т.е. расширять систему типов.
now playing: Mathew Jonson — Stop
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 14.09.07 05:46
Оценка:
Здравствуйте, jazzer, Вы писали:

L>>Оффтопик: целочисленные параметры в шаблонах — это, конечно, здорово, а над этими параметрами можно проводить стандартные операции над целыми числами для генерации нового типа?


J>В смысле? поясни на примере, что ты хочешь получить. Но скорее всего ответ — можно.

J>Например, из того, что пришло в голову навскидку

Да, это то, что я имел в виду
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[46]: Являются ли макросы свидетельством недостаточной выр
От:  
Дата: 14.09.07 07:18
Оценка:
Hello, VladD2!
You wrote on Tue, 11 Sep 2007 12:08:13 GMT:

C>> Почему-то, .NET-программисты страдают "туннельным видением" -

C>> все не-MS-технологии они просто не замечают. Удобные mapper'ы в
C>> виде iBatis'а и Hibernate работают в Java уже который год. И
C>> ничего, никакой LINQ не нужен.

V> А каким видением страдают ява-программисты, что незамечают, что

V> море народу засовывает в задницу Кибернэйты и начинает
V> использовать Руби на Рельсах, где мапер проще, но удобнее?

Какое к черту море?? Они просто кричат очень громко.
Posted via RSDN NNTP Server 2.1 beta
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 14.09.07 07:54
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>А реально имея относительно минимальный набор (АлТД, ФВП в общем то, что есть в Standard ML) в статически типизированном языке и макросы докурутить всё остальное — type classes, fundeps,...?


Смотря что скрывается под термином "реально"
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: EvilChild Ниоткуда  
Дата: 14.09.07 08:12
Оценка:
Здравствуйте, cl-user, Вы писали:

EC>>А реально имея относительно минимальный набор (АлТД, ФВП в общем то, что есть в Standard ML) в статически типизированном языке и макросы докурутить всё остальное — type classes, fundeps,...?


CU>Смотря что скрывается под термином "реально"


Возможно ли в принципе? И если да, что насколько трудоёмко?
now playing: Alexander Kowalski — Your Affection
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: cl-user  
Дата: 14.09.07 09:50
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>>>А реально имея относительно минимальный набор (АлТД, ФВП в общем то, что есть в Standard ML) в статически типизированном языке и макросы докурутить всё остальное — type classes, fundeps,...?


CU>>Смотря что скрывается под термином "реально"


EC>Возможно ли в принципе? И если да, что насколько трудоёмко?


Хм, трудно себе представить неразрешимую в принципе задачу, если только её определение не содержит противоречий

С трудоёмкостью сложнее. Я лишь поверхностно знаком с p4 для ocaml (и это не Standart ML) и p4 таки "рядом" а не "в" ocaml. Это с одной стороны. С другой — макры это _только_ кодогенерация. Т.е. если вы представляете как реализовать необходимые вам "фичи" на базовом языке — макры вам помогут. Если нет...
Re[47]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.09.07 10:02
Оценка:
Здравствуйте, YК, Вы писали:

V>> А каким видением страдают ява-программисты, что незамечают, что

V>> море народу засовывает в задницу Кибернэйты и начинает
V>> использовать Руби на Рельсах, где мапер проще, но удобнее?

YК>Какое к черту море?? Они просто кричат очень громко.


Это еще одно подтверждение тунельного зрения?

Понимаеш ли... кричать можно, ну месяц, ну пол года... а про Рельсы кричат уже пару лет. Значит все же что-то в этом есть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.09.07 10:02
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>А вот тут как раз есть форум по С++. Посмотри сколько траха с МП на шаблонах. Посмотри во что превратился Буст и т.п. А С++ действительно имеет более удобную для МП систему типов (допускающую целочисленные параметры в шаблонах).


L>При чём тут С++?


При том, что он обладает более подходящей для МП системой типов, но все равно МП-код получается ужасным и вызвает море проблем.

L>Оффтопик: целочисленные параметры в шаблонах — это, конечно, здорово, а над этими параметрами можно проводить стандартные операции над целыми числами для генерации нового типа?


Да.

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


Я занаю достаточно. Все остальное оставим на твоей совести (хотя это п. 5 в чистом виде).

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


Не надо мне компостировать мозг. Я не против сильной системы типов. Я против попыток программирования на ней. И уж темболее мне не неравится когда это программирвоание выдается за крутость системы типов. Это совсем друго — убогость основного языка и извороты чтобы их обойти.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.09.07 10:44
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>А реально имея относительно минимальный набор (АлТД, ФВП в общем то, что есть в Standard ML) в статически типизированном языке и макросы докурутить всё остальное — type classes, fundeps,...?


В Лиспе так и сделали. В прочем классы типов такая базовая вещь, что разумно ее реализовывать в языке. А вот разные gmap однозначно надо было делать макросами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Являются ли макросы свидетельством недостаточной выр
От:  
Дата: 14.09.07 10:45
Оценка:
Hello, VladD2!
You wrote on Fri, 14 Sep 2007 10:02:22 GMT:

V>>> А каким видением страдают ява-программисты, что незамечают, что

V>>> море народу засовывает в задницу Кибернэйты и начинает
V>>> использовать Руби на Рельсах, где мапер проще, но удобнее?

YК>> Какое к черту море?? Они просто кричат очень громко.


V> Это еще одно подтверждение тунельного зрения?


V> Понимаеш ли... кричать можно, ну месяц, ну пол года... а про

V> Рельсы кричат уже пару лет. Значит все же что-то в этом есть.

Потрясающая компетентность и аргументация. Слышал звон..
Член с пальцем не надо сравнивать.
Posted via RSDN NNTP Server 2.1 beta
Re[32]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.09.07 12:59
Оценка:
Здравствуйте, mkizub, Вы писали:

M>А вот и не угадал.

M>Если нам компилятор/язык гарантирует, что данный метод будет заинлайнен — то это те-же макросы, вид сбоку.
M>Спрашивается, нафига козе баян? Если в N уже есть макросы, более мощные чем инлайн-функции — нафига делать через инлайн, а не макросы?!

Разница в том, что писать макрос на каждый чих банально тяжело. А вот если компилятор автоматически оптимизирует код и породит из хитрого замыкания плоский и быстрый код, то я смогу пользоваться очень удобной абстракцией не латя за это ничего. В итоге атоматически я получаю программы не уступающие в производительности аналогичным написанным на С/С++/ассеблере, но при этом трачу на них в разы меньше усилий.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.09.07 12:59
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Речь зашла о том, что foreach в N можно сделать в виде closures, и инлайнинге метода foreach.


Кстати, прикольно, что в Немерле foreach это макрос который переписывает С-подобный код в код основанный на рекурсивном вызове локального метода. Любое обращение к переменным в теле цикла автоматически превращается функцию в замыкание. По этому в Немерле рекурсивная фунция может оказаться несколько быстрее чем аналог написанный на for-е или foreach-е. Вот только разница столь мала, что ее в большинстве случаев и в микроскоп не увидишь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.09.07 12:59
Оценка:
Здравствуйте, YК, Вы писали:

YК>Потрясающая компетентность и аргументация. Слышал звон..

YК>Член с пальцем не надо сравнивать.

Научишся общаться, подходи пообщаемся. А пока, пока.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.