Re[11]: ФП и абстракция списка
От: BulatZiganshin  
Дата: 06.06.07 13:23
Оценка: 111 (6)
К>Если можешь привнести ясность — буду благодарен.

три раза уже вносил для Влада

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

print x = putStrLn (show x)



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

1) в compile time подставить тело print в каждую точку вызова и выбрать нужную реализацию show в каждой точке вызова отдельно. т.е. compile-time polymorphism. он реализуется в C++ механизмом overload и темплейтами, которые готовы в любой момент сгенерировать код для нужной комбинации типов. ты, как я порнимаю, до сих пор полагал, что type classes устроены так же

2) сгенерить один-единственный type-independent code для print, и упаковать таблицу виртуальных функций (VMT) вместе с каждым объектом. это и есть ООП подход. когда print должна вызвать функию show — она лезет в VMT и берёт её адрес оттуда. таким образом, один-единственный откомпилированный экземпляр print может работать с любым объектом, реализующим этот интерфейс

3) также сгенерить один-единственный экземпляр print, но передавать информацию обо всех вызываемых полиморфных функиях в так назыавемом словаре класса — дополнительном невидимом аргументе. т.е. после дешугаринга этот вызов выглядит так:

print show x = putStrLn (show x)



если скажем, передаётся объект класса Number, реализующий 4 действия арифметики, то вызов после дешугаринга выглядит как:

double (+,-,*,/) x = x*2



как видишь, все функции класса просто идут в этом неявном аргументе. вот и всё. у этого подхода свои преимущества и недостатки, но главное для FP — что он в отличие от OO classes совместим с HM type inference. поскольку в OOP print может получить объект любого типа — всё определяется в run-time, и весь type inference на этом кончается. с type classes же такой проблемы не возникает. зато, с другой стороны, нельзя например делать полиморфные коллекции без дополнительных ухищрений (фактически эмулирующих VMT)
Люди, я люблю вас! Будьте бдительны!!!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.