Полез в исходники сабжа. Смотрю, например, файл gtk2hs-0.9.12.1\gtk\Graphics\UI\Gtk\Buttons\Button.chs.pp, есть декларация

module Graphics.UI.Gtk.Buttons.Button (
[...]
-- * Types
  Button,
  ButtonClass,
[...]

Где собственно сами описания типа и класса?

А полез я туда вот почему. В ООП языках, на сколько я понимаю, класс это некая структура данных, с которой "ассоциированы" некие процедуры (которые называются методами). Однако в Хаскеле класс — это класс типов Класс в Хаскеле не хранит никаких данных, он своего рода интерфейс, который определяет что можно делать с данными. А структура данных описывается отдельно от класса. При этом сами структуры данных не наследуются (???) друг от друга.

Т.е. система классов в ООП языках и Хаскеле устроены совсем по разному. И тут возник вопрос: каким образом gtk, на сколько я понимаю реализованный в традициях ООП, наложен поверх совсем не похожих классов Хаскелла???

Более практическая формулировка: как мне создать свой графический компонент, расширяющий класс Widget, а от моего компонента создать еще один класс-потомок и т.д.???

А>Т.е. система классов в ООП языках и Хаскеле устроены совсем по разному. И тут возник вопрос: каким образом gtk, на сколько я понимаю реализованный в традициях ООП, наложен поверх совсем не похожих классов Хаскелла???

В некотором роде, таким же образом как и наложен поверх Си, а именно: извращениями.

Здравствуйте, Аноним, Вы писали:

А>Т.е. система классов в ООП языках и Хаскеле устроены совсем по разному. И тут возник вопрос: каким образом gtk, на сколько я понимаю реализованный в традициях ООП, наложен поверх совсем не похожих классов Хаскелла???

В чисто процедурном стиле, как в Си (примерно)...

Здравствуйте, Аноним, Вы писали:

А>Т.е. система классов в ООП языках и Хаскеле устроены совсем по разному. И тут возник вопрос: каким образом gtk, на сколько я понимаю реализованный в традициях ООП, наложен поверх совсем не похожих классов Хаскелла???

он реализован скорей как раз в традициях type classes. afaik, классы gtk — это просто интерфейсы, никакого наследования данных (видимого пользователю) там нет

BZ>он реализован скорей как раз в традициях type classes. afaik, классы gtk — это просто интерфейсы, никакого наследования данных (видимого пользователю) там нет

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

Здравствуйте, Аноним, Вы писали:

BZ>>он реализован скорей как раз в традициях type classes. afaik, классы gtk — это просто интерфейсы, никакого наследования данных (видимого пользователю) там нет

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

сам бы хотел узнать в приницпе в хаскеле это делается так:

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

2. затем берёшь интерфейс, который тебе нужно реализовать, и объявляешь свой тип его инстанцией

очень условный пример, где мы создаём виджеты для отображения Int и Integer:

read_value :: (Show a) =>  IORef a -> IO String
read_value var = do val <- readIORef a
                    return (show val)
write_value .... - аналогично

instance Widget (IORef Int) where
  getValue = read_value 
  setValue = write_value

instance Widget (IORef Integer) where
  getValue = read_value 
  setValue = write_value

BZ>сам бы хотел узнать в приницпе в хаскеле это делается так:

Много читал, долго думал... Вобщем придумал как прикрутить ООП, и... получился полный ужос...

Сейчас смотрю в сторону Fudgets, кто-нибудь пробовал сие чудо? Как оно? Вожможно на нем писать крупные коммерческие приложения? Как там с повторным использованием кода?