Здравствуйте, FR, Вы писали:
FR>Рано, сначало надо узнать что он думает про этот симптом у поклоников Немерли
Дык в процессе больбы с оным свойством мы и пришли к Немерле. Мы отдаем себе отчет в том, что Немерле не идеал, но по сравнению с Шарпом и Явой это рельный (и не малый) шаг вперед и при этом он не являтся игрушками ученого мира, а вполне может прменяться в тех задачах где используются Ява и Шарп.
Мы как раз и отличаемся тем, что отсуствующие фичи мы воспринимаем адекватно. Макросы и открытый компилятор позволяют хотя бы надеяться на то, что нужные фичи появятся в языке.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Andrei F., Вы писали:
C>>Феникс вообще пока умер. Есть еще RAILS — но они тоже как-то присмерти. AF>Почему умер? Последний RDK вроде за март этого года.
Даже лучше, в Июле выложили Microsoft Phoenix SDK Pre-release July 2007
Never underestimate those behind you...
Re[47]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, mkizub, Вы писали:
M>Никакий "различной реализации" для шаблонов я не вижу. Параметризация (что и служит для инстантиирования типа из шаблона) за полиморфизм, IMHO, не канает.
Почитай что-нть про специализацию и про частичную специализацию.
Здравствуйте, BulatZiganshin, Вы писали:
L>>gmap может создать любой смертный. Средствами по мне более простыми нежели макросы.
BZ>с интеллектом в 1000 миллиОлегов как раз syb4.hs, ссылку на который я давал — это реализаций generic программирования в compile time , которую не сможет понять ни один смертный
Оставь, пожалуйста syb4 может быть, а вот ту реализацию gmap что я давал — очень даже запросто.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, 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, Вы писали:
L>Как это сделать на макросах?
Зачем делать на макросах то для чего они не предназначены? Это так же глупо как делать не на макросах то, что проще или понятнее/логичнее делается на макросах.
Здравствуйте, lomeo, Вы писали:
BZ>>а по-моему, RULES — это частный случай макросов, нацеленный на решение одной конкретной задачи. кстати, TH для оптимизации кода тоже использовали. при этом с одной стороны возможности RULES очень ограничены, с другой — их писать гораздо-гораздо проще, чем аналогичное решение с помощью TH. универсальность против удобства использования.
L>Может быть, но это уже философский спор о терминах
Не может быть, а точно. Вернее так: RULES — это частное средство метапрограммирования котрое может быть воспроизведено средствами макросов — более универсального средства метапрограммирования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, 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]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, BulatZiganshin, Вы писали:
M>>Да не в ООП!!! В принципе полиморфизма это. Может ты не видишь разницы, но больше мне добавить нечего.
BZ>я как раз вижу templates — это по твоему не полиморфизм?
Плдиморфизм бывает разный. Бывает статически, бывает динамический, а бывает утиный. Так вот несомненно без динамики вообще жить нельзя. И несомнено на есть (не может не быть) и в ООП и в ФП. И так же несомненно, что статической типизации это не отменяет. Как несомненно, что динамический полиморфизм делает решения более гибкими.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
BZ>>типы в ООП динамические.
G>Вась, ты не мог бы дать определение термина "динамический тип", и чем он отличается от "статического типа"? Я всегда, понимаешь, держу руку на пульсе и открыт свежим веяниям в computer science. Есть у меня предположения, что ты говоришь о старых добрых "полиморфных переменных"
Сдается мне, что речь идет о том, что во время компиляции зачастую доступен только абстрактный тип вроде базового класса или интерфейса, а в рантайме это может быть ссылкой на любой объект который всилах поддерживать данный интерфейс.
При этом статическим типом можно считать этот интерфейс, а динамическим — фактический тип объекта. Это хорошо видно в отладчиках.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>Не совсем так. Не текстом программы. Я и в динамическом языке могу во многих случаях тип вывести из контекста употребления. Разница в том, как семантика языка трактует ошибку типа — может ли она у меня во время выполнения выскочить, или это невозможно в принципе.
Ошибка типов может выскачить в С++, C#, Java, VB.NET и т.п. Это не значит, что это не статически типизированные языки. Как совершенно не важно есть ли прибмбасы для частичного вывода типов. Важно скорее другое. Рассчитан ли язык на то чтобы на нем можно было написать программу которая вообще не содержит мест способных вызвать ошибку типов в рантайме. Вот это для С++, C#, Java, VB.NET верно. Хотя и сложно осуществимо... порой...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Cyberax, Вы писали:
C>Почему-то, .NET-программисты страдают "туннельным видением" — все не-MS-технологии они просто не замечают. Удобные mapper'ы в виде iBatis'а и Hibernate работают в Java уже который год. И ничего, никакой LINQ не нужен.
А каким видением страдают ява-программисты, что незамечают, что море народу засовывает в задницу Кибернэйты и начинает использовать Руби на Рельсах, где мапер проще, но удобнее?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Зачем делать на макросах то для чего они не предназначены? Это так же глупо как делать не на макросах то, что проще или понятнее/логичнее делается на макросах.
VD>Примеры? Их посовывает сама жизнь: [Haskell] Метопрограммирование на типах
Зачем делать на макросах то, что проще делается без них и для чего они не предназначены?
Если же задача стоит делать это именно компайл-тайм, то почему макросы здесь подходят лучше, чем зависимые типы (вернее, очень близкие к ним)?
Тут есть два момента. Во-первых, сама по себе эта задача не очень то жизненная. Однако, её решение — наложение ограничений на типы и проверка этих ограничений — имеет смысл в практике. Это перенос части работы по проверке в компайл тайм — написание типов, в которых невозможно читать из закрытого файла, например, в которых невозможно написать фунцию сортировки коллекции, возвращающую неверно отсортированную коллекцию и прочие примеры из моего предыдущего поста.
Во-вторых, если взять язык с зависимыми типами вроде Омеги, то это решение будет выглядеть очень близко к исходному (рантайм) варианту, но при этом работать в компайл тайм на проверке типов. Просто потому что в языке есть удобный сахар + нужная типизация, что делает его очень выразительным — например, функции над типами пишутся практически так же как и обычные. Т.е. в этом случае макросы не нужны — и данная задача лишь подтверждает гипотезу EvilChild'а.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[27]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Дык, проблема в том, что это не меньшая магия чем макросы. Точнее даже куда большая.
Ну представь, что это не монады — они тут нужны только для сахара, чтобы запись была красивее.
По большому счёту это ФВП — с помощью набора комбинаторов мы создаём одну длинную функцию — это и есть парсер.
Монады тут совершенно не важны — они служат лишь для удобной связки этих комбинаторов.
ФВП тебе как? Меньшая магия, чем макросы или большая?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Являются ли макросы свидетельством недостаточной выр
L>Зачем делать на макросах то, что проще делается без них и для чего они не предназначены?
Незачем. Как незачем делать обратное. Вот пример обратного и находится по этой ссылке.
L>Если же задача стоит делать это именно компайл-тайм, то почему макросы здесь подходят лучше, чем зависимые типы (вернее, очень близкие к ним)?
Птому, что они позяоляют решать задачу, а не терять время почем зря.
Если кто-то этого не понимает, то пусть пребывает в своем заблуждении сколько угодно.
L>Тут есть два момента. Во-первых, сама по себе эта задача не очень то жизненная. Однако, её решение — наложение ограничений на типы и проверка этих ограничений — имеет смысл в практике.
Задача конечно бессмысленная. Но это банальное, не тривиальное вычисление в компайлтайме. А в этом смысл на практие сплошь и рядом.
L> Это перенос части работы по проверке в компайл тайм — написание типов, в которых невозможно читать из закрытого файла, например, в которых невозможно написать фунцию сортировки коллекции, возвращающую неверно отсортированную коллекцию и прочие примеры из моего предыдущего поста.
Я не понял. И что? Это пример безграмотного подхода к решению проблемы — выбора не соответствующего интсрумента. То что этот инструмет к тому же сильно ограничен не более чем частности.
L>Во-вторых, если взять язык с зависимыми типами вроде Омеги, то это решение будет выглядеть очень близко к исходному (рантайм) варианту
А зачем нужно "очень близкое к исходному решение" если есть "полностью аналогичное"?
Зачем вставлять в зад горелку от автогена когда можно просто удалять гланды через рот?
Ладно. Это музыка будет вечна, если вдруг с дури заменить батерейки. Позиции всех участников дискуссии понятны. Мое мнение — попытки оправадать подобный подход не более чем фанатизм который не позволяет правильно оценить выбор интрумента. Обсуждать тут больше не чего. Прелдагаю закрыть дискуссию.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Ну представь, что это не монады — они тут нужны только для сахара, чтобы запись была красивее. L>По большому счёту это ФВП — с помощью набора комбинаторов мы создаём одну длинную функцию — это и есть парсер.
По любому счету ФВП есть почти в любом языке. Так что не надо разводить софистику. Монады — это черная магия непонятная никому кроме тех кто влюблен в Хаскель. И аргументировать хаками с монадами отсуствие необходимости в прямых и понятных средствах, на мой взгляд, просто бессмысленно. Если достаточно ФВП и там скажем замыканий, то флаг вам в руки. Покажите примеры на C# 3.0, скажем, или на Скале.
L>Монады тут совершенно не важны — они служат лишь для удобной связки этих комбинаторов.
Да, конечно, конечно. Вообще ничего не важно. Трехэтажная ахинея на системе типов — это нормально. А макросы решающие туже задач прямо и просто — это зло. Загадочные манадные навороты приводящие к тормозам и тратам памяти — это хорошо, а прямое и понятно решение на маросах — это опять таки зло.
Это товарищи господа — обычная предвзятость.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Ладно. Это музыка будет вечна, если вдруг с дури заменить батерейки. Позиции всех участников дискуссии понятны. Мое мнение — попытки оправадать подобный подход не более чем фанатизм который не позволяет правильно оценить выбор интрумента. Обсуждать тут больше не чего. Прелдагаю закрыть дискуссию.
Мы с тобой по разному смотрим на эту статью. Для тебя это безграмотное решение практической задачи, для меня демонстрация некоторых приёмов при программировании на типах. Или программирование на типах тоже некошерно?
Что касается самой задачи, то её решение что на типах, что на макросах считаю одинаково неправильным. Эта задачка для простого скрипта, какие могут быть практические соображения, чтобы писать её решение в компайл тайм, не понимаю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Являются ли макросы свидетельством недостаточной выр
Разрешите встрять?
L>Зачем делать на макросах то, что проще делается без них и для чего они не предназначены?
1. Хаскелевская работа с типами (по пути обобщения а не по пути сужения) ещё более "специфична", нежели генерация кода макрами — её (систему типов) в любой язык не вопрёшь.
2. Макры просто генерят код. Не только для наложения ограничений на типы. Т.е. менее ограничены (не привязаны к типам, хотя есть языки, где макры могут типами пользоваться )
3. Если данную конкретную задачу в данном языке проще решить без макр — да, макры не нужны. Но мы же не будем из данного утверждения делать необоснованные обобщения?
Ещё раз: макры нужны для генерации кода вкупе с использованием всех возможностей базового языка. Если вам это не надо — макры вам не нужны. Но о чём тогда спор? О том, что отдельные задачи проще решать специально заточенным для этого инструментом? Да, но, к сожалению, пока ещё нет инструментов для всех задач (тем более для ещё неизвестных задач). Да и язык, который будет обладать всеми такими инструментами (и средствами для их дальнейшего построения) — но не макрами , трудно себе представить.
L>Если же задача стоит делать это именно компайл-тайм, то почему макросы здесь подходят лучше, чем зависимые типы (вернее, очень близкие к ним)?
Макры "здесь" никак не подходят, ибо их нет в Хаскеле (стандартном).
L>Тут есть два момента. Во-первых, сама по себе эта задача не очень то жизненная. Однако, её решение — наложение ограничений на типы и проверка этих ограничений — имеет смысл в практике. Это перенос части работы по проверке в компайл тайм — написание типов, в которых невозможно читать из закрытого файла, например, в которых невозможно написать фунцию сортировки коллекции, возвращающую неверно отсортированную коллекцию и прочие примеры из моего предыдущего поста.
Это очень "частная" задача по сравнению с ничем неограниченным количеством задач, которые можно успешно решать с помощью кодогенерации.
L>Во-вторых, если взять язык с зависимыми типами вроде Омеги, то это решение будет выглядеть очень близко к исходному (рантайм) варианту, но при этом работать в компайл тайм на проверке типов. Просто потому что в языке есть удобный сахар + нужная типизация, что делает его очень выразительным — например, функции над типами пишутся практически так же как и обычные. Т.е. в этом случае макросы не нужны — и данная задача лишь подтверждает гипотезу EvilChild'а.
Таки буду утверждать: языка, который будет обладать частными средствами решения для всех частных задач, в том числе и для построения новых "частных" средств для вновь открывшихся задач — и всё это во время компиляции проекта (а не путём пересборки самого компилятора под конкретный набор задач), но не использующего макросистему — _не будет никогда_ (по определению).
P.S. Ответ тем, кто захочет ограничить пространство решаемых задач наиболее часто встречающимися / "мэйнстримом" / собственным кругозором — Java у вас никто и не отбирает.
Re[13]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Мы с тобой по разному смотрим на эту статью. Для тебя это безграмотное решение практической задачи, для меня демонстрация некоторых приёмов при программировании на типах. Или программирование на типах тоже некошерно?
Некошерно — это не то слово. Правильное слово будет — "ужасно". В прочем, это слишком мягкое слово. Но в пределах цензурных выражений инчего лучше пока подобрать не могу.
L>Что касается самой задачи, то её решение что на типах, что на макросах считаю одинаково неправильным. Эта задачка для простого скрипта, какие могут быть практические соображения, чтобы писать её решение в компайл тайм, не понимаю.
Да считай все что угодно. Только не надо на базе своего мнения какие-то выводы делать, и темболее, такие-то теории обосновывать (вроде сабжевой).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
как раз syb4.hs, ссылку на который я давал — это реализаций generic программирования в compile time , которую не сможет понять ни один смертный 
.
Прелдагаю закрыть дискуссию.
