Здравствуйте, 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]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
L>>Ну представь, что это не монады — они тут нужны только для сахара, чтобы запись была красивее. L>>По большому счёту это ФВП — с помощью набора комбинаторов мы создаём одну длинную функцию — это и есть парсер.
VD>По любому счету ФВП есть почти в любом языке. Так что не надо разводить софистику. Монады — это черная магия непонятная никому кроме тех кто влюблен в Хаскель. И аргументировать хаками с монадами отсуствие необходимости в прямых и понятных средствах, на мой взгляд, просто бессмысленно. Если достаточно ФВП и там скажем замыканий, то флаг вам в руки. Покажите примеры на C# 3.0, скажем, или на Скале.
Примеры чего? Парсека? Зачем мне его показывать на шарпе не пойму — чтобы доказать, что монады в парсеке не нужны? Или что? Ты чего хочешь понять/узнать/прояснить?
L>>Монады тут совершенно не важны — они служат лишь для удобной связки этих комбинаторов.
VD>Да, конечно, конечно. Вообще ничего не важно. Трехэтажная ахинея на системе типов — это нормально. А макросы решающие туже задач прямо и просто — это зло. Загадочные манадные навороты приводящие к тормозам и тратам памяти — это хорошо, а прямое и понятно решение на маросах — это опять таки зло.
VD>Это товарищи господа — обычная предвзятость.
Согласен.
Трехэтажная ахинея на системе типов — плохо
Загадочные манадные навороты приводящие к тормозам и тратам памяти — плохо
прямое и понятно решение на маросах — хорошо
С другой стороны
Грамотно спроектированное решение на системе типов — хорошо
Прозрачные монадные решения, не приводящие к тормозам и тратам памяти — хорошо
Кривое и невнятное решение на макросах — плохо
Как с тобой нелегко — ты говоришь, говоришь, вроде всё понятно, и спорить то не о чём, а что сказать то хотел — непонятно. Остаётся только пожать плечами.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Некошерно — это не то слово. Правильное слово будет — "ужасно". В прочем, это слишком мягкое слово. Но в пределах цензурных выражений инчего лучше пока подобрать не могу.
Более мощная система типов позволяет вынести больше ошибок из рантайма в компиляцию. Что в этом ужасного, если она для этого и предназначается?
VD>Да считай все что угодно.
Симметрично.
VD>Только не надо на базе своего мнения какие-то выводы делать, и темболее, такие-то теории обосновывать (вроде сабжевой).
А то что?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[30]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, VladD2, Вы писали:
VD>>По любому счету ФВП есть почти в любом языке. Так что не надо разводить софистику. Монады — это черная магия непонятная никому кроме тех кто влюблен в Хаскель. И аргументировать хаками с монадами отсуствие необходимости в прямых и понятных средствах, на мой взгляд, просто бессмысленно. Если достаточно ФВП и там скажем замыканий, то флаг вам в руки. Покажите примеры на C# 3.0, скажем, или на Скале.
L>Примеры чего? Парсека? Зачем мне его показывать на шарпе не пойму — чтобы доказать, что монады в парсеке не нужны? Или что? Ты чего хочешь понять/узнать/прояснить?
Кстати, вот Mirrorer кинул тут на днях ссылку — не совсем парсек, конечно, но рядом с этим (и на шарпе).
Re[31]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>М-м-м. Кажется я понял, в чём у нас недопонимание. Для меня сабж — "является ли использование макросов для такой то задачи маркером того, что язык не обладает для этой задачи достаточно выразительными средствами", а не "является ли наличие макросов в языке свидетельством недостаточной выразительности этого языка вообще".
Ок, так конкретнее. Но даже в таком варианте всё зависит от характера задачи. И к тому-же в языках, имеющих встроенные макросистемы, различные "встроенные" инструкции создаются именно на макрах — ибо зачем для одного и того-же иметь два инструмента? Не повод же это утверждать, что у них компилятор "недоделанный" Так что без конкретики сабж не проходит ни в каком варианте
L>В Хаскеле, например, макросы есть, только их очень мало используют. Я не скажу, что я сторонник этой гипотезы, например, для кодогенерации средства лучше не найдёшь. Но я и не противник — а может быть в каком нибудь языке и не нужна эта кодогенерация (пример с gmap).
Кодогенерация "не нужна" не в языке, а для определённых задач (или нужна для определённых задач). А в Хаскеле макры мало используют скорее всего потому, что он сам по себе довольно лаконичен и "засахарен", и макры таки в нём "сбоку", а не "внутри".
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
L>>Более мощная система типов позволяет вынести больше ошибок из рантайма в компиляцию.
VD>Это домыслы. А вто то, что с ее помощью можно сделать больше ошибок — это факт.
И чем ты можешь этот факт подтвердить?
Я вот смои домыслы могу подвердить отсылкой к dependent types, предназначенных именно для уже неоднократно перечисленных мной примеров.
L>> Что в этом ужасного, если она для этого и предназначается?
VD>Ужасно использование вещей не по назначению. Система типов предназначена для описания типов. А молоток для забивания гвоздей.
Что есть описание типов, как не расстановка ограничений на их значения? Если мы в функции, которая по сигнатуре должна приниматься тип A передаём тип B — компилятор бьёт нам по рукам. Или если в функции, которая должна принимать два списка одинаковой длины, принимает списки разной длины — компилятор тоже бьёт нам по рукам.
Чем одно ограничение отличается от другого? Почему первое можно, а второе нет?
Просто в некоторых системах можно задавать тип — "список длины n", "список длины m", "список длины n+m". А в некоторых — нет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
L>>Более мощная система типов позволяет вынести больше ошибок из рантайма в компиляцию.
VD>Это домыслы. А вто то, что с ее помощью можно сделать больше ошибок — это факт.
Свершилось твоё превращение в сторонника динамической типизации?
Здравствуйте, 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]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Cyberax, Вы писали:
C>Потому как я не хочу разбираться с тем, что наделали индусы, дорвавшиеся до макросов. Если им захочется написать свою инспекцию — пожалуйста, нет проблем. Я ее просто у себя отключу, если мне захочется.
Дык в чем проблема? Отключи макросы которые написали индусы.
IT>>Но по сути это же просто обыкновенная затычка. Теперь оказывается нужно не только компилятор запускать, но ещё перед ним не забыть запустить инспектор. C>А ты не забываешь запустить компиляцию перед запуском приложения?
А, что, это возможно? Вот EDI возможно. Например, в ночной сборке...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[47]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, cl-user, Вы писали:
CU>Ок, так конкретнее. Но даже в таком варианте всё зависит от характера задачи. И к тому-же в языках, имеющих встроенные макросистемы, различные "встроенные" инструкции создаются именно на макрах — ибо зачем для одного и того-же иметь два инструмента?
А реально имея относительно минимальный набор (АлТД, ФВП в общем то, что есть в Standard ML) в статически типизированном языке и макросы докурутить всё остальное — type classes, fundeps,...?
now playing: The Streets — It’s Too Late
Re[18]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>А вот тут как раз есть форум по С++. Посмотри сколько траха с МП на шаблонах. Посмотри во что превратился Буст и т.п. А С++ действительно имеет более удобную для МП систему типов (допускающую целочисленные параметры в шаблонах).
При чём тут С++?
Оффтопик: целочисленные параметры в шаблонах — это, конечно, здорово, а над этими параметрами можно проводить стандартные операции над целыми числами для генерации нового типа?
L>>Я вот смои домыслы могу подвердить отсылкой к dependent types, предназначенных именно для уже неоднократно перечисленных мной примеров.
VD>Ты лучше сам этоти проповеди читай. Я как-то не проникаюсь.
Это называется воинствующее невежество — делать безапелляционные заявления по теме, о которой даже знать ничего не хочешь.
То, что ты называешь статической типизацией всего лишь часть более мощной системы, позволяющей задавать ещё больше ограничений, причём более универсальным способом — чем это может быть вредно, не понимаю.
L>>Просто в некоторых системах можно задавать тип — "список длины n", "список длины m", "список длины n+m". А в некоторых — нет.
VD>А причем тут это? Используй эти удивительные возможности по назначению и никто тебе ни слова не скажет. А вот когда ты начинашь на типах списки времени компиляции эмулировать и вывертывать фунции вроде MapAppend, то извини, но это уже не ограничение на типы, а исползование побочного эффекта. Ты перестаешь использовать систему типов для описания типов. Ты уже описываешь код на языке который родился как побочный эффект от усиления системы типов.
В некоторых системах для описания типов используется тот же язык, что и основной, т.е. мы можем, например, писать функции над типами. Например, MapAppend
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, EvilChild, Вы писали:
CU>>Ок, так конкретнее. Но даже в таком варианте всё зависит от характера задачи. И к тому-же в языках, имеющих встроенные макросистемы, различные "встроенные" инструкции создаются именно на макрах — ибо зачем для одного и того-же иметь два инструмента?
EC>А реально имея относительно минимальный набор (АлТД, ФВП в общем то, что есть в Standard ML) в статически типизированном языке и макросы докурутить всё остальное — type classes, fundeps,...?
С помощью макросов?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, 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); // не скомпилируется
Здравствуйте, lomeo, Вы писали: L>Оффтопик: целочисленные параметры в шаблонах — это, конечно, здорово, а над этими параметрами можно проводить стандартные операции над целыми числами для генерации нового типа?
Ну конечно же можно. И проводят — только в путь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
)
