LINUX.ORG.RU

[haskell] есть ли что-то типа reflection? (недемократизм языка?)

 


0

0

Обычная фраза: deriving (Read, Show, Eq, Ord)

Компилятор умеет выводить инстансы этих typeclass-ов. А что делать, если хочется их выводить чуть-чуть по-другому или добавить еще один, который автоматически бы выводился? (Для этого, возможно, подошло что-то похожее на reflection, патчить компилятор не предлагайте)

__________________________________________________

Недемократизм языка в моем понимании -- это

1. Частичная реализация некой фичи и одновременно отстутствие инструмента для расширения реализации этой фичи. Например в яве оператор + для сложения целых, вещественных, строк и все: комплексные, кватернионы, вектора, матрицы... складывай уже через add.

2. Невозможность смены конкретной реализации фичи (зачастую связано с п.1). Например, невозможность создать в рамках с++ свой virtual dispatch (для того, что сделать множественный virtual dispatch, т.е. п.1). В принципе, п.2 до некоторой степени неизбежен, так как иногда намного проще сделать фичу, чем API для написания фич).

__________________________________________________

Более глобальный вопрос -- а насколько хаскель демократичен? (для обеспечения демократизма разрешается использовать ключи компилятора, template haskell, ...)

Ответ на: комментарий от www_linux_org_ru

Не смог странслировать 20 строк из хаскеля на с++, и после этого с высокой колокольни плюешь на мнение специалистов CS об этом c++.

// FIXED

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от Miguel

>Нет. Это такое распространённое заблуждение.

Они определяются как функции нескольких аргументов. И частичное применение ничего не меняет в данном случае, f [a b] и f a b ( или как там правильно) являются разными функциями. Опять мимо.

>Тьфу ты, блин. Я сразу про посеты подумал.

Это зачем, чтобы в f(5,5) аргументы местами менять? Может в итоге и от модной системы типов практической пользы немногим больше?

aninamous
()
Ответ на: комментарий от aninamous

>Они определяются как функции нескольких аргументов. И частичное применение ничего не меняет в данном случае, f [a b] и f a b ( или как там правильно) являются разными функциями. Опять мимо.

Смотря, что ты хотел. Ну вот 3 варианта:

1) f a b -- функция от одного аргумента, возвращающая функцию от одного аргумента

2) f (a, b) -- функция от одного элемента (двумерного кортежа)

3) f [a, b] -- функция от одного элемента (списка)

Waterlaz ★★★★★
()
Ответ на: комментарий от tailgunner

> Образование вообще и математика в частности не имеют к этому отношения. Это особенность харктера или диагноз.

> P.S. нельзя ли вернуться к конструктивному флейму? А то рассуждения о высоких теоретических материях (типа является ли программирование математикой) навевают скуку.

Тут надо отметить, что

1. все-таки в математике есть такой момент, и при наличии у тебя неизвестного всему миру контрпримера ты и правда можешь существенно скорректировать мнение авторитетов о перспективном направлении исследования (но плевать на него -- это imho перебор)

2. CS (точнее Programming Language Design) в нектором смысле не математика, т.к. так (насколько мне известо) нет объективных (и соостветственно доказуемых как в математике) метрик качества языков программирования. И вероятно не будет. Так что все же авторитеты, холивары, etc.

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

> Иди поспорь с Benjamin C. Pierce. и заставь его переписать TAPL, альтернативно одаренный ты наш.

Кстати, никто бы не мог поделиться электронным вариантом? или в природе есть только книжный?

paranonymous
()
Ответ на: комментарий от www_linux_org_ru

> с неизвестным постоянным или с неизвестным переменным?

В общем случае с неизвестным переменным.

anonymous
()
Ответ на: комментарий от anonymous

> Почему я должен делать аннотации, если у меня нет никаких ошибок - компилятор умнее меня?

Хороший вопрос. И ответ на него должен быть не да/нет. В общем-то даже надо научить компилятор отвечать на этот вопрос.

Например, когда ты определяешь

f = g . h

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

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от paranonymous

> Кстати, никто бы не мог поделиться электронным вариантом? или в природе есть только книжный?

В диком виде замечена пиратская pdf-ка, кроме того, Алекс Отт перевел большой кусок на русский (и продолжает).

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

> Не смог странслировать 20 строк из хаскеля на с++

Дык никто не смог.

> и после этого с высокой колокольни плюешь на мнение специалистов CS.

Кто сказал "после"? Я на него всегда плевал. Меня аргументы интересуют, а мнения товарищи специалисты могут оставить при себе.

Miguel ★★★★★
()
Ответ на: комментарий от aninamous

> Они определяются как функции нескольких аргументов.

Может, ты ещё и определение скажешь?

> Это зачем, чтобы в f(5,5) аргументы местами менять?

При чём тут это?

Miguel ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> нет объективных (и соостветственно доказуемых как в математике) метрик качества языков программирования

Естественно. И вопросом "качества языков программирования" не занимается ни математика, ни входящая в неё CS. Зато вопросы, например, корректности алгоритмов проверки типов (это пример, первый пришедший в голову) - вопросы, где могут быть доказательства.

Miguel ★★★★★
()
Ответ на: комментарий от paranonymous

> Кстати, никто бы не мог поделиться электронным вариантом?

На гигапедии лежит. В CHM, кажется.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Математика понятия не имеет о мутабельном состоянии, фактически.
А всё контупер сайнс на нем фактически и строится. Так что, мимо.

anonymous
()
Ответ на: комментарий от Miguel

>> Не смог странслировать 20 строк из хаскеля на с++

> Дык никто не смог.

И *это* говорит математик? Не смешите мои тапочки.

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

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от anonymous

А, ну да, выразить любой алгоритм без мутабельного стейта - нельзя.
По определению, хотя бы.

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

anonymous
()
Ответ на: комментарий от Miguel

> И вопросом "качества языков программирования" не занимается ни математика, ни входящая в неё CS.

кхе-кхе...

ну а какая же отрасль знания занимается вопросом "качества языков программирования"?

и заодно -- как отрасль знания занимыается классификацией "язык со статической|динамической типизациией" ?

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от anonymous

>Математика понятия не имеет о мутабельном состоянии, фактически.

ну вот только что буквально читал определение императивного программирования со вводом как функтора некоторого вида, построенного из некоторого множества базовых функций (add, multiply, etc) с использованием операций, доступных в дистрибутивной категории. я, конечно, не специалист, но как по мне, так очень похоже на правду :)

>А всё контупер сайнс на нем фактически и строится

вообще-то где-то половина, и то не самая интересная. lambda the ultimate читать приходилось ведь? ultimate imperative и ultimate declarative? или это не CS?

jtootf ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>ну а какая же отрасль знания занимается вопросом "качества языков программирования"?

для того, чтобы решать задачу, её сначала надо сформулировать. ты можешь это сделать?

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

>трекстрочный "квиксорт", которым так любят хаскелоиды хвастаться перед сишниками

это неправильные хаскелоиды!

>выразить любой алгоритм без мутабельного стейта - нельзя

а любой и не нужно, вообще-то

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

> для того, чтобы решать задачу, её сначала надо сформулировать. ты можешь это сделать?

ну так по моему мнению темой данного флейма и являются критерии качества языков программирования (и некоторые тут уже сформулированы)

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

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

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

Понимаешь, _у меня там нет ошибок_. Если компилятор думает, что скорее всего у меня где-то ошибка - пусть выдаст варнинг с местом.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

> ну так по моему мнению темой данного флейма и являются критерии качества языков программирования (и некоторые тут уже сформулированы)

так я что ль один участвую во флейме статика вс динамика? :) Кстати, я забыл ответить тебе про метапрограммирование :(.

anonymous
()
Ответ на: комментарий от anonymous

> В общем случае с неизвестным переменным.

А можно ли заставить компилятор вывести неизвестное *постоянное* число?

т.е. как в С,

int a[] = { 5, 6, 7, 8 };

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

int a[4] = { 5, 6, 7, 8 };

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от jtootf

> ну вот только что буквально читал определение императивного программирования со вводом как функтора некоторого вида, построенного из некоторого множества базовых функций (add, multiply, etc) с использованием операций, доступных в дистрибутивной категории. я, конечно, не специалист, но как по мне, так очень похоже на правду :)

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

anonymous
()
Ответ на: комментарий от www_linux_org_ru

>ну так по моему мнению темой данного флейма и являются критерии качества языков программирования

не, я тут про математику только

>не нарушает ли язык программирования некий неявно подразумеваемый человеком критерий качества

ну тогда их надо формально определить для начала...

>и если нарушает -- то сформулировать его

...и каталогизировать. другое дело, что куда как проще считать то, что есть (возможности языка), а не то, чего нет (его недостатки). тем более, что первое, как правило, является прямой причиной второго: убрав недостатки ты испортишь достоинства и получишь очередной C++ :)

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

>Математика понятия не имеет о мутабельном состоянии, фактически.

Математика фактически, теоретически и практически прекрасно все знает о мутабельном состоянии... Определения в математике немутабельны (логично, да?) но это ведь совсем другое.

Waterlaz ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> А можно ли заставить компилятор вывести неизвестное *постоянное* число?

Честно говоря не знаю, завтра когда буду дома - посмотрю.

anonymous
()
Ответ на: комментарий от jtootf

> ну тогда их надо формально определить для начала...

ну есть такое понятие как readability - как его формализовать?

anonymous
()
Ответ на: комментарий от anonymous

> Понимаешь, _у меня там нет ошибок_. Если компилятор думает, что скорее всего у меня где-то ошибка - пусть выдаст варнинг с местом.

Не верю.

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

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от jtootf

> тем более, что первое, как правило, является прямой причиной второго: убрав недостатки ты испортишь достоинства и получишь очередной C++ :)

ерунда.

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от anonymous

>Так почему же просто не пользоваться "говеной императивщиной" напрямую, когда она нам действительно нужна?

ну так никто и не возражает, я так вообще исключительно за. просто всему своё место и время

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

>ну есть такое понятие как readability - как его формализовать?

понятия не имею. я бы не взялся

jtootf ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>ерунда.

нет, ну идея хорошая, я просто озвучиваю свой на неё взгляд :)

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

> ну есть такое понятие как readability - как его формализовать?

мы можем формализовать нарушения понятия readability

например: дублирование нарушает читабельность

1. std::pair<int,char*> x( 12, "asdf" ); // сhar* очевидно определяется из "asdf"

2. или вот из явы: LongClassName obj = new LongClassName(1,2,117);

да, в обоих случаях могут быть ситуации, когда дублирования нет, но тогда и читабельность не страдает:

InterfaceName obj = new LongClassName(1,2,117);

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

> Не верю.

Ты мне не веришь? :)

> Такое бывает очень редко.

Опять потребностей в колбасе нет :) У меня год может быть представлен как число или как строка. Я в зависимости от параметра возвращаю либо числовое представление, либо строковое.

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

Дык тапл он на то и тапл, чтобы разные типы хранить вместе.

ЗЫ. я знаю алгоритм Хиндли-Милнера и знаю почему там выдается именно ошибка, а не предупреждение.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

> например: дублирование нарушает читабельность

Паттерны программирования - это можно считать дублированием или даже мета-дублированием? :)

anonymous
()
Ответ на: комментарий от anonymous

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

это стоит считать неудачной шуткой. я не про твою фразу если что :)

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

> ну есть такое понятие как readability - как его формализовать?

мы можем формализовать нарушения понятия readability

еще:

for( int i=0; i<n; i++ ) { f(i); }

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

1 скачок: i<n ----> f(i)
2 скачок: f(i) ----> i++
3 скачок: i++ ----> i<n


int i=0; while(i<n) { f(i); i++; }

все ОК, т.к. поток выполнения совершает скачок ровно 1 раз, и меньше просто невозможно


www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

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

В функциональных и логических - как такового нет потока выполнения - они за гранью добра и зла?

anonymous
()
Ответ на: комментарий от anonymous

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

Вот еще один критерий качества:

*все* паттерны программирования должны быть выразимы в виде конструкций, в которые надо просто подставить аргументы (аргументами могут быть и куски кода, конечно)

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от anonymous

> В функциональных и логических - как такового нет потока выполнения - они за гранью добра и зла?

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

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

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

>В функциональных аргументы вычисляются до вычисления функции

это ещё с какой радости? ФП != аппликативный порядок вычислений

jtootf ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> В функциональных аргументы вычисляются до вычисления функции, так что поток таки есть.

А если у нас ленивые вычисления? Там аргументы не вычисляются :)

anonymous
()
Ответ на: комментарий от jtootf

>>В функциональных аргументы вычисляются до вычисления функции

>это ещё с какой радости? ФП != аппликативный порядок вычислений

я уже вместе с ненужными словами пропускаю нужные, смысл меняется...

В функциональных (используемые в вычислении значения) аргументы вычисляются до вычисления (значения) функции

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

>В функциональных (используемые в вычислении значения) аргументы вычисляются до вычисления (значения) функции

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

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

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

Зря я на эту тему вообще повелся.

У функциональных и логических ЯП будут свои варианты нечитабельности, и все.

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

>У функциональных и логических ЯП будут свои варианты нечитабельности, и все.

с такими определениями далеко не уйдёшь, сам понимаешь

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

> с такими определениями далеко не уйдёшь, сам понимаешь

кому надо, те пусть и каталогизируют нечитабельности ФЯП и ЛЯП.

А мне сейчас кажется, что вообще ленивый порядок вычисления -- одна сплошная нечитабельность. Я лично математическую функцию воспринимаю как функцию без побочных эффектов (да), но аргументы она вычисляет все, по-порядку и ровно 1 раз. Конечно, нужны еще побочные эффекти и функции (типа a?b:c) которые вычисляют не все аргументы, но тут читабельность заключается в том, что можно легко сказать, какие аргументы будут вычислены. А эмулировать такое ленивыми вычислениями -- это нечитабельность.

Да, это все надо аргументировать...

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

И даже для ЛЯП я подозреваю полезность потока управления.

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

> Конечно, нужны еще побочные эффекти и функции (типа a?b:c) которые вычисляют не все аргументы, но тут читабельность заключается в том, что можно легко сказать, какие аргументы будут вычислены.

уточню "легко":

например, функция and(arg1, ... argN) вычисляет не все свои аргументы, но мы точно должны знать, что существует такое К, что arg1 ... argK вычеслены, а argK+1 ... argN не вычислены

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

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

>я подозреваю полезность

вот на этом можно было бы и остановиться. ибо:

>Да, это все надо аргументировать...

jtootf ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.