К>Если можешь привнести ясность — буду благодарен.
три раза уже вносил для Влада
ладно. вот смотри. есть функция, печатающая значение, условно говоря, объекта. для этого она вызывает функцию, возвращающую строкове представление этого объекта:
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)
